[openstack-dev] [tripleo] State of upgrade CLI commands
Hello TripleO-ians, I've started to look again at the introduced, but unused/undocumented upgrade commands. It seems to me that given the current state of the upgrade process (at least from Liberty -> Mitaka), these commands make a lot less sense. I see one of two directions to take on this. Of course I would love to hear other options. 1) Revert these commands immediately, and forget they ever existed. They don't exactly work, and as I said, were never officially documented, so I don't think a revert is out of the question. or 2) Do a major overhaul, and rethink the interface entirely. For instance, the L->M upgrade introduced a couple of new steps (the AODH migration and the Keystone migration). These would have either had to have completely new commands added, or have some type of override to the existing upgrade command to handle them. Personally, I would go for step 1. The 'overcloud deploy' command can accomplish all of the upgrade steps that involve Heat. In order for the new upgrade commands to work properly, there's a lot that needs to be refactored out of the deploy command itself so that it can be shared with deploy and upgrade, like passing of passwords and the like. I just don't see a need for discrete commands when we have an existing command that will do it for us. And with the addition of an answer file, it makes it even easier. Thoughts? -- Brad __ 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] State of upgrade CLI commands
On 16.8.2016 21:08, Brad P. Crochet wrote: Hello TripleO-ians, I've started to look again at the introduced, but unused/undocumented upgrade commands. It seems to me that given the current state of the upgrade process (at least from Liberty -> Mitaka), these commands make a lot less sense. I see one of two directions to take on this. Of course I would love to hear other options. 1) Revert these commands immediately, and forget they ever existed. They don't exactly work, and as I said, were never officially documented, so I don't think a revert is out of the question. or 2) Do a major overhaul, and rethink the interface entirely. For instance, the L->M upgrade introduced a couple of new steps (the AODH migration and the Keystone migration). These would have either had to have completely new commands added, or have some type of override to the existing upgrade command to handle them. Personally, I would go for step 1. The 'overcloud deploy' command can accomplish all of the upgrade steps that involve Heat. In order for the new upgrade commands to work properly, there's a lot that needs to be refactored out of the deploy command itself so that it can be shared with deploy and upgrade, like passing of passwords and the like. I just don't see a need for discrete commands when we have an existing command that will do it for us. And with the addition of an answer file, it makes it even easier. Thoughts? +1 for approach no. 1. Currently `overcloud deploy` meets the upgrade needs and it gave us some flexibility to e.g. do migrations like AODH and Keystone WSGI. I don't think we should have a special command for upgrades at this point. The situation may change as we go towards upgrades of composable services, and perhaps wrap upgrades in Mistral if/when applicable, but then the potential upgrade command(s) would probably be different from the current ones anyway, so +1 for removing them. Jirka __ 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] State of upgrade CLI commands
On 17/08/16 15:46, Jiří Stránský wrote: > On 16.8.2016 21:08, Brad P. Crochet wrote: >> Hello TripleO-ians, >> >> I've started to look again at the introduced, but unused/undocumented >> upgrade commands. It seems to me that given the current state of the >> upgrade process (at least from Liberty -> Mitaka), these commands make >> a lot less sense. >> >> I see one of two directions to take on this. Of course I would love to >> hear other options. >> >> 1) Revert these commands immediately, and forget they ever existed. >> They don't exactly work, and as I said, were never officially >> documented, so I don't think a revert is out of the question. >> >> or >> >> 2) Do a major overhaul, and rethink the interface entirely. For >> instance, the L->M upgrade introduced a couple of new steps (the AODH >> migration and the Keystone migration). These would have either had to >> have completely new commands added, or have some type of override to >> the existing upgrade command to handle them. >> >> Personally, I would go for step 1. The 'overcloud deploy' command can >> accomplish all of the upgrade steps that involve Heat. In order for >> the new upgrade commands to work properly, there's a lot that needs to >> be refactored out of the deploy command itself so that it can be >> shared with deploy and upgrade, like passing of passwords and the >> like. I just don't see a need for discrete commands when we have an >> existing command that will do it for us. And with the addition of an >> answer file, it makes it even easier. >> >> Thoughts? >> > > +1 for approach no. 1. Currently `overcloud deploy` meets the upgrade > needs and it gave us some flexibility to e.g. do migrations like AODH > and Keystone WSGI. I don't think we should have a special command for > upgrades at this point. > > The situation may change as we go towards upgrades of composable > services, and perhaps wrap upgrades in Mistral if/when applicable, but > then the potential upgrade command(s) would probably be different from > the current ones anyway, so +1 for removing them. +1 from me too, especially because this ^^^ (the workflow we currently have and use will change quite drastically I expect) thanks, sorry I didn't spot this earlier, marios > > Jirka > > __ > 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] State of upgrade CLI commands
On 08/18/2016 09:29 AM, Marios Andreou wrote: > On 17/08/16 15:46, Jiří Stránský wrote: >> On 16.8.2016 21:08, Brad P. Crochet wrote: >>> Hello TripleO-ians, >>> >>> I've started to look again at the introduced, but unused/undocumented >>> upgrade commands. It seems to me that given the current state of the >>> upgrade process (at least from Liberty -> Mitaka), these commands make >>> a lot less sense. >>> >>> I see one of two directions to take on this. Of course I would love to >>> hear other options. >>> >>> 1) Revert these commands immediately, and forget they ever existed. >>> They don't exactly work, and as I said, were never officially >>> documented, so I don't think a revert is out of the question. >>> >>> or >>> >>> 2) Do a major overhaul, and rethink the interface entirely. For >>> instance, the L->M upgrade introduced a couple of new steps (the AODH >>> migration and the Keystone migration). These would have either had to >>> have completely new commands added, or have some type of override to >>> the existing upgrade command to handle them. >>> >>> Personally, I would go for step 1. The 'overcloud deploy' command can >>> accomplish all of the upgrade steps that involve Heat. In order for >>> the new upgrade commands to work properly, there's a lot that needs to >>> be refactored out of the deploy command itself so that it can be >>> shared with deploy and upgrade, like passing of passwords and the >>> like. I just don't see a need for discrete commands when we have an >>> existing command that will do it for us. And with the addition of an >>> answer file, it makes it even easier. >>> >>> Thoughts? >>> >> +1 for approach no. 1. Currently `overcloud deploy` meets the upgrade >> needs and it gave us some flexibility to e.g. do migrations like AODH >> and Keystone WSGI. I don't think we should have a special command for >> upgrades at this point. >> >> The situation may change as we go towards upgrades of composable >> services, and perhaps wrap upgrades in Mistral if/when applicable, but >> then the potential upgrade command(s) would probably be different from >> the current ones anyway, so +1 for removing them. > +1 from me too, especially because this ^^^ (the workflow we currently > have and use will change quite drastically I expect) > > thanks, sorry I didn't spot this earlier, > marios +1 for me too, even if, I think for an end-user experience it's not ideal and the CLI would be a better way for this point. >> Jirka >> >> __ >> 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 __ 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] State of upgrade CLI commands
On Thu, Aug 18, 2016 at 4:25 AM, mathieu bultel wrote: > On 08/18/2016 09:29 AM, Marios Andreou wrote: >> On 17/08/16 15:46, Jiří Stránský wrote: >>> On 16.8.2016 21:08, Brad P. Crochet wrote: Hello TripleO-ians, I've started to look again at the introduced, but unused/undocumented upgrade commands. It seems to me that given the current state of the upgrade process (at least from Liberty -> Mitaka), these commands make a lot less sense. I see one of two directions to take on this. Of course I would love to hear other options. 1) Revert these commands immediately, and forget they ever existed. They don't exactly work, and as I said, were never officially documented, so I don't think a revert is out of the question. or 2) Do a major overhaul, and rethink the interface entirely. For instance, the L->M upgrade introduced a couple of new steps (the AODH migration and the Keystone migration). These would have either had to have completely new commands added, or have some type of override to the existing upgrade command to handle them. Personally, I would go for step 1. The 'overcloud deploy' command can accomplish all of the upgrade steps that involve Heat. In order for the new upgrade commands to work properly, there's a lot that needs to be refactored out of the deploy command itself so that it can be shared with deploy and upgrade, like passing of passwords and the like. I just don't see a need for discrete commands when we have an existing command that will do it for us. And with the addition of an answer file, it makes it even easier. Thoughts? >>> +1 for approach no. 1. Currently `overcloud deploy` meets the upgrade >>> needs and it gave us some flexibility to e.g. do migrations like AODH >>> and Keystone WSGI. I don't think we should have a special command for >>> upgrades at this point. >>> >>> The situation may change as we go towards upgrades of composable >>> services, and perhaps wrap upgrades in Mistral if/when applicable, but >>> then the potential upgrade command(s) would probably be different from >>> the current ones anyway, so +1 for removing them. >> +1 from me too, especially because this ^^^ (the workflow we currently >> have and use will change quite drastically I expect) >> >> thanks, sorry I didn't spot this earlier, >> marios > > +1 for me too, even if, I think for an end-user experience it's not > ideal and the CLI would be a better way for this point. >>> Jirka >>> I have proposed the following reverts: python-tripleoclient: https://review.openstack.org/#/c/357192/ https://review.openstack.org/#/c/357194/ https://review.openstack.org/#/c/357195/ tripleo-common: https://review.openstack.org/#/c/357219/ https://review.openstack.org/#/c/357220/ https://review.openstack.org/#/c/357221/ -- Brad __ 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
