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

This is what we should do, indeed, as a Fuel library team. First, always
get the patch merged upstream, and only next - backport this to Fuel fork.
Ideally, we will next switch to upstream manifests, eventually, so there
would be no need for forks anymore. Sadly, this *never* worked for us
and doesn't work yet as we're, it seems, not ready for this *quite a
long path* of changes landing> So there was a "lazy compromise" and
shortcuts found, which I personally don't like.

I strongly believe that someday this will start to work for us. And this
is not just a words of hope. Before we did the first
"get-closer-to-upstream" effort, our fork's code base diverge was ~97%
and 0 patches contributed upstream by changes in Fuel library. An
initial sync with upstream modules was the very first step on the right
way. And we're keep doing the best to reduce the code diverge to be
ready to switch upstream modules one day.

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

Nothing to add, you are completely right.

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

Agree, this makes the technical dept only to grow uncontrollable.

> 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

I'm all for this option. We have a backlog item to deploy
OpenStack from upstream packages with Fuel. I'd say this must be done by
upstream puppet manifests as well.

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


-- 
Best regards,
Bogdan Dobrelya,
Skype #bogdando_at_yahoo.com
Irc #bogdando