Re: [openstack-dev] [TripleO][Tuskar] Common library for shared code
On Fri, Mar 20, 2015 at 7:20 AM, Jan Provazník wrote: > On 03/18/2015 04:22 PM, Ben Nemec wrote: >> So is this eventually going to live in Tuskar? If so, I would point out >> that it's going to be awkward to move it there if it starts out as a >> separate thing. There's no good way I know of to copy code from one git >> repo to another without losing its history. >> >> I guess my main thing is that everyone seems to agree we need to do >> this, so it's not like we're testing the viability of a new project. >> I'd rather put this code in the right place up front than have to mess >> around with moving it later. That said, this is kind of outside my >> purview so I don't want to hold things up, I just want to make sure >> we've given some thought to where it lives. >> >> -Ben >> > > Hi, > I don't have a strong opinion where this lib should live. James, as TripleO > PTL, what is your opinion about the lib location? > > For now, I set WIP on the patch which adds this lib into Stackforge [1] > (which I sent shortly before Ben pointed out the concern about its > location). > > Jan > > [1] https://review.openstack.org/#/c/165433/ I'd say just propose it under openstack/ for all the afore mentioned reasons. We might as well start when we intend to end up, especially since Tuskar API is already under openstack/. If anyone ends up surfacing any objections, that will become known on the review. -- -- 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][Tuskar] Common library for shared code
On 03/18/2015 04:22 PM, Ben Nemec wrote: On 03/17/2015 09:13 AM, Zane Bitter wrote: On 16/03/15 16:38, Ben Nemec wrote: On 03/13/2015 05:53 AM, Jan Provaznik wrote: On 03/10/2015 05:53 PM, James Slagle wrote: On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník wrote: Hi, it would make sense to have a library for the code shared by Tuskar UI and CLI (I mean TripleO CLI - whatever it will be, not tuskarclient which is just a thing wrapper for Tuskar API). There are various actions which consist from "more that a single API call to an openstack service", to give some examples: - nodes registration - for loading a list of nodes from a user defined file, this means parsing a CSV file and then feeding Ironic with this data - decommission a resource node - this might consist of disabling monitoring/health checks on this node, then gracefully shut down the node - stack breakpoints - setting breakpoints will allow manual inspection/validation of changes during stack-update, user can then update nodes one-by-one and trigger rollback if needed I agree something is needed. In addition to the items above, it's much of the post deployment steps from devtest_overcloud.sh. I'd like to see that be consumable from the UI and CLI. I think we should be aware though that where it makes sense to add things to os-cloud-config directly, we should just do that. Yes, actually I think most of the devtest_overcloud content fits os-cloud-config (and IIRC for this purpose os-cloud-config was created). It would be nice to have a place (library) where the code could live and where it could be shared both by web UI and CLI. We already have os-cloud-config [1] library which focuses on configuring OS cloud after first installation only (setting endpoints, certificates, flavors...) so not all shared code fits here. It would make sense to create a new library where this code could live. This lib could be placed on Stackforge for now and it might have very similar structure as os-cloud-config. And most important... what is the best name? Some of ideas were: - tuskar-common I agree with Dougal here, -1 on this. - tripleo-common - os-cloud-management - I like this one, it's consistent with the os-cloud-config naming I'm more or less happy with any of those. However, If we wanted something to match the os-*-config pattern we might could go with: - os-management-config - os-deployment-config Well, the scope of this lib will be beyond configuration of a cloud so having "-config" in the name is not ideal. Based on feedback in this thread I tend to go ahead with os-cloud-management and unless someone rises an objection here now, I'll ask infra team what is the process of adding the lib to stackforge. Any particular reason you want to start on stackforge? If we're going to be consuming this in TripleO (and it's basically going to be functionality graduating from incubator) I'd rather just have it in the openstack namespace. The overhead of some day having to rename this project seems unnecessary in this case. I think the long-term hope for this code is for it to move behind the Tuskar API, so at this stage the library is mostly to bootstrap that development to the point where the API is more or less settled. In that sense stackforge seems like a natural fit, but if folks feel strongly that it should be part of TripleO (i.e. in the openstack namespace) from the beginning then there's probably nothing wrong with that either. So is this eventually going to live in Tuskar? If so, I would point out that it's going to be awkward to move it there if it starts out as a separate thing. There's no good way I know of to copy code from one git repo to another without losing its history. I guess my main thing is that everyone seems to agree we need to do this, so it's not like we're testing the viability of a new project. I'd rather put this code in the right place up front than have to mess around with moving it later. That said, this is kind of outside my purview so I don't want to hold things up, I just want to make sure we've given some thought to where it lives. -Ben Hi, I don't have a strong opinion where this lib should live. James, as TripleO PTL, what is your opinion about the lib location? For now, I set WIP on the patch which adds this lib into Stackforge [1] (which I sent shortly before Ben pointed out the concern about its location). Jan [1] https://review.openstack.org/#/c/165433/ __ 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][Tuskar] Common library for shared code
On 03/17/2015 09:13 AM, Zane Bitter wrote: > On 16/03/15 16:38, Ben Nemec wrote: >> On 03/13/2015 05:53 AM, Jan Provaznik wrote: >>> On 03/10/2015 05:53 PM, James Slagle wrote: On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník wrote: > Hi, > it would make sense to have a library for the code shared by Tuskar UI and > CLI (I mean TripleO CLI - whatever it will be, not tuskarclient which is > just a thing wrapper for Tuskar API). There are various actions which > consist from "more that a single API call to an openstack service", to > give > some examples: > > - nodes registration - for loading a list of nodes from a user defined > file, > this means parsing a CSV file and then feeding Ironic with this data > - decommission a resource node - this might consist of disabling > monitoring/health checks on this node, then gracefully shut down the node > - stack breakpoints - setting breakpoints will allow manual > inspection/validation of changes during stack-update, user can then update > nodes one-by-one and trigger rollback if needed I agree something is needed. In addition to the items above, it's much of the post deployment steps from devtest_overcloud.sh. I'd like to see that be consumable from the UI and CLI. I think we should be aware though that where it makes sense to add things to os-cloud-config directly, we should just do that. >>> >>> Yes, actually I think most of the devtest_overcloud content fits >>> os-cloud-config (and IIRC for this purpose os-cloud-config was created). >>> > > It would be nice to have a place (library) where the code could live and > where it could be shared both by web UI and CLI. We already have > os-cloud-config [1] library which focuses on configuring OS cloud after > first installation only (setting endpoints, certificates, flavors...) so > not > all shared code fits here. It would make sense to create a new library > where > this code could live. This lib could be placed on Stackforge for now and > it > might have very similar structure as os-cloud-config. > > And most important... what is the best name? Some of ideas were: > - tuskar-common I agree with Dougal here, -1 on this. > - tripleo-common > - os-cloud-management - I like this one, it's consistent with the > os-cloud-config naming I'm more or less happy with any of those. However, If we wanted something to match the os-*-config pattern we might could go with: - os-management-config - os-deployment-config >>> >>> Well, the scope of this lib will be beyond configuration of a cloud so >>> having "-config" in the name is not ideal. Based on feedback in this >>> thread I tend to go ahead with os-cloud-management and unless someone >>> rises an objection here now, I'll ask infra team what is the process of >>> adding the lib to stackforge. >> >> Any particular reason you want to start on stackforge? If we're going >> to be consuming this in TripleO (and it's basically going to be >> functionality graduating from incubator) I'd rather just have it in the >> openstack namespace. The overhead of some day having to rename this >> project seems unnecessary in this case. > > I think the long-term hope for this code is for it to move behind the > Tuskar API, so at this stage the library is mostly to bootstrap that > development to the point where the API is more or less settled. In that > sense stackforge seems like a natural fit, but if folks feel strongly > that it should be part of TripleO (i.e. in the openstack namespace) from > the beginning then there's probably nothing wrong with that either. So is this eventually going to live in Tuskar? If so, I would point out that it's going to be awkward to move it there if it starts out as a separate thing. There's no good way I know of to copy code from one git repo to another without losing its history. I guess my main thing is that everyone seems to agree we need to do this, so it's not like we're testing the viability of a new project. I'd rather put this code in the right place up front than have to mess around with moving it later. That said, this is kind of outside my purview so I don't want to hold things up, I just want to make sure we've given some thought to where it lives. -Ben __ 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][Tuskar] Common library for shared code
On 16/03/15 16:38, Ben Nemec wrote: On 03/13/2015 05:53 AM, Jan Provaznik wrote: On 03/10/2015 05:53 PM, James Slagle wrote: On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník wrote: Hi, it would make sense to have a library for the code shared by Tuskar UI and CLI (I mean TripleO CLI - whatever it will be, not tuskarclient which is just a thing wrapper for Tuskar API). There are various actions which consist from "more that a single API call to an openstack service", to give some examples: - nodes registration - for loading a list of nodes from a user defined file, this means parsing a CSV file and then feeding Ironic with this data - decommission a resource node - this might consist of disabling monitoring/health checks on this node, then gracefully shut down the node - stack breakpoints - setting breakpoints will allow manual inspection/validation of changes during stack-update, user can then update nodes one-by-one and trigger rollback if needed I agree something is needed. In addition to the items above, it's much of the post deployment steps from devtest_overcloud.sh. I'd like to see that be consumable from the UI and CLI. I think we should be aware though that where it makes sense to add things to os-cloud-config directly, we should just do that. Yes, actually I think most of the devtest_overcloud content fits os-cloud-config (and IIRC for this purpose os-cloud-config was created). It would be nice to have a place (library) where the code could live and where it could be shared both by web UI and CLI. We already have os-cloud-config [1] library which focuses on configuring OS cloud after first installation only (setting endpoints, certificates, flavors...) so not all shared code fits here. It would make sense to create a new library where this code could live. This lib could be placed on Stackforge for now and it might have very similar structure as os-cloud-config. And most important... what is the best name? Some of ideas were: - tuskar-common I agree with Dougal here, -1 on this. - tripleo-common - os-cloud-management - I like this one, it's consistent with the os-cloud-config naming I'm more or less happy with any of those. However, If we wanted something to match the os-*-config pattern we might could go with: - os-management-config - os-deployment-config Well, the scope of this lib will be beyond configuration of a cloud so having "-config" in the name is not ideal. Based on feedback in this thread I tend to go ahead with os-cloud-management and unless someone rises an objection here now, I'll ask infra team what is the process of adding the lib to stackforge. Any particular reason you want to start on stackforge? If we're going to be consuming this in TripleO (and it's basically going to be functionality graduating from incubator) I'd rather just have it in the openstack namespace. The overhead of some day having to rename this project seems unnecessary in this case. I think the long-term hope for this code is for it to move behind the Tuskar API, so at this stage the library is mostly to bootstrap that development to the point where the API is more or less settled. In that sense stackforge seems like a natural fit, but if folks feel strongly that it should be part of TripleO (i.e. in the openstack namespace) from the beginning then there's probably nothing wrong with that either. cheers, Zane. __ 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][Tuskar] Common library for shared code
On 03/13/2015 05:53 AM, Jan Provaznik wrote: > On 03/10/2015 05:53 PM, James Slagle wrote: >> On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník wrote: >>> Hi, >>> it would make sense to have a library for the code shared by Tuskar UI and >>> CLI (I mean TripleO CLI - whatever it will be, not tuskarclient which is >>> just a thing wrapper for Tuskar API). There are various actions which >>> consist from "more that a single API call to an openstack service", to give >>> some examples: >>> >>> - nodes registration - for loading a list of nodes from a user defined file, >>> this means parsing a CSV file and then feeding Ironic with this data >>> - decommission a resource node - this might consist of disabling >>> monitoring/health checks on this node, then gracefully shut down the node >>> - stack breakpoints - setting breakpoints will allow manual >>> inspection/validation of changes during stack-update, user can then update >>> nodes one-by-one and trigger rollback if needed >> >> I agree something is needed. In addition to the items above, it's much >> of the post deployment steps from devtest_overcloud.sh. I'd like to see that >> be >> consumable from the UI and CLI. >> >> I think we should be aware though that where it makes sense to add things >> to os-cloud-config directly, we should just do that. >> > > Yes, actually I think most of the devtest_overcloud content fits > os-cloud-config (and IIRC for this purpose os-cloud-config was created). > >>> >>> It would be nice to have a place (library) where the code could live and >>> where it could be shared both by web UI and CLI. We already have >>> os-cloud-config [1] library which focuses on configuring OS cloud after >>> first installation only (setting endpoints, certificates, flavors...) so not >>> all shared code fits here. It would make sense to create a new library where >>> this code could live. This lib could be placed on Stackforge for now and it >>> might have very similar structure as os-cloud-config. >>> >>> And most important... what is the best name? Some of ideas were: >>> - tuskar-common >> >> I agree with Dougal here, -1 on this. >> >>> - tripleo-common >>> - os-cloud-management - I like this one, it's consistent with the >>> os-cloud-config naming >> >> I'm more or less happy with any of those. >> >> However, If we wanted something to match the os-*-config pattern we might >> could go with: >> - os-management-config >> - os-deployment-config >> > > Well, the scope of this lib will be beyond configuration of a cloud so > having "-config" in the name is not ideal. Based on feedback in this > thread I tend to go ahead with os-cloud-management and unless someone > rises an objection here now, I'll ask infra team what is the process of > adding the lib to stackforge. Any particular reason you want to start on stackforge? If we're going to be consuming this in TripleO (and it's basically going to be functionality graduating from incubator) I'd rather just have it in the openstack namespace. The overhead of some day having to rename this project seems unnecessary in this case. -Ben __ 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][Tuskar] Common library for shared code
On 03/10/2015 05:53 PM, James Slagle wrote: On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník wrote: Hi, it would make sense to have a library for the code shared by Tuskar UI and CLI (I mean TripleO CLI - whatever it will be, not tuskarclient which is just a thing wrapper for Tuskar API). There are various actions which consist from "more that a single API call to an openstack service", to give some examples: - nodes registration - for loading a list of nodes from a user defined file, this means parsing a CSV file and then feeding Ironic with this data - decommission a resource node - this might consist of disabling monitoring/health checks on this node, then gracefully shut down the node - stack breakpoints - setting breakpoints will allow manual inspection/validation of changes during stack-update, user can then update nodes one-by-one and trigger rollback if needed I agree something is needed. In addition to the items above, it's much of the post deployment steps from devtest_overcloud.sh. I'd like to see that be consumable from the UI and CLI. I think we should be aware though that where it makes sense to add things to os-cloud-config directly, we should just do that. Yes, actually I think most of the devtest_overcloud content fits os-cloud-config (and IIRC for this purpose os-cloud-config was created). It would be nice to have a place (library) where the code could live and where it could be shared both by web UI and CLI. We already have os-cloud-config [1] library which focuses on configuring OS cloud after first installation only (setting endpoints, certificates, flavors...) so not all shared code fits here. It would make sense to create a new library where this code could live. This lib could be placed on Stackforge for now and it might have very similar structure as os-cloud-config. And most important... what is the best name? Some of ideas were: - tuskar-common I agree with Dougal here, -1 on this. - tripleo-common - os-cloud-management - I like this one, it's consistent with the os-cloud-config naming I'm more or less happy with any of those. However, If we wanted something to match the os-*-config pattern we might could go with: - os-management-config - os-deployment-config Well, the scope of this lib will be beyond configuration of a cloud so having "-config" in the name is not ideal. Based on feedback in this thread I tend to go ahead with os-cloud-management and unless someone rises an objection here now, I'll ask infra team what is the process of adding the lib to stackforge. Jan __ 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][Tuskar] Common library for shared code
On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník wrote: > Hi, > it would make sense to have a library for the code shared by Tuskar UI and > CLI (I mean TripleO CLI - whatever it will be, not tuskarclient which is > just a thing wrapper for Tuskar API). There are various actions which > consist from "more that a single API call to an openstack service", to give > some examples: > > - nodes registration - for loading a list of nodes from a user defined file, > this means parsing a CSV file and then feeding Ironic with this data > - decommission a resource node - this might consist of disabling > monitoring/health checks on this node, then gracefully shut down the node > - stack breakpoints - setting breakpoints will allow manual > inspection/validation of changes during stack-update, user can then update > nodes one-by-one and trigger rollback if needed I agree something is needed. In addition to the items above, it's much of the post deployment steps from devtest_overcloud.sh. I'd like to see that be consumable from the UI and CLI. I think we should be aware though that where it makes sense to add things to os-cloud-config directly, we should just do that. > > It would be nice to have a place (library) where the code could live and > where it could be shared both by web UI and CLI. We already have > os-cloud-config [1] library which focuses on configuring OS cloud after > first installation only (setting endpoints, certificates, flavors...) so not > all shared code fits here. It would make sense to create a new library where > this code could live. This lib could be placed on Stackforge for now and it > might have very similar structure as os-cloud-config. > > And most important... what is the best name? Some of ideas were: > - tuskar-common I agree with Dougal here, -1 on this. > - tripleo-common > - os-cloud-management - I like this one, it's consistent with the > os-cloud-config naming I'm more or less happy with any of those. However, If we wanted something to match the os-*-config pattern we might could go with: - os-management-config - os-deployment-config -- -- 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][Tuskar] Common library for shared code
- Original Message - > From: "Jan Provazník" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Monday, 9 March, 2015 8:35:29 PM > Subject: [openstack-dev] [TripleO][Tuskar] Common library for shared code > > Hi, > it would make sense to have a library for the code shared by Tuskar UI > and CLI (I mean TripleO CLI - whatever it will be, not tuskarclient > which is just a thing wrapper for Tuskar API). There are various actions > which consist from "more that a single API call to an openstack > service", to give some examples: > > - nodes registration - for loading a list of nodes from a user defined > file, this means parsing a CSV file and then feeding Ironic with this data > - decommission a resource node - this might consist of disabling > monitoring/health checks on this node, then gracefully shut down the node > - stack breakpoints - setting breakpoints will allow manual > inspection/validation of changes during stack-update, user can then > update nodes one-by-one and trigger rollback if needed > > It would be nice to have a place (library) where the code could live and > where it could be shared both by web UI and CLI. We already have > os-cloud-config [1] library which focuses on configuring OS cloud after > first installation only (setting endpoints, certificates, flavors...) so > not all shared code fits here. It would make sense to create a new > library where this code could live. This lib could be placed on > Stackforge for now and it might have very similar structure as > os-cloud-config. > > And most important... what is the best name? Some of ideas were: > - tuskar-common -1 for the reasons you gave above, this is much more than just Tuskar. > - tripleo-common > - os-cloud-management - I like this one, it's consistent with the > os-cloud-config naming I'd be happy with either of these, I think that they both convey the message well enough but I agree with you and slightly lean towards os-cloud-management. Dougal __ 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][Tuskar] Common library for shared code
Hi, it would make sense to have a library for the code shared by Tuskar UI and CLI (I mean TripleO CLI - whatever it will be, not tuskarclient which is just a thing wrapper for Tuskar API). There are various actions which consist from "more that a single API call to an openstack service", to give some examples: - nodes registration - for loading a list of nodes from a user defined file, this means parsing a CSV file and then feeding Ironic with this data - decommission a resource node - this might consist of disabling monitoring/health checks on this node, then gracefully shut down the node - stack breakpoints - setting breakpoints will allow manual inspection/validation of changes during stack-update, user can then update nodes one-by-one and trigger rollback if needed It would be nice to have a place (library) where the code could live and where it could be shared both by web UI and CLI. We already have os-cloud-config [1] library which focuses on configuring OS cloud after first installation only (setting endpoints, certificates, flavors...) so not all shared code fits here. It would make sense to create a new library where this code could live. This lib could be placed on Stackforge for now and it might have very similar structure as os-cloud-config. And most important... what is the best name? Some of ideas were: - tuskar-common - tripleo-common - os-cloud-management - I like this one, it's consistent with the os-cloud-config naming Any thoughts? Thanks, Jan [1] https://github.com/openstack/os-cloud-config __ 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
