Re: [openstack-dev] [TripleO][Tuskar] Common library for shared code

2015-03-20 Thread Jan Provazník

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 jprov...@redhat.com 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

2015-03-20 Thread James Slagle
On Fri, Mar 20, 2015 at 7:20 AM, Jan Provazník jprov...@redhat.com 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

2015-03-18 Thread Ben Nemec
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 jprov...@redhat.com 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

2015-03-17 Thread Zane Bitter

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 jprov...@redhat.com 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

2015-03-16 Thread Ben Nemec
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 jprov...@redhat.com 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

2015-03-13 Thread Jan Provaznik

On 03/10/2015 05:53 PM, James Slagle wrote:

On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník jprov...@redhat.com 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

2015-03-10 Thread James Slagle
On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník jprov...@redhat.com 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

2015-03-10 Thread Dougal Matthews
- Original Message -
 From: Jan Provazník jprov...@redhat.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 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

2015-03-09 Thread Jan Provazník

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