On Tue, Apr 22, 2014 at 6:49 PM, Isaku Yamahata <[email protected]> wrote: > Hi. Keyle, thank you for starting this discussion to make progress. > > On Mon, Apr 21, 2014 at 08:41:19PM -0500, > Kyle Mestery <[email protected]> wrote: > >> On Mon, Apr 21, 2014 at 4:20 PM, Doug Hellmann >> <[email protected]> wrote: >> > On Mon, Apr 21, 2014 at 3:07 PM, Kyle Mestery <[email protected]> >> > wrote: >> >> For the upcoming Summit there are 3 sessions filed around "Service >> >> VMs" in Neutron. After discussing this with a few different people, >> >> I'd like to propose the idea that the "Service VM" work be moved out >> >> of Neutron and into it's own project on stackforge. There are a few >> >> reasons for this: >> > >> > How long do you anticipate the project needing to live on stackforge >> > before it can move to a place where we can introduce symmetric gating >> > with the projects that use it? > > To be honest, I'm not sure how long it will take. We will see after > the summit. > At this point, my feeling is > - before the summit, preliminary discussion, preparation for the summit > - discuss at the summit (including project name?) > - after the summit, create its own project on stackforge and start > its own activity like weekly IRC meeting. > import neutron code repo as the first code base, and cleaning/stripping > it up and so on. > > What do you think?
What I'm worried about is having neutron (or another project) depending on a quickly-evolving stackforge project, and having that cause instability in tests. We can't (by policy) gate an integrated project on a stackforge project, but we may be able to set up some test jobs on the new project to warn when changes there are likely to break the app. Doug PS - We have some tools in oslo that may help create a better starting point than forking the entire neutron repository. In particular, oslo-incubator/tools/graduate.sh shows how to extract the git history for a subset of a repository. It would need to be altered for your case, since it assumes you're building a new oslo library repository from the oslo-incubator, but you could use it as an example of how to do the sort of extraction you actually need. >> The patches for this (look at the BP here [1]) have been in review for >> a while now as WIP. I think it's reasonable to expect that moving this >> to stackforge would let the authors and others interested collaborate >> faster. I expect this would take a cycle on stackforge before we could >> talk about other projects using this. But honestly, that's a better >> question for Isaku and Bob. > > In fact, this is not the first time that such opinion is claimed. > But this is the first time to get much feedback. > It's good timing to give it a consideration. > > Just to make it clear, the session slot will be allocated to discuss on > this? At least it would be valuable to share the current status and > to discuss on its future direction, and which part will be separated out > and which part will remain in Neutron. > > >> > Who is going to drive the development work? >> > >> For that, I'm thinking Isaku and Bob (copied above) would be the ones >> driving it. But anyone else who is interested should feel free to jump >> in as well. > > I'm willing to take the responsibility (and to share it with Bob). > Also others to help are very welcome. > > thanks, > >> Thanks, >> Kyle >> >> [1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms >> >> > Doug >> > >> >> >> >> 1. There is nothing Neutron specific about service VMs. >> >> 2. Service VMs can perform services for other OpenStack projects. >> >> 3. The code is quite large and may be better served being inside it's >> >> own project. >> >> >> >> Moving the work out of Neutron and into it's own project would allow >> >> for separate velocity for this project, and for code to be shared for >> >> the Service VM work for things other than Neutron services. >> >> >> >> I'm starting this email thread now to get people's feedback on this >> >> and see what comments other have. I've specifically copied Isaku and >> >> Bob, who both filed summit sessions on this and have done a lot of >> >> work in this area to date. >> >> >> >> Thanks, >> >> Kyle >> >> >> >> _______________________________________________ >> >> OpenStack-dev mailing list >> >> [email protected] >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > [email protected] >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- > Isaku Yamahata <[email protected]> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
