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 <jprov...@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
Hi,
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
location).
Jan
[1] https://review.openstack.org/#/c/165433/
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
