Open Stack

On Mon, Nov 18, 2013 at 12:50 AM, Pedro Roque Marques <
pedro.r.marques at gmail.com> wrote:

> Does it address the catch-22 problem that a Neutron reviewer asks for the
> plugin to be accepted upstream into devstack as pre-condition for
> acceptance whether a devstack reviewer as for the plugin to be upstreamed
> into Neutron first ?
>

Yes, that is the intention.  However, you have to do the work of
integrating it, it isn't going to go into the existing gate right off, if
ever.  Mark's message this morning[1] lays it out from their point of view.
 He mentions using the CI third party testing integration [2] in the
'Testing Requirements' section.  Ideally, you get that running with a trunk
DevStack plus your plugin against the Nova and Neutron branches with your
contrail plugin/mods.

Also, DevStack does not install support services that are not packaged in
> the underlying distro.  Look at Docker's split between the support
> service(s) that start before stack.sh runs and the parts that specifically
> configure Nova.
>
>
> Can you please elaborate as to what are "support services" in this context
> ?
>
> Things required of the running environment that are not shipped with the
OS need to be in place before stack.sh runs.  i.e., you are compiling a
kernel module.  DevStack's workflow is not an appropriate place to do that.
 As another example, we have an install script for Docker that takes care
of their service installation and startup that is up to the end-user ot
have run before running stack.sh.  This keeps us (DevStack) out of the
business of trying to maintain something we {can not/do not} test.


> The patches that are being applied by the script have been submitted for
> review. Using a patch approach is helpful in attempting to demonstrate that
> the resulting code works against the master branch of Nova/Neutron.
>

The OpenStack methodology for this is to fork the repo and create a branch
of the source tree with your patch and test against that.

For the gate testing, DevStack actually does NONE of the source branch
setup work.  A CI component names Zuul does all of that, pulling branches
and repos as it requires to set up the correct environment.  Patching the
source trees after that destroys the integrity of what
Gerrit/Jenkins/devstack-gate thinks it is testing.



> Can you please suggest a sequence of steps... ?
> I understand that it makes sense to follow the plugin documentation
> specified above. That would be the first step. But it is not clear to me
> how to break it down further while having something that is still
> functional.
>

If you get it running as a plugin and there are no changes required to the
existing DevStack files then you are done.  Any changes to DevStack
indicate a shortcoming in the plugin interface and may need to be
generalized anyway.

dt

[1]
http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg08700.html
[2] http://ci.openstack.org/third_party.html


-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131118/883eb92b/attachment.html>