Open Stack

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.

Jan