Open Stack

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

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