Re: [openstack-dev] [tripleo-ansible] Future plans
Hi Martin,On Mon, 2018-09-03 at 21:16 +0200, Martin Magr wrote: > Gretings, > > since I did not find any blueprint regarding proper usage of > tripleo-ansible, I would like to ask how exactly we plan to use > tripleo-ansible project, what should be the proper structure of > roles/playbooks, etc. Given the discussion in [1] it is the best place > for backup and restore playbooks and I'd like to start preparing > patches for B Currently the development being done in [2], but I > hope that is only temporary location. I've added the backup task example to the ansible roles blueprint[0]. Generally you'll want to add your tasks, variables, role-specific handlers, etc to the appropriate ansible role repo (in this case ansible-role-openstack-operations) and the playbooks for using those role tasks to the tripleo-ansible project repo. TripleO-specific shared handlers/libraries/etc - things your playbooks will use that are not specific to one single role - would also go in the tripleo-ansible repo. [0] https://blueprints.launchpad.net/tripleo/+spec/ansible-tasks-to-role > > Thanks in advance for answers, > Martin > > [1] https://review.openstack.org/#/c/582453/ > [2] https://github.com/centos-opstools/os-backup-ansible > > -- > Martin Mágr > Senior Software Engineer > Red Hat Czech > __ > > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubsc > ribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: This is a digitally signed message part __ 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] ansible roles in tripleo
On Thu, 2018-08-23 at 10:42 -0400, Dan Prince wrote: > On Tue, Aug 14, 2018 at 1:53 PM Jill Rouleau wrote: > > > > > > Hey folks, > > > > Like Alex mentioned[0] earlier, we've created a bunch of ansible > > roles > > for tripleo specific bits. The idea is to start putting some basic > > cookiecutter type things in them to get things started, then move > > some > > low-hanging fruit out of tripleo-heat-templates and into the > > appropriate > > roles. For example, docker/services/keystone.yaml could have > > upgrade_tasks and fast_forward_upgrade_tasks moved into ansible- > > role- > > tripleo-keystone/tasks/(upgrade.yml|fast_forward_upgrade.yml), and > > the > > t-h-t updated to > > include_role: ansible-role-tripleo-keystone > > tasks_from: upgrade.yml > > without having to modify any puppet or heat directives. > > > > This would let us define some patterns for implementing these > > tripleo > > roles during Stein while looking at how we can make use of ansible > > for > > things like core config. > I like the idea of consolidating the Ansible stuff and getting out of > the practice of inlining it into t-h-t. Especially the "core config" > which I take to mean moving away from Puppet and towards Ansible for > service level configuration. But presumably we are going to rely on > the upstream Openstack ansible-os_* projects to do the heavy config > lifting for us here though right? We won't have to do much on our side > to leverage that I hope other than translating old hiera to equivalent > settings for the config files to ensure some backwards comparability. > We'll hopefully be able to rely on the OSA roles for a lot of the config, yes, but there will still be a fair bit of TripleO specific stuff that will need to be handled, and that's what we plan to do in these ansible-role-tripleo-* repos. > While I agree with the goals I do wonder if the shear number of git > repos we've created here is needed. Like with puppet-tripleo we were > able to combine a set of "small lightweight" manifests in a way to > wrap them around the upstream Puppet modules. Why not do the same with > ansible-role-tripleo? My concern is that we've created so many cookie > cutter repos with boilerplate code in them that ends up being much > heavier than the files which will actually reside in many of these > repos. This in addition to the extra review work and RPM packages we > need to constantly maintain. > In theory it should be roughly the same amount of commits/review work, just a question of what repo they go to - service specific patches go to the appropriate role and shared plugins, libs, etc go to the tripleo- ansible project repo. We want the roles to be modular rather than monolithic so only the roles that are being used in a given environment need to be pulled in. Also by having them separated, they should be easier to parse and contribute to. Yes it's a higher number of repos that could be contributed to, but when doing so a person won't have to mentally frontload how all of the possible things work just to be able to add an upgrade task for service $foo like it is today with t-h-t. Unless there's a different breakdown/layout you're thinking of beyond "dump everything in one place"? I'm interested in other options if we have some to reduce packaging or maintenance overhead. With other deployers I've done stable branches checked out straight from git, but I doubt that would fly for downstream. We could push the roles to Ansible Galaxy but we would need to think about how that would work for offline deploys and they still need to be maintained there, it's just painting the problem a different color. - Jill > Dan > > > > > > > t-h-t and config-download will still drive the vast majority of > > playbook > > creation for now, but for new playbooks (such as for operations > > tasks) > > tripleo-ansible[1] would be our project directory. > > > > So in addition to the larger conversation about how deployers can > > start > > to standardize how we're all using ansible, I'd like to also have a > > tripleo-specific conversation at PTG on how we can break out some of > > our > > ansible that's currently embedded in t-h-t into more modular and > > flexible roles. > > > > Cheers, > > Jill > > > > [0] http://lists.openstack.org/pipermail/openstack-dev/2018-August/1 > > 3311 > > 9.html > > [1] https://git.openstack.org/cgit/openstack/tripleo-ansible/tree/__ > > > > > > OpenStack Development Mailing List (not for usage questions) &
Re: [openstack-dev] [tripleo] ansible roles in tripleo
On Wed, 2018-08-15 at 13:08 -0600, Alex Schultz wrote: > On Tue, Aug 14, 2018 at 11:51 AM, Jill Rouleau > wrote: > > > > Hey folks, > > > > Like Alex mentioned[0] earlier, we've created a bunch of ansible > > roles > > for tripleo specific bits. The idea is to start putting some basic > > cookiecutter type things in them to get things started, then move > > some > > low-hanging fruit out of tripleo-heat-templates and into the > > appropriate > > roles. For example, docker/services/keystone.yaml could have > > upgrade_tasks and fast_forward_upgrade_tasks moved into ansible- > > role- > > tripleo-keystone/tasks/(upgrade.yml|fast_forward_upgrade.yml), and > > the > > t-h-t updated to > > include_role: ansible-role-tripleo-keystone > > tasks_from: upgrade.yml > > without having to modify any puppet or heat directives. > > > Do we have any examples of what the upgrade.yml would be or what type > of variables (naming conventions or otherwise) which would need to be > handled as part of this transtion? I assume we may want to continue > passing in some variable to indicate the current deployment step. Is > there something along these lines that we will be proposing or need to > handle? We're already doing something similar with the > host_prep_tasks for the docker registry[0] but we have a set_fact > block to pass parameters in. I'm assuming we'll need to define > something similar. The task file would look very much like the task as it exists in t-h-t today. For example if we took the FFU task out of docker/services.keystone.yaml and write that to ansible-role-tripleo- keystone/tasks/fast_forward_upgrade.yml, and update any necessary vars (like steps) to be role vars, like tripleo_keystone_step. Then docker/services.keystone.yaml could be updated like: fast_forward_upgrade_tasks: include_role: name: ansible-role-tripleo-keystone tasks_from: fast_forward_upgrade vars: tripleo_keystone_step: step|int - Jill > > Thanks, > -Alex > > [0] http://git.openstack.org/cgit/openstack/tripleo-heat-templates/tre > e/puppet/services/docker-registry.yaml#n54 > > > > > This would let us define some patterns for implementing these > > tripleo > > roles during Stein while looking at how we can make use of ansible > > for > > things like core config. > > > > t-h-t and config-download will still drive the vast majority of > > playbook > > creation for now, but for new playbooks (such as for operations > > tasks) > > tripleo-ansible[1] would be our project directory. > > > > So in addition to the larger conversation about how deployers can > > start > > to standardize how we're all using ansible, I'd like to also have a > > tripleo-specific conversation at PTG on how we can break out some of > > our > > ansible that's currently embedded in t-h-t into more modular and > > flexible roles. > > > > Cheers, > > Jill > > > > [0] http://lists.openstack.org/pipermail/openstack-dev/2018-August/1 > > 3311 > > 9.html > > [1] https://git.openstack.org/cgit/openstack/tripleo-ansible/tree/ > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsub > > scribe > > 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:unsubsc > ribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: This is a digitally signed message part __ 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] ansible roles in tripleo
Hey folks, Like Alex mentioned[0] earlier, we've created a bunch of ansible roles for tripleo specific bits. The idea is to start putting some basic cookiecutter type things in them to get things started, then move some low-hanging fruit out of tripleo-heat-templates and into the appropriate roles. For example, docker/services/keystone.yaml could have upgrade_tasks and fast_forward_upgrade_tasks moved into ansible-role- tripleo-keystone/tasks/(upgrade.yml|fast_forward_upgrade.yml), and the t-h-t updated to include_role: ansible-role-tripleo-keystone tasks_from: upgrade.yml without having to modify any puppet or heat directives. This would let us define some patterns for implementing these tripleo roles during Stein while looking at how we can make use of ansible for things like core config. t-h-t and config-download will still drive the vast majority of playbook creation for now, but for new playbooks (such as for operations tasks) tripleo-ansible[1] would be our project directory. So in addition to the larger conversation about how deployers can start to standardize how we're all using ansible, I'd like to also have a tripleo-specific conversation at PTG on how we can break out some of our ansible that's currently embedded in t-h-t into more modular and flexible roles. Cheers, Jill [0] http://lists.openstack.org/pipermail/openstack-dev/2018-August/13311 9.html [1] https://git.openstack.org/cgit/openstack/tripleo-ansible/tree/ signature.asc Description: This is a digitally signed message part __ 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 - 25th Edition
On Thu, 2018-08-02 at 13:30 -0400, Pradeep Kilambi wrote: > > > On Wed, Aug 1, 2018 at 6:06 PM Jill Rouleau wrote: > > On Tue, 2018-07-31 at 07:38 -0400, Pradeep Kilambi wrote: > > > > > > > > > On Mon, Jul 30, 2018 at 2:17 PM Jill Rouleau > > wrote: > > > > On Mon, 2018-07-30 at 11:35 -0400, Pradeep Kilambi wrote: > > > > > > > > > > > > > > > On Mon, Jul 30, 2018 at 10:42 AM Alex Schultz > .com > > > > > > > > > > wrote: > > > > > > On Mon, Jul 30, 2018 at 8:32 AM, Martin Magr > om> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > On Tue, Jul 17, 2018 at 6:12 PM, Emilien Macchi > edha > > > > t.co > > > > > > m> wrote: > > > > > > >> > > > > > > >> Your fellow reporter took a break from writing, but is > > now > > > > back > > > > > > on his > > > > > > >> pen. > > > > > > >> > > > > > > >> Welcome to the twenty-fifth edition of a weekly update in > > > > TripleO > > > > > > world! > > > > > > >> The goal is to provide a short reading (less than 5 > > minutes) > > > > to > > > > > > learn > > > > > > >> what's new this week. > > > > > > >> Any contributions and feedback are welcome. > > > > > > >> Link to the previous version: > > > > > > >> http://lists.openstack.org/pipermail/openstack-dev/2018-J > > une/ > > > > 1314 > > > > > > 26.html > > > > > > >> > > > > > > >> +-+ > > > > > > >> | General announcements | > > > > > > >> +-+ > > > > > > >> > > > > > > >> +--> Rocky Milestone 3 is next week. After, any feature > > code > > > > will > > > > > > require > > > > > > >> Feature Freeze Exception (FFE), asked on the mailing- > > list. > > > > We'll > > > > > > enter a > > > > > > >> bug-fix only and stabilization period, until we can push > > the > > > > > > first stable > > > > > > >> version of Rocky. > > > > > > > > > > > > > > > > > > > > > Hey guys, > > > > > > > > > > > > > > I would like to ask for FFE for backup and restore, > > where we > > > > > > ended up > > > > > > > deciding where is the best place for the code base for > > this > > > > > > project (please > > > > > > > see [1] for details). We believe that B support for > > > > overcloud > > > > > > control > > > > > > > plane will be good addition to a rocky release, but we > > started > > > > > > with this > > > > > > > initiative quite late indeed. The final result should the > > > > support > > > > > > in > > > > > > > openstack client, where "openstack overcloud > > (backup|restore)" > > > > > > would work as > > > > > > > a charm. Thanks in advance for considering this feature. > > > > > > > > > > > > > > > > > > > Was there a blueprint/spec for this effort? Additionally do > > we > > > > have > > > > > > a > > > > > > list of the outstanding work required for this? If it's just > > > > these > > > > > > two > > > > > > playbooks, it might be ok for an FFE. But if there's > > additional > > > > > > tripleoclient related changes, I wouldn't necessarily feel > > > > > > comfortable > > > > > > with these unless we have a complete list of work. Just as > > a > > > > side > > > > > > note, I'm not sure putting these in tripleo-common is going > > to > > > > be > > > > > > the > > > > > > ideal place for this. > > > > > > > > Was it this review? https://review.openstack.
Re: [openstack-dev] [tripleo] The Weekly Owl - 25th Edition
On Tue, 2018-07-31 at 07:38 -0400, Pradeep Kilambi wrote: > > > On Mon, Jul 30, 2018 at 2:17 PM Jill Rouleau wrote: > > On Mon, 2018-07-30 at 11:35 -0400, Pradeep Kilambi wrote: > > > > > > > > > On Mon, Jul 30, 2018 at 10:42 AM Alex Schultz > > > > > wrote: > > > > On Mon, Jul 30, 2018 at 8:32 AM, Martin Magr > > > > wrote: > > > > > > > > > > > > > > > On Tue, Jul 17, 2018 at 6:12 PM, Emilien Macchi > t.co > > > > m> wrote: > > > > >> > > > > >> Your fellow reporter took a break from writing, but is now > > back > > > > on his > > > > >> pen. > > > > >> > > > > >> Welcome to the twenty-fifth edition of a weekly update in > > TripleO > > > > world! > > > > >> The goal is to provide a short reading (less than 5 minutes) > > to > > > > learn > > > > >> what's new this week. > > > > >> Any contributions and feedback are welcome. > > > > >> Link to the previous version: > > > > >> http://lists.openstack.org/pipermail/openstack-dev/2018-June/ > > 1314 > > > > 26.html > > > > >> > > > > >> +-+ > > > > >> | General announcements | > > > > >> +-+ > > > > >> > > > > >> +--> Rocky Milestone 3 is next week. After, any feature code > > will > > > > require > > > > >> Feature Freeze Exception (FFE), asked on the mailing-list. > > We'll > > > > enter a > > > > >> bug-fix only and stabilization period, until we can push the > > > > first stable > > > > >> version of Rocky. > > > > > > > > > > > > > > > Hey guys, > > > > > > > > > > I would like to ask for FFE for backup and restore, where we > > > > ended up > > > > > deciding where is the best place for the code base for this > > > > project (please > > > > > see [1] for details). We believe that B support for > > overcloud > > > > control > > > > > plane will be good addition to a rocky release, but we started > > > > with this > > > > > initiative quite late indeed. The final result should the > > support > > > > in > > > > > openstack client, where "openstack overcloud (backup|restore)" > > > > would work as > > > > > a charm. Thanks in advance for considering this feature. > > > > > > > > > > > > > Was there a blueprint/spec for this effort? Additionally do we > > have > > > > a > > > > list of the outstanding work required for this? If it's just > > these > > > > two > > > > playbooks, it might be ok for an FFE. But if there's additional > > > > tripleoclient related changes, I wouldn't necessarily feel > > > > comfortable > > > > with these unless we have a complete list of work. Just as a > > side > > > > note, I'm not sure putting these in tripleo-common is going to > > be > > > > the > > > > ideal place for this. > > > > Was it this review? https://review.openstack.org/#/c/582453/ > > > > For Stein we'll have an ansible role[0] and playbook repo[1] where > > these > > types of tasks should live. > > > > [0] https://github.com/openstack/ansible-role-openstack-operations > > [1] https://review.openstack.org/#/c/583415/ > Thanks Jill! The issue is, we want to be able to backport this to > Queens once merged. With the new repos you're mentioning would this be > possible? If no, then this wont work for us unfortunately. > We wouldn't backport the new packages to Queens, however the repos will be on github and available to clone and use. This would be far preferable than adding them to tripleo-common so late in the rocky cycle then having to break them back out right away in stein. > > > > > > > > > > > > Thanks Alex. For Rocky, if we can ship the playbooks with relevant > > > docs we should be good. We will integrated with client in Stein > > > release with restore logic included. Regarding putting tripleo- > > common, > > > we're open to suggestions. I think Dan just sub
Re: [openstack-dev] [tripleo] The Weekly Owl - 25th Edition
On Mon, 2018-07-30 at 11:35 -0400, Pradeep Kilambi wrote: > > > On Mon, Jul 30, 2018 at 10:42 AM Alex Schultz > wrote: > > On Mon, Jul 30, 2018 at 8:32 AM, Martin Magr > > wrote: > > > > > > > > > On Tue, Jul 17, 2018 at 6:12 PM, Emilien Macchi > m> wrote: > > >> > > >> Your fellow reporter took a break from writing, but is now back > > on his > > >> pen. > > >> > > >> Welcome to the twenty-fifth edition of a weekly update in TripleO > > world! > > >> The goal is to provide a short reading (less than 5 minutes) to > > learn > > >> what's new this week. > > >> Any contributions and feedback are welcome. > > >> Link to the previous version: > > >> http://lists.openstack.org/pipermail/openstack-dev/2018-June/1314 > > 26.html > > >> > > >> +-+ > > >> | General announcements | > > >> +-+ > > >> > > >> +--> Rocky Milestone 3 is next week. After, any feature code will > > require > > >> Feature Freeze Exception (FFE), asked on the mailing-list. We'll > > enter a > > >> bug-fix only and stabilization period, until we can push the > > first stable > > >> version of Rocky. > > > > > > > > > Hey guys, > > > > > > I would like to ask for FFE for backup and restore, where we > > ended up > > > deciding where is the best place for the code base for this > > project (please > > > see [1] for details). We believe that B support for overcloud > > control > > > plane will be good addition to a rocky release, but we started > > with this > > > initiative quite late indeed. The final result should the support > > in > > > openstack client, where "openstack overcloud (backup|restore)" > > would work as > > > a charm. Thanks in advance for considering this feature. > > > > > > > Was there a blueprint/spec for this effort? Additionally do we have > > a > > list of the outstanding work required for this? If it's just these > > two > > playbooks, it might be ok for an FFE. But if there's additional > > tripleoclient related changes, I wouldn't necessarily feel > > comfortable > > with these unless we have a complete list of work. Just as a side > > note, I'm not sure putting these in tripleo-common is going to be > > the > > ideal place for this. Was it this review? https://review.openstack.org/#/c/582453/ For Stein we'll have an ansible role[0] and playbook repo[1] where these types of tasks should live. [0] https://github.com/openstack/ansible-role-openstack-operations [1] https://review.openstack.org/#/c/583415/ > > Thanks Alex. For Rocky, if we can ship the playbooks with relevant > docs we should be good. We will integrated with client in Stein > release with restore logic included. Regarding putting tripleo-common, > we're open to suggestions. I think Dan just submitted the review so we > can get some eyes on the playbooks. Where do you suggest is better > place for these instead? > > > > > Thanks, > > -Alex > > > > > Regards, > > > Martin > > > > > > [1] https://review.openstack.org/#/c/582453/ > > > > > >> > > >> +--> Next PTG will be in Denver, please propose topics: > > >> https://etherpad.openstack.org/p/tripleoci-ptg-stein > > >> +--> Multiple squads are currently brainstorming a framework to > > provide > > >> validations pre/post upgrades - stay in touch! > > >> > > >> +--+ > > >> | Continuous Integration | > > >> +--+ > > >> > > >> +--> Sprint theme: migration to Zuul v3 (More on > > >> https://trello.com/c/vyWXcKOB/841-sprint-16-goals) > > >> +--> Sagi is the rover and Chandan is the ruck. Please tell them > > any CI > > >> issue. > > >> +--> Promotion on master is 4 days, 0 days on Queens and Pike and > > 1 day on > > >> Ocata. > > >> +--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meet > > ing > > >> > > >> +-+ > > >> | Upgrades | > > >> +-+ > > >> > > >> +--> Good progress on major upgrades workflow, need reviews! > > >> +--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad > > -status > > >> > > >> +---+ > > >> | Containers | > > >> +---+ > > >> > > >> +--> We switched python-tripleoclient to deploy containerized > > undercloud > > >> by default! > > >> +--> Image prepare via workflow is still work in progress. > > >> +--> More: > > >> https://etherpad.openstack.org/p/tripleo-containers-squad-status > > >> > > >> +--+ > > >> | config-download | > > >> +--+ > > >> > > >> +--> UI integration is almost done (need review) > > >> +--> Bug with failure listing is being fixed: > > >> https://bugs.launchpad.net/tripleo/+bug/1779093 > > >> +--> More: > > >> https://etherpad.openstack.org/p/tripleo-config-download-squad-st > > atus > > >> > > >> +--+ > > >> | Integration | > > >> +--+ > > >> > > >> +--> We're enabling decoupled deployment plans e.g for OpenShift, > > DPDK > > >> etc: > > >>
