Re: [openstack-dev] [tripleo] quickstart for humans
On 8/31/18 12:07 PM, Jiří Stránský wrote: [...] > * "for humans" definition differs significantly based on who you ask. > E.g. my intention with [2] was to readily expose *more* knobs and tweaks > and be more transparent with the underlying workings of Ansible, because > i felt like quickstart.sh hides too much from me. In my opinion [2] is > sufficiently "for humans", yet it does pretty much the opposite of what > you're looking for. Hey Jiri, I think that "for humans" means simply that you launch the command with just one parameter (i.e. the virthost), and then you have something. And because of this I think here is just a matter of concentrate the efforts to turn back quickstart.sh to its original scope: making you launch it with just one parameter and have an available environment after a while (OK, sometimes more than a while). Since part of the recent discussions were around the hypotheses of removing it, maybe we can think about make it useful again. Mostly because it is right that the needs of everyone are different, but on the other side with a solid starting point (the default) you can think about customizing depending on your needs. I'm for recycling what we have, planet (and me) will enjoy it! My 0,002 cents. -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] PTL non-candidacy
On 25/07/2018 15:23, Alex Schultz wrote: > Hey folks, > So it's been great fun and we've accomplished much over the last two > cycles but I believe it is time for me to step back and let someone > else do the PTLing. I'm not going anywhere so I'll still be around to > focus on the simplification and improvements that TripleO needs going > forward. I look forwards to continuing our efforts with everyone. > Thanks, > -Alex To me you did really a great job. I know you'll be around and so on, but let me just say thank you. -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Stein blueprint - Plan to remove Keepalived support (replaced by Pacemaker)
On 18/07/2018 22:36, Michele Baldessari wrote: [...] > Besides E), I think a reasonable use case is to be able to have a small > all-in-one installation that mimicks a more "real-world" overcloud. > I think there is a bit of value in that, as long as the code to make it > happen is not horribly huge and complex (and I was under the impression > from Emilien's patchset that this is not the case) [...] Small question aside related to all-in-one: we're talking about use cases in which we might want to go from 1 to 3 controllers, but how this can become a thing? I always thought to all-in-one as a developer/ci "tool", so why we should care about giving the possibility to expand? This question is related also to the main topic of this thread: it was proposed to replace Keepalived with anything (instead of Pacemaker), and one of the outcomes was that this approach would not guarantee some of the goals, like undercloud HA and keeping 1:1 structure between undercloud and overcloud. But what else are we supposed to control with Pacemaker on the undercloud apart from the IPs? -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Status of Standalone installer (aka All-In-One)
On 05/06/2018 02:26, Emilien Macchi wrote: [...] > I hope this update was useful, feel free to give feedback or ask any > questions, [...] I'm no prophet here, but I see a bright future for this approach. I can imagine how useful this can be on the testing and much more the learning side. Thanks for sharing! -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] The Weekly Owl - 13th Edition
On 20/03/2018 20:16, Emilien Macchi wrote: > On Tue, Mar 20, 2018 at 9:01 AM, Emilien Macchi <emil...@redhat.com > <mailto:emil...@redhat.com>> wrote: > +--> Matt is John and ruck is John. Please let them know any new CI > issue. > so I double checked and Matt isn't John but in fact he's the rover ;-) But Rover is Rover or not? -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][CI][QA][HA][Eris][LCOO] Validating HA on upstream
On 15/03/2018 01:57, Ghanshyam Mann wrote: > Thanks all for starting the collaboration on this which is long pending > things and we all want to have some start on this. > Myself and SamP talked about it during OPS meetup in Tokyo and we talked > about below draft plan- > - Update the Spec - https://review.openstack.org/#/c/443504/. which is > almost ready as per SamP and his team is working on that. > - Start the technical debate on tooling we can use/reuse like Yardstick > etc, which is more this mailing thread. > - Accept the new repo for Eris under QA and start at least something in > Rocky cycle. > I am in for having meeting on this which is really good idea. non-IRC > meeting is totally fine here. Do we have meeting place and time setup ? > -gmann Hi Ghanshyam, as I wrote earlier in the thread it's no problem for me to offer my bluejeans channel, let's sort out which timeslice can be good. I've added to the main etherpad [1] my timezone (line 53), let's do all that so that we can create the meeting invite. [1] https://etherpad.openstack.org/p/extreme-testing-contacts -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][CI][QA][HA][Eris][LCOO] Validating HA on upstream
On 08/03/2018 17:03, Adam Spiers wrote: [...] > Yes agreed again, this is a strong case for collaboration between the > self-healing and QA SIGs. In Dublin we also discussed the idea of the > self-healing and API SIGs collaborating on the related topic of health > check APIs. Guys, thanks a ton for your involvement in the topic, I am +1 to any kind of meeting we can have to discuss this (like it was proposed by Adam) so I'll offer my bluejeans channel for whatever kind of meeting we want to organize. About the best practices part Georg was mentioning I'm 100% in agreement, the testing methodologies are the first thing we need to care about, starting from what we want to achieve. That said, I'll keep studying Yardstick. Hope to hear from you soon, and thanks again! -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][CI][QA][HA] Validating HA on upstream
On 06/03/2018 13:27, Adam Spiers wrote: > Hi Raoul and all, > Sorry for joining this discussion late! [...] > I do not work on TripleO, but I'm part of the wider OpenStack > sub-communities which focus on HA[0] and more recently, > self-healing[1]. With that hat on, I'd like to suggest that maybe > it's possible to collaborate on this in a manner which is agnostic to > the deployment mechanism. There is an open spec on this> > https://review.openstack.org/#/c/443504/ > which was mentioned in the Denver PTG session on destructive testing > which you referenced[2]. [...] > https://www.opnfv.org/community/projects/yardstick [...] > Currently each sub-community and vendor seems to be reinventing HA > testing by itself to some extent, which is easier to accomplish in the > short-term, but obviously less efficient in the long-term. It would > be awesome if we could break these silos down and join efforts! :-) Hi Adam, First of all thanks for your detailed answer. Then let me be honest while saying that I didn't know yardstick. I need to start from scratch here to understand what this project is. In any case, the exact meaning of this thread is to involve people and have a more comprehensive look at what's around. The point here is that, as you can see from the tripleo-ha-utils spec [1] I've created, the project is meant for TripleO specifically. On one side this is a significant limitation, but on the other one, due to the pluggable nature of the project, I think that integrations with other software like you are proposing is not impossible. Feel free to add your comments to the review. In the meantime, I'll check yardstick to see which kind of bridge we can build to avoid reinventing the wheel. Thanks a lot again for your involvement, [1] https://review.openstack.org/#/c/548874/ -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][CI][QA] Validating HA on upstream
On 02/03/2018 15:19, Emilien Macchi wrote: > Talking with clarkb during PTG, we'll need to transform > tripleo-quickstart-utils into a non-forked repo - or move the roles to > an existing repo. But we can't continue to maintain this fork. > Raoul, let us know what you think is best (move repo to OpenStack or > move modules to an existing upstream repo). > Thanks, Hey Emilien, I prepared this [1] in which some folks started to have a look at, maybe it's what we need to move on on this. If you think something else needs to be done, let me know, I'll work on it. Thanks, [1] https://review.openstack.org/#/c/548874 -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][CI][QA] Validating HA on upstream
On 16/02/2018 15:41, Wesley Hayutin wrote: [...] > Using galaxy is an option however we would need to make sure that galaxy > is proxied across the upstream clouds. > Another option would be to follow the current established pattern of > adding it to the requirements file [1] > Thanks Bogdan, Raoul! > [1] > https://github.com/openstack/tripleo-quickstart/blob/master/quickstart-extras-requirements.txt This is how we're using it today into the internal pipelines, so once we will have the tripleo-ha-utils (or whatever it will be called) it will be just a matter of adding it into the file. In the end I think that once the project will be created either way of using it will be fine. Thanks for your involvement on this folks! -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][CI][QA] Validating HA on upstream
On 16/02/2018 10:24, Bogdan Dobrelya wrote: [...] > +1 this looks like a perfect fit. Would it be possible to install that > tripleo-ha-utils/tripleo-quickstart-utils with ansible-galaxy, alongside > the quickstart, then apply destructive-testing playbooks with either the > quickstart's static inventory [0] (from your admin/control node) or > maybe via dynamic inventory [1] (from undercloud managing the overcloud > under test via config-download and/or external ansible deployment > mechanisms)? > [0] > https://git.openstack.org/cgit/openstack/tripleo-quickstart/tree/roles/tripleo-inventory > [1] > https://git.openstack.org/cgit/openstack/tripleo-validations/tree/scripts/tripleo-ansible-inventory Hi Bogdan, thanks for your answer. On the inventory side of things these playbooks work on any kind of inventory, we're using it at the moment with both manual and quickstart generated environments, or even infrared ones. We're able to do it at the same time the environment gets deployed or in a second time like a day two action. What is not clear to me is the ansible-galaxy part you're mentioning, today we rely on the github.com/redhat-openstack git repo, so we clone it and then launch the playbooks via ansible-playbook command, how do you see ansible-galaxy into the picture? Thanks! -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO][CI] Validating HA on upstream
TL;DR: we would like to change the way HA is tested upstream to avoid being hitten by evitable bugs that the CI process should discover. Long version: Today HA testing in upstream consist only in verifying that a three controllers setup comes up correctly and can spawn an instance. That's something, but it’s far from being enough since we continuously see "day two" bugs. We started covering this more than a year ago in internal CI and today also on rdocloud using a project named tripleo-quickstart-utils [1]. Apart from his name, the project is not limited to tripleo-quickstart, it covers three principal roles: 1 - stonith-config: a playbook that can be used to automate the creation of fencing devices in the overcloud; 2 - instance-ha: a playbook that automates the seventeen manual steps needed to configure instance HA in the overcloud, test them via rally and verify that instance HA works; 3 - validate-ha: a playbook that runs a series of disruptive actions in the overcloud and verifies it always behaves correctly by deploying a heat-template that involves all the overcloud components; To make this usable upstream, we need to understand where to put this code. Here some choices: 1 - tripleo-validations: the most logical place to put this, at least looking at the name, would be tripleo-validations. I've talked with some of the folks working on it, and it came out that the meaning of tripleo-validations project is not doing disruptive tests. Integrating this stuff would be out of scope. 2 - tripleo-quickstart-extras: apart from the fact that this is not something meant just for quickstart (the project supports infrared and "plain" environments as well) even if we initially started there, in the end, it came out that nobody was looking at the patches since nobody was able to verify them. The result was a series of reviews stuck forever. So moving back to extras would be a step backward. 3 - Dedicated project (tripleo-ha-utils or just tripleo-utils): like for tripleo-upgrades or tripleo-validations it would be perfect having all this grouped and usable as a standalone thing. Any integration is possible inside the playbook for whatever kind of test. Today we're using the bash framework to interact with the cluster, rally to test instance-ha and Ansible itself to simulate full power outage scenarios. There's been a lot of talk about this during the last PTG [2], and unfortunately, I'll not be part of the next one, but I would like to see things moving on this side. Everything I wrote is of course up to discussion, that's precisely the meaning of this mail. Thanks to all who'll give advice, suggestions, and thoughts about all this stuff. [1] https://github.com/redhat-openstack/tripleo-quickstart-utils [2] https://etherpad.openstack.org/p/qa-queens-ptg-destructive-testing -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo][containerized][osp12] Unable to deploy containerised overcloud
On 10/26/2017 10:17 AM, Pranav Sarwate wrote: > How do I debug this further? What logs can I look at? Also, it would be > great if someone can validate that we are using the correct reference link. Hi Pranav, I can't help you about the validation, but I bet the error at that stage means that you've problems while getting container images from the repo you configured. Of course having the logs from the controller will help a lot (check for status_code != 0 in /var/lib/heat-config/deployed directory). Bye, -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Future of the tripleo-quickstart-utils project
On 13/06/2017 21:14, Emilien Macchi wrote: [...]>> Moving this stuff in the tripleo-validations project would impose a >> massive change in the approach HA validation is made today. >> The bash script way is something that was used to make someone able to >> do the validation even without ansible. Anyone could write his test by >> just adding the script inside the test (and recovery) dir. >> This is the tech reason behind the choice, and today this is doing great >> as it is. >> So I think that until I can reserve a slot to make this "port" this can >> stay where it is today. > It's unclear to me if yes or no you're willing to move this bash > script into tripleo-validations. Mine it's basically a yes, I just need to figure out a coherent migration path. I don't see this as a thing I can do one day to another, but I'll start working on it. [...]>> Since we're moving into integrating stonith and (hopefully) instance HA >> directly inside tripleo, then this can stay where it is today, it would >> be useless giving effort in putting this since soon we will have the >> same directly inside tripleo. > Ok, so forget this one if the problem is solved within TripleO. Yes, this seems reasonable. [...] >>> I would suggest to move it to tripleo-docs, so we have a single place for >>> doc. >> Action item for me here: move this document under tripleo-docs. I'm >> already preparing a review for this. So I finally updated a review [1] for the documentation, it took quite a bit to adapt it to the audience of the tripleo-docs project, but it now seems fine... at least to me :) [1] https://review.openstack.org/#/c/474225/ Many thanks for your time Emilien. -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Future of the tripleo-quickstart-utils project
On 17/05/2017 10:47, Bogdan Dobrelya wrote: [...]> It is amusing a little bit as it looks a controversial to the > "Validations before upgrades and updates" effort. Shall we just move the > tripleo-quickstart-utils back to extras, or to validations repo and have > both issues solved? :) The reason why this was put outside extras was that basically no one was looking at the reviews, since the topic was so specific that no one had the opportunity to test the modifications on the field. So we decided to move it outside, to be quick and independent on the reviews. [...] > A side note, this peculiar way to use ansible is a deliberate move for > automatic documenting of reproducing steps. So those jinja templated > scripts could be as well used aside of the ansible playbooks. It looked > odd to me as well, but I tend to agree that is an interesting solution > for automagic documentation builds. I need to understand in depth this automatic documenting you're writing about. Can you give some tip to fully comprehend what you wrote? Many thanks, and sorry for the long delay between the answers. -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Future of the tripleo-quickstart-utils project
On 17/05/2017 04:01, Emilien Macchi wrote: > Hey Raoul, > Thanks for putting this up in the ML. Replying inline: Sorry for the long delay between the answers, a lot of things on going. [...] > I've looked at > https://github.com/redhat-openstack/tripleo-quickstart-utils/blob/master/roles/validate-ha/tasks/main.yml > and I see it's basically a set of tasks that validates that HA is > working well on the overcloud. > Despite little things that might be adjusted (calling bash scripts > from Ansible), I think this role would be a good fit with > tripleo-validations projects, which is "a collection of Ansible > playbooks to detect and report potential issues during TripleO > deployments". Moving this stuff in the tripleo-validations project would impose a massive change in the approach HA validation is made today. The bash script way is something that was used to make someone able to do the validation even without ansible. Anyone could write his test by just adding the script inside the test (and recovery) dir. This is the tech reason behind the choice, and today this is doing great as it is. So I think that until I can reserve a slot to make this "port" this can stay where it is today. >> 2 - stonith-config: to configure STONITH inside an HA env; [...]> Great, it means we could easily re-use the bits, modulo some technical > adjustments. Since we're moving into integrating stonith and (hopefully) instance HA directly inside tripleo, then this can stay where it is today, it would be useless giving effort in putting this since soon we will have the same directly inside tripleo. >> There's also a docs related to the Multi Virtual Undercloud project [4] >> that explains how to have more than one virtual Undercloud on a physical >> machine to manage more environments from the same place. > I would suggest to move it to tripleo-docs, so we have a single place for doc. Action item for me here: move this document under tripleo-docs. I'm already preparing a review for this. [...] > IIRC, everything in this repo could be moved to existing projects in > TripleO that are already productized, so little efforts would be done. [...]> Thanks for bringing this up! Agreed. Bye, -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Future of the tripleo-quickstart-utils project
Hi everybody, as discussed in today's TripleO meeting [1] here's a brief recap of the tripleo-quickstart-utils topic. ### TL;DR ### We are trying to understand whether is good or not to put the contents of [2] somewhere else for a wider exposure. ### Long version ### tripleo-quickstart-utils project started after splitting the ha-validation stuff from the tripleo-quickstart-extras repo [3], basically because the specificity of the topic was creating a leak of reviewers. Today this repository have three roles: 1 - validate-ha: to do ha specific tests depending on the version. This role relies on a micro bash framework named ha-test-suite available in the same repo, under the utils directory; 2 - stonith-config: to configure STONITH inside an HA env; 3 - instance-ha: to configure high availability for instances on the compute nodes; Despite of the name, this is not just a tripleo-quickstart related project, it is also usable on every TripleO deployed environment, and is meant to support all the TripleO OpenStack versions from kilo to pike for all the roles it sells; There's also a docs related to the Multi Virtual Undercloud project [4] that explains how to have more than one virtual Undercloud on a physical machine to manage more environments from the same place. That's basically the meaning of the word "utils" in the name of the repo. What I would like to understand is if you see this as something useful that can be placed somewhere more near to upstream TripleO project, to reach a wider audience for further contribution/evolution. ### [1] http://eavesdrop.openstack.org/meetings/tripleo/2017/tripleo.2017-05-16-14.00.log.html [2] https://github.com/redhat-openstack/tripleo-quickstart-utils [3] https://github.com/openstack/tripleo-quickstart-extras/tree/master/roles/validate-ha [4] https://github.com/redhat-openstack/tripleo-quickstart-utils/tree/master/docs/multi-virtual-undercloud ### Thanks for your time, -- Raoul Scarazzini ra...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo][tripleo-quickstart] Multiple parallel deployments on a single virthost
Hi Lars, trying to the same result, I documented this process [1] named "TripleO Quickstart Multi-virtual Undercloud" (if you can't access the doc please ask and I'll enable you). The base principle is the same, but I need just one patch on oooq, I actually manage up to 5 different overcloud from the same virthost. What is different is that I use 5 different undercloud vms. But this keep things clean and separated, with the same isolation grade you aim. Hope this can be somehow useful. [1] https://docs.google.com/presentation/d/1v2zqrNn2qWtfpRzkJRGbZJ2LXTostaX-O8-gQ6jaPnI/edit#slide=id.p -- Raoul Scarazzini ra...@redhat.com On 04/03/2017 05:52, Lars Kellogg-Stedman wrote: > I've just submitted a slew of changes to tripleo-quickstart with the > ultimate goal of being able to spin up multiple openstack deployments > in parallel on the same target virthost. > > The meat of the change is an attempt to clearly separate the virthost > from the undercloud; we had several tasks that worked only because the > user name (and working directory) happened to be the same in both > environments. > > With these changes in place, I am able to rapidly deploy multiple > tripleo-deployments on a single virthost, each one isolated to a > particular user account. I'm using a playbook that includes > just the libvirt/setup, undercloud-deploy, and overlcoud-* roles. > This is extremely convenient for some of the work that I'm doing now. > > This does require some pre-configuration on the virthost (each user > gets their own overcloud bridge) and in the quickstart (each user gets > their own underlcoud_external_network_cidr). > > - https://review.openstack.org/441559 modify basic test to not require > quickstart-extras > - https://review.openstack.org/441560 use a non-default virthost_user for the > basic test > - https://review.openstack.org/441561 restore support for multiple > deployments on virthost > - https://review.openstack.org/441562 improve generated ssh configuration > - https://review.openstack.org/441563 derive overcloud_public_vip and > overcloud_public_vip6 > - https://review.openstack.org/441564 yaml cleanup and formatting > - https://review.openstack.org/441565 don't make ssh_config files executable > - https://review.openstack.org/441566 restrict bashate to files in repository > - https://review.openstack.org/441567 restrict pep8 to files in repository > - https://review.openstack.org/441568 fix ansible-lint error ANSIBLE0012 > - https://review.openstack.org/439133 define non_root_group explicitly > > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
