On Thu, Aug 28, 2014 at 12:22 PM, Richard Woo richardwoo2...@gmail.com
wrote:
I have another question about incubator proposal, for CLI and GUI. Do we
imply that the incubator feature will need to branch python-neutron client,
Horizon, and or Nova ( if changes are needed)?
This is as good
On 08/27/2014 04:28 PM, Kevin Benton wrote:
What are you talking about? The only reply was from me clarifying that
one of the purposes of the incubator was for components of neutron that
are experimental but are intended to be merged.
Right. The special unicorns.
In that case it might
not
Right. The special unicorns.
Repeating this without defining it isn't helping anything.
b) The experimental piece of code intends to replace whole-hog a large
chunk of Neutron's existing codebase, or:
In the DVR example I gave this is is the only relevant reason. Regardless
of how well the
On Aug 28, 2014, at 10:45 AM, Jay Pipes jaypi...@gmail.com wrote:
On 08/27/2014 04:28 PM, Kevin Benton wrote:
What are you talking about? The only reply was from me clarifying that
one of the purposes of the incubator was for components of neutron that
are experimental but are intended to be
I have another question about incubator proposal, for CLI and GUI. Do we
imply that the incubator feature will need to branch python-neutron client,
Horizon, and or Nova ( if changes are needed)?
On Tue, Aug 26, 2014 at 7:09 PM, James E. Blair cor...@inaugust.com wrote:
Hi,
After reading
On 2014-08-28 08:31:26 -0700 (-0700), Kevin Benton wrote:
[...]
DVR completely changed the reference L3 service plugin, which
lives in the main tree.
A well-defined, versioned internal API would not have helped any
of the issues I brought up.
[...]
Except, perhaps, insofar as that (in some
Yes, in theory all of the plugins should be removable from the core neutron
repo. So then it would only need to be responsible for the APIs, db models,
etc. However, IIRC there are no plans to move any reference plugins from
the tree.
On Thu, Aug 28, 2014 at 11:20 AM, Jeremy Stanley
On Wed, Aug 27, 2014 at 2:44 PM, Kevin Benton blak...@gmail.com wrote:
Incubator doesn't mean being kicked out of tree, it just mean that the
API and resource model needs to be baked for fast iteration, and can't be
put in tree temporarily.
That was exactly my point about developing a major
Flag is only for admin use, tenant can't see it, and the default policy
for router is setup by config file.
It's still a public API that will have to follow a deprecation cycle. If a
new API was going to be introduced for admins to control the distributed
nature of routers, it would have been
On 08/26/2014 07:09 PM, James E. Blair wrote:
Hi,
After reading https://wiki.openstack.org/wiki/Network/Incubator I have
some thoughts about the proposed workflow.
We have quite a bit of experience and some good tools around splitting
code out of projects and into new projects. But we don't
What are you talking about? The only reply was from me clarifying that one
of the purposes of the incubator was for components of neutron that are
experimental but are intended to be merged. In that case it might not make
sense to have a life cycle of their own in another repo indefinitely.
On
I agree that components isolated to one service or something along those
lines where there is a clear plugin point in Neutron, it might make sense
to separate them permanently. However, at that point why even bother with
the Neutron incubator when a new project can be started?
The feature branch
Quoting Stefano from a different thread [0]:
The rationale for the separate repository is that Neutron's code needs a
lot of love for the *existing* codebase, before new features can be
added (and before core team can accept more responsibilities for it).
But progress is unstoppable: new
On 2014-08-27 16:05:36 -0700 (-0700), Joe Gordon wrote:
We have feature branches? How do we use them? I am not even sure
if feature branches were evaluated as an option when the incubator
was proposed.
Keystone's new API used a feature branch, the EC work in Swift did,
so did the Gearman
Also note that one of the features of the incubator is that it can be
packaged/released independently (like python-neutronclient) and a feature
branch is not designed for that workflow.
Regards,
Mandeep
On Wed, Aug 27, 2014 at 4:55 PM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2014-08-27
On 2014-08-27 16:53:39 -0700 (-0700), Clark Boylan wrote:
[...]
I thought there was a wiki article on how they work but I can't
find it. Maybe someone else can link it here.
[...]
https://wiki.openstack.org/wiki/GerritJenkinsGit#Merge_Commits
--
Jeremy Stanley
On 2014-08-27 16:59:54 -0700 (-0700), Mandeep Dhami wrote:
Also note that one of the features of the incubator is that it can be
packaged/released independently (like python-neutronclient) and a feature
branch is not designed for that workflow.
Good point, and that definitely is a reason to
On Wed, Aug 27, 2014 at 6:59 PM, Mandeep Dhami dh...@noironetworks.com
wrote:
Also note that one of the features of the incubator is that it can be
packaged/released independently (like python-neutronclient) and a feature
branch is not designed for that workflow.
Which is a good reason to
On Wed, Aug 27, 2014 at 5:06 PM, Jeremy Stanley fu...@yuggoth.org wrote:
Good point, and that definitely is a reason to just keep those
pieces in their own separate Git repositories outside of the core
Neutron repository in perpetuity (even after they graduate from
incubation). One package
Hi,
After reading https://wiki.openstack.org/wiki/Network/Incubator I have
some thoughts about the proposed workflow.
We have quite a bit of experience and some good tools around splitting
code out of projects and into new projects. But we don't generally do a
lot of importing code into
From what I understand, the intended projects for the incubator can't
operate without neutron because they are just extensions/plugins/drivers.
For example, if the DVR modifications to the reference reference L3 plugin
weren't already being developed in the tree, DVR could have been developed
in
Incubator doesn't mean being kicked out of tree, it just mean that the API
and resource model needs to be baked for fast iteration, and can't be put
in tree temporarily. As kyle has said, incubator is not talking about
moving 3rd drivers out of tree, which is in another thread.
For DVR, as it has
22 matches
Mail list logo
