Re: [Openstack-operators] Packaging sample config versions
On 12/14/2014 06:39 AM, George Shuklin wrote: Btw: we talking about debian packages or ubuntu? Debian, not Ubuntu. They are differ - debian heavily relies on answers to debconfig You mean debconf. And no, it doesn't rely on, it's completely optional, and the packages *must* be able to be installed in a non-interactive way (as per the Debian policy). and ubuntu just put files in proper places without changing configs. Ahem... Ubuntu simply doesn't care much about config files. See what they ship for Nova and Cinder. I wouldn't say without changing configs in this case. We using chef for configuration, so ubuntu approach is better It's not better or worse, it's exactly the same as for Debian, as the Debian package will *never* change something you modified in a config file, as per Debian policy (if they do, then it's a bug you shall report to the tracker). (when we starts doing openstack that was on of deciding factors between debian and ubuntu). Then you decided on the wrong grounds. On 12/14/2014 09:03 AM, George Shuklin wrote: Well, 'preseed' is just more work But it's completely optional. And also, the openstack-meta-packages source package provides all the facility for you (see the openstack-deploy package which contains the preseed lib). noninteractive dpkg - is much better. Then use: DEBIAN_FRONTEND=noninteractive apt-get install something and the Debian packages are all non-interactive as well. Anyway, I'm ready to help but have no idea how (within my limits). Do you have any experience building 3rd party CIs on OpenStack infra? Thomas Goirand (zigo) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Packaging sample config versions
On 12/13/14, 8:09 AM, Thomas Goirand z...@debian.org wrote: On 12/12/2014 02:17 AM, Kris G. Lindgren wrote: Why do you think it's a good idea to restart doing the work of distributions by yourself? Why not joining a common effort? Well for a lot of reasons. Some of us carry our own patch sets My employer (ie: Mirantis) also has its own patch set, however, we can only work together on community packages, so I don't really see your point here. - some of us want to run certain services on trunk. I also would like to have packages following trunk. One of the reason would be to do gating on trunk, working together with the infra team. I only lack time to build that CI for the moment, but it shouldn't be very hard to build. But mainly the bigger push is that if we come up with a standard set of openstack packages - then we can build a standard set of tooling around dealing/installing those packages. It'd be super nice if the standard would be what's in Debian. I am convinced that Debian is the correct place to make it happen, as it's not bound to any company or agenda. That¹s - great. But other people will want it to be based on RHEL - others Ubuntu, some people will want it on SLES. I understand debian makes your life easier, but at Paris is was already determined that a one size fits all approach wont work. Whatever is done needs to handle both deb packages and rpms. The point of this is that we are trying to build that common effort and not leave it up to the distro's to solve all the problems? How isn't what's happening in Debian not a common effort? It's all community based. I'm largely not interested in anything RPM based, so others could work on that part if they wish. I never said it wasn't - its just for *ME* what you are doing for debian packages has very little carry over to what I have to do for rpm packages. On 12/09/2014 11:23 AM, Fischer, Matt wrote: Not only is the sample config a useful reference, but having it in a git repo allows me to see when new options were added or defaults were changed. Yeah, though if you've been doing packages for a long time, you do have this information. At least, I do have it for all the last stable releases. Great - some of us also are busy actually running clouds here... I wasn't meaning that I know (hopefully, I'm not that pretending). But rather the Git knows or the Debian archive knows. In other words, the distribution has a history of all .conf.sample over time, which makes it possible to know. On 12/09/2014 12:01 PM, Kris G. Lindgren wrote: [...] sample config and replace it with some tox script. Which may or may not run on your current operating system without going to pip to get newer versions of stuff. Excuse my words, but that's bullshit. If your operating system doesn't have a version high enough for one of your build-dependency, then this should be fixed. It should be your work as a package maintainer. For example, if we need a newer version of tox (which is *not* the case, as tox isn't really needed for generating config files), then the tox package should be updated. It's as simple as that. And if you want this to happen, then I would strongly suggest you to get involved in Debian and/or Fedora packaging, because that's where things happen. I guess from my point of view - not providing a sample config file for your project is bullshit - unless said project can work without any config file at all (even then its still bullshit). Providing a script to do it - ok that¹s live-able. Providing documentation to use tox that installs all the projects deps into a venv then generates a script from those deps which don't match what on the system. That¹s bullshit as well. I shouldn't have used bullshit, I can see you took it badly. Sorry. That wasn't aimed to create a strong reaction. What I wanted to say was that the fact you can't run a specific command in your distribution because of an outdated Python module is wrong, simply because it's the work of a package maintainer to do updates if it's needed. And no, you don't need a venv. I use tox.ini files as a kind of packaging documentation, so I know what shell command to use, and everything else happens in debian/rules, with build-dependencies, not venv stuff. On 12/09/2014 12:01 PM, Kris G. Lindgren wrote: Let me give you an example. In most (if not *all* projects) you will find some [keystone:auth_token] section. These are directly derived from what's in python-keystoneclient. Indeed, the output .conf.sample file will depend on that... Now let's say the maintainers of python-keystoneclient would like to update something (let's say, update a comment on one of the directives, or simply a *new* directive), obviously, you want that change to propagate on all projects, but *only* if we have a new version of python-keystoneclient. I guess I can get that for staying on trunk. But when openstack does a stable release... Shouldn't the
[Openstack-operators] Help improve the OpenStack Horizon user portal!
You are invited to participate in an online card sort activity sponsored by the Horizon team. The purpose of this activity is to help us evaluate the current information architecture and find ways to improve it. We are specifically interested in individuals who use cloud services as a consumer (IaaS, PaaS, SaaS, etc). Activity Time: 15 minutes to complete the online activity by yourself – no scheduling required! Link to card sort: http://ows.io/os/0v46l867 **Participants will be automatically added to a drawing for one of three HP 7 G2 tablets.** Feel free to forward the link to anyone else who might be interested. College students are welcome to participate. As always, the results will be shared with the community. Thanks, Piet Kruithof Sr. UX Architect – HP Helion Cloud PS - This is a different from the usability study that was posted earlier. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] Heat in production?
Hi there, My name is Ari Rubenstein, and I'm new to the list. I've been researching Heat. I was wondering if anyone has direct experience or links to how customers are Heat orchestration in the real world. Use cases? Experiences? Best practices? Gotchas? I'm working with a customer on an Icehouse based cluster. They're wondering if Heat is ready for production or should be considered beta. I've heard good things about Heat, but the customer is cautious. Thanks in advance, - Ari ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Heat in production?
We (the TripleO developers) use Heat as part of TripleO to manage small (40 nodes) clouds for TripleO. This means that we're using Heat to manage our bare metal nodes which are in turn managed by nova+ironic. For the most part it is only used to bring up new nodes or change parameters (not something we do often). For that purpose, it works fine. Icehouse Heat lacks some really nice features that came out in Juno, not the least of which being that Juno's Heat can resume from failed operations where Icehouse cannot. Also, my employer, HP, is shipping Heat as part of the Helion distribution of OpenStack. I'm not certain if anybody is in full production using the Heat in Helion just yet, as it only recently released. I also know that Rackspace has been running some kind of Heat public beta/alpha/something for a while, so it might be worth asking them about their Heat. Excerpts from Ari Rubenstein's message of 2014-12-15 15:10:50 -0800: Hi there, My name is Ari Rubenstein, and I'm new to the list. I've been researching Heat. I was wondering if anyone has direct experience or links to how customers are Heat orchestration in the real world. Use cases? Experiences? Best practices? Gotchas? I'm working with a customer on an Icehouse based cluster. They're wondering if Heat is ready for production or should be considered beta. I've heard good things about Heat, but the customer is cautious. Thanks in advance, - Ari ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Packaging sample config versions
On 12/15/2014 10:49 AM, Thomas Goirand wrote: and ubuntu just put files in proper places without changing configs. Ahem... Ubuntu simply doesn't care much about config files. See what they ship for Nova and Cinder. I wouldn't say without changing configs in this case. We using chef for configuration, so ubuntu approach is better It's not better or worse, it's exactly the same as for Debian, as the Debian package will *never* change something you modified in a config file, as per Debian policy (if they do, then it's a bug you shall report to the tracker). Thank you. It's rather unexpected, but I'll take this in account for next installation. I'm not a big fan of ubuntu maintanance policy (they basically dropped it 2 month prior announced date), and I prefer use of debian where possible. Now I see it's ok with openstack too, and it's good. I think is some kind of implicit FUD, because I was absolutely sure that Canonical/RH packaging and Debian is far in the tail of the process. It is not true and I'm happy. Anyway, I'm ready to help but have no idea how (within my limits). Do you have any experience building 3rd party CIs on OpenStack infra? Nope. I've only done stuff with debian-jenkins-glue. But I have some experience on backporting patches from icehouse to havana (it still in production and still need fixes). I can research/fix something specific and local. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
