Open Stack

Hi,

Before you read me, please remember I know almost nothing about puppet. :)

On 06/11/2015 11:03 PM, Matt Fischer wrote:
> We as a community don't do a great job watching bugs, so personally I'd
> prefer that fuel developers just push patches, filing a bug too if you
> want. (Note: we do need to improve our bug tracking!) However, I don't
> think that asking puppet openstack devs to ask in the fuel channel if a
> given bug is fixed in fuel is a very sustainable model. I'm not sure of
> many projects where the upstream polls downstream to ask whether they've
> fixed bugs. Can we come up with a way to collaborate more that everyone
> likes? I think there's a lot of value in it for everyone, we all get a
> better product out of it.
> 
> 
> On Thu, Jun 11, 2015 at 8:36 AM, Matthew Mosesohn
>     The point you raised about fixing bugs in Fuel and not in Puppet
>     OpenStack is definitely valid and something we need to collaborate on.
>     The first and easiest option when a bug is applicable to both, we
>     could use Launchpad to assign bugs to both Fuel project and
>     puppet-$project so it gains visibility. If a bug is discovered in
>     Puppet OpenStack after it's been reported and/or fixed in Fuel, then
>     it would be best to ping someone in #fuel-dev on IRC and we can try to
>     figure out how to get this applied upstream correctly. Our best
>     results come from fixing upstream and I want to make sure that is
>     clear.

Matt,

I appreciate a lot who you are, and all the help you've given me so far,
but what you are asking here is wrong. You shouldn't ask Emilien to
track the work of the Fuel team, and ping them on IRC to contribute
back. It should be up to them to directly fix upstream *first*, and
*then* fix back in Fuel.

> If you have specific bugs or commits you'd like to discuss, let's work
> them out. I believe I can get the Fuel Library team to agree to do a
> walk through all the open bugs in Puppet OpenStack and see if we have
> any related fixes or bug reports.

It shouldn't be the way either. The team working on fuel-library should
be pro-active and doing the contributions, Emilien shouldn't have to
discuss a "specific bug of commits". I believe also that Emilien's
reasoning goes beyond just one or 2 commits, it's a general thinking.

On 06/11/2015 04:36 PM, Matthew Mosesohn wrote:
> I can see why you might be unhappy with Fuel's actions with regards to
> the OpenStack Puppet modules. You could make this argument about many
> components in Fuel. The heart of the matter is that we bundle the
> upstream OpenStack Puppet modules with all the other modules,
> developed both upstream and by Fuel's developers in one single git
> repository. This decision, along with all the other decisions to put
> Fuel's components under its own repositories, was intended to add
> stability and granular control to the product. I'm not saying it's the
> most community-oriented approach, but Fuel would have never evolved
> and matured without it. The attribution in commits is lost because our
> directory namespace differs such that it can't just be merged cleanly.
> Revisiting submodules is an option, but it led to maintenance problems
> in the past.

This isn't the only place where we have a huge git repository doing
everything. This IMO is a big mistake, which give us more work because
we have to duplicate what's upstream and constantly rebase. This is yet
another technical dept... This only works because we have a lot of
Mirantis employee doing the work, so the inefficiency is counter
balanced by the work force. But as you know, we're always pushing to the
very limit of everyone to release a new version of MOS and Fuel, so
maybe now is the time to rethink the way we work.

To move forward, I really believe we (as in: Mirantis) should be:
1/ Rework fuel-library to use multiple git for puppet, and maybe work
out a way to package these individually.
2/ Using unmodified version of upstream puppet as much as possible
3/ Work *only* on upstream puppet and not on a separate fork

As a lot of the changes that I propose, this would be a one-off painful
effort to kill this technical dept, but on the long run, we would really
benefits from such reorganization.

If we don't do the above, it's going to be "business as usual", no mater
how much efforts Mirantis engineer will put on: the pressure we have to
deliver Fuel/MOS should shift from the fork to what's upstream.

Cheers,

Thomas Goirand (zigo)