Open Stack

On 06/12/2015 07:58 AM, Bogdan Dobrelya wrote:
>> 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.

I'm actually happy to hear from you, since we were discussing together
about that over the last 2 summits, without real plan between both groups.

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

Good feedback from the patch's author.

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

Sounds like another plan here, which sounds great.

> OpenStack from upstream packages with Fuel. I'd say this must be done by
> upstream puppet manifests as well.

Can you clarify what must be done by upstream manifests?

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

-- 
Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150612/78e933ea/attachment.pgp>