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

Dougal Matthews dougal at redhat.com
Tue Mar 10 08:33:58 UTC 2015


----- Original Message -----
> From: "Jan Provazník" <jprovazn at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at 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



More information about the OpenStack-dev mailing list