4 ms·

We have a similar problem when deploying Openstack using puppet - all the services need to be brought up after config that sets things like the central DB and A

by stonith 13y ago

We have a similar problem when deploying Openstack using puppet - all the services need to be brought up after config that sets things like the central DB and AMQP locations. It means that a deployed site will always have errors in their logs right from the start, which confuses customers and makes it harder to spot when there is actually an error in the deployment tool.

Patrick_Devine 13y ago
If you're using Ubuntu, the .deb packages need a lot of work. I've been playing around with this for the past week and there are all sorts of little glitches and gotchas. A big problem is that the package maintainers didn't use debconf, so you end up having to install, set some settings and then bring the service up. This is definitely not the debian/ubuntu way of doing things. If I find some time I'll see if I can repackage things to properly use debconf and push things upstream.
- Daviey 13y ago
  No, Ubuntu specifically made the choice to avoid debconf for Openstack packages. If you are using debconf interactively, it simply doesn't scale - if you are preseeding - or using juju, puppet or chef - what value does debconf add? Please don't assume that it is simply wrong, just because it doesn't do x or y. The debconf templates will always be trying to play catchup, and the transition of options between components doesn't make a lot of sense. It would be really good to know what issues you have identified, as we take quality very seriously in this area. However, your help with packaging will be most appreciated. Feel free to give me a shout on IRC, and we'll go through it.
  - Patrick_Devine 13y ago
    I'm not quite sure I'm parsing your sentence correctly. If you're preseeding with debconf the value is that you got to preseed the correct configuration options. This means the debs will work with anything, not just the flavour of the week devops tool. Juju, Puppet and Chef aren't the only games in town. I'll agree that they are all very useful tools, but you shouldn't need to write complex scripts/manifests/whatever around them to stand up services. That should happen out of the box without requiring anyone to jump through 50 hoops. It also means that you can scale from 1 instance all the way up to 5000 instances which is a lot better than optimizing for the 5000 instance case. I'll definitely give you a shout on IRC.

by stonith 13y ago

Patrick_Devine 13y ago

If you're using Ubuntu, the .deb packages need a lot of work. I've been playing around with this for the past week and there are all sorts of little glitches and gotchas. A big problem is that the package maintainers didn't use debconf, so you end up having to install, set some settings and then bring the service up. This is definitely not the debian/ubuntu way of doing things. If I find some time I'll see if I can repackage things to properly use debconf and push things upstream.

Daviey 13y ago
No, Ubuntu specifically made the choice to avoid debconf for Openstack packages. If you are using debconf interactively, it simply doesn't scale - if you are preseeding - or using juju, puppet or chef - what value does debconf add? Please don't assume that it is simply wrong, just because it doesn't do x or y. The debconf templates will always be trying to play catchup, and the transition of options between components doesn't make a lot of sense. It would be really good to know what issues you have identified, as we take quality very seriously in this area. However, your help with packaging will be most appreciated. Feel free to give me a shout on IRC, and we'll go through it.
- Patrick_Devine 13y ago
  I'm not quite sure I'm parsing your sentence correctly. If you're preseeding with debconf the value is that you got to preseed the correct configuration options. This means the debs will work with anything, not just the flavour of the week devops tool. Juju, Puppet and Chef aren't the only games in town. I'll agree that they are all very useful tools, but you shouldn't need to write complex scripts/manifests/whatever around them to stand up services. That should happen out of the box without requiring anyone to jump through 50 hoops. It also means that you can scale from 1 instance all the way up to 5000 instances which is a lot better than optimizing for the 5000 instance case. I'll definitely give you a shout on IRC.