Open Stack

Hey Matt & other OpenStack folks,

I agree that pinging #fuel-dev would not be scalable for every
request. But I think it was more of if someone notices something is
fixed in fuel-library but not in an OpenStack puppet library, then by
all means come and poke someone so we can try and get it in to
upstream if we failed to do so.  As for the inclusion of the OpenStack
puppet modules within fuel-library, I also am not a fan of the way it
is done today, but I'm new here so I can't speak for previous
decisions.  It would be nice if it followed a similar model to how the
OpenStack python libraries are consumed. Leveraging something like
Librarian where we can just increment version numbers or swap out
repositories would be a nice option.  That being said, there's a lot
more tooling that is required in order to get to that and it's hard to
prioritize things like that.  Puppet modules aren't traditionally
packaged via rpms/debs/etc so it's kinda of hard to do that dependency
checking like we do for all the OpenStack services.  I, personally and
I'm sure there are others, would welcome any assistance or ideas on
the best way to do something like that.  I think this is where some
community help would be much appreciated so that we can get to that
point.  I'd be happy to help with trying to push some of these ideas
forward.  I think there are probably others who detest having to
manually pull in module updates every few months and battle test and
merge issues, so anything to make everyones' lives easier would be
welcomed.

Thanks,
-Alex Schultz

On Thu, Jun 11, 2015 at 4:03 PM, Matt Fischer <matt at mattfischer.com> 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 <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
>
>
>
> __________________________________________________________________________
> 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
>