[openstack-dev] [TripleO][Tuskar] Common library for shared code
james.slagle at gmail.com
Tue Mar 10 16:53:43 UTC 2015
On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník <jprovazn at redhat.com> wrote:
> 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.
> 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  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:
-- James Slagle
More information about the OpenStack-dev