Open Stack

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 <mmosesohn at mirantis.com>
wrote:

> Hi Emilien,
>
> 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.


> Secondly, I'd like to point out that Fuel is not so different from
> what other teams are doing. At the Summit, I heard from others who all
> maintain internal Gerrits and internal forks of the modules. The
> difference is that Fuel is being worked on in the open in StackForge.
> Anyone is free to contribute to Fuel as he or she wishes, take our
> patches, or review changesets.
>


> Starting in October 2014, the Fuel team has adopted a policy that we
> cannot merge any patches into the core Puppet OpenStack modules of
> Fuel without submitting a patch or at least a bug upstream. Our
> reviewers block patches consistently. The truth is that the upstream
> modules are quite excellent and we don't need to make changes so
> often. Our goal is to work with upstream modules or in the issue where
> upstream integration is impossible, we place that config in our own
> separate modules.
>
> 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.
>
> 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.
>
> Best Regards,
> Matthew Mosesohn
>
> On Thu, Jun 11, 2015 at 2:34 PM, Sanjay Upadhyay <saneax at gmail.com> wrote:
> > +1 for the thread, I would also like to hear from Mirantis on this.
> >
> > The Fork on fuel/puppet has been actively seen patching and
> consolidation.It
> > seems like parallel effort why not merge it.
> >
> > regards
> > /sanjay
> >
> > On Thu, Jun 11, 2015 at 9:12 AM, Emilien Macchi <emilien at redhat.com>
> wrote:
> >>
> >> Hi,
> >>
> >> Before reading this e-mail, please keep in mind:
> >>
> >> * I have a lot of admiration for Fuel and since I'm working on OpenStack
> >> Installers (at eNovance and now Red Hat), Fuel is something I always
> >> consider a good product.
> >> * This e-mail is about Fuel and Puppet, nothing about Mirantis.
> >> * I'm writing on behalf of my thoughts, and not on our group.
> >> * I'm using open mailing-list for open discussion. There is not bad
> >> spirit in this e-mail and I want to have a productive thread.
> >>
> >> I have some concerns I would like to share with you and hopefully find
> >> some solutions together.
> >>
> >> Since I've been working on Puppet OpenStack (2 years now), I see some
> >> situations that happen - according to me - too often:
> >>
> >> * A bug is reported in both Fuel Library and the Puppet module having
> >> trouble. A patch is provided in Fuel Library (your fork of Puppet
> >> OpenStack modules) but not in Puppet upstream module. That means you fix
> >> the bug for Fuel, and not for Puppet OpenStack community. It does not
> >> happen all the time but quite often.
> >>
> >> * A patch is submitted in a Puppet module and quite often does not land
> >> because there is no activity, no tests or is abandonned later because
> >> fixed in Fuel Library. I've noticed the patch is fixed in Fuel Library
> >> though.
> >>
> >> * RAW copy/paste between upstream modules code and your forks. In term
> >> of Licensing, I'm even not sure you have the right to do that (I'm not a
> >> CLA expert though) but well... in term of authorship and statistics on
> >> code, I'm not sure it's fair. Using submodules with custom patches would
> >> have been great to respect the authors who created the original code and
> >> you could have personalize the manifests.
> >>
> >> Note: you can see that I don't give any example because I'm not here to
> >> blame people or judge anyone.
> >>
> >> So the goal of my e-mail is to open the discussion and have a *real*
> >> collaboration between Fuel team which seems to have a lot of good Puppet
> >> engineers and Puppet OpenStack team.
> >>
> >> We had this kind of discussion at the Summit (in Vancouver and also
> >> Paris, and even before). Now I would like to officialy know if you are
> >> interested or not to be more involved.
> >> I'm also open at any feedback about Puppet OpenStack group and if
> >> something blocks you to contribute more.
> >>
> >> We have the same goals, having Puppet modules better. I think it can be
> >> win/win: you have less diff with upstream and we have more hands in our
> >> module maintenance.
> >> Thank you for reading so far, and I'm looking forward to reading from
> you.
> >>
> >> Best regards,
> >> --
> >> Emilien Macchi
> >>
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> > --
> > Sanjay Upadhyay
> > http://saneax.blogspot.com
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150611/0cec4891/attachment.html>