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

Jan Provazník jprovazn at redhat.com
Fri Mar 20 11:20:12 UTC 2015

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

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 


[1] https://review.openstack.org/#/c/165433/

More information about the OpenStack-dev mailing list