Code review comment for lp:~nii/nova/nova-deployment-tool

>>> I don't really see a problem with it going into contrib. We don't
>>> really have a good other location for items like this.
>> I believe we do. It's called "outside".

I think to a great extent this is the problem we need to address. My primary
concern is related to having this in trunk. Trunk is very much a moving target.
If this stuff is only going to be updated ocasionally (perhaps in sync with
various freezes or whatnot), that means it'll be out-of-date most of the
time. To me, this means it belongs somewhere else. Not necessarily outside of
OpenStack, but outside of Nova's trunk.

If this is the one tool we're going to use, and the one set of puppet recipes
we're going to encourage people to use, I have no problem "advertising" it on
the front page of the wiki, on the Launchpad page for Nova, etc. etc.

> I have a commitment to make the code up-to-date when we release for
> Bexar. So, I am expecting to be very tough days just before 3rd of
> Mar. As Soren says, I think it's really, really hard to keep this
> stuff up-to-date anytime, even after the release.

That's another good reason why you may want to keep this separate from
trunk. If you expect to keep adjusting it after release, you can't do
that if it's in trunk. We're not going to release new tarballs of Nova
itself to publish new puppet recipes.

> We should inform aim of tool by which users can know which is fit to
> their needs.

Yes. See below.

> I did not know any other ways than to follow the procedure, which I
> was taught, in order to contribute to the community.

You've done nothing wrong :) I really do appreciate the contribution
and I'm not meaning to reject your work. I'm just don't believe the
specific location for it (Nova's trunk) is what is best for neither your
work, nor Nova. Imagine this scenario: You make sure the scripts and
the recipes are in perfect order by the time of Bexar's release. The
next day, we make some changes on trunk that are incompatible with your
scripts. People checking out trunk will still find your recipes, try
them, and find that they do not give them a functional cloud. They
either blame you, because they can see that you provided the recipes, or
they blame the entire OpenStack project. That doesn't help anyone at
all.

In summary, if this is in Nova's trunk, it needs to be up-to-date. If
it's kept somewhere else (maybe in a separate "nova-deployment" project
on Launchpad under the OpenStack umbrella) it's easier to have it say
"This tool is for deploying OpenStack Bexar" so that people know exactly
what to expect.

> 1) Write a Blueprint
> 2) Present it at the developer conference
> 3) Get an Approval to it
> 4) Upload codes
> 5) Propose merge to trunk by 6th of Jan.
> 6) Get an Approval to it

Yup, this looks correct to me. Again, you did nothing wrong. :)

> I am now asking Todd to become a volunteer following Sore's advice.
> Please help me to find a way to contribute the code for openstack
> users' value.
>
> I was thinking that the tool would make installation easier and help everybody
> wins. -- yoko

I completely agree. I think this could also serve well as a tool for
automated full-scale testing. It's good stuff! My only real concern is
where we put it.