I'm almost out of the RDO/OpenStack CLI cheatsheet bookmarks, and I was
hoping that before we do another run of them, I could get a few eyes on
them to be sure that what we are printing is still correct (it's been
over a year since it was updated) and covers the most useful things.
We have very limited space, of course, so deciding what's most important
can be difficult.
I would appreciate any suggested edits and/or pull requests.
Rich Bowen - rbowen(a)redhat.com
OpenStack Community Liaison
What, exactly I mean, how to update ha.yml to setup neutron router on PCS cluster
to be HA and distributed at a time and run Compute Node(s) (<=2 ) in DVR mode ?
In general , Mitaka would allow this configuration.
On Fri, Jun 10, 2016 at 1:14 PM, Marcin Juszkiewicz
> There were discussions on irc about it but I lost track of who I should
> speak with etc so decided to write to mailing list instead.
> The goal is to rebuild OpenStack 'mitaka' packages for AArch64 (AltArch) in
> CBS (there is one builder for this architecture).
> Question is how to make it in best way?
> One of ideas was:
> 1. create new tag (cloud7-openstack-mitaka-candidate-aarch64?)
> 2. import all 'noarch' builds from cloud7-openstack-mitaka-* tags
> 3. send all required packages to the builder
> 4. test resulting packages
> 5. import/merge all of them to proper cloud7-openstack-mitaka-* tag
> Other was about doing scratch builds and merging them with x86-64 ones.
> How we can proceed? I think that first idea is good as it allows us to do
> builds without touching x86-64 tag before we are ready for merging. But I do
> not have koji experience so may be wrong.
New tag is the way to go, we don't want to block x86_64.
After some discussions about the way Packstack was (mis)using Puppet, and how to improve it, I've been working on a refactor. Its current state is available at https://github.com/javierpena/packstack/tree/feature/manifest_refactor, and as soon as it is polished it will go to Gerrit. It basically tries to reduce the number of Puppet executions to one per server role (controller, network node, compute), instead of multiple individual runs.
While talking about the refactor, a second discussion about a deeper change was started. I'd like to summarize the current concerns and ideas in this mail, so we can follow-up and make a decision:
- Currently, the Packstack CI is only testing single-node installs. Testing multi-node installs upstream has been challenging, and multi-node may go beyond the PoC target of Packstack. So, one proposal is to keep all-in-one single node only, add Ansible wrapper (in unsupported contrib/ subfolder) reading *_HOSTS parameters for backward compat.
- Another idea was to refactor the Packstack Python part around Ansible, summarized at https://etherpad.openstack.org/p/packstack-refactor-take2 . This proposal aims at keeping multi-node support, since Ansible makes it easy anyway.
Any other ideas/concerns? Pros and cons of each?
----- Original Message -----
> From: "Alan Pevec" <apevec(a)redhat.com>
> To: "Ivan Chavero" <ichavero(a)redhat.com>
> Cc: "rdo-list" <rdo-list(a)redhat.com>
> Sent: Wednesday, June 8, 2016 5:48:07 PM
> Subject: Re: [rdo-list] Packstack refactor and future ideas
> > I don't agree with this, we can set the untested features as "experimental"
> or "unsupported"
> Best is to remove them to make that clear, because no matter what
> deprecation warnings you put[*] people will keep using features until
> they're gone, giving us bug reports to take care of and without CI to
> verify fixes.
> It's long-term maintenance burden I am concerned about, for features
> which are clearly out of scope.
I understand this, my concern is that if we remove this feature we will leave
users with no tool for doing multinode in a lightweight way and this might
drive off users from testing/adopting RDO.
I'm willing to create CI tests for multinode Packstack in order to maintain
And believe me it would be easier for me just to drop this features but i really
think users are benefiting from this features.