[openstack-dev] [TripleO] Deployment workflow changes for ui/client
I've been looking at how we can hook up the deployment changes for config-download[1] with the existing deployment workflows in Mistral. However, it seems we have not sufficiently abstracted the logic to do a "deployment" behind a given workflow(s). The existing things a client (or UI) has to do is: - call tripleo.deployment.v1.deploy_plan - poll for success/failure of that workflow - poll for success/failure of in progress Heat stack (list events, etc) - call tripleo.deployment.v1.overcloudrc (probably more things too) If I want to make some changes to the deployment workflow, such that after the Heat stack operation is complete, we run a config-download action/workflow, then apply the generated ansible via ansible-playbook, I can't really do that without requiring all clients to also get updated to use those new steps (via calling new workflows, etc). As a first attempt, I took a shot at creating a workflow that does every step: https://review.openstack.org/#/c/512876/ But even that will require client changes as it necessitates a behavior change in that the workflow has to wait for the stack to be complete as opposed to returning as soon as the stack operation is accepted by Heat. I'd like to implement this in a way that minimizes the impact of changes on both python-tripleoclient and tripleo-ui, but it's looking as if some changes would be required to use this new ansible driven approach. Thoughts or feedback on how to proceed? I'm guess I'm also wondering if the existing API exposed by the workflows is easy to consume by the UI, or if it would be better to be wrapped in a single workflow...at least that way we could make logical implementation changes without requiring ui/cilent changes. [1] https://blueprints.launchpad.net/tripleo/+spec/ansible-config-download -- -- James Slagle -- __ 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] Deployment workflow changes for ui/client
On Thu, Oct 19, 2017 at 4:56 PM James Slagle wrote: > I've been looking at how we can hook up the deployment changes for > config-download[1] with the existing deployment workflows in Mistral. > > However, it seems we have not sufficiently abstracted the logic to do > a "deployment" behind a given workflow(s). The existing things a > client (or UI) has to do is: > > - call tripleo.deployment.v1.deploy_plan > - poll for success/failure of that workflow > - poll for success/failure of in progress Heat stack (list events, etc) > - call tripleo.deployment.v1.overcloudrc > (probably more things too) > > If I want to make some changes to the deployment workflow, such that > after the Heat stack operation is complete, we run a config-download > action/workflow, then apply the generated ansible via > ansible-playbook, I can't really do that without requiring all clients > to also get updated to use those new steps (via calling new workflows, > etc). > > As a first attempt, I took a shot at creating a workflow that does every > step: > https://review.openstack.org/#/c/512876/ > But even that will require client changes as it necessitates a > behavior change in that the workflow has to wait for the stack to be > complete as opposed to returning as soon as the stack operation is > accepted by Heat. > > Thankfully we already have that capability. :) > I'd like to implement this in a way that minimizes the impact of > changes on both python-tripleoclient and tripleo-ui, but it's looking > as if some changes would be required to use this new ansible driven > approach. > > Thoughts or feedback on how to proceed? I'm guess I'm also wondering > if the existing API exposed by the workflows is easy to consume by the > UI, or if it would be better to be wrapped in a single workflow...at > least that way we could make logical implementation changes without > requiring ui/cilent changes. > > [1] https://blueprints.launchpad.net/tripleo/+spec/ansible-config-download > > +1 to all of this. I think from the CLI perspective, it should be a minimal impact. If anything, it will get rid of a lot of code that doesn't really belong. I can't say what the impact to the UI would be. However, one thing that we should make sure of is that we send messages back through Zaqar to keep the CLI and UI informed of what is occurring. That should happen already with most of the existing workflows. This is a great step in the right direction. The Workflows squad will be happy to assist in any way we can. We will start by reviewing what you have so far. > -- > -- James Slagle > -- > > __ > 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 > -- Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS Principal Software Engineer (c) 704.236.9385 __ 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] Deployment workflow changes for ui/client
On Fri, Oct 20, 2017 at 1:20 PM, Brad P. Crochet wrote: > On Thu, Oct 19, 2017 at 4:56 PM James Slagle > wrote: > >> I've been looking at how we can hook up the deployment changes for >> config-download[1] with the existing deployment workflows in Mistral. >> >> However, it seems we have not sufficiently abstracted the logic to do >> a "deployment" behind a given workflow(s). The existing things a >> client (or UI) has to do is: >> >> - call tripleo.deployment.v1.deploy_plan >> - poll for success/failure of that workflow >> - poll for success/failure of in progress Heat stack (list events, etc) >> - call tripleo.deployment.v1.overcloudrc >> (probably more things too) >> >> If I want to make some changes to the deployment workflow, such that >> after the Heat stack operation is complete, we run a config-download >> action/workflow, then apply the generated ansible via >> ansible-playbook, I can't really do that without requiring all clients >> to also get updated to use those new steps (via calling new workflows, >> etc). >> >> As a first attempt, I took a shot at creating a workflow that does every >> step: >> https://review.openstack.org/#/c/512876/ >> But even that will require client changes as it necessitates a >> behavior change in that the workflow has to wait for the stack to be >> complete as opposed to returning as soon as the stack operation is >> accepted by Heat. >> >> > Thankfully we already have that capability. :) > > >> I'd like to implement this in a way that minimizes the impact of >> changes on both python-tripleoclient and tripleo-ui, but it's looking >> as if some changes would be required to use this new ansible driven >> approach. >> >> Thoughts or feedback on how to proceed? I'm guess I'm also wondering >> if the existing API exposed by the workflows is easy to consume by the >> UI, or if it would be better to be wrapped in a single workflow...at >> least that way we could make logical implementation changes without >> requiring ui/cilent changes. >> >> [1] https://blueprints.launchpad.net/tripleo/+spec/ansible- >> config-download >> >> > +1 to all of this. I think from the CLI perspective, it should be a > minimal impact. If anything, it will get rid of a lot of code that doesn't > really belong. I can't say what the impact to the UI would be. However, one > thing that we should make sure of is that we send messages back through > Zaqar to keep the CLI and UI informed of what is occurring. That should > happen already with most of the existing workflows. > > This is a great step in the right direction. The Workflows squad will be > happy to assist in any way we can. We will start by reviewing what you have > so far. > Having a workflow which wraps whole deployment sounds great from the UI side too as it allows us to simplify the steps you described above. IIRC the reason the whole deployment did not get wrapped into a single workflow before is that the workflow/tasks timeouted before the deployment could finish which caused the workflow to fail. It should not be problematic to integrate these changes in GUI. The soon we can test it the better. As Brad noted, it is important to get as many Zaqar messages as possible so we can track the progress properly. -- Jirka > > >> -- >> -- James Slagle >> -- >> >> >> __ >> 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 >> > -- > Brad P. Crochet, RHCA, RHCE, RHCVA, RHCDS > Principal Software Engineer > (c) 704.236.9385 <(704)%20236-9385> > > > __ > 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
Re: [openstack-dev] [TripleO] Deployment workflow changes for ui/client
On Tue, Oct 24, 2017 at 6:04 AM, Jiri Tomasek wrote: > Having a workflow which wraps whole deployment sounds great from the UI side > too as it allows us to simplify the steps you described above. IIRC the > reason the whole deployment did not get wrapped into a single workflow > before is that the workflow/tasks timeouted before the deployment could > finish which caused the workflow to fail. > > It should not be problematic to integrate these changes in GUI. The soon we > can test it the better. As Brad noted, it is important to get as many Zaqar > messages as possible so we can track the progress properly. Thanks :). Sounds like at least the 3 of us, are in general agreement about moving more towards wrapping all the deployment logic into a single workflow, or as few workflows as possible. Doing so will reduce the amount of logic we have to do client side and in the UI. That being said...as I started to look in that direction, I realized it is a lot of work to get us there, even if we did just enough to support using config-download. I feel like such an effort should probably be tracked in its own blueprint and properly scoped so that the risk is well understood. I'd estimate it to be fairly disruptive given the amount of changes needed in the clients and workflows. To that end, I'm proposing we push such an effort off to Rocky, given we already passed Queens-1. For config-download for Queens, I've proposed the following as an alternative solution: https://review.openstack.org/#/c/514701/ (python-tripleoclient) https://review.openstack.org/#/c/512876/ (tripleo-common) I think it's fairly simple with low risk and it just follows the existing pattern of calling an additional workflow to add functionality. If we're happy with where we get to in queens with config-download, we could consider making it the default. -- -- James Slagle -- __ 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] Deployment workflow changes for ui/client
On Tue, Oct 24, 2017 at 8:16 AM, James Slagle wrote: > On Tue, Oct 24, 2017 at 6:04 AM, Jiri Tomasek wrote: >> Having a workflow which wraps whole deployment sounds great from the UI side >> too as it allows us to simplify the steps you described above. IIRC the >> reason the whole deployment did not get wrapped into a single workflow >> before is that the workflow/tasks timeouted before the deployment could >> finish which caused the workflow to fail. >> >> It should not be problematic to integrate these changes in GUI. The soon we >> can test it the better. As Brad noted, it is important to get as many Zaqar >> messages as possible so we can track the progress properly. > > Thanks :). Sounds like at least the 3 of us, are in general agreement > about moving more towards wrapping all the deployment logic into a > single workflow, or as few workflows as possible. Doing so will reduce > the amount of logic we have to do client side and in the UI. > > That being said...as I started to look in that direction, I realized > it is a lot of work to get us there, even if we did just enough to > support using config-download. I feel like such an effort should > probably be tracked in its own blueprint and properly scoped so that > the risk is well understood. I'd estimate it to be fairly disruptive > given the amount of changes needed in the clients and workflows. > > To that end, I'm proposing we push such an effort off to Rocky, given > we already passed Queens-1. +1, let's make iterations and config-download seems an excellent one. > For config-download for Queens, I've proposed the following as an > alternative solution: > > https://review.openstack.org/#/c/514701/ (python-tripleoclient) > https://review.openstack.org/#/c/512876/ (tripleo-common) > > I think it's fairly simple with low risk and it just follows the > existing pattern of calling an additional workflow to add > functionality. If we're happy with where we get to in queens with > config-download, we could consider making it the default. We'll give feedback in the review. Thanks James for this update, -- Emilien Macchi __ 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
