OpenStack Compute (nova)

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

nova-deployment-tool
Merge into trunk

Revision history for this message

Shigetoshi Yokoyama (yoko) wrote on 2011-01-14:

> >>> 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.

I understand that it is better to put our code into its own OpenStack project,
in a separate "nova-deployment" project on Launchpad under the OpenStack umbrella.

NII has been talking to NASA team on this issue because they developed similar tool
for NASA deployment. Actually, NII modified the code to use external node instead of
tags of puppet, based on NASA idea. So, I thought that it was suitable to put our
tool in trunk/contrib because NASA tool stayed in the directory.

Because of this background, I wanted to know some opinions from NASA members
in this session. Vish kindly told his opinion and I was convinced, too.

I appreciate your thoughtful help. I will put the very current version which
is up-to-date, just now, soon. :-> -- yoko

> >>> 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.

I understand that it is better to put our code into its own OpenStack project,
in a separate "nova-deployment" project on Launchpad under the OpenStack umbrella.

NII has been talking to NASA team on this issue because they developed similar tool
for NASA deployment. Actually, NII modified the code to use external node instead of
tags of puppet, based on NASA idea. So, I thought that it was suitable to put our 
tool in trunk/contrib because NASA tool stayed in the directory.

Because of this background, I wanted to know some opinions from NASA members
in this session. Vish kindly told his opinion and I was convinced, too.

I appreciate your thoughtful help.  I will put the very current version which
is up-to-date, just now, soon. :->  -- yoko

« Back to merge proposal