Open Stack

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 <jprovazn at 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.