Open Stack

On Thu, Jun 11, 2015 at 11:01:19PM -0400, Emilien Macchi wrote:
> > 1) "If you are adding a module that is the work of another project and
> > is already tracked in separate repo (...) review should also contain the
> > commit hash from the upstream repo in the commit message". Using this
> > reference to upstream commit, you can cleanly and automatically isolate
> > Fuel specific changes to that module into a patch series with two useful properties:
> > 
> >    a) You can associate each deviant line with a commit in fuel-library
> >    repository that would refer to specific LP bug or blueprint and
> >    otherwise explain the change.
> > 
> >    b) The whole patch series can be cleanly applied on top of the
> >    specified commit in upstream git. This means you can automatically
> >    graft a branch made out of the patch series onto upstream git, and
> >    then use git rebase to make that branch mergeable with the current
> >    upstream git head.
> 
> I spent some time to read Fuel Library, specially its custom manifests
> [1] and I don't see any example of these commits. I'm pretty sure I've
> missed them, can you give some example?
> 
> [1]
> https://github.com/stackforge/fuel-library/commits/master/deployment/puppet/openstack/manifests/

puppet-openstack is the module that has the most Fuel-specific
customizations, so it's probably going to be the last to be synced.

I see that by the time you finished writing your email you've found an
example of how synced our nova module with puppet-nova, here's a another
example of how it's supposed to look:

One commit to import a specific revision from upstream:
https://review.openstack.org/101166

Second commit to make the module compatible with Fuel:
https://review.openstack.org/101471

> > 2) "submit patch to upstream module first, and once merged or +2
> > recieved from a core reviewer, the patch should be backported to Fuel
> > library as well". Aside from the obvious benefit of immediate
> > contribution to upstream, this rule helps to keep Fuel specific changes
> > confined within Fuel-specific modules, and discourages arbitrary
> > deviations of forked modules from upstream.
> 
> Please let me show you an example of a bug that has been fixed in Fuel,
> but not in upstream (puppet-nova here), *after* the new Fuel policy
> (mentioned by Matthew, October 2014).
> 
> The bug: https://bugs.launchpad.net/fuel/+bug/1378962
> "Node Libvirt Unique UUID Not Generated On Deployment"
> 
> Patch in Fuel, merged & released: https://review.openstack.org/#/c/128640/
> Patch in puppet-nova, with negative feedback, without any +2 and staled
> for October 2014: https://review.openstack.org/#/c/131710

I can see how this example shows a less than ideal experience for
everyone involved (including Fuel developers). It does however confirm
that we do submit our bugfixes to upstream, and, at least in this
particular case, we don't do a "fire and forget" and actually make an
effort to comply with upstream reviewers' comments.

It also illustrates the reason why holding a merge into Fuel back until
there's +2 from upstream is something we can't yet afford: it took 1
patch set and 5 days for the patch to land in Fuel, and it took 6 patch
sets and 62 days for the Fuel developer to give up on trying to land it
in upstream.

> This is an example and again, I don't blame anyone here. I respect
> people who did the patches and I'm happy it's fixed in Fuel.

Thanks for staying positive, greatly appreciated!

> > I understand that even with these rules in place the process isn't
> > perfect, even if it were followed flawlessly. If you have ideas on what
> > else we can tweak to make upstream's life easier, please share, we're
> > always looking for ways to improve our processes.
> 
> Like puppet-murano?
> Someone from Fuel team created first the module in Fuel, 6 months ago
> [1] and 3 months later someone from Fuel team  created an empty
> repository in Stackforge [2]. By the way, Puppet OpenStack community
> does not have core permissions on this module and it's own by Murano team.
> 
> [1]
> https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/murano/
> [2] https://review.openstack.org/#/c/155688/
> 
> Again another example, where I'm very happy to see the module in Fuel
> but nothing in Stackforge leveraged by Puppet OpenStack community.

Thanks for reporting this!

Serg, can you comment? The situation with puppet-murano repository on
Stackforge doesn't look right to me.

On the lemons to lemonade side: we can leverage the fact that Murano
team owns both the murano module in fuel-library and puppet-murano
repository on Stackforge, and try to use this module as a proving ground
to experiment with different collaboration models.

> I've been working on OpenStack installers for 2 years now [1] [2], I
> understand what is a product deadline.
> 
> [1] http://spinalstack.enovance.com
> [2] https://www.rdoproject.org/RDO-Manager

Can you share more about your experience with these projects? Were/are
you using vanilla Puppet modules from Puppet OpenStack and PuppetLabs in
your products?

> Let me clarify two things:
> * We both agree Fuel started wrong by forking Puppet OpenStack modules
> and now Fuel is trying the best to catch-up to upstream. I'm totally
> good with that and I'm really happy you changed your methodology.

And yet you use very judgemental words like "wrong" and "catch-up" :(

> * I understand Fuel team wants their product awesome (who doesn't?) and
> they have deadlines but I'm pretty sure (and this is the goal of this
> thread) we can do something together.
> 
> Until now, I'm still concerned about 'are we really going to have
> collaboration in future' or all of these are words (this e-mail, Fuel
> documentation in Wiki) and just words that won't make any change.

Can't really start making changes until we've even agreed on what
exactly is not good enough. Actions are important, but they do more harm
then good when done without common understanding. Let's hope that we can
quickly reach the latter so that we can move on to discussing the
former.

-- 
Dmitry Borodaenko