Sean Dague <s...@dague.net> wrote:
On 11/13/2015 04:08 AM, Ihar Hrachyshka wrote:
Armando M. <arma...@gmail.com> wrote:
On 12 November 2015 at 20:24, Sean M. Collins <s...@coreitpro.com> wrote:
On Thu, Nov 12, 2015 at 05:55:51PM EST, Ihar Hrachyshka wrote:
I also believe that the first step to get the job set is making
neutron own
its grenade future, by migrating to grenade plugin maintained in
neutron
tree.
I'd like to see what Sean Dague thinks of this - my worry is that if we
start pulling things into Neutron we lose valuable insight from people
who know a lot about Grenade.
Not to mention, Sean and I have had conversations about trying to get
Neutron as the default for DevStack - we can't just take our ball and go
in our own corner.
Agreed. (I feel like) we had a good discussion at the summit about
this: we clearly have key pieces that are and will stay within the
realm of both devstack and grenade.
Agreed that it’s worth clarifying with grenade folks what should be
included in grenade plugin, and what belongs to core grenade; and where
multinode ‘partial’ job stands in this regard.
Ok, I top responded with the details of the job, honestly I think it's
just a project-config change to get up and running, and then hacking at
the bugs that fall out.
Much like with devstack, I think that neutron core service configuration
/ upgrade should stay in the tree. We want more people familiar with it,
and I really do want to get us over to Neutron by default some day
(hopefully not too far off). I'm quite hopefully of the work Sean
Collins is doing there.
The advanced services should all be in plugins. I think we fully removed
them from base grenade testing last cycle.
There are lots of coupling in the set of projects that need to cooperate
to get computes on the network, so debugging and fixing those issues
often depends on understanding the whole collection. Having the code
that does that and the ability to bugfix in one place means we can turn
around breaks faster. It also means that everyone in the ecosystem
becomes familiar with all of that by default.
Cool, thanks for clarification. I was under impression that all projects
should adopt plugins, not just those considered not part of core. Also glad
to hear it’s a matter of infra patch for a new job. I think we’ll roll it
from here.
Thanks
Ihar
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
