[openstack-dev] [fuel][puppet] The state of collaboration: 5 weeks

Alex Schultz aschultz at mirantis.com
Mon Jul 20 15:24:15 UTC 2015


>
> As a new contributor to any openstack project, this is the first thing I
> do.  Find out when the weekly meetings is, attend and monitor the
> conversion.  Almost always there is an open discussion at the end of the
> weekly business.
>
> Going back through the last 5 weeks of irclogs[1], I couldn't find any
> references to 'fuel'.  I'm not trying to lay fault or blame, but perhaps a
> something can be added to the agenda[2] each week giving a status update on
> the puppet-fuel progress.
>
> Over in openstack-infra we have a downstream-puppet effort that has been
> spanning more then 6months now. Each week downstream developers raise any
> new issues or code reviews that need eyes, for the most part I think it has
> worked very well.
>
> I think Mirantis / Fuel could do the same, a weekly update to give an
> update on the effort. Any issues that need more eyes on, and patchsets that
> have stalled.
>
> Thoughts?
>
> [1] http://eavesdrop.openstack.org/meetings/puppet_openstack/
> [2] https://wiki.openstack.org/wiki/Meetings/PuppetOpenStack



So I know we had fuel members as a part of the meetings over the last few
weeks[0][1]. I think there is some mis-understanding of how fuel uses the
upstream modules.  Honestly, fuel is more like an operator in the way we
are consuming these modules.   The fuel-library repository is not a normal
puppet module, it's more of an environment role/profile setup specifically
to act in concert with the other fuel projects.  At least from my view
point, the fuel team isn't necessarily trying to make large sweeping
changes in many of the core upstream modules.  There are a few instances
where I would say there have been some larger changes, but overall I think
the effort is to try and introduce additional ways to utilize the modules.
Overall we're just trying to get them to work in our reference
architecture[2].  Much of the issue with the upstream code being in the
fuel-library repository is being worked on but it takes time to address all
the issues by getting changes upstreamed, adjusting the usage, and being
able to switch. I have personally made a large push[3] to start this
endeavor. But as I mentioned early on in the previous email thread[4], help
from others would be welcomed as this effort requires people from both
sides to be successful.  I know for a fact that I personally have been
trying to push from the fuel-library side to make sure that we can consume
upstream modules as much as possible.  I feel saddened by this thread
because I know I'm investing effort and pushing to correct the things being
brought up but they aren't being seen or acknowledged as actually
happening. I don't think anyone disagrees that we need to fix the state of
fuel-library, but there needs to be some understanding that this will take
time and we are in the process of making the requested changes.  An effort
is being made from the fuel side, and I feel that the original email in
this thread was sent to make sure that it is being recognized and make sure
we are all working towards the previously discussed expectations.

Thanks,
-Alex

[0]
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-07-14-15.00.txt
- xarses
[1]
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-07-07-15.00.txt
- xarses, mwhahaha
[2]
https://docs.mirantis.com/openstack/fuel/fuel-6.1/reference-architecture.html#ref-arch
[3] https://blueprints.launchpad.net/fuel/+spec/fuel-puppet-librarian
[4] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066675.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150720/932dea7a/attachment.html>


More information about the OpenStack-dev mailing list