[openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

[Neil Jerram]

Hi there.  I've been looking into a tricky point, and hope I can succeed
in expressing it clearly here...

I believe it is the case, even when using a committedly Neutron-based
networking implementation, that Nova is still involved a little bit in
the networking setup logic.  Specifically I mean the plug() and unplug()
operations, whose implementations are provided by *VIFDriver classes for
the various possible hypervisors.

For example, for the libvirt hypervisor, LibvirtGenericVIFDriver
typically implements plug() by calling create_tap_dev() to create the
TAP device, and then plugging into some form of L2 bridge.

Does this logic actually have to be in Nova?  For a Neutron-based
networking implementation, it seems to me that it should also be
possible to do this in a Neutron agent (obviously running on the compute
node concerned), and that - if so - that would be preferable because it
would enable more Neutron-based experimentation without having to modify
any Nova code.

Specifically, therefore, I wonder if we could/should add a "do-nothing"
value to the set of Nova VIF types (VIF_TYPE_NOOP?), and implement
plug()/unplug() for that value to do nothing at all, leaving all setup
to the Neutron agent?  And then hopefully it should never be necessary
to introduce further Nova VIF type support ever again...

Am I missing something that really makes that not fly?  Two possible
objections occurs to me, as follows, but I think they're both
surmountable.

1. When the port is created in the Neutron DB, and handled (bound etc.)
   by the plugin and/or mechanism driver, the TAP device name is already
   present at that time.

   I think this is still OK because Neutron knows anyway what the TAP
   device name _will_ be, even if the actual TAP device hasn't been
   created yet.

2. With some agent implementations, there isn't a direct instruction,
   from the plugin to the agent, to say "now look after this VM /
   port".  Instead the agents polls the OS for new TAP devices
   appearing.  Clearly, then, if there isn't something other than the
   agent that creates the TAP device, any logic in the agent will never
   be triggered.

   This is certain a problem.  For new networking experimentation,
   however, we can write agent code that is directly instructed by the
   plugin, and hence (a) doesn't need to poll (b) doesn't require the
   TAP device to have been previously created by Nova - which I'd argue
   is preferable.

Thoughts?

(FYI my context is that I've been working on a networking implementation
where the TAP device to/from a VM should _not_ be plugged into a bridge
- and for that I've had to make a Nova change even though my team's aim
was to do the whole thing in Neutron.

I've proposed a spec for the Nova change that plugs a TAP interface
without bridging it (https://review.openstack.org/#/c/130732/), but that
set me wondering about this wider question of whether such Nova changes
should still be necessary...)

Many thanks,
 Neil

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

[Neil Jerram]

Kevin Benton  writes:

> What you are proposing sounds very reasonable. If I understand
> correctly, the idea is to make Nova just create the TAP device and get
> it attached to the VM and leave it 'unplugged'. This would work well
> and might eliminate the need for some drivers. I see no reason to
> block adding a VIF type that does this.

I was actually floating a slightly more radical option than that: the
idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does
absolutely _nothing_, not even create the TAP device.

(My pending Nova spec at https://review.openstack.org/#/c/130732/
proposes VIF_TYPE_TAP, for which Nova _does_ creates the TAP device, but
then does nothing else - i.e. exactly what you've described just above.
But in this email thread I was musing about going even further, towards
providing a platform for future networking experimentation where Nova
isn't involved at all in the networking setup logic.)

> However, there is a good reason that the VIF type for some OVS-based
> deployments require this type of setup. The vSwitches are connected to
> a central controller using openflow (or ovsdb) which configures
> forwarding rules/etc. Therefore they don't have any agents running on
> the compute nodes from the Neutron side to perform the step of getting
> the interface plugged into the vSwitch in the first place. For this
> reason, we will still need both types of VIFs. 

Thanks.  I'm not advocating that existing VIF types should be removed,
though - rather wondering if similar function could in principle be
implemented without Nova VIF plugging - or what that would take.

For example, suppose someone came along and wanted to implement a new
OVS-like networking infrastructure?  In principle could they do that
without having to enhance the Nova VIF driver code?  I think at the
moment they couldn't, but that they would be able to if VIF_TYPE_NOOP
(or possibly VIF_TYPE_TAP) was already in place.  In principle I think
it would then be possible for the new implementation to specify
VIF_TYPE_NOOP to Nova, and to provide a Neutron agent that does the kind
of configuration and vSwitch plugging that you've described above.

Does that sound correct, or am I missing something else?

>> 1 .When the port is created in the Neutron DB, and handled (bound
> etc.)
> by the plugin and/or mechanism driver, the TAP device name is already
> present at that time.
>
> This is backwards. The tap device name is derived from the port ID, so
> the port has already been created in Neutron at that point. It is just
> unbound. The steps are roughly as follows: Nova calls neutron for a
> port, Nova creates/plugs VIF based on port, Nova updates port on
> Neutron, Neutron binds the port and notifies agent/plugin/whatever to
> finish the plumbing, Neutron notifies Nova that port is active, Nova
> unfreezes the VM. 
>
> None of that should be affected by what you are proposing. The only
> difference is that your Neutron agent would also perform the
> 'plugging' operation.

Agreed - but thanks for clarifying the exact sequence of events.

I wonder if what I'm describing (either VIF_TYPE_NOOP or VIF_TYPE_TAP)
might fit as part of the "Nova-network/Neutron Migration" priority
that's just been announced for Kilo.  I'm aware that a part of that
priority is concerned with live migration, but perhaps it could also
include the goal of future networking work not having to touch Nova
code?

Regards,
Neil

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

[Neil Jerram]

Ian Wells  writes:

> On 4 December 2014 at 08:00, Neil Jerram 
> wrote:
>
> Kevin Benton  writes:
> I was actually floating a slightly more radical option than that:
> the
> idea that there is a VIF type (VIF_TYPE_NOOP) for which Nova does
> absolutely _nothing_, not even create the TAP device.
> 
>
> Nova always does something, and that something amounts to 'attaches
> the VM to where it believes the endpoint to be'. Effectively you
> should view the VIF type as the form that's decided on during
> negotiation between Neutron and Nova - Neutron says 'I will do this
> much and you have to take it from there'. (In fact, I would prefer
> that it was *more* of a negotiation, in the sense that the hypervisor
> driver had a say to Neutron of what VIF types it supported and
> preferred, and Neutron could choose from a selection, but I don't
> think it adds much value at the moment and I didn't want to propose a
> change just for the sake of it.) I think you're just proposing that
> the hypervisor driver should do less of the grunt work of connection.
>
> Also, libvirt is not the only hypervisor driver and I've found it
> interesting to nose through the others for background reading, even if
> you're not using them much.
>
> For example, suppose someone came along and wanted to implement a
> new
> OVS-like networking infrastructure? In principle could they do
> that
> without having to enhance the Nova VIF driver code? I think at the
> moment they couldn't, but that they would be able to if
> VIF_TYPE_NOOP
> (or possibly VIF_TYPE_TAP) was already in place. In principle I
> think
> it would then be possible for the new implementation to specify
> VIF_TYPE_NOOP to Nova, and to provide a Neutron agent that does
> the kind
> of configuration and vSwitch plugging that you've described above.
> 
>
> At the moment, the rule is that *if* you create a new type of
> infrastructure then *at that point* you create your new VIF plugging
> type to support it - vhostuser being a fine example, having been
> rejected on the grounds that it was, at the end of Juno, speculative.
> I'm not sure I particularly like this approach but that's how things
> are at the moment - largely down to not wanting to add code that isn;t
> used and therefore tested.
>
> None of this is criticism of your proposal, which sounds reasonable; I
> was just trying to provide a bit of context.

Many thanks for your explanations; I think I'm understanding this more
fully now.  For example, I now see that, when using libvirt, Nova has to
generate config that describes all aspects of the VM to launch,
including how the VNIC is implemented and how it's bound to networking
on the host.  Also different hypervisors, or layers like libvirt, may go
to different lengths as regards how far they connect the VNIC to some
form of networking on the host, and I can see that Nova would want to
normalize that, i.e. to ensure that a predictable level of connectivity
has always been achieved, regardless of hypervisor, by the time that
Nova hands over to someone else such as Neutron.

Therefore I see now that Nova _must_ be involved to some extent in VIF
plugging, and hence that VIF_TYPE_NOOP doesn't fly.

For a minimal, generic implementation of an unbridged TAP interface,
then, we're back to VIF_TYPE_TAP as I've proposed in
https://review.openstack.org/#/c/130732/.  I've just revised and
reuploaded this, based on the insight provided by this ML thread, and
hope people will take a look.

Many thanks,
 Neil


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

[Neil Jerram]

Kevin Benton  writes:

> I see the difference now. 
> The main concern I see with the NOOP type is that creating the virtual
> interface could require different logic for certain hypervisors. In
> that case Neutron would now have to know things about nova and to me
> it seems like that's slightly too far the other direction. 

Many thanks, Kevin.  I see this now too, as I've just written more fully
in my response to Ian.

Based on your and others' insight, I've revised and reuploaded my
VIF_TYPE_TAP spec, and hope it's a lot clearer now.

Regards,
 Neil

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron] Boundary between Nova and Neutron involvement in network setup?

[Neil Jerram]

Hi Wu,

As I've also written in a comment at
https://review.openstack.org/#/c/130732/6, it appears that
VIF_TYPE_VHOSTUSER is already covered by the approved spec at
https://review.openstack.org/#/c/96138/.

Given that, is there any reason to consider adding VIF_TYPE_VHOSTUSER
into the VIF_TYPE_TAP spec as well?

Thanks,
Neil


Wuhongning  writes:

> Hi Neil,
>
> @Neil, could you please also add VIF_TYPE_VHOSTUSER in your spec (as I
> commented on it)? There has been active VHOSTUSER discuss in JUNO nova
> BP, and it's the same usefulness as VIF_TYPE_TAP.
>
> Best Regards
> Wu
> ____
> From: Neil Jerram [neil.jer...@metaswitch.com]
> Sent: Saturday, December 06, 2014 10:51 AM
> To: Kevin Benton
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova][neutron] Boundary between Nova and  
> Neutron involvement in network setup?
>
> Kevin Benton  writes:
>
>> I see the difference now.
>> The main concern I see with the NOOP type is that creating the virtual
>> interface could require different logic for certain hypervisors. In
>> that case Neutron would now have to know things about nova and to me
>> it seems like that's slightly too far the other direction.
>
> Many thanks, Kevin.  I see this now too, as I've just written more fully
> in my response to Ian.
>
> Based on your and others' insight, I've revised and reuploaded my
> VIF_TYPE_TAP spec, and hope it's a lot clearer now.
>
> Regards,
>  Neil
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

[Neil Jerram]

"Daniel P. Berrange"  writes:

> Failing that though, I could see a way to accomplish a similar thing
> without a Neutron launched agent. If one of the VIF type binding
> parameters were the name of a script, we could run that script on
> plug & unplug. So we'd have a finite number of VIF types, and each
> new Neutron mechanism would merely have to provide a script to invoke
>
> eg consider the existing midonet & iovisor VIF types as an example.
> Both of them use the libvirt "ethernet" config, but have different
> things running in their plug methods. If we had a mechanism for
> associating a "plug script" with a vif type, we could use a single
> VIF type for both.
>
> eg iovisor port binding info would contain
>
>   vif_type=ethernet
>   vif_plug_script=/usr/bin/neutron-iovisor-vif-plug
>
> while midonet would contain
>
>   vif_type=ethernet
>   vif_plug_script=/usr/bin/neutron-midonet-vif-plug
>
>
> And so you see implementing a new Neutron mechanism in this way would
> not require *any* changes in Nova whatsoever. The work would be entirely
> self-contained within the scope of Neutron. It is simply a packaging
> task to get the vif script installed on the compute hosts, so that Nova
> can execute it.
>
> This is essentially providing a flexible VIF plugin system for Nova,
> without having to have it plug directly into the Nova codebase with
> the API & RPC stability constraints that implies.

I agree that this is a very promising idea.  But... what about the
problem that it is libvirt-specific?  Does that matter?

Regards,
Neil


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Kilo specs review day

[Neil Jerram]

Hi Joe,

Joe Gordon  writes:

> In preparation, I put together a nova-specs dashboard:
>
> https://review.openstack.org/141137
>
> https://review.openstack.org/#/dashboard/?foreach=project%3A%5Eopenstack%2Fnova-specs+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D-1+label%3AVerified%3E%3D1%252cjenkins+NOT+label%3ACode-Review%3E%3D-2%252cself+branch%3Amaster&title=Nova+Specs&&Your+are+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=reviewer%3Aself&Needs+final+%2B2=label%3ACode-Review%3E%3D2+NOT%28reviewerin%3Anova-specs-core+label%3ACode-Review%3C%3D-1%29+limit%3A100&Passed+Jenkins%2C+Positive+Nova-Core+Feedback=NOT+label%3ACode-Review%3E%3D2+%28reviewerin%3Anova-core+label%3ACode-Review%3E%3D1%29+NOT%28reviewerin%3Anova-core+label%3ACode-Review%3C%3D-1%29+limit%3A100&Passed+Jenkins%2C+No+Positive+Nova-Core+Feedback%2C+No+Negative+Feedback=NOT+label%3ACode-Review%3C%3D-1+NOT+label%3ACode-Review%3E%3D2+NOT%28reviewerin%3Anova-core+label%3ACode-Review%3E%3D1%29+limit%3A100&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+7+days%29=NOT+label%3ACode-Review%3C%3D2+age%3A7d&Some+negative
 
+feedback%2C+might+still+be+worth+commenting=label%3ACode-Review%3D-1+NOT+label%3ACode-Review%3D-2+limit%3A100&Dead+Specs=label%3ACode-Review%3C%3D-2

My Nova spec (https://review.openstack.org/#/c/130732/) does not appear
on this dashboard, even though I believe it's in good standing and - I
hope - close to approval.  Do you know why - does it mean that I've set
some metadata field somewhere wrongly?

Many thanks,
 Neil

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Kilo specs review day

[Neil Jerram]

Joe Gordon  writes:

> On Mon, Dec 15, 2014 at 8:46 AM, Radoslav Gerganov
>  wrote:
>
> On 12/15/2014 12:54 PM, Neil Jerram wrote:
> 
> My Nova spec (https://review.openstack.org/#/c/130732/) does not
> appear
> on this dashboard, even though I believe it's in good standing
> and - I
> hope - close to approval. Do you know why - does it mean that
> I've set
> some metadata field somewhere wrongly?
> 
> 
>
> The dashboard doesn't show your own specs. You have to remove
> "+NOT+owner%3Aself" from the URL to see them.

Ah, as simple an explanation and solution as that.  Thanks!

> The latest iteration of the dashboard
> (https://review.openstack.org/#/c/130732/) shows your own specs:
>
> https://review.openstack.org/#/dashboard/?foreach=project%3Aopenstack%2Fnova%252Dspecs+status%3Aopen+NOT+label%3AWorkflow%3C%3D%252D1+branch%3Amaster+NOT+owner%3Aself&title=Nova+Specs&Your+are+a+reviewer%252c+but+haven%27t+voted+in+the+current+revision=reviewer%3Aself+NOT+label%3ACode%252DReview%3E%3D%252D2%252cself+label%3AVerified%3E%3D1%252cjenkins&Not+blocked+by+%252D2s=NOT+label%3ACode%252DReview%3C%3D%252D2+NOT+label%3ACode%252DReview%3E%3D2+NOT+label%3ACode%252DReview%3E%3D%252D2%252cself+label%3AVerified%3E%3D1%252cjenkins&No+votes+and+spec+is+%3E+1+week+old=NOT+label%3ACode%252DReview%3E%3D%252D2+age%3A7d+label%3AVerified%3E%3D1%252cjenkins&Needs+final+%2B2=label%3ACode%252DReview%3E%3D2+NOT+label%3ACode%252DReview%3E%3D%252D2%252cself+label%3AVerified%3E%3D1%252cjenkins&Broken+Specs+%28doesn%27t+pass+Jenkins%29=label%3AVerified%3C%3D%252D1%252cjenkins&Dead+Specs+%28blocked+by+a+%252D2%29=label%3ACode%252DReview%3C%3D%252D2

Actually that URL still doesn't.  But this one does:

https://review.openstack.org/#/dashboard/?foreach=project%3Aopenstack%2Fnova%252Dspecs+status%3Aopen+NOT+label%3AWorkflow%3C%3D%252D1+branch%3Amaster&title=Nova+Specs&Your+are+a+reviewer%252c+but+haven%27t+voted+in+the+current+revision=reviewer%3Aself+NOT+label%3ACode%252DReview%3E%3D%252D2%252cself+label%3AVerified%3E%3D1%252cjenkins&Not+blocked+by+%252D2s=NOT+label%3ACode%252DReview%3C%3D%252D2+NOT+label%3ACode%252DReview%3E%3D2+NOT+label%3ACode%252DReview%3E%3D%252D2%252cself+label%3AVerified%3E%3D1%252cjenkins&No+votes+and+spec+is+%3E+1+week+old=NOT+label%3ACode%252DReview%3E%3D%252D2+age%3A7d+label%3AVerified%3E%3D1%252cjenkins&Needs+final+%2B2=label%3ACode%252DReview%3E%3D2+NOT+label%3ACode%252DReview%3E%3D%252D2%252cself+label%3AVerified%3E%3D1%252cjenkins&Broken+Specs+%28doesn%27t+pass+Jenkins%29=label%3AVerified%3C%3D%252D1%252cjenkins&Dead+Specs+%28blocked+by+a+%252D2%29=label%3ACode%252DReview%3C%3D%252D2

Thanks for your reply and for generating this dashboard!

   Neil


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change

[Neil Jerram]

Hi all,

Following the approval for Neutron vendor code decomposition
(https://review.openstack.org/#/c/134680/), I just wanted to comment
that it appears to work fine to have an ML2 mechanism driver _entirely_
out of tree, so long as the vendor repository that provides the ML2
mechanism driver does something like this to register their driver as a
neutron.ml2.mechanism_drivers entry point:

  setuptools.setup(
  ...,
  entry_points = {
  ...,
  'neutron.ml2.mechanism_drivers': [
  'calico = xyz.openstack.mech_xyz:XyzMechanismDriver',
  ],
  },
  )

(Please see
https://github.com/Metaswitch/calico/commit/488dcd8a51d7c6a1a2f03789001c2139b16de85c
for the complete change and detail, for the example that works for me.)

Then Neutron and the vendor package can be separately installed, and the
vendor's driver name configured in ml2_conf.ini, and everything works.

Given that, I wonder:

- is that what the architects of the decomposition are expecting?

- other than for the reference OVS driver, are there any reasons in
  principle for keeping _any_ ML2 mechanism driver code in tree?

Many thanks,
 Neil

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Neil Jerram]

Stefano Maffulli  writes:

> On 12/09/2014 04:11 PM,  by wrote:
[vad] how about the documentation in this case?... bcos it needs some
>> place to document (a short desc and a link to vendor page) or list these
>> kind of out-of-tree plugins/drivers...  just to make the user aware of
>> the availability of such plugins/driers which is compatible with so and
>> so openstack release.  
>> I checked with the documentation team and according to them, only the
>> following plugins/drivers only will get documented...
>> 1) in-tree plugins/drivers (full documentation) 
>> 2) third-party plugins/drivers (ie, one implements and follows this new
>> proposal, a.k.a partially-in-tree due to the integration module/code)...
>> 
>> *** no listing/mention about such completely out-of-tree plugins/drivers***
>
> Discoverability of documentation is a serious issue. As I commented on
> docs spec [1], I think there are already too many places, mini-sites and
> random pages holding information that is relevant to users. We should
> make an effort to keep things discoverable, even if not maintained
> necessarily by the same, single team.
>
> I think the docs team means that they are not able to guarantee
> documentation for third-party *themselves* (and has not been able, too).
> The docs team is already overworked as it is now, they can't take on
> more responsibilities.
>
> So once Neutron's code will be split, documentation for the users of all
> third-party modules should find a good place to live in, indexed and
> searchable together where the rest of the docs are. I'm hoping that we
> can find a place (ideally under docs.openstack.org?) where third-party
> documentation can live and be maintained by the teams responsible for
> the code, too.
>
> Thoughts?

I suggest a simple table, under docs.openstack.org, where each row has
the plugin/driver name, and then links to the documentation and code.
There should ideally be a very lightweight process for vendors to add
their row(s) to this table, and to edit those rows.

I don't think it makes sense for the vendor documentation itself to be
under docs.openstack.org, while the code is out of tree.

Regards,
Neil


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Kilo Release Status - just passed spec freeze

[Neil Jerram]

John Garbutt  writes:

> Hi all,
>
> With the release of kilo-1 we have frozen the approval of new specs for kilo.
>
> This is to make sure we can focus on our agreed kilo priorities:
> http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html
>
> As always, there are exceptions, here is how:
>
> 1) email ML, "[nova] Request Spec Freeze Exception" in the subject
> 2) nova-drivers will review the spec in gerrit, at normal
> 3) either the spec gets a -2 for kilo, or the spec gets approved, in
> the usual way

Hi John,

Do I need to follow this process for
https://review.openstack.org/#/c/130732/ ?  This spec was approved as of
Patch Set 7, but with some requests for minor clarifications to the
text.  When I uploaded Patch Sets 8 and 9, to make those clarifications,
it appears that those approvals were lost.

Hence I'm not clear what the situation now is - please could you advise?

> Hopefully that helps clear things up. Catch me on IRC for questions.

Ah, OK, I'll do that too!  Also planning to attend the Nova meeting on
Thursday, in case that's the right forum to discuss this.

Many thanks,
 Neil

__
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

[openstack-dev] [nova] Request Spec Freeze Exception for VIF_TYPE_TAP (https://review.openstack.org/#/c/130732/)

[Neil Jerram]

Hi all,

I'd like to request an exception for my Nova spec adding VIF_TYPE_TAP:

https://review.openstack.org/#/c/130732/

(Some history: This spec was previously approved as of Patch Set 7, but
with some requests for minor clarifications to the text.  When I
uploaded Patch Sets 8 and 9, to make those clarifications, it appears
that those approvals were lost, and the spec wasn't merged before the
recent deadline.)

The corresponding code change is available for review at:

https://review.openstack.org/#/c/146914/

Please do let me know if any further information would be helpful.

Many thanks,
 Neil

__
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

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

[Neil Jerram]

Maxime Leroy  writes:

> Ok, thank you for the details. I will look how to implement this feature.

Hi Maxime,

Did you have time yet to start looking at this?  My team now has a use
case that could be met by using vif_plug_script, so I would be
happy to help with writing the spec for that.  Would that be of interest
to you?

Thanks,
Neil

__
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

Re: [openstack-dev] [Neutron] Neutron Social Meetup in Tokyo

[Neil Jerram]

Lovely, thanks for organizing! Looking forward to it!

Neil


  Original Message
From: Akihiro Motoki
Sent: Friday, 23 October 2015 17:27
To: OpenStack Development Mailing List
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron] Neutron Social Meetup in Tokyo


Hi Neutron folks,

We are pleased to announce Neutron social meet-up in Tokyo.
Thanks Takashi and Hirofumi for the big help.

I hope many of you will be there and enjoy the time.
If you have made RSVP, don't miss it!
We recommend  to join the beginning, but come and join us even if you
arrive late.



Thursday, Oct 29 19:00-22:00
Hokkaido (北海道 品川インターシティー店)

Location:
https://www.google.com/maps/d/edit?mid=zBFFkY6dvVno.kOTkyNjZ2oU0&usp=sharing
5th floor at the "shop and restaurant building" (between A and B buildings).
It is at the opposite side of JR Shinagawa Station from the Summit side.)

Approximately it costs ~5000 (Japanese) Yen depending on the number of
folks who join.
Note that we have no sponsors.

If you have any trouble in reaching there or some question, reach me
@ritchey98 on Twitter.



See you in Tokyo!
Akihiro

__
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

__
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

Re: [openstack-dev] DevStack errors...

[Neil Jerram]

On 02/11/15 23:56, Thales wrote:
I'm trying to get DevStack to work, but am getting errors.  Is this a good list 
to ask questions for this?  I can't seem to get answers anywhere I look.   I 
tried the openstack list, but it kind of moves slow.

Thanks for any help.

Regards, John

In case it helps, I had no problem using DevStack's stable/liberty branch 
yesterday.  If you don't specifically need master, you might try that too:

  # Clone the DevStack repository.
  git clone https://git.openstack.org/openstack-dev/devstack

  # Use the stable/liberty branch.
  cd devstack
  git checkout stable/liberty

  ...

I also just looked again at your report on openstack@.  Were you using Python 
2.7?

I expect you'll have seen discussions like 
http://stackoverflow.com/questions/23176697/importerror-no-module-named-io-in-ubuntu-14-04.
  It's not obvious to me how those can be relevant, though, as they seem to 
involve corruption of an existing virtualenv, whereas DevStack I believe 
creates a virtualenv from scratch.

When you say 'on Ubuntu 14.04', are we talking a completely fresh install with 
nothing else on it?  That's the most reliable way to run DevStack - people 
normally create a fresh disposable VM for this kind of work.

Regards,
Neil

__
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

Re: [openstack-dev] [Neutron][dns]What the meaning of "dns_assignment" and "dns_name"?

[Neil Jerram]

Hi Miguel,

I’ve just been looking at this, and have deduced the following summary of the 
new dns_name and dns_assignment fields:

- dns_name is a simple name, like 'vm17'. It is a writable port field, and gets 
combined with a dns_domain that is specified elsewhere. 

- dns_assignment is a server-generated read-only field‎, holding a list of 
dicts like {'hostname': 'vm17', 'ip_address': '10.65.0.4', 'fqdn': 
'vm17.datcon.co.uk'}.

Can you confirm whether that's correct?

What is the reason (or requirement) for dns_assignment being able to specify 
hostname and fqdn on a per-IP-address basis?  Does it ever make sense for a VM 
to associate a different hostname with different NICs or IP addresses?

Many thanks,
Neil



From: Miguel Lavalle [mailto:mig...@mlavalle.com] 
Sent: 14 October 2015 04:22
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Neutron][dns]What the meaning of "dns_assignment" 
and "dns_name"?

Zhi Chang,
Thank you for your questions. We are in the process of integrating Neutron and 
Nova with an external DNS service, using Designate as the reference 
implementation. This integration is being achieved in 3 steps. What you are 
seeing is the result of only the first one. These steps are:
1) Internal DNS integration in Neutron, which merged recently: 
https://review.openstack.org/#/c/200952/. As you may know, Neutron has an 
internal DHCP / DNS service based on dnsmasq for each virtual network that you 
create. Previously, whenever you created a port on a given network, your port 
would get a default host name in dnsmasq of the form 
'host-xx-xx-xx-xx.openstacklocal.", where xx-xx-xx-xx came from the port's 
fixed ip address "xx.xx.xx.xx" and "openstacklocal" is the default domain used 
by Neutron. This name was generated by the dhcp agent. In the above mentioned 
patchset, we are moving the generation of these dns names to the Neutron 
server, with the intent of allowing the user to specify it. In order to do 
that, you need to enable it by defining in neutron.conf the 'dns_domain' 
parameter with a value different to the default 'openstacklocal'. Once you do 
that, you can create or update a port and assign a value to its 'dns_name' 
attribute. Why is this useful? Please read on.

2) External DNS integration in Neutron. The patchset is being worked now: 
https://review.openstack.org/#/c/212213/. The functionality implemented here 
allows Neutron to publish the dns_name associated with a floating ip under a 
domain in an external dns service. We are using Designate as the reference 
implementation, but the idea is that in the future other DNS services can be 
integrated.. Where does the dns name and domain of the floating ip come from? 
It can come from 2 sources. Source number 1 is the floating ip itself, because 
in this patchset we are adding a dns_name and a dns_domain attributes to it. If 
the floating ip doesn't have a dns name and domain associated with it, then 
they can come from source number 2: the port that the floating ip is associated 
with (as explained in point 1, ports now can have a dns_name attribute) and the 
port's network, since this patchset adds dns_domain to networks.
3) Integration of Nova with Neutron's DNS. I have started the implementation of 
this and over the next few days will push the code to Gerrit for first review. 
When an instance is created, nova will request to Neutron the creation of the 
corresponding port specifying the instance's hostname in the port's 'dns_name' 
attribute (as explained in point 1). If the network where that port lives has a 
dns_domain associated with it (as explained in point 2) and you assign a 
floating ip to the port, your instance's hostname will be published in the 
external dns service.
To make it clearer, here I walk you through an example that I executed in my 
devstack: http://paste.openstack.org/show/476210/
As mentioned above, we also allow the dns_name and dns_domain to be published 
in the external dns to be defined at the floating ip level. The reason for this 
is that we envision a use case where the name and ip address made public in the 
dns service are stable, regardless of the nova instance associated with the 
floating ip.
If you are attending the upcoming Tokyo summit, you could attend the following 
talk for further information:  
http://openstacksummitoctober2015tokyo.sched.org/event/5cbdd5fb4a6d080f93a5f321ff59009c#.Vh3KMZflRz2
 Looking forward to see you there!

Hope this answers your questions
Best regards
Miguel Lavalle

On Tue, Oct 13, 2015 at 9:58 AM, Zhi Chang  wrote:
Hi, all
    I install the latest devstack and create a vm by nova. I get the port's 
info which created by Neutron. I'm confused that what the meaning of column 
"dns_assignment" and column "dns_name".
    First, column "dns_assignment" is a read-only attribute. What is it used 
for? I think that this column is useless except shows DNS infomation (include 
hostname, ip, fqdn). Do

Re: [openstack-dev] DevStack errors...

[Neil Jerram]

Thanks for following up with these details.  Good news!

Neil


From: Thales [mailto:thale...@yahoo.com] 
Sent: 05 November 2015 20:16
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] DevStack errors...

Neil Jerram wrote:
"When you say 'on Ubuntu 14.04', are we talking a completely fresh install with 
nothing else on it?  That's the most reliable way to run DevStack - people 
normally create a fresh disposable VM for this kind of work."

   -- I finally got it running!   I did what you said, and created a VM.   I 
basically followed this guys video tutorial.  The only difference is I used the 
stable/liberty instead of the stable/icehouse (which I guess no longer exists). 
  It is, however, *very* slow on my machine, with 4 giga bytes and 30 GB HDD.  

   I did have some problems getting VirtualBox working (I know others are using 
VMware) with their "guest additions", because none of the standard instructions 
worked.    Some user on askubuntu.com here had the answer.  This gave me the 
bigger screen.
http://askubuntu.com/questions/451805/screen-resolution-problem-with-ubuntu-14-04-and-virtualbox



  The answer given by the guy named "Chip" and then the reply to him by "Snark" 
did the trick.   

The tutorial I used:
https://www.youtube.com/watch?v=zoi8WpGwrXM



  I supplied details here in case anyone else has the same difficulties.

   Thanks for the help!

Regards,
...John
On Tuesday, November 3, 2015 3:35 AM, Neil Jerram  
wrote:

On 02/11/15 23:56, Thales wrote:
I'm trying to get DevStack to work, but am getting errors.  Is this a good list 
to ask questions for this?  I can't seem to get answers anywhere I look.   I 
tried the openstack list, but it kind of moves slow.

Thanks for any help.

Regards, John

In case it helps, I had no problem using DevStack's stable/liberty branch 
yesterday.  If you don't specifically need master, you might try that too:

  # Clone the DevStack repository.
  git clone https://git.openstack.org/openstack-dev/devstack

  # Use the stable/liberty branch.
  cd devstack
  git checkout stable/liberty

  ...

I also just looked again at your report on openstack@.  Were you using Python 
2.7?

I expect you'll have seen discussions like 
http://stackoverflow.com/questions/23176697/importerror-no-module-named-io-in-ubuntu-14-04.
  It's not obvious to me how those can be relevant, though, as they seem to 
involve corruption of an existing virtualenv, whereas DevStack I believe 
creates a virtualenv from scratch.

When you say 'on Ubuntu 14.04', are we talking a completely fresh install with 
nothing else on it?  That's the most reliable way to run DevStack - people 
normally create a fresh disposable VM for this kind of work.

Regards,
    Neil

__
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

Re: [openstack-dev] [release] Release countdown for week R-21, Nov 9-13

[Neil Jerram]

On 05/11/15 14:22, Doug Hellmann wrote:
> All deliverables should have reno configured before Mitaka 1. See
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html
> for details, and follow up on that thread with questions.

I guess that 'deliverables' do not include projects with
release:independent.  Is that correct?

Nevertheless, would use of reno be recommended for release:independent
projects too?

Thanks,
Neil


__
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

[openstack-dev] [neutron][stable] Understanding stable/branch process for Neutron subprojects

[Neil Jerram]

Prompted by the thread about maybe allowing subproject teams to do their
own stable maint, I have some questions about what I should be doing in
networking-calico; and I guess the answers may apply generally to
subprojects.

Let's start from the text at
http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html:

> Stable branches for libraries should be created at the same time when

"libraries"?  Should that say "subprojects"?

> corresponding neutron stable branches are cut off. This is to avoid
> situations when a postponed cut-off results in a stable branch that
> contains some patches that belong to the next release. This would
> require reverting patches, and this is something you should avoid.

(Textually, I think "created" would be clearer here than "cut off", if
that is the intended meaning.  "cut off" could also mean "deleted" or
"stop being used".)

I think I understand the point here.  However, networking-calico doesn't
yet have a stable/liberty branch, and in practice its master branch
currently targets Neutron stable/liberty code.  (For example, its
DevStack setup instructions say "git checkout stable/liberty".)

To get networking-calico into a correct state per the above guideline, I
think I'd need/want to

- create a stable/liberty branch (from the current master, as there is
nothing in master that actually depends on Neutron changes since
stable/liberty)

- continue developing useful enhancements on the stable/liberty branch -
because my primary target for now is the released Liberty - and then
merge those to master

- eventually, develop on the master branch also, to take advantage of
and keep current with changes in Neutron master.

But is that compatible with the permitted stable branch process?  It
sounds like the permitted process requires me to develop everything on
master first, then (ask to) cherry-pick specific changes to the stable
branch - which isn't actually natural for the current situation (or
targeting Liberty releases).

I suspect I'm missing a clue somewhere - thanks for any input!

Regards,
Neil


__
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

Re: [openstack-dev] [neutron][stable] Understanding stable/branch process for Neutron subprojects

[Neil Jerram]

On 06/11/15 13:46, Ihar Hrachyshka wrote:
> Neil Jerram  wrote:
>
>> Prompted by the thread about maybe allowing subproject teams to do their
>> own stable maint, I have some questions about what I should be doing in
>> networking-calico; and I guess the answers may apply generally to
>> subprojects.
>>
>> Let's start from the text at
>> http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html:
>>
>>> Stable branches for libraries should be created at the same time when
>> "libraries"?  Should that say "subprojects”?
> Yes. Please send a patch to fix wording.

https://review.openstack.org/#/c/242506/

> I think I understand the point here.  However, networking-calico doesn't
> yet have a stable/liberty branch, and in practice its master branch
> currently targets Neutron stable/liberty code.  (For example, its
> DevStack setup instructions say "git checkout stable/liberty".)
>
> Well that’s unfortunate. You should allow devstack to check out the needed  
> branch for neutron instead of overwriting its choice.

I'm afraid I don't understand, could you explain further?  Here's what
the setup instructions [1] currently say:

  # Clone the DevStack repository.
  git clone https://git.openstack.org/openstack-dev/devstack

  # Use the stable/liberty branch.
  cd devstack
  git checkout stable/liberty

What should they say instead?

[1]
https://git.openstack.org/cgit/openstack/networking-calico/tree/devstack/bootstrap.sh

>
>> To get networking-calico into a correct state per the above guideline, I
>> think I'd need/want to
>>
>> - create a stable/liberty branch (from the current master, as there is
>> nothing in master that actually depends on Neutron changes since
>> stable/liberty)
>>
>> - continue developing useful enhancements on the stable/liberty branch -
>> because my primary target for now is the released Liberty - and then
>> merge those to master
>>
> Once spinned out, stable branches should receive bug fixes only. No new  
> features, db migrations, configuration changes are allowed in stable  
> branches.
>
>> - eventually, develop on the master branch also, to take advantage of
>> and keep current with changes in Neutron master.
>>
> All new features must go to master only. Your master should always be  
> tested and work with neutron master (meaning, your master should target  
> Mitaka, not Liberty).
>
>> But is that compatible with the permitted stable branch process?  It
>> sounds like the permitted process requires me to develop everything on
>> master first, then (ask to) cherry-pick specific changes to the stable
>> branch - which isn't actually natural for the current situation (or
>> targeting Liberty releases).
>>
> Yes, that’s what current stable branch process implies. All stadium  
> projects must follow the same stable branch process.
>
> Now, you may also not see any value in supporting Liberty, then you can  
> avoid creating a branch for it; but it seems it’s not the case here.
>
> All that said, we already have stadium projects that violate the usual  
> process for master (f.e. GBP project targets its master development to kilo  
> - sic!) I believe that’s something to clear up as part of discussion of  
> what it really means to be a stadium project. I believe following general  
> workflow that is common to the project as a whole is one of the  
> requirements that we should impose.

Thanks for these clear answers.  I'll work towards getting all this correct.

Regards,
Neil


__
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

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

[Neil Jerram]

Yes, maybe. I'm interested in a pluggable IPAM module that will allocate an IP 
address for a VM that depends on where that VM's host is‎ in the physical data 
center network. Is that similar to your requirement?

I don't yet know whether that might lead me to want to store additional data in 
the Neutron DB. My intuition though is that it shouldn't, and that any 
additional data or state that I need for this IPAM module should be stored 
separately from the Neutron DB.

Regards,
   Neil


From: Shraddha Pandhe
Sent: Friday, 6 November 2015 20:23
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db 
tables


Bumping this up :)


Folks, does anyone else have a similar requirement to ours? Are folks making 
scheduling decisions based on networking?



On Thu, Nov 5, 2015 at 12:24 PM, Shraddha Pandhe 
mailto:spandhe.openst...@gmail.com>> wrote:
Hi,

I agree with all of you about the REST Apis.

As I said before, I had to bring up the idea of JSON blob because based on 
previous discussions, it looked like neutron community was not willing to 
enhance the schemas for different ipam dbs. Entire rationale behind pluggable 
IPAM is to provide flexibility. So, community should be open to ideas for 
enhancing the schema to incorporate more information in the db tables. I would 
be extremely happy if use cases for different companies are considered and 
schema is enhanced to include specific columns in db  schemas instead of a 
column with random JSON blob.

Lets pick up subnets db table for example. We have some use cases where it 
would be great if following information is associated with the subnet db table

1. Rack switch info
2. Backplane info
3. DHCP ip helpers
4. Option to tag allocation pools inside subnets
5. Multiple gateway addresses

We also want to store some information about the backplanes locally, so a 
different table might be useful.

In a way, this information is not specific to our company. Its generic 
information which ought to go with the subnets. Different companies can use 
this information differently in their IPAM drivers. But, the information needs 
to be made available to justify the flexibility of ipam

In Yahoo! OpenStack is still not the source of truth for this kind of 
information and database limitation is one of the reasons. I would prefer to 
avoid having our own database to make sure that our use-cases are always shared 
with the community.








On Thu, Nov 5, 2015 at 9:37 AM, Kyle Mestery 
mailto:mest...@mestery.com>> wrote:
On Thu, Nov 5, 2015 at 10:55 AM, Jay Pipes 
mailto:jaypi...@gmail.com>> wrote:
On 11/04/2015 04:21 PM, Shraddha Pandhe wrote:
Hi Salvatore,

Thanks for the feedback. I agree with you that arbitrary JSON blobs will
make IPAM much more powerful. Some other projects already do things like
this.

:( Actually, though "powerful" it also leads to implementation details leaking 
directly out of the public REST API. I'm very negative on this and would prefer 
an actual codified REST API that can be relied on regardless of backend driver 
or implementation.

I agree with Jay here. We've had people propose similar things in Neutron 
before, and I've been against them. The entire point of the Neutron REST API is 
to not leak these details out. It dampens the strength of the logical model, 
and it tends to have users become reliant on backend implementations.


e.g. In Ironic, node has driver_info, which is JSON. it also has an
'extras' arbitrary JSON field. This allows us to put any information in
there that we think is important for us.

Yeah, and this is a bad thing, IMHO. Public REST APIs should be structured, not 
a Wild West free-for-all. The biggest problem with using free-form JSON blobs 
in RESTful APIs like this is that you throw away the ability to evolve the API 
in a structured, versioned way. Instead of evolving the API using 
microversions, instead every vendor just jams whatever they feel like into the 
JSON blob over time. There's no way for clients to know what the server will 
return at any given time.

Achieving consensus on a REST API that meets the needs of a variety of backend 
implementations is *hard work*, yes, but it's what we need to do if we are to 
have APIs that are viewed in the industry as stable, discoverable, and reliably 
useful.

++, this is the correct way forward.

Thanks,
Kyle


Best,
-jay

Best,
-jay

Hoping to get some positive feedback from API and DB lieutenants too.


On Wed, Nov 4, 2015 at 1:06 PM, Salvatore Orlando
mailto:salv.orla...@gmail.com> 
>> wrote:

Arbitrary blobs are a powerful tools to circumvent limitations of an
API, as well as other constraints which might be imposed for
versioning or portability purposes.
The parameters that should end up in such blob are typically

Re: [openstack-dev] [neutron][tap-as-a-service] weekly meeting

[Neil Jerram]

Sounds interesting!  I'd like to look at some past meeting logs (including from 
today), but the 'past meetings' link at 
http://eavesdrop.openstack.org/#Tap_as_a_Service_Meeting does not work for me.

Neil

-Original Message-
From: Takashi Yamamoto [mailto:yamam...@midokura.com] 
Sent: 11 November 2015 03:09
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [neutron][tap-as-a-service] weekly meeting

hi,

tap-as-a-service meeting will be held weekly, starting today.
http://eavesdrop.openstack.org/#Tap_as_a_Service_Meeting
anyone interested in the project is welcome.
sorry for immediate notice.

__
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

__
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

Re: [openstack-dev] Linux kernel IPv4 configuration during the neutron installation

[Neil Jerram]

On 11/11/15 10:30, JinXing F wrote:
>
> Hi, guys:
>
> during the neutron installation guide, I found that we need to
> config the linux kernel as bellow: 
>
> net.ipv4.ip_forward=1
>
> net.ipv4.conf.all.rp_filter=0
>
> net.ipv4.conf.default.rp_filter=0
>
>
> the first one is the ip address translation between LAN and WLAN,
>

No, that's incorrect.  net.ipv4.ip_forward simply allows Linux to
forward IPv4 packets - i.e. to receive a packet on one network
interface, determine that it is not a packet that should be delivered
locally, and forward it on to its next IP hop.  There is no IP address
translation involved here.

> the second and third command is used for "Reverse Path Filtering".
>
> I cann't understand the purpose of the config in the neutron.
>

Do you mean that you don't understand what "Reverse Path Filtering" is? 
Or that you don't understand why Neutron needs RPF to be disabled?

For the former, please see
https://en.wikipedia.org/wiki/Reverse_path_forwarding.

Regards,
Neil

> 1. If the instance in compute node connect with exteral network,what's
> the function of the three config?
>
> 2. The instance connect with each others, what's the function of the
> three config?
>
>
> I am very confused about this config.Please explain the answer to me. 
>
> Thanks. 
>


__
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

[openstack-dev] REST API collation and visualization

[Neil Jerram]

Hi there,

I'm interested in collating all the REST API exchanges to and between
OpenStack components, and presenting / visualizing all those in an
easily comprehensible way.  Is there already some tool to do that?

Many thanks,
Neil


__
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

Re: [openstack-dev] REST API collation and visualization

[Neil Jerram]

On 16/11/15 16:37, Neil Jerram wrote:
> Hi there,
>
> I'm interested in collating all the REST API exchanges to and between
> OpenStack components, and presenting / visualizing all those in an
> easily comprehensible way.  Is there already some tool to do that?
>
> Many thanks,
> Neil

Well here's a start anyway, for capturing requests into Neutron:

$ sudo tshark -i any -d tcp.port==9696,http -f 'tcp port 9696' -V -Y
http | awk -f filter.awk > pcap.txt

where filter.awk is:

--cut here---
BEGIN {
disp = 0;
}

/^[A-Z]/ {
disp = 0;
}

/^Hypertext/ {
disp = 1;
}

/^Java/ {
disp = 1;
}

{
if (disp) print;
}
--cut here---

But I'm guessing that more developed things already exist?

Neil


__
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

Re: [openstack-dev] REST API collation and visualization

[Neil Jerram]

On 16/11/15 17:54, Neil Jerram wrote:
> On 16/11/15 16:37, Neil Jerram wrote:
>> Hi there,
>>
>> I'm interested in collating all the REST API exchanges to and between
>> OpenStack components, and presenting / visualizing all those in an
>> easily comprehensible way.  Is there already some tool to do that?
>>
>> Many thanks,
>> Neil
> Well here's a start anyway [...]

Latest evolution below, for anyone else interested in this.  This
version captures REST API for all OpenStack endpoints on the local node.

Neil

#!/bin/bash

set - `openstack catalog list --format csv | gawk '{ if (match($0,
"publicURL: http://[^:]*:([^/]*)/", arr)) { print arr[1]; } }' | sort |
uniq`

display_filter_for_port () {
echo "-d tcp.port==$1,http"
}

capture_filter_for_port() {
echo "tcp port $1"
}

display_filters=`display_filter_for_port $1`
capture_filters=`capture_filter_for_port $1`
shift

for port in $*; do
display_filters="$display_filters `display_filter_for_port $port`"
capture_filters="$capture_filters or `capture_filter_for_port $port`"
done

sudo tshark -i any $display_filters -f "$capture_filters" -V -Y http | awk '

BEGIN {
disp = 0;
}

/^[A-Z]/ {
disp = 0;
}

/^Hypertext/ {
disp = 1;
}

/^Java/ {
disp = 1;
}

{
if (disp) print;
}
'


__
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

Re: [openstack-dev] [tc][infra][neutron] branches for release-independent projects targeting Openstack release X

[Neil Jerram]

Thanks to Thomas for continuing this discussion about networking-*
projects, and to Thierry for his responses below, and Ihar for his
earlier guidance.  I have a couple further points that I hope may
contribute...

On 19/11/15 09:46, Thierry Carrez wrote:
> Thomas Morin wrote:
>> The starting point for this post is a specific Neutron sub-project
>> (networking-bgpvpn) but I believe the issues raised are shared with
>> other neutron stadium project and possibly relevant beyond Neutron, to
>> projects tagged release-independent in general.
>>
>> In the context of the networking-bgpvpn project, we have a few unsolved
>> issues related to branches, more specifically about which branches we
>> can create to host active development to make our subprojet (a Neutron
>> service plugin) work with the last Openstack release and to backport it
>> with to earlier releases.
>>
>> Here are precisely the assumptions that we've made, largely based on the
>> fact that the project is tagged 'release-independent' (meaning
>> "completely bypass the 6-month cycle and release independently" [1]):
>> a) that we can make a release targeting Liberty much later than the
>> release date of Liberty
>> b) that we could make releases more frequent than the 6-month cycle ;
>> not only bugfix releases but also feature releases
>> c) that the idea of a release-independent project being backported to
>> work with past Openstack releases is acceptable (of course, without
>> requiring any change in release-managed projects, something largely
>> possible in many cases for projects such as a Neutron service plugin or
>> an ML2 driver)
> So we have three models. The release:independent model is for projects
> that don't follow the common development cycle, and therefore won't make
> a "liberty" release. The release:cycle-with-milestones model is the
> traditional "one release at the end of the cycle" model, and the
> release:cycle-with-intermediary model is an hybrid where you follow the
> development cycle (and make an end-of-cycle release) but can still make
> intermediary, featureful releases as necessary.
>
> The difference between the two groups is the concept of per-cycle
> branches (the stable/liberty branch which is used to maintain backports
> following the stable branch policy). Projects following the
> release:independent model should not have a stable/liberty branch, since
> they didn't formally do a liberty release. Those independent projects
> that have a stable/liberty branch are actually all
> release:cycle-with-intermediary projects that ignore their true nature.
>
> Looking at your specific case, it appears you could adopt the
> release:cycle-with-intermediary model, since you want to maintain a
> branch mapped to a given release. The main issue is your (a) point,
> especially the "much later" point. Liberty is in the past now, so making
> "liberty" releases now that we are deep in the Mitaka cycle is a bit
> weird. When are you likely to start shipping your liberty branch ?
>
> Maybe we need a new model to care for such downstream projects when they
> can't release in relative sync with the projects they track.

On the other hand this could just be a matter of discipline and
planning, and of networking-* projects still being quite new. 
networking-calico is currently release:independent, and was only created
a short time before the Liberty release, and was not completely ready at
the time of the Liberty release.  But I believe that that it would be
achievable if the project targeted moving into sync with the Mitaka
cycle, and hence then could be release:cycle-with-milestones or
release:cycle-with-intermediary.

>
>> Note that we aren't the only big tent project having this kind of
>> expectations (e.g. [3]).

I'd like to say a little more about branch thinking in
networking-calico, as I think it may be another useful data point.  The
last exchange on this, between Ihar and me, was as follows:

> > > To get networking-calico into a correct state per the above
guideline, I
> > > think I'd need/want to
> > >
> > > - create a stable/liberty branch (from the current master, as there is
> > > nothing in master that actually depends on Neutron changes since
> > > stable/liberty)
> > >
> > > - continue developing useful enhancements on the stable/liberty
branch -
> > > because my primary target for now is the released Liberty - and then
> > > merge those to master
> >
> > Once spinned out, stable branches should receive bug fixes only. No
new 
> > features, db migrations, configuration changes are allowed in stable 
> > branches.
> >
> > > - eventually, develop on the master branch also, to take advantage of
> > > and keep current with changes in Neutron master.
> >
> > All new features must go to master only. Your master should always be 
> > tested and work with neutron master (meaning, your master should
target 
> > Mitaka, not Liberty).
> >
> > > But is that compatible with the permitted stable branch process?  It
> > > sounds lik

Re: [openstack-dev] [all] how to add/list drivers @ https://www.openstack.org/marketplace/drivers/

[Neil Jerram]

That reminds me of a follow-on question, as I added my driver's data to
the driverlog project a few weeks ago [1]: when does the content at
https://www.openstack.org/marketplace/drivers/ get rebuilt?

Thanks,
Neil

[1] https://review.openstack.org/#/c/240830/


On 25/11/15 09:42, Ilya Shakhat wrote:
> Community-maintained list of drivers exists within the project
> DriverLog. The UI is available
> at http://stackalytics.com/report/driverlog , it has all options to
> filter the data.
>
>
> Thanks,
> Ilya
>
> 2015-11-25 11:48 GMT+03:00 Mohan Kumar  >:
>
> Hi Team,
>
>  In the following link, i can see only some vendor plug-ins, not
> all is listed here! ..
>
>  https://www.openstack.org/marketplace/drivers/
>
> So [1]  what is the criteria to get a vendor plug-in listed on
> this page? [2]  where can i see the supported vendor
> plugins/drivers for a given Openstack release (specfically Liberty) ??
>
> Thanks.,
> Mohankumar.N
>
> __
> 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
>
>


__
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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Neil Jerram]

On 01/12/15 04:13, Russell Bryant wrote:
> On 11/30/2015 07:56 PM, Armando M. wrote:
>> As a result, there is quite an effort imposed on the PTL, the various
>> liaisons (release, infra, docs, testing, etc) and the core team to
>> help manage the existing relationships and to ensure that the picture
>> stays coherent over time. 
> For example, you mention "release" here, though IIUC, Kyle is handling
> releases for all of these sub-projects, right?  If so, Kyle, what do you
> think?  What's causing pain and how can we improve?
>
> "infra" - I take it this is about the Neutron infra liaisons having to
> ack every infra patch for all of these repos.  That does sound annoying.
>  It'd be nice if the lead for each driver or whatever could act as the
> infra liaison for jobs that only affect that repo.

I'd be happy to do that for networking-calico.  (Even though I'm not
sure quite how great the implications are, it sounds like the Right Thing.)

Neil


__
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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Neil Jerram]

On 01/12/15 05:16, Doug Wiegley wrote:
> Part of the issue is that in a year, we added all the repos above. And
> all of said repos were all heading over to infra with the same newbie
> questions/mistakes. Not a bad thing in and of itself, but the sheer
> volume was causing a lot of infra load. So the infra liasions are
> meant to buffer that; exactly the opposite of splitting again. Now add
> that many repos again this year, and the problem doubles. The review
> overhead for centralizing this is quite small. The mentor overhead to
> avoid the repeated mistakes hitting infra is quite a bit higher, but
> that has to land somewhere, and still isn’t huge. 

On the other hand, it may also be that we're very unlikely to see so
many new projects again, as we have in the first 'stadium' (half-)year. 
So if this is a significant aspect of the pain that Armando is
describing, I suspect it would be overreaction to make a big governance
change for it - as it's unlikely to happen again.

But actually I guess most of the pain is elsewhere, i.e. in the
cognitive aspect of the Neutron PTL logically needing to understand
everything in all of the stadium projects.

Neil


__
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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Neil Jerram]

On 01/12/15 10:42, Thierry Carrez wrote:
> Armando M. wrote:
>> [...]
>> So my question is: would revisiting/clarifying the concept be due after
>> some time we have seen it in action? I would like to think so.
> I also think it's time to revisit this experience now that it's been
> around for some time. On one hand the Neutron stadium allowed to
> increase the development bandwidth by tackling bottlenecks in reviews
> using smaller core review teams. On the other it's been difficult for
> Neutron leadership to follow up on all those initiatives and the results
> in terms of QA and alignment with "the OpenStack way" have been... mixed.

Agreed.  networking-calico has now existed as an OpenStack and Neutron
stadium project since August, but we don't yet have an IRC meeting or
formal subproject PTL (if such a thing should exist - I'm not sure), so
there are some design discussions that we're not conducting in public;
and in those senses we are not yet fully following the OpenStack way. 
(These things are planned!  But not there yet.)

If the Neutron stadium didn't exist and we were an OpenStack project
like (say) magnum or sahara, would processes and oversight have forced
us to address those points sooner?  If so, it might be said that the
Neutron stadium is providing a grey area for projects that are dragging
their feet a bit.  From a lazy vendor point of view, that might be
convenient, but from an OpenStack community point of view it's not good.

Regards,
Neil


__
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

[openstack-dev] [neutron] Purpose and documentation of the API

[Neil Jerram]

Sometimes when I'm discussing or reviewing proposed specs, I feel as
though I may have incorrect assumptions about what the Neutron API is
_for_.  And certainly I feel that we lack good unified documentation of
it - or at least, that I haven't yet found that documentation, if it
exists.  So I'd like to start a conversation about that here.

_What is important: the API, or documented use cases?_

Being theoretically inclined, I tend to assume that if an API exists, it
is the primary thing, and hence that everything that is expressible in
that API should make sense and be implemented by at least some
implementations.  (It's fine for the API to explicit exclude certain
combinations of properties or calls; those exclusions then become part
of the definition of 'the API'.  It's also fine for particular
implementations only to implement a subset of the API.)

But a perfectly consistent alternative position would be to say that
that is _not_ the case with the Neutron API, and - rather - what really
matters is our set of documented use cases [1].  If that was the view,
then the API would simply be a piece of how we provide those use cases,
and anything _else_ that the resulting API happened to be able to
express would be regarded technically as an accident or 'unspecified
behavior'.

[1] http://docs.openstack.org/networking-guide/deploy.html

Which of those positions do we actually take?  (What is the overall
contract that Neutron provides to the rest of the OpenStack world?)

If it's the latter, then much of the rest of this email may be moot. 
But I'll write it anyway in case it's the former - i.e. that we believe
the Neutron API is important as a more general thing than just the
documented use cases - or in case it's interesting for other reasons.

_What should be expressed on the Neutron API?_

My first intuition is that the Neutron API should _only_ describe the
connectivity and networking services that it provides to instances - L2,
L3, security, service chains, DNS, DHCP etc. etc. - and primarily this
is indeed what it does.  But it only takes a slightly longer look to see
other things that are not part of specifying the connectivity or
services that can be observed by instances, but instead directions to
the (assumed) implementation about how that connectivity should be
implemented.  For example, the 'provider' API extension is entirely in
the latter camp.

So in practice it seems we use the Neutron API for two purposes:

1. To describe the connectivity and networking services that Neutron
provides to instances.

2. As a convenient central distribution point for instructions to
assumed networking implementations.

Is that right, as a description of current reality?

Is it right, in terms of what we _should_ be doing?  Should we, for
example, perhaps have a clearer formal separation between (1) and (2)?

_Documentation_

Whatever is the consensus on the questions raised here, I'd like that to
be explicitly recorded somewhere, and volunteer to do that.  Not sure
yet whether that should be in the Neutron devref, or in the networking
guide - opinions welcome!

Also, if we agree that the Neutron API is a primary thing, I think we
should have some unified documentation of it that explains what all the
data model objects mean.  I'm not sure I can do all of that myself, but
I'd be happy to make a start - so again, opinions welcome on where and
how to do that.

Apologies if either of these things already exists - in that case please
just point to them.


Thanks for reading!  Please let me know what you think.

Neil


__
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

Re: [openstack-dev] [Fuel] Patch size limit

[Neil Jerram]

On 01/12/15 12:45, Maciej Kwiek wrote:
> Hi,
>
> I recently noticed the influx of big patches hitting Gerrit
> (especially in fuel-web, but I also heard that there was a couple of
> big ones in library). I think that patches that have 1000 LOC are
> simply too big to review thoroughly and reliably.
>
> I would argue that there should be a limit to patch size, either a
> soft one (i.e. written down in contributor guidelines) or a hard one
> (e.g. enforced by gate job).
>
> I think that we need a discussion whether we really need this limit,
> what should it be, and how to enforce it.
>
> I personally think that most patches that are over 400 LOC could be
> easily split into at least two smaller changes.
>
> Regarding the limit enforcement - I think we should go with the soft
> limit, with X LOC written as a guideline and giving the reviewers a
> possibility to give -1s to patches that are too big, but also giving
> the possibility to merge bigger changes if it's absolutely necessary
> (in really rare cases the changes simply cannot be split). We may mix
> in the hard limit for ridiculously large patches (twice the "soft
> limit" would be good in my opinion), so the gate would automatically
> reject such patches, forcing contributor to split his patch.
>
> Please share your thoughts on this.

I think most of your principle is correct.  However I can imagine a file
renaming / moving patch that would appear in Gerrit to be >=1000 LOC,
but would actually just be file moves, with perhaps some trivial changes
to Python module paths; and I don't think it would be helpful to force a
patch like that to be split up.  So it may not be correct to enforce a
hard limit all the time.

Neil


__
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

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Neil Jerram]

I'm new to this discussion, but you did ask for any feedback, so ...

On 03/12/15 18:29, Smigiel, Dariusz wrote:
> Hey Neutrinos (thanks armax for this word :),
> Keystone is planning to deprecate V2 API (again :). This time in Mitaka [6], 
> and probably forever. It will stay at least four releases, but we need to 
> decide, how to conquer problem of renaming... 
> And more important: consider if it's a problem for Neutron?
>
> I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to 
> 'project', and trying to find out all the details.
> First attempt to solve this problem was raised in November 2013 [4][5] but 
> unfortunately, no one finished it. Although Keystone V3 API is already 
> supported in Neutron client [2], there are still some unknowns about Neutron 
> server side. Monty Taylor is trying to address necessary (if any) changes [3].
>
> Findings:
> I've focused on two projects: python-neutronclient and neutron.
> grep found 429 occurrences of 'tenant' in Client while Server has 3021 of it. 
> Some of them are just documentation and docstrings, but there are a lot of 
> places, where variables are tangled: defined in DB, used in server, accessed 
> by client. Most of places are just internal usages. The only thing where I've 
> found 'public' information about tenants is 'help' command in neutron client.
>
> Suggested plan for conquer:
> 1. First step would be to deal with neutronclient. It's much smaller amount 
> of code to look through, update all places and be successful :)
> 2. Bigger challenge will be to change server side code. I'd suggest to start 
> with renaming db columns. It affects a lot of places, so when finished should 
> significantly lower number of remained "tenants".
> 3. Deal with all other places.
>
> Pros:
> - variable names unification in OpenStack code base. Someone needs to start 
> this job.
> - one way to describe the same thing, instead of: tenant/account/project. 
> Helpful, especially for newcomers.
> - alignment with Keystone V3 API
>
> Cons:
> - A. Lot. Of. Work.
> - dealing with DB migrations
> - about 2-4 weeks of work for every part of code. Additional, a lot of 
> patchsets to be reviewed.
>
> What do you think about this? About proposed way of dealing with all changes?
> Is this change necessary?

My intuition is that we should just not do this change.  The whole world
says 'tenant' for the 'tenant' concept, particularly in the context of
networking.  Changing to a different term is just silly.

But I haven't looked into the history.  Perhaps there's some reason we
need to anyway.

Neil


__
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

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Neil Jerram]

On 04/12/15 18:03, Kevin Benton wrote:
> >The whole world says 'tenant' for the 'tenant' concept, particularly
> in the context of networking.  Changing to a different term is just
> silly.
>
> Except for the rest of OpenStack.

Do you mean OpenStack developers, OpenStack customers, or OpenStack code?

OpenStack developers mostly say 'tenant', I'd say from my following of
the ML.

All the OpenStack users/operators/customers that I've interacted with,
say 'tenant'.

As far as code is concerned, I'm fine with any initiative to align the
Neutron code better with other OpenStack code - but only so long as this
is change that doesn't cause pain and loss of back-compatibility.  Even
the merge pain from this change may be substantial, let alone that from
API changes.

> Consistency is the one argument we can't use as a reason not to switch
> to project.

I'm not sure what you mean here.

> Please read the blueprint and the email it links
> to: https://blueprints.launchpad.net/neutron/+spec/rename-tenant-to-project

Dariusz asked for feedback, and I believe it's valid and useful for me
to give my intuitive feedback without having to read up on the history
first.

Also it seems likely to me that the fact that this work hasn't happened,
for two years, is a reflection of most people not really wanting it.  I
thought it might be helpful to get that out in the open.

That said, I did look at some of the history -
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09709.html:

> +1 for using the term "project" across all services. Projects provide
> multi-tenant isolation for resources across the cloud. Part of the reason
> we prefer "projects" in keystone is that "domains" conceptually provide
> multi-tenant isolation within keystone itself, so the overloaded "tenant"
> terminology gets really confusing.

and noted a couple of points:

1. The text here twice says "multi-tenant isolation", not "multi-project
isolation".

2. This whole renaming proposal apparently stems from an internal
confusion in keystone?

Regards,
Neil


__
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

Re: [openstack-dev] [Neutron] Rename tenant to project: discussion

[Neil Jerram]

Really?  I don't want to escalate, but I  think that I'm entitled:


- to have an opinion on this, regardless of how much of the history I've read


- to express that opinion in response to an explicit request for "any 
feedback", particularly when no one else had responded to that call for nearly 
24 hours.


FWIW, it's also fine with me that there is apparently a strong consensus _for_ 
this change, and I'm happy to reflect and ponder that my intuition might be 
wrong.  I'd rather have stuck my neck out and contributed to a discussion, than 
be asked later "why did no one say anything?"


Neil


From: Armando M. 
Sent: 04 December 2015 21:01
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Rename tenant to project: discussion



On 4 December 2015 at 08:46, Neil Jerram 
mailto:neil.jer...@metaswitch.com>> wrote:
I'm new to this discussion, but you did ask for any feedback, so ...

On 03/12/15 18:29, Smigiel, Dariusz wrote:
> Hey Neutrinos (thanks armax for this word :),
> Keystone is planning to deprecate V2 API (again :). This time in Mitaka [6], 
> and probably forever. It will stay at least four releases, but we need to 
> decide, how to conquer problem of renaming...
> And more important: consider if it's a problem for Neutron?
>
> I'm looking at blueprint [1] about renaming all occurrences of 'tenant' to 
> 'project', and trying to find out all the details.
> First attempt to solve this problem was raised in November 2013 [4][5] but 
> unfortunately, no one finished it. Although Keystone V3 API is already 
> supported in Neutron client [2], there are still some unknowns about Neutron 
> server side. Monty Taylor is trying to address necessary (if any) changes [3].
>
> Findings:
> I've focused on two projects: python-neutronclient and neutron.
> grep found 429 occurrences of 'tenant' in Client while Server has 3021 of it. 
> Some of them are just documentation and docstrings, but there are a lot of 
> places, where variables are tangled: defined in DB, used in server, accessed 
> by client. Most of places are just internal usages. The only thing where I've 
> found 'public' information about tenants is 'help' command in neutron client.
>
> Suggested plan for conquer:
> 1. First step would be to deal with neutronclient. It's much smaller amount 
> of code to look through, update all places and be successful :)
> 2. Bigger challenge will be to change server side code. I'd suggest to start 
> with renaming db columns. It affects a lot of places, so when finished should 
> significantly lower number of remained "tenants".
> 3. Deal with all other places.
>
> Pros:
> - variable names unification in OpenStack code base. Someone needs to start 
> this job.
> - one way to describe the same thing, instead of: tenant/account/project. 
> Helpful, especially for newcomers.
> - alignment with Keystone V3 API
>
> Cons:
> - A. Lot. Of. Work.
> - dealing with DB migrations
> - about 2-4 weeks of work for every part of code. Additional, a lot of 
> patchsets to be reviewed.
>
> What do you think about this? About proposed way of dealing with all changes?
> Is this change necessary?

My intuition is that we should just not do this change.  The whole world
says 'tenant' for the 'tenant' concept, particularly in the context of
networking.  Changing to a different term is just silly.


If you don't know the whole story why are you making these remarks?

But I haven't looked into the history.  Perhaps there's some reason we
need to anyway.

Neil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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

Re: [openstack-dev] [neutron] Multiple locations for documentation of features

[Neil Jerram]

On 04/12/15 19:24, Henry Gessau wrote:
> Sean M. Collins  wrote:
>> I've noticed that a lot of features are now being documented as RSTs
>> inside of devref. Like the following:
>>
>> https://review.openstack.org/#/c/251859/
>>
>> But there are lots already present. Can someone point out to me what the
>> criteria is for these documents? I am a little confused about the
>> relationship between neutron-specs, RFE bugs, and some features being
>> documented in devref. Especially when a review includes the actual code,
>> then a new RST file in devref - wasn't that what specs were for?
> Here is how I would like to see things ending up:
>
> 1. RFE: "I want X"
> 2. Spec: "I plan to implement X like this"
> 3. devref: "How X is implemented and how to extend it"
> 4. OS docs: "API and guide for using X"

> Once X is implemented I don't want to have to go to 1 or 2 to find information
> on it. The devref may have a lot of content from the spec, but the spec is not
> maintained and the implementation may differ in some ways. The devref should
> be kept current with refactorings, etc. of the implementation.
>

FWIW, that's exactly how I'd see things too.  It may be well that some
of a spec's text is roughly suitable for later moving to a devref or OS
doc, but even so it should be re-reviewed and edited for the new
context, and for any details that changed during implementation.

Regards,
Neil


__
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

Re: [openstack-dev] [client][all][neutron] client option removal policy

[Neil Jerram]

On 07/12/15 12:01, Akihiro Motoki wrote:
> Hi,
>
> neutronclient is now dropping XML support and as a result
> "--request-format" option is no longer needed as JSON is the only format now.
>
> What is the recommended way for options no longer needed?
> Does bumping major version of CLI allow us to drop an option without
> deprecation?
>
> - Deprecate such option.
>   The option still exists with only one available choiceuntil the
> option is deleted.
>
> - Drop it without deprecation.
>   This breaks users who uses "--requiest-format json", but 'json' is the 
> default
>   value and most users do not specify the option.

I'd say it depends on how the deprecation of '--request-format xml' was
announced.  If it said

"XML format is deprecated and will be removed in a future release.  The
only supported format will then be JSON, and so the --request-format
option will also be removed"

then the option can clearly be removed now.

How was it announced?  If I look at
http://docs.openstack.org/cli-reference/content/neutronclient_commands.html,
I see many occurrences of

*--request-format {json,xml}*

The XML or JSON request format.

**

without anything to say that XML is deprecated.  And I see many other
things in the same page that _are_ marked as "DEPRECATED!"  So, if I was
reading this documentation, I would not know that XML format is deprecated.

Regards,
Neil


__
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

Re: [openstack-dev] [neutron] Multiple locations for documentation of features

[Neil Jerram]

On 07/12/15 17:42, Sean M. Collins wrote:
> On Mon, Dec 07, 2015 at 12:18:29PM EST, Carl Baldwin wrote:
>> On Fri, Dec 4, 2015 at 12:22 PM, Henry Gessau  wrote:
>>> 1. RFE: "I want X"
>>> 2. Spec: "I plan to implement X like this"
>>> 3. devref: "How X is implemented and how to extend it"
>>> 4. OS docs: "API and guide for using X"
>>>
>>> Once X is implemented I don't want to have to go to 1 or 2 to find 
>>> information
>>> on it. The devref may have a lot of content from the spec, but the spec is 
>>> not
>>> maintained and the implementation may differ in some ways. The devref should
>>> be kept current with refactorings, etc. of the implementation.
>> Henry, I was also impressed by how clearly you communicated this.
>> This ought to be included somewhere prominently in our
>> doc/source/policies/ or somewhere like that.
>>
> +1 for Henry's great answer, and +1 for Carl's suggestion!
>

I've suggested a change for this at
https://review.openstack.org/#/c/254669/.  Please take a look.

Neil


__
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

Re: [openstack-dev] [neutron] Multiple locations for documentation of features

[Neil Jerram]

On 08/12/15 10:04, Mathieu Rohon wrote:
Hi all,

thanks for the explanation.
Can you also explain how does neutron team use blueprints? how it overlaps with 
RFE bugs?

Hi Mathieu,

This is all documented, in principle, at 
http://docs.openstack.org/developer/neutron/policies/blueprints.html.

Neil

__
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

Re: [openstack-dev] [charms] Juju Charms for OpenStack

[Neil Jerram]

+1 from me (as an OpenStack contributor, and one of those 'developers at
SDN and storage vendors' :-) ).

  Neil


On Thu, May 19, 2016 at 11:38 AM James Page  wrote:

> Hi All
>
> tl;dr Juju is a great way of deploying OpenStack, and we'd like the
> OpenStack Charms for Juju to become a official OpenStack Project
>
> read on if you want the full details
>
> Juju [0] is a service modelling tool that's been around since about 2010;
> developed primarily by Canonical, Juju takes a high level approach to
> modelling services and the relations between them (think cinder,
> neutron-api, nova-cloud-controller), with the details on exactly how each
> of those services is installed, configured, scaled-up, scaled-down, HA'ed
> etc.. implemented by a charm for each of the services that form part of a
> model;  Juju uses underlying providers (responsible for managing compute,
> storage and network resources) to translate the model onto actual machine
> resources - in the context of OpenStack, the MAAS (metal-as-a-service [1])
> provider is used to deploy an OpenStack model, using the OpenStack Charms,
> to a combination of physical servers and LXD containers running on those
> servers.
>
> The OpenStack Charms have been around for about the same time as Juju; I
> think the first release we supported was OpenStack Diablo, and we've
> updated, redesigned and re-factored the charms to support every OpenStack
> release on Ubuntu since then.
>
> The OpenStack Charms are a core part of the Ubuntu OpenStack teams
> approach to distributing OpenStack on Ubuntu (we use them for all of our
> deployment and testing CI, as well as for deploying production OpenStack
> Clouds at Canonical's customers). As a result when OpenStack releases we've
> always had aligned support in Ubuntu and the OpenStack charms for the
> latest release.
>
> The OpenStack charms (26 of them including some things not specifically
> OpenStack such as Ceph, Percona XtraDB Cluster and RabbitMQ) are written in
> Python; the code base has evolved a-lot over the years (once upon a time
> they where bash scripts), as has the approach to writing best practice
> charms, and we expect new OpenStack charms to take a slightly different
> approach to charm authoring which should make writing a new OpenStack charm
> much more lightweight (see [3]).
>
> We migrated development to OpenStack project infrastructure (from its
> original home in Launchpad and Bazaar branches) around 4 months ago at the
> request of the TC from our original request to be formally recognised as an
> OpenStack project; we now have some history that's readily re-viewable so
> I've restored our request to become a formal OpenStack project:
>
>  https://review.openstack.org/224797
>
> The community of developers around the charms is not as diverse as I would
> like, but we've had a number of contributions from developers at SDN and
> storage vendors (who are also maintaining charms for their own solutions)
> as well as contribution from CloudBase for enabling support for Microsoft
> Hyper-V in a Juju deployed OpenStack Cloud (Juju and MAAS can deploy
> WIndows machines as well).
>
> We have some outstanding work to consolidate developer and user
> documentation around the OpenStack charms, which the team currently expect
> to complete in the next few months.
>
> Cheers
>
> James
>
> [0] https://jujucharms.com/
> [1] https;//maas.ubuntu.com/
> [2] https://jujucharms.com/openstack
> [3]
> https://github.com/openstack-charmers/openstack-community/blob/master/openstack-api-charm-creation-guide.md
>
> __
> 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
>
__
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

Re: [openstack-dev] [nova-lxd]Nova-lxd with Linuxbridge

[Neil Jerram]

FWIW, the networking-calico team plans soon to make nova-lxd work with
Calico networking, i.e. where data from/to the veth is routed on the
compute host.  That should land in July or August.

Neil


On Fri, May 20, 2016 at 3:30 PM Chuck Short 
wrote:

> Hi,
>
> Currently it only works with OVS mode, there is a patch lying around for
> Linuxbridge agent support that needs to be integrated.
>
> Thanks
> chuck
>
> On Fri, May 20, 2016 at 8:47 AM, Gyorgy Szombathelyi <
> gyorgy.szombathe...@doclerholding.com> wrote:
>
>> Hi!
>>
>> I just have a simple question: is nova-lxd supposed to work with the
>> Linuxbridge agent?
>> As I see, the LXD driver creates veth interface pairs, and vif.py
>> connects it to a normal linux bridge. However the Linuxbridge agent code
>> scans only for tap devices.
>> So the question is: Should the LXD driver create a tap device, bridged
>> with that veth?
>>
>> Br,
>> György
>>
>> __
>> 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
>>
>
> __
> 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
>
__
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

Re: [openstack-dev] [Fuel] Correct wrong nomenclature in the Networks section of Fuel-ui

[Neil Jerram]

As I just commented in the review, I think the wording was clearer as it
was before.  So would prefer if you do not use this as a model for further
similar changes.

   Neil


On Wed, Jun 1, 2016 at 2:06 PM Giuseppe Cossu 
wrote:

> Hi folks,
> I submitted a bug and the related fix about a wrong nomenclatura in
> fuel-ui.
> The fix is merged but I think we need to improve other things such as the
> translations of the same content and the related parameters (e.g., replace
> "internal_cidr" with "admin_tenant_cidr") inside the fuel-ui and fuel-web
> repositories.
>
> If we proceed in that way I suppose that is required to coordinate the
> activities in multiple fuel repositories. What do you think?
>
> https://review.openstack.org/#/c/322050/
> https://bugs.launchpad.net/fuel/+bug/1586332
>
> Regards,
> Giuseppe
> --
> 
> Giuseppe Cossu
> Distributed Computing and Information Processing (DISCO)
> Cloud Engineer
> CREATE-NET  Research Center
> Via alla Cascata 56/D - 38123 Povo, Trento (Italy)
> e-mail: giuseppe.co...@create-net.org
> www.create-net.org
> 
> __
> 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
>
__
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

Re: [openstack-dev] [charms] Re-licensing OpenStack charms under Apache 2.0

[Neil Jerram]

Me too.

On Fri, Jun 10, 2016 at 10:32 AM Cory Benfield  wrote:

>
> > On 8 Jun 2016, at 11:20, James Page  wrote:
> >
> > The majority of contributors are from Canonical (from whom I have
> permission to make this switch) with a further 18 contributors from outside
> of Canonical who I will be directly contacting for approval in gerrit as
> reviews are raised for each repository.
>
> Hey James,
>
> I’m happy for you to relicense my contributions as Apache 2.0.
>
> Cory
>
> __
> 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
>
__
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

Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port is Active

[Neil Jerram]

Hi Mohammad,

Why is the blocking needed?  Is it to report some kind of status back to
Docker/Kubernetes, or to allow some follow-on action to happen?

When using networking-calico as the driver, I think that only option (1)
would work, out of the options you've suggested below.  (3) doesn't work,
as you say, because Calico doesn't involve an L2 agent.  Also Calico
doesn't use the RPC message queue for reporting port status, because we've
found that that message queue is in itself a scalability bottleneck.

I guess another option would be for the using system to determine for
itself when the port appears to be working, e.g. by the host pinging the
container/pod's IP address.

Regards,
Neil


On Wed, Jun 8, 2016 at 4:23 PM Mohammad Banikazemi  wrote:

> For the Kuryr project, in order to support blocking until vifs are plugged
> in (that is adding config options similar to the following options define
> in Nova: vif_plugging_is_fatal and vif_plugging_timeout), we need to detect
> that the Neutron plugin being used is done with plugging a given vif.
>
> Here are a few options:
>
> 1- The simplest approach seems to be polling for the status of the Neutron
> port to become Active. (This may lead to scalability issues but short of
> having a specific goal for scalability, it is not clear that will be the
> case.)
> 2- Alternatively, We could subscribe to the message queue and wait for
> such a port update event.
> 3- It was also suggested that we could use l2 agent extension to detect
> such an event but that seems to limit us to certain Neutron plugins and
> therefore not acceptable.
>
> I was wondering if there are other and better options.
>
> Best,
>
> Mohammad
> __
> 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
>
__
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

Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port isActive

[Neil Jerram]

Yes, that all makes sense - thanks for explaining.

Neil


On Fri, Jun 10, 2016 at 3:50 PM Mohammad Banikazemi  wrote:

> Hi Neil,
>
> Currently, when a docker libnetwork "join" operation in Kuryr is returned,
> it is not guaranteed that the network connectivity has been established.
> There are containers that check for network connectivity as the first thing
> they do when they come up and under heavy load some notice there is no
> connectivity and simply bail out. I am trying to deal with such a use case,
>
> Thanks for pointing out that option 2 won't work for you. I think
> Salvatore also alluded to that in his response. What you are suggesting
> with pinging the container from the appropriate namespace may be worth a
> try but then there may be containers that do not allow ingress traffic
> while they are up and happy. So short of what Salvatore suggested in his
> earlier email (and I am not sure if that can be done without additions to
> Neutron), we are left with option 1.
>
> Keep in mind that users can choose not to enable the blocking option and
> things will be as they are right now. Would that be reasonable?
>
> Best,
>
> Mohammad
>
> [image: Inactive hide details for Neil Jerram ---06/10/2016 09:25:59
> AM---Hi Mohammad, Why is the blocking needed? Is it to report som]Neil
> Jerram ---06/10/2016 09:25:59 AM---Hi Mohammad, Why is the blocking needed?
> Is it to report some kind of status back to
>
> From: Neil Jerram 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: 06/10/2016 09:25 AM
>
>
> Subject: Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port
> is Active
> --
>
>
>
> Hi Mohammad,
>
> Why is the blocking needed?  Is it to report some kind of status back to
> Docker/Kubernetes, or to allow some follow-on action to happen?
>
> When using networking-calico as the driver, I think that only option (1)
> would work, out of the options you've suggested below.  (3) doesn't work,
> as you say, because Calico doesn't involve an L2 agent.  Also Calico
> doesn't use the RPC message queue for reporting port status, because we've
> found that that message queue is in itself a scalability bottleneck.
>
> I guess another option would be for the using system to determine for
> itself when the port appears to be working, e.g. by the host pinging the
> container/pod's IP address.
>
> Regards,
> Neil
>
>
> On Wed, Jun 8, 2016 at 4:23 PM Mohammad Banikazemi <*m...@us.ibm.com*
> > wrote:
>
>
>For the Kuryr project, in order to support blocking until vifs are
>plugged in (that is adding config options similar to the following options
>define in Nova: vif_plugging_is_fatal and vif_plugging_timeout), we need to
>detect that the Neutron plugin being used is done with plugging a given 
> vif.
>
>Here are a few options:
>
>1- The simplest approach seems to be polling for the status of the
>Neutron port to become Active. (This may lead to scalability issues but
>short of having a specific goal for scalability, it is not clear that will
>be the case.)
>2- Alternatively, We could subscribe to the message queue and wait for
>such a port update event.
>3- It was also suggested that we could use l2 agent extension to
>detect such an event but that seems to limit us to certain Neutron plugins
>and therefore not acceptable.
>
>I was wondering if there are other and better options.
>
>Best,
>
>Mohammad
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
>*openstack-dev-requ...@lists.openstack.org?subject:unsubscribe*
><http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>
>
>*http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*
><http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>__
>
>
>
>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
>
>
>
> __
> 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
>
__
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

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Neil Jerram]

On Wed, Jun 15, 2016 at 9:52 AM Thierry Carrez 
wrote:

> [...]
> Those are good points. Note that I do not advocate for those projects to
> be kept closed/private: I'm simply saying that those (open source)
> projects should not be blessed as "official" and be put under the
> Technical Committee oversight. They can still exist in the OpenStack
> ecosystem, be developed using Gerrit and an openstack/* git repository,
> be plugged into the gate... but as an unofficial project.
>

Could you point me to where it's described how to create and operate an
unofficial project like that?  (Or are you talking about a possible future
arrangement that doesn't already exist?)

Thanks,
Neil
__
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

[openstack-dev] [neutron][calico] New networking-calico IRC meeting

[Neil Jerram]

Calling everyone interested in networking-calico ...!  networking-calico
has been around in the Neutron stadium for a while now, and it's way past
time that we had a proper forum for discussing and evolving it - so I'm
happy to be finally proposing a regular IRC meeting slot for it: [1].  A
strawman initial agenda is up at [2].

[1] https://review.openstack.org/#/c/331689/
[2] https://wiki.openstack.org/wiki/Meetings/NetworkingCalico

Please do take a look and

   - let me know your views on the timing, either here or on the review
   - feel free to add items to the agenda.


Many thanks,
   Neil
__
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

Re: [openstack-dev] [packaging-deb] Status of the project

[Neil Jerram]

Is there a higher-level overview somewhere of what packaging-deb does?
Should it be useful to me as the packager of a Neutron driver project
(networking-calico)?  (Currently I've rolled my own processes for
generating Debian packages for Ubuntu Trusty and Xenial.)

Thanks,
Neil


On Wed, Jun 22, 2016 at 10:10 AM Thomas Goirand  wrote:

> I've been asked to tell everyone the status of the project. So here is a
> report.
>
> What's been already done:
> - Debian Jessie image is up and running on all Infra nodes.
>
> - openstack-pkg-tools package can be built on each request, and is
> gating on the fact that it builds or not. This includes installing and
> setting-up the build environment using sbuild and git-buildpackage,
> which will be reused everywhere.
>
> - openstack-pkg-tools resulting packages are pushed to
> tarballs.openstack.org after a merge of a patch proposal. Though it
> seems there's still some issues to fix so that it pushes to the correct
> location (ie: /packaging-deb/openstack-pkg-tools/).
>
> What we need to do:
>
> 1/ Push openstack-pkg-tools to a Debian repo
> Once pushing the built openstack-pkg-tools to tarballs.openstack.org is
> done on the correct location, we should build another job that will pick
> the resulting artefacts (ie: source package and binary package), and add
> it to a (new) Debian repository.
>
> 2/ Once we have a repository with openstack-pkg-tools, we can (finish)
> the infra job to build all other packages. This will be *very* easy to
> do, since all the work is already done to build openstack-pkg-tools
> itself. The only difference is that it will use the build scripts from
> the openstack-pkg-tools *package* instead of openstack-pkg-tools reusing
> its own scripts from the git clone (copied in /usr/bin). There's such a
> difference to avoid a bad commit within openstack-pkg-tools blocking
> everything, including a fix to openstack-pkg-tools itself.
>
> 3/ Another Debian repository should be created to handle "one time"
> backports of packages not currently maintained within the PKG OpenStack
> group in Debian. Design has already been discussed on how to do it.
> However, since it may take a large amount of time to get this finished
> and working as we expect, what we can do as a temporary solution, is
> simply doing a sync from Mirantis Debian repository (reprepro does it
> very well).
>
> 4/ Add all OpenStack packaging Git repository, and enjoy doing the work
> in OpenStack gerrit.
>
> What's taking so much time currently, is simply step 1/. The infra team
> has its own requirements on how to do it, because of security reasons,
> global distribution of the workload (ie: the Debian repository must be
> available everywhere we build packages, so it must be stored on the
> AFS). This is a non-trivial thing to implement. I don't have enough
> knowledge of OpenStack infra myself to do it alone, and the infra team
> has been very busy over the last months doing many things (upgrade to
> Xenial for many nodes, switching to the new version of Zuul, getting rid
> of Jenkins, etc.).
>
> I've been asked if it was possible to move everything we do within the
> current mixture of git.debian.org + Jenkins build servers hosted at both
> Linaro and Mirantis. It seems, from what I've heard, that it would be
> possible to use Gerrit, while continuing to use the current build system
> with Jenkins. However, I am really not convince that we should put some
> efforts into this, as the infra team is already super busy and has a
> hard time finding time to help us implementing the above. And it doesn't
> seem reasonable to move all the packaging to Gerrit if we don't have the
> same level of functionality and QA that we currently have (ie: build on
> each git push, full packaged based Tempest CI, etc.).
>
> I hope the above is what everyone expected me to write, and that there's
> enough details. I'd happily give more details if one asks. Monty, please
> feel free to reply and add text to this thread if you need to.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> 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
>
__
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

Re: [openstack-dev] [neutron][calico] New networking-calico IRC meeting

[Neil Jerram]

Thanks, Carl.  I had the same observation, so would also be interested in
the answer.

Neil


On Thu, Jun 30, 2016 at 9:15 PM Carl Baldwin  wrote:

> On Mon, Jun 20, 2016 at 8:42 AM, Neil Jerram  wrote:
> > Calling everyone interested in networking-calico ...!  networking-calico
> has
> > been around in the Neutron stadium for a while now, and it's way past
> time
> > that we had a proper forum for discussing and evolving it - so I'm happy
> to
> > be finally proposing a regular IRC meeting slot for it: [1].  A strawman
> > initial agenda is up at [2].
>
> I see that the meeting yaml has merged and I've tried to check
> eavesdrop.o.o [3].  I figured that since this is a biweekly meeting,
> it would help me avoid mistakes to download the ICS file and import it
> in to my calendar.  But, I can't find this meeting on that page!  Has
> this page stopped updating?
>
> Carl
>
> > [1] https://review.openstack.org/#/c/331689/
> > [2] https://wiki.openstack.org/wiki/Meetings/NetworkingCalico
>
> [3] http://eavesdrop.openstack.org/
>
> __
> 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
>
__
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

Re: [openstack-dev] [neutron][calico] New networking-calico IRC meeting

[Neil Jerram]

The first networking-calico IRC meeting was planned for 28th June, but I'm
afraid I was unwell - so it will now be 12th July.  I've updated the agenda
[2] accordingly.

Neil

On Mon, Jun 20, 2016 at 3:42 PM Neil Jerram  wrote:

> Calling everyone interested in networking-calico ...!  networking-calico
> has been around in the Neutron stadium for a while now, and it's way past
> time that we had a proper forum for discussing and evolving it - so I'm
> happy to be finally proposing a regular IRC meeting slot for it: [1].  A
> strawman initial agenda is up at [2].
>
> [1] https://review.openstack.org/#/c/331689/
> [2] https://wiki.openstack.org/wiki/Meetings/NetworkingCalico
>
> Please do take a look and
>
>- let me know your views on the timing, either here or on the review
>- feel free to add items to the agenda.
>
>
> Many thanks,
>Neil
>
>
__
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

Re: [openstack-dev] [Neutron] Neutron-lib and Stadium evolution

[Neil Jerram]

Hi Armando,

Who exactly are you addressing here?  AFAICS, [1] on its own doesn't give
me (or anyone) any new rights for neutron-lib changes.  It appears to be
preparatory to a planned expansion of neutron-lib-core - but looking at
[5], the membership doesn't include me, or folk from many stadium
projects.  So, did I misunderstand who this thread is addressed to?  Or is
the planned expansion still to happen?

Thanks,
Neil


[5] https://review.openstack.org/#/admin/groups/1187,members

On Wed, Jun 29, 2016 at 8:07 PM Armando M.  wrote:

> Hi Neutrinos,
>
> As some of you may have noticed, since the merge of [1] you have now +2
> rights on neutron-lib changes. Please make yourself familiar with review
> guidelines [2]: in general, code that targets the library should go through
> a much greater level of scrutiny and should be targeted if and only if it
> serves the purpose of reuse across the Stadium, and the decoupling of
> Neutron from its consumer projects.
>
> Please, also bear in mind that since [3] is in effect, I'll be working
> over the next few days to implement some of the steps outlined in the plan,
> and that involves consolidating APIs and move them over to neutron-lib.
> Akihiro started the effort of moving the API documentation [4] over
> neutron-lib, and we'll continue towards the consolidation effort.
>
> Please become more involved, and consider neutron-lib as one of the
> projects you take the time of reviewing on a day to day basis.
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/335250/
> [2] http://docs.openstack.org/developer/neutron-lib/review-guidelines.html
> [3]
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
> [4] http://developer.openstack.org/api-ref/networking/
> __
> 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
>
__
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

Re: [openstack-dev] [Neutron] Neutron-lib and Stadium evolution

[Neil Jerram]

Cool - thanks for clarifying that!

   Neil


On Fri, Jul 8, 2016 at 5:20 PM Armando M.  wrote:

> On 8 July 2016 at 08:22, Neil Jerram  wrote:
>
>> Hi Armando,
>>
>> Who exactly are you addressing here?  AFAICS, [1] on its own doesn't give
>> me (or anyone) any new rights for neutron-lib changes.  It appears to be
>> preparatory to a planned expansion of neutron-lib-core - but looking at
>> [5], the membership doesn't include me, or folk from many stadium
>> projects.  So, did I misunderstand who this thread is addressed to?  Or is
>> the planned expansion still to happen?
>>
>> Thanks,
>> Neil
>>
>>
>> [5] https://review.openstack.org/#/admin/groups/1187,members
>>
>
> Right now this is limited to the core maintainers of repos that spun out
> of Neutron. We'll extend rights to other teams over time as soon as we
> complete the Stadium transition plan.
>
>
>>
>> On Wed, Jun 29, 2016 at 8:07 PM Armando M.  wrote:
>>
>>> Hi Neutrinos,
>>>
>>> As some of you may have noticed, since the merge of [1] you have now +2
>>> rights on neutron-lib changes. Please make yourself familiar with review
>>> guidelines [2]: in general, code that targets the library should go through
>>> a much greater level of scrutiny and should be targeted if and only if it
>>> serves the purpose of reuse across the Stadium, and the decoupling of
>>> Neutron from its consumer projects.
>>>
>>> Please, also bear in mind that since [3] is in effect, I'll be working
>>> over the next few days to implement some of the steps outlined in the plan,
>>> and that involves consolidating APIs and move them over to neutron-lib.
>>> Akihiro started the effort of moving the API documentation [4] over
>>> neutron-lib, and we'll continue towards the consolidation effort.
>>>
>>> Please become more involved, and consider neutron-lib as one of the
>>> projects you take the time of reviewing on a day to day basis.
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/335250/
>>> [2]
>>> http://docs.openstack.org/developer/neutron-lib/review-guidelines.html
>>> [3]
>>> http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
>>> [4] http://developer.openstack.org/api-ref/networking/
>>>
>>> __
>>> 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
>>>
>>
>> __
>> 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
>>
>> __
> 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
>
__
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

Re: [openstack-dev] [neutron][calico] New networking-calico IRC meeting

[Neil Jerram]

Hi all,

Just a quick reminder: the first networking-calico IRC meeting will be
tomorrow (12th July) at 1600 UTC.

Neil


On Fri, Jul 1, 2016 at 12:31 PM Neil Jerram  wrote:

> The first networking-calico IRC meeting was planned for 28th June, but I'm
> afraid I was unwell - so it will now be 12th July.  I've updated the agenda
> [2] accordingly.
>
> Neil
>
>
> On Mon, Jun 20, 2016 at 3:42 PM Neil Jerram  wrote:
>
>> Calling everyone interested in networking-calico ...!  networking-calico
>> has been around in the Neutron stadium for a while now, and it's way past
>> time that we had a proper forum for discussing and evolving it - so I'm
>> happy to be finally proposing a regular IRC meeting slot for it: [1].  A
>> strawman initial agenda is up at [2].
>>
>> [1] https://review.openstack.org/#/c/331689/
>> [2] https://wiki.openstack.org/wiki/Meetings/NetworkingCalico
>>
>> Please do take a look and
>>
>>- let me know your views on the timing, either here or on the review
>>- feel free to add items to the agenda.
>>
>>
>> Many thanks,
>>Neil
>>
>>
__
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

[openstack-dev] Singing in Barcelona

[Neil Jerram]

 I know it's crazy, but I've talked with a few people in Vancouver, Tokyo and Austin about the idea of getting a singing group together during a summit, and they've all encouraged me to go for it - so I'll start to look silly if I don't even try this... :-)So this is a call for anyone who wants to do some singing in Barcelona. I don't yet know who, what, or how we'll perform, but I've created an etherpad:https://etherpad.openstack.org/p/barcelona-singingPlease do contribute there if interested! As with everything in OpenStack, it's important for this to be inclusive, so please don't exclude yourself by assuming anything about style of music or required abilities - feel free to add whatever your ideas and interests might be.       Neil 

__
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

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Neil Jerram]

On 29/03/16 09:38, Thomas Goirand wrote:
> On 03/23/2016 04:06 PM, Mike Perez wrote:
>> Hey all,
>>
>> I've been talking to a variety of projects about lack of install guides. This
>> came from me not having a great experience with trying out projects in the 
>> big
>> tent.
>>
>> [...]
>
> Sorry to jump in this conversation a bit later, as I missed this thread.
>
> I've contributed lots of entries for Debian, and I'm a bit frustrated to
> still not have an active link to it.

I don't understand.  Do you mean that you could have published this 
guide yourself, but haven't yet done that;  or that you think someone 
else should be publishing it?

Neil


__
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

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Neil Jerram]

On 29/03/16 12:40, Thomas Goirand wrote:
>
> The documentation people decided to *not* publish the Debian
> install-guide (and remove the link to it) even though it can be
> generated and (to my opinion, which is probably biased) works well.
>
> I'd like to know the steps needed to restore a working active link.
>
> I also am not thrived to see that it's been decided to remove completely
> the Debian guide without even asking me about it. First, this isn't
> big-tent-ish spirit (ie: best effort based), and this isn't the first
> time I'm seeing this kind of things happening within the install-guide.
>
> On each release it's the same: I try to first finish the Debian
> packages, test them well, and *then* work on the install-guide, but when
> this is happening, the Debian install-guide gets removed. I'm not given
> the opportunity to work on it when I have the time to (and my opinion
> isn't even asked).
>
> I've been told multiple times to get someone else to work on the Debian
> guide. Well, it's not happening, nobody is volunteering, and there's
> only me so far. So what do you propose? Just get rid of my work?

Thanks for explaining.  I'd certainly like to see a Debian install guide 
available, if that is achievable.

Neil



__
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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Neil Jerram]

On 29/03/16 15:17, Jay Pipes wrote:
> Hi!
>
> Once Shotgun is pulled out of Fuel, may I suggest renaming it to
> something different? I know in the past that Anita and a few others
> thought the name was not something we should really be encouraging in
> the OpenStack ecosystem.
>
> Just something to consider since it's being decoupled anyway and may be
> a good opportunity to rename at that point...
>
> Best,
> -jay

+1

Neil


__
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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Neil Jerram]

FWIW, as a naive bystander:

On 30/03/16 11:06, Igor Kalnitsky wrote:
> Hey Fuelers,
>
> I know that you probably wouldn't like to hear that, but in my opinion
> Fuel has to stop using Shotgun. It's nothing more but a command runner
> over SSH. Besides, it has well known issues such as retrieving remote
> directories with broken symlinks inside.

It makes sense to me that a command runner over SSH might not need to be 
a whole Fuel-specific component.

> So I propose to find a modern alternative and reuse it. If we stop
> supporting Shotgun, we can spend extra time to focus on more important
> things.
>
> As an example, we can consider to use Ansible. It should not be tricky
> to generate Ansible playbook instead of generating Shotgun one.
> Ansible is a  well known tool for devops and cloud operators, and they
> we will only benefit if we provide possibility to extend diagnostic
> recipes in usual (for them) way. What do you think?

But isn't Ansible also over-complicated for just running commands over SSH?

Neil


__
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

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Neil Jerram]

On 30/03/16 13:35, Igor Kalnitsky wrote:
> Neil Jerram wrote:
>> But isn't Ansible also over-complicated for just running commands over SSH?
>
> It may be not so "simple" to ignore that. Ansible has a lot of modules
> which might be very helpful. For instance, Shotgun makes a database
> dump and there're Ansible modules with the same functionality [1].
>
> Don't think I advocate Ansible as a replacement. My point is, let's
> think about reusing ready solutions. :)

Agreed.
Neil


__
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

Re: [openstack-dev] [Neutron]Relationship between physical networks and segment

[Neil Jerram]

On 29/03/16 20:42, Miguel Lavalle wrote:
> Hi,

Hi Miguel,

> I am writing a patchset to build a mapping between hosts and network
> segments. The goal of this mapping is to be able to say whether a host
> has access to a given network segment. I am building this mapping
> assuming that if a host A has a bridges mapping containing 'physnet 1'
> and a segment has 'physnet 1' in its 'physical_network' attribute, then
> the host has access to that segment.
>
> 1) Is this assumption correct? Looking at method check_segment_for_agent
> in
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/mech_agent.py#n180
> seems to me to suggest that my assumption is correct?

Yes, I would say so.  In other words: if a host can access a particular 
physical network, it can access all segments that use that physical network.

>
> 2) Furthermore, when a segment is mapped to a physical network, is there
> a one to one relationship between segments and physical nets?

No; I would say that segments are N:1 with physical networks, with VLANs 
being the most obvious example.

Neil



__
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

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

[Neil Jerram]

On 11/03/16 23:20, Carl Baldwin wrote:
> Hi,

Hi Carl, and sorry for the lateness of this reply.

> I have started to get into coding [1] for the Neutron routed networks
> specification [2].
>
> This spec proposes a new association between network segments and
> subnets.  This affects how IPAM needs to work because until we know
> where the port is going to land, we cannot allocate an IP address for
> it.

Note: according to the text and discussion at 
https://review.openstack.org/#/c/263898/, Neutron actually _does_ 
already know where the port is going to land (i.e. the chosen host) at 
the time when it is first allocating an IP address.  At least in the 
most common case, which is when the user request is "launch instance(s) 
on  network".

> Also, IPAM will need to somehow be aware of segments.  We have
> proposed a host / segment mapping which could be transformed to a host
> / subnet mapping for IPAM purposes.
>
> I wanted to get the opinion of folks like Salvatore, John Belamaric,
> and you (if you interested) on this.  How will this affect the
> interface to pluggable IPAM and how can pluggable implementations can
> accommodate this change.

Well, first of all we have a problem that the pluggable IPAM interface 
is not documented as it is already.  So it is tricky to comment at all 
on how that interface might need to change. :-)

Petra Sargent, with a little of my help, has started documenting the 
interface at https://review.openstack.org/#/c/289460/, but I think there 
is still lots more to be said there - so I would encourage anyone with 
existing knowledge of the IPAM interface to go there and contribute 
useful chunks of extra explanatory text.

With that as a big caveat, here are my thoughts so far.  The pluggable 
IPAM interface has core Neutron code on one side, and pluggable IPAM 
drivers on the other.  As a general principle, it's better if we can 
keep complexity on the core side, and keep the IPAM drivers as simple as 
possible to write and maintain; because there is only one Neutron core, 
and there will in future be many IPAM drivers.

I believe it's already the case that the core tells the driver about the 
subnet(s) that the driver can allocate an IP from.  (Although I'm not 
sure exactly what form that takes, and also if the subnet(s) is/are 
specified on a per-instance basis or per-group of instances, or 
something else.)  Therefore, in the case where segments are being used, 
and subnets are defined with affinity to those segments, the core could 
handle that by reducing the set of subnets that it offers to the driver; 
and that would not require any change to existing IPAM drivers.

At least in the first implementation, I would _not_ pass any new 
segment-specific information over the pluggable IPAM interface (i.e. to 
the driver), because I don't see any reason for the driver to need this; 
I think it's better to contain the handling of that within the Neutron core.

I believe that the core does _not_ tell the driver about the chosen host 
for the port for which an IP allocation is wanted (i.e. 
port['binding:host_id']).  I would like this information to be passed to 
the driver, so as to enable cases where some kind of host-subnet 
affinity is desirable, but that affinity cannot be described by Neutron 
segment objects.  So in this case the driver should receive

- all of the subnet(s) that are defined for the relevant Network

- the chosen host

and it would use its own out-of-band knowledge to decide how to allocate 
an IP from some subrange of the available subnet(s), depending on the 
chosen host.

Finally, I believe that the current pluggable IPAM interface technically 
already allows the last paragraph to be achieved - but that it is pretty 
hard and complex to do that, as it requires subclassing many classes. 
Assuming I'm right about that, I don't think that such a simple 
interface enhancement should require so much work, and hence I'd prefer 
binding:host_id to be added to the core interface.

>  Obviously, we wouldn't require
> implementations to support it

"implementations" = existing IPAM drivers, here?  I think what we need 
can be done in a way such that there is no "it" for them to support.

> but routed networks wouldn't be very
> useful without it.

Here, I assume that "it" means "allocating IPs in a host- or 
segment-dependent way", and I agree with you that this is a practical 
requirement for large scale routed network usage.

>  So, those implementations would not be compatible
> when routed networks are deployed.

(Again, I think we shouldn't need to say this.)

> Another related topic was brought up in the recent Neutron mid-cycle.
> We talked about adding a service type attribute to to subnets.  The
> reason for this change is to allow operators to create special subnets
> on a network to be used only by certain kinds of ports.  For example,
> DVR fip namespace gateway ports burn a public IP for no good reason.
> This new feature would allow operator

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

[Neil Jerram]

On 29/03/16 19:16, Carl Baldwin wrote:
> I've been playing with this a bit on this patch set [1].  I haven't
> gotten very far yet but it has me thinking.
>
> Calico has a similar use case in mind as I do.  Essentially, we both
> want to group subnets to allow for aggregation of routes.  (a) In
> routed networks, we want to group them by segment and the boundaries
> are hard meaning that if an IP is requested from a particular segment,
> IPAM should fail if it can't allocate it from the same.
>
> (b) For Calico, I believe that the goal is to group by host.  Their
> boundaries are soft meaning that it is okay to allocate any IP on the
> network but one that allows maximum route aggregation is strongly
> preferred.

Correct, and thanks for thinking about this case.

> (c) Brian Haley will soon post a spec to address the need to group
> subnets by service type.  This is another sort of grouping but is
> orthogonal to the need to group for routing purposes.  Here, we're
> trying to group like ports together so that we can use different types
> of addresses.  This kind of grouping could coexist with route grouping
> since they are orthogonal.
>
> Given all this grouping, it seems like it might make sense to add some
> sort of grouping feature to IPAM.  Here's how I'm thinking it will
> work.
>
> 1.  When a subnet is allocated, a group id(s) can be passed with the
> request.  IPAM will remember the group id with the subnet.
> 2.  When an IP address is needed, a group id(s) can be passed with the
> request.  IPAM will try to allocate from a subnet with a matching
> group id(s).

When you say "a group id(s) can be passed", are you thinking of the API 
into Neutron (e.g. from Nova), or of the API between the Neutron core 
and a pluggable IPAM driver?  (Or some other API?)

My guess is you mean the API between Neutron core and a pluggable IPAM 
driver.  For that case, I think your suggestion would make sense if 
information about all available subnets was passed upfront to the driver 
- i.e. whenever the network/subnet data model changes - but I am not 
sure if that is what happens.  Rather, I think it might be the case that 
the available subnets/CIDRs are passed to the driver for each IP 
allocation that is wanted.

If that last sentence is correct, then the Neutron core could do the 
filtering-by-group-id itself, and simply pass a filtered set of 
subnets/CIDRs to the driver, and I think that that would be simpler.

> 3.  If no IP address is available that exactly matches the group id(s)
> then IPAM may fall back to another subnet.  This behavior needs to be
> different for the various use cases mentioned which is where it gets
> kind of complicated.
>(a) No fallback is allowed.  The IP allocation should fail.
>(b) We can fall back to any other subnet.  There might be some
> reasons to prefer some over others but this could get complicated
> fast.
>(c) We can fall back to any subnet with None as its group (legacy
> subnets) but not to other groups (e.g. if I'm trying to allocate a
> floating IP address, I don't want to fall back to a subnet meant for
> DVR gateways because those aren't public IP addresses).
>
> I put (s) after group id in many cases above because it appears that
> we can have more than one kind of orthogonal grouping to consider at
> the same time.
>
> What do folks think?
>
> Am I trying to generalize too much and making it complicated?

FWIW, I don't think so.  But I'd like to be a lot surer about the shape 
of the existing pluggable IPAM interface.

Regards,
Neil


__
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

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

[Neil Jerram]

On 29/03/16 21:55, Carl Baldwin wrote:
>
> I thought of another type of grouping which could benefit pluggable
> IPAM today.  It occurred to me as I was refreshing my memory on how
> pluggable IPAM works when there are multiple subnets on a network.
> Currently, Neutron's backend pulls the subnets  and then tries to ask
> the IPAM driver for an IP on each one in turn [1].  This is
> inefficient and I think it is a natural opportunity to evolve the IPAM
> interface to allow this to be handled within the driver itself.  The
> driver could optimize it to avoid repeated round-trips to an external
> server.

Yes, that sounds sensible.  It would be nice to continue supporting the 
current pattern too though.

> Anyway, it occurred to me that this is just like segment aware IPAM
> except that the network is the group instead of the segment.  The IPAM
> driver could consider it another orthogonal grouping of subnets (even
> though it isn't really orthogonal to Neutron's point of view).  I
> could provide an implementation that would provide a shim for existing
> IPAM drivers to work without modification.  In fact, I could do that
> for all the types of grouping I've mentioned.

Yes - I think this is the same as I've been saying in previous replies, 
i.e. that the Neutron core can filter the subnets before it offers them 
to the driver.  Is that what you meant too?

 > Drivers could choose to
> sub-class the behavior to optimize it if they have the capability.
>
> Carl
>
> [1] 
> https://github.com/openstack/neutron/blob/4a6d05e410/neutron/db/ipam_pluggable_backend.py#L88

While we're here...

 def _ipam_try_allocate_ip(self, context, ipam_driver, port, ip_dict):
 factory = ipam_driver.get_address_request_factory()
 ip_request = factory.get_request(context, port, ip_dict)
 ipam_subnet = ipam_driver.get_subnet(ip_dict['subnet_id'])
 return ipam_subnet.allocate(ip_request)

What is the benefit of the separate "ipam_subnet = " line?  Why not just:

 def _ipam_try_allocate_ip(self, context, ipam_driver, port, ip_dict):
 factory = ipam_driver.get_address_request_factory()
 ip_request = factory.get_request(context, port, ip_dict)
 return ipam_driver.allocate(ip_request)

Similarly, what is the benefit of calling the driver twice to convert 
from (available info) to (request object) and then from (request object) 
to (IP allocation)?  Why not go directly from (available info) to (IP 
allocation)?

Finally, while I'm asking IPAM interface questions, what are subnet 
requests for?

Neil


__
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

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

[Neil Jerram]

On 30/03/16 16:08, Pavel Bondar wrote:

> We are now in early Newton, so it is good time to discuss plan for
> pluggable ipam for this release cycle.
>
> Kevin Benton commented on review page for current migration to pluggable
> approach [1]:
>>
>> IMO this cannot be optional. It's going to be a nightmare to try to
>> support two IPAM systems that people may have switched between at
>> various points in time. I would much rather go all-in on the upgrade
>> by making it automatic with alembic and removing the option to use the
>> legacy IPAM code completely.
>>
>> I've already been bitten by testing the new IPAM code with the config
>> option and switching back which resulted in undeletable subnets. Now
>> we can always yell at anyone that changes the config option like I
>> did, but it takes a lot of energy to yell at users and they don't care
>> for it much. :)
>>
>> Even ignoring the support issue, consider schema changes. This
>> migration script will have to be constantly updated to work with
>> whatever the current state of the schema is on both sets of ipam
>> tables. Without constant in-tree testing enforcing that, we are one
>> schema change away from this script breaking.
>>
>> So let's bite the bullet and make this a normal contract migration.
>> Either the new ipam system is stable enough for us to commit to
>> supporting it and fix whatever bugs it may have, or we need to remove
>> it from the tree. Supporting both systems is unsustainable.
>>
> This sound reasonable to me. It simplify support and testing (testing
> both implementations in gate with full coverage is not easy).
>  From user prospective there should be no visible changes between
> pluggable ipam and non-pluggable.
> And making switch early in release cycle gives us enough time to fix any
> bug we will find in pluggable implementation.
>
> Right now we have some open bugs for pluggable code [2], but they are
> still possible to fix.
>
> Does it make sense to you?

Yes!  Kill the non-pluggable code already.  Neutron desperately needs to 
have less and simpler code in any area where it can possibly get it.

Neil


__
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

Re: [openstack-dev] [Nova] No rejoin-stack.sh script in my setup

[Neil Jerram]

On 31/03/16 12:10, Ouadï Belmokhtar wrote:
> Hi everyone,
>
> Could you give any help to my question here, please.
>
> http://stackoverflow.com/questions/36268822/no-rejoin-stack-sh-script-in-my-setup
>
> I'm blocked with the same problem since 10 days. Any help is considered.

I think the recommended equivalent now is: screen -x stack

Neil



__
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

Re: [openstack-dev] [All][Neutron] Improving development and review velocity - Is it time for a drastic change?

[Neil Jerram]

On 01/04/16 02:16, Assaf Muller wrote:
> Have you been negatively impacted by slow development and review
> velocity? Read on.
>
> OpenStack has had a slow review velocity for as long as I can
> remember. This has a cascading effect where people take up multiple
> tasks, so that they can work on something while the other is being
> reviewed. This adds even more patches to ever growing queues. Features
> miss releases and bugs never get fixed. Even worse, we turn away new
> contributors due to an agonizing process.
>
> In the Neutron community, we've tried a few things over the years.
> Neutron's growing scope was identified and load balancing, VPN and
> firewall as a service were split out to their own repositories.
> Neutron core reviewers had less load, *aaS contributors could iterate
> faster, it was a win win. Following that, Neutron plugins were split
> off as well. Neutron core reviewers did not have the expertise or
> access to specialized hardware of vendors anyway, vendors could
> iterate faster, and everybody were happy. Finally, a specialization
> system was created. Areas of the Neutron code base were determined and
> a "Lieutenant" was chosen for each area. That lieutenant could then
> nominate core reviewers, and those reviewers were then expected to +2
> only within their area. This led to doubling the core team, and for my
> money was a great success. Leading us to today.
>
> Today, I think it's clear we still have a grave problem. Patches sit
> idle for months, turning contributors away. I believe we've reached a
> tipping point, and now is the time for out of the box thinking. I am
> proposing two changes:
>
> 1) Changing what a core reviewer is. It is time to move to a system of
> trust: Everyone have +2 rights to begin with, and the system
> self-regulates by shaming offending individuals and eventually taking
> away rights for repeated errors in judgement. I've proposed a Neutron
> governance change here:
>
> https://review.openstack.org/300271
>
> 2) Now, transform yourself six to twelve months in the future. We now
> face a new problem. Patches are flying in. You're no longer working on
> a dozen patches in parallel. You push up something, it is reviewed
> promptly, and you move on to the next thing. Our next issue is then CI
> run-time. The time it takes to test (Check queue), approve and test a
> patch again (Gate queue) is simply too long. How do we cut this down?
> Again, by using a proven open source methodology of trust. As
> Neutron's testing lieutenant, I hereby propose that we remove the
> tests.

You had me until this sentence. :-)  Nice one!

Neil

> Why deal with a problem you can avoid in the first place? The
> Neutron team has been putting out fires in the form of gate issues on
> a weekly basis, double so late in to a release cycle. The gate has so
> many false negatives, the tests are riddled with race conditions,
> we've clearly failed to get testing right. Needless to say, my
> proposal keeps pep8 in place. We all know how important a consistent
> style is. I've proposed a patch that removes Neutron's tests here:
>
> https://review.openstack.org/300272
>
> __
> 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
>


__
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

Re: [openstack-dev] [nova] [all] FYI: Removing default flavors from nova

[Neil Jerram]

I hesitate to write this, even now, but I do think that OpenStack has a 
problem with casual incompatibilities, such as this appears to be.  But, 
frankly, I've been slapped down for expressing my opinion in the past 
(on the pointless 'tenant' to 'project' change), so I just quietly 
despaired when I saw that ops thread, rather than saying anything.

I haven't researched this particular case in detail, so I could be 
misunderstanding its implications.  But in general my impression, from 
the conversations that occur when these topics are raised, is that many 
prominent OpenStack developers do not care enough about 
release-to-release compatibility.  The rule for incompatible changes 
should be "Just Don't", and I believe that if everyone internalized 
that, they could easily find alternative approaches without breaking 
compatibility.

When an incompatible change like this is made, imagine the 1000s of 
operators and users around the world, with complex automation around 
OpenStack, who see their deployment or testing failing, spend a couple 
of hours debugging, and eventually discover 'oh, they removed m1.small' 
or 'oh, they changed the glance command line'.  Given that hassle and 
bad feeling, is the benefit that developers get from the incompatibility 
still worth it?

I would guess there are many others like me, who generally don't say 
anything because they've already observed that the prevailing sentiment 
is not sufficiently on the side of compatibility.

Neil


__
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

Re: [openstack-dev] [all] [devstack] Adding example "local.conf" files for testing?

[Neil Jerram]

On 14/04/16 08:35, Markus Zoeller wrote:
> Sometimes (especially when I try to reproduce bugs) I have the need
> to set up a local environment with devstack. Everytime I have to look
> at my notes to check which option in the "local.conf" have to be set
> for my needs. I'd like to add a folder in devstacks tree which hosts
> multiple example local.conf files for different, often used setups.
> Something like this:
>
>  example-confs
>  --- newton
>  --- --- x86-ubuntu-1404
>  --- --- --- minimum-setup
>  --- --- --- --- README.rst
>  --- --- --- --- local.conf
>  --- --- --- serial-console-setup
>  --- --- --- --- README.rst
>  --- --- --- --- local.conf
>  --- --- --- live-migration-setup
>  --- --- --- --- README.rst
>  --- --- --- --- local.conf.controller
>  --- --- --- --- local.conf.compute1
>  --- --- --- --- local.conf.compute2
>  --- --- --- minimal-neutron-setup
>  --- --- --- --- README.rst
>  --- --- --- --- local.conf
>  --- --- s390x-1.1.1-vulcan
>  --- --- --- minimum-setup
>  --- --- --- --- README.rst
>  --- --- --- --- local.conf
>  --- --- --- live-migration-setup
>  --- --- --- --- README.rst
>  --- --- --- --- local.conf.controller
>  --- --- --- --- local.conf.compute1
>  --- --- --- --- local.conf.compute2
>  --- mitaka
>  --- --- # same structure as master branch. omitted for brevity
>  --- liberty
>  --- --- # same structure as master branch. omitted for brevity
>
> Thoughts?

Yes, this looks useful to me.  Only thing is that you shouldn't need the 
per-release subtrees, though; the DevStack repository already has 
per-release stable/ branches, which you need to check out in 
order to do a DevStack setup of a past release.  So I would expect the 
local.confs for each past release to live in the corresponding branch.

Regards,
Neil



__
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

[openstack-dev] summit tools

[Neil Jerram]

A couple of questions about our Austin-related planning tools...

- Can one's calendar at 
https://www.openstack.org/summit/austin-2016/summit-schedule/#day=2016-04-25 
be exported as .ics, or otherwise integrated into a wider calendaring 
system?

- Is the app working for anyone else?  All I get is 'Oops - there was an 
error performing this operation' and 'There was a problem loading summit 
information ...'  My phone is a Blackberry, which means I'm asking for 
trouble, but OTOH it has an Android runtime and does successfully run 
several other Android apps.

Thanks,
Neil

__
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

Re: [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad project

[Neil Jerram]

On 19/04/16 16:52, Irina Povolotskaya wrote:
> Hi to everyone,
>
> as you possibly know (at least, those dev. teams working on their Fuel
> plugins) we have a fuel-plugins Launchpad project [1] which serves as
> all-in-one entry point for filing bugs, related
> to plugin-specific problems.
>
> nevertheless, this single project is a bad idea in terms of providing
> granularity and visibility for each plugin:
> - it's not possible to make up milestones, unique for every plugin that
> would coincide with the plugin's version (which is specified in
> metadata.yaml file)
> - it's not possible to provide every dev. team with exclusive rights on
> managing importance, milestones etc.
>
> therefore, I would like to propose the following:
> - if you have your own fuel plugin, create a separate LP project for it
> e.g.[2] [3]and make up all corresponding groups for managing release
> cycle of your plugin
> - if you have some issues with fuel plugin framework itself, please
> consider filing bugs in fuel project [4] as usual.
>
> I would appreciate getting feedback on this idea.
> if it seems fine, then I'll follow-up with adding instructions into our
> SDK [5] and the list of already existing LP projects.

I agree that it is better to have a project for each plugin.  For the 
Calico plugin, we actually already have this [1].

Thanks,
Neil

[1] https://launchpad.net/fuel-plugin-calico


__
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

Re: [openstack-dev] [neutron] Social at the summit

[Neil Jerram]

On 25/04/16 10:58, Kyle Mestery wrote:
> Ihar, Henry and I were talking and we thought Thursday night makes sense for 
> a Neutron social in Austin. If others agree, reply on this thread and we'll 
> find a place.

That sounds good to me - thanks for thinking of it!

Neil



__
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

Re: [openstack-dev] Easing contributions to central documentation

[Neil Jerram]

On 09/05/16 22:57, Matt Kassawara wrote:
> At each summit, I speak with a variety of developers from different
> projects about the apparent lack of contributions to the central
> documentation. At previous summits, the most common complaint involved
> using DocBook. After converting most of the documentation to RST, the
> most common complaint at the recent summit involves the review
> process, particularly the lengthy amount of time patches sit in the
> review queue with -1s for various "conventions" problems such as
> structure, formatting, grammar, spelling, etc. Unlike most OpenStack
> developers that focus on a particular project, the documentation team
> covers all projects and lacks the capacity to understand each one
> enough to contribute and maintain technically accurate documentation
> in a timely manner. However, covering all projects enables the
> documentation team to organize and present the documentation to
> various audiences, primarily operators and users, that consume
> OpenStack as a coherent product. In other words, the entire process
> relies on developers contributing to the central documentation. So,
> before developer frustrations drive some or all projects to move their
> documentation in-tree which which negatively impacts the goal of
> presenting a coherent product, I suggest establishing an agreement
> between developers and the documentation team regarding the review
> process. 
>
> As much as the documentation team wants to present OpenStack as a
> coherent product, it contains many projects with different
> contribution processes. In some cases, individual developers prefer to
> contribute in unique ways. Thus, the conventional "one-size-fits-all"
> approach that the documentation team historically takes with reviewing
> contributions from developers yields various levels of frustration
> among projects and developers. I ran a potential solution by various
> developers during the recent summit and received enough positive
> feedback to discuss it with a larger audience. So, here goes...
>
> A project or individual developer decides the level of documentation
> team involvement with reviewing patches. The developer adds a WIP to
> the documentation patch while adding content to prevent premature
> reviews by the documentation team. Once the content achieves a
> sufficient level of technical accuracy, the developer removes the WIP
> and adds a comment in the review indicating of the following preferences:
>
> 1) The documentation team should review the patch for compliance with
> conventions (proper structure, format, grammar, spelling, etc.) and
> provide feedback to the developer who updates the patch.
> 2) The documentation team should modify the patch to make it compliant
> and ask the developer for a final review to prior to merging it.
> 3) The documentation team should only modify the patch to make it
> build (if necessary) and quickly merge it with a documentation bug to
> resolve any compliance problems in a future patch by the documentation
> team.
>
> What do you think?

I have mixed feelings about this.  I have contributed documentation in
the past, and felt frustrated by the level of pickiness of the reviews -
to the extent of being somewhat demotivated about contributing more doc
improvements and additions.  So I think I understand where this
conversation is arising from.

On the other hand, firstly I like some of the pickiness, e.g. I don't
really want to see our docs littered with spelling mistakes - so it
might just be that I'm being subjective about what I think is good and
bad pickiness; and secondly I think we should acknowledge that this
isn't only a documentation issue: I've had 'could you also clean this up
while you're in the area' comments, and comments that seem to ask for
things just because they can, rather than being properly argued or
clearly beneficial, for code changes just as much as for docs.

On balance, though, and given that IMO we are still lacking a lot of
important OpenStack documentation (or documentation structure), I think
it would be good for documentation reviewers to adjust their bar down
slightly, so as to encourage more contributions.

I'm not sure if that needs the detailed solution proposed above; it
should be enough for the team to agree an adjusted approach among
themselves.

Regards,
Neil


__
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

[openstack-dev] [kuryr] Port binding query

[Neil Jerram]

I'm trying Kuryr with networking-calico and think I've hit an unhelpful
inconsistency.  A Neutron port has 'id' and 'device_id' fields that are
usually different.  When Nova does VIF binding for a Neutron port, it
generates the Linux device name from 'tap' + port['id'].  But when Kuryr
does VIF binding for a Neutron port, I think it generates the Linux
device name from 'tap' + port['device_id'].

Thoughts?  Does that sound right, or have I misread the code and my
logs?  If it's correct, it marginally impacts the ability to use
identical agent and Neutron driver/plugin code for the two cases (Nova
and Kuryr).

Thanks,
Neil


__
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

[openstack-dev] [kuryr] Port binding query

[Neil Jerram]

I'm trying Kuryr with networking-calico and think I've hit an unhelpful
inconsistency. A Neutron port has 'id' and 'device_id' fields that are
usually different. When Nova does VIF binding for a Neutron port, it
generates the Linux device name from 'tap' + port['id']. But when Kuryr
does VIF binding for a Neutron port, I think it generates the Linux device
name from 'tap' + port['device_id'].

Thoughts? Does that sound right, or have I misread the code and my logs? If
it's correct, it marginally impacts the ability to use identical agent and
Neutron driver/plugin code for the two cases (Nova and Kuryr).

Thanks,
Neil
__
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

Re: [openstack-dev] Easing contributions to central documentation

[Neil Jerram]

On 09/05/16 22:57, Matt Kassawara wrote:
> At each summit, I speak with a variety of developers from different
> projects about the apparent lack of contributions to the central
> documentation. At previous summits, the most common complaint involved
> using DocBook. After converting most of the documentation to RST, the
> most common complaint at the recent summit involves the review
> process, particularly the lengthy amount of time patches sit in the
> review queue with -1s for various "conventions" problems such as
> structure, formatting, grammar, spelling, etc. Unlike most OpenStack
> developers that focus on a particular project, the documentation team
> covers all projects and lacks the capacity to understand each one
> enough to contribute and maintain technically accurate documentation
> in a timely manner. However, covering all projects enables the
> documentation team to organize and present the documentation to
> various audiences, primarily operators and users, that consume
> OpenStack as a coherent product. In other words, the entire process
> relies on developers contributing to the central documentation. So,
> before developer frustrations drive some or all projects to move their
> documentation in-tree which which negatively impacts the goal of
> presenting a coherent product, I suggest establishing an agreement
> between developers and the documentation team regarding the review
> process.
>
> As much as the documentation team wants to present OpenStack as a
> coherent product, it contains many projects with different
> contribution processes. In some cases, individual developers prefer to
> contribute in unique ways. Thus, the conventional "one-size-fits-all"
> approach that the documentation team historically takes with reviewing
> contributions from developers yields various levels of frustration
> among projects and developers. I ran a potential solution by various
> developers during the recent summit and received enough positive
> feedback to discuss it with a larger audience. So, here goes...
>
> A project or individual developer decides the level of documentation
> team involvement with reviewing patches. The developer adds a WIP to
> the documentation patch while adding content to prevent premature
> reviews by the documentation team. Once the content achieves a
> sufficient level of technical accuracy, the developer removes the WIP
> and adds a comment in the review indicating of the following preferences:
>
> 1) The documentation team should review the patch for compliance with
> conventions (proper structure, format, grammar, spelling, etc.) and
> provide feedback to the developer who updates the patch.
> 2) The documentation team should modify the patch to make it compliant
> and ask the developer for a final review to prior to merging it.
> 3) The documentation team should only modify the patch to make it
> build (if necessary) and quickly merge it with a documentation bug to
> resolve any compliance problems in a future patch by the documentation
> team.
>
> What do you think?

I have mixed feelings about this.  I have contributed documentation in
the past, and felt frustrated by the level of pickiness of the reviews -
to the extent of being somewhat demotivated about contributing more doc
improvements and additions.  So I think I understand where this
conversation is arising from.

On the other hand, firstly I like some of the pickiness, e.g. I don't
really want to see our docs littered with spelling mistakes - so it
might just be that I'm being subjective about what I think is good and
bad pickiness; and secondly I think we should acknowledge that this
isn't only a documentation issue: I've had 'could you also clean this up
while you're in the area' comments, and comments that seem to ask for
things just because they can, rather than being properly argued or
clearly beneficial, for code changes just as much as for docs.

On balance, though, and given that IMO we are still lacking a lot of
important OpenStack documentation (or documentation structure), I think
it would be good for documentation reviewers to adjust their bar down
slightly, so as to encourage more contributions.

I'm not sure if that needs the detailed solution proposed above; it
should be enough for the team to agree an adjusted approach among
themselves.

Regards,
Neil
__
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

Re: [openstack-dev] [Neutron] Team meeting this Tuesday at 1400UTC

[Neil Jerram]

On 14/12/15 20:37, Armando M. wrote:
> Hi neutrinos,
>
> A kind reminder for this week's meeting.
>
> For this week we'll continue with the post-milestone format: we'll
> continue talking about blueprints/specs and RFEs. We'll be brief on
> announcements and bugs, and skip the other sections, docs and open
> agenda. More details on [1].
>
> Also, please join me in wishing good riddance to the 'Apologies for
> absence' section. We don't call the roll during the meeting, as
> attendance is not required, even though strongly encouraged.
>
> Cheers,
> Armando
>
> [1] https://wiki.openstack.org/wiki/Network/Meetings
> 

I'm afraid I can't make the meeting today, but will check the logs
afterwards.

One thing that (I think) is not on the agenda is next steps from the
recent stadium discussions.  Perhaps that should be added for next
week's meeting?

Regards,
Neil


__
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

Re: [openstack-dev] [neutron] Query about re-directing incoming traffic.

[Neil Jerram]

On 28/12/15 16:16, Vikram Choudhary wrote:
> Hi All,
>
> We want to redirect all / some specific incoming traffic to a
> particular neutron port, where a network function is deployed.
> [Network function could be DPI, IDS, Firewall, Classifier, etc]. In
> this regard, we have few queries:

Isn't that what SFC is?  (Service Function Chaining.)

Regards,
Neil

>
> 1. How we can achieve this?
>
> 2. Do we have well-defined NBI's for such use-case?
>
> Any thought / suggestion will be appreciated.
>
> Thanks
> Vikram


__
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

Re: [openstack-dev] Further closing the holes that let gate breakage happen

[Neil Jerram]

On 13/01/16 19:27, Carl Baldwin wrote:
> Hi,
>
> I was looking at the most recent gate breakage in Neutron [1], fixed
> by [2].  This gate breakage was held off for some time by the
> upper-constraints.txt file.   This is great progress and I applaud it.
> I'll continue to cheer on this effort.
>
> Now to the next problem.   If my assessment of this gate failure is
> correct, the update to the upper-constraints file [3] was merged
> without running all of the tests across all of the projects that would
> be broken by bringing in this new constraint.  So, we still get
> breakage and it is still (IMO) too often.
>
> As I see it, there are a couple of options.
>
> 1) We run all tests under the upper-constraints control on all updates
> to the upper constraints file like [2].  This would probably mean each
> update has a very long list of tests and we would require that they
> all be fixed before the upper constraint update can be merged.  This
> seems like a difficult thing to coordinate all at once.
> 2) We handle upper-constraints much like we do the global requirements
> updates.  We have the master and a bot that proposes updates to it out
> to the individual projects.  This would create a situation where
> projects are out of sync with the master but I think if we froze the
> master early enough, we could have time to reconcile before release.
> 3) We continue to allow changes in the upper constraints to break
> individual projects.
>
> Are there options that I missed?  What is your opinion?  In my
> opinion, gate breakage happens a bit too often and the effect on the
> community is widespread.  I'd like to contain it even a little bit
> more.
>
> Carl
>
> [1] https://bugs.launchpad.net/neutron/+bug/1533638
> [2] https://review.openstack.org/#/c/266885/
> [3] https://review.openstack.org/#/c/266042/

I've only just started to learn about requirements and constraints, so I
may be misunderstanding.  However,
https://github.com/openstack/requirements/blob/master/README.rst says:

> For upper-constraints.txt changes
>
> If the change was proposed by the OpenStack CI bot, then if the
> change has passed CI, only one reviewer is needed and they should +2
> +A without thinking about things.
>
> If the change was not proposed by the OpenStack CI bot, and does not
> include a global-requirements.txt change, then it should be rejected:
> the CI bot will generate an appropriate change itself. Ask in
> #openstack-infra if the bot needs to be run more quickly.

Doesn't that mean that [3] should have been rejected, and hence already
cover the recent situation?

Neil


__
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

Re: [openstack-dev] Further closing the holes that let gate breakage happen

[Neil Jerram]

On 14/01/16 12:01, Davanum Srinivas wrote:
> Neil,
>
> The global requirements upper-constraints.txt do not cover neutron
> unit test targets. So the unit tests pick up latest from pypi.

I'm afraid I don't understand how that's related to my question below. 
Could you explain further?

It seems you might be saying that upper-constraints.txt should have no
effect on Neutron UTs.  But my understanding from Carl's message is that
an upper-constraints.txt change caused a Neutron UT (running as part of
a gate job) to fail.  So I'm not sure how to understand your statement.

Thanks,
Neil


>
> -- Dims
>
>
>
> On Thu, Jan 14, 2016 at 6:51 AM, Neil Jerram  
> wrote:
>> On 13/01/16 19:27, Carl Baldwin wrote:
>>> Hi,
>>>
>>> I was looking at the most recent gate breakage in Neutron [1], fixed
>>> by [2].  This gate breakage was held off for some time by the
>>> upper-constraints.txt file.   This is great progress and I applaud it.
>>> I'll continue to cheer on this effort.
>>>
>>> Now to the next problem.   If my assessment of this gate failure is
>>> correct, the update to the upper-constraints file [3] was merged
>>> without running all of the tests across all of the projects that would
>>> be broken by bringing in this new constraint.  So, we still get
>>> breakage and it is still (IMO) too often.
>>>
>>> As I see it, there are a couple of options.
>>>
>>> 1) We run all tests under the upper-constraints control on all updates
>>> to the upper constraints file like [2].  This would probably mean each
>>> update has a very long list of tests and we would require that they
>>> all be fixed before the upper constraint update can be merged.  This
>>> seems like a difficult thing to coordinate all at once.
>>> 2) We handle upper-constraints much like we do the global requirements
>>> updates.  We have the master and a bot that proposes updates to it out
>>> to the individual projects.  This would create a situation where
>>> projects are out of sync with the master but I think if we froze the
>>> master early enough, we could have time to reconcile before release.
>>> 3) We continue to allow changes in the upper constraints to break
>>> individual projects.
>>>
>>> Are there options that I missed?  What is your opinion?  In my
>>> opinion, gate breakage happens a bit too often and the effect on the
>>> community is widespread.  I'd like to contain it even a little bit
>>> more.
>>>
>>> Carl
>>>
>>> [1] https://bugs.launchpad.net/neutron/+bug/1533638
>>> [2] https://review.openstack.org/#/c/266885/
>>> [3] https://review.openstack.org/#/c/266042/
>> I've only just started to learn about requirements and constraints, so I
>> may be misunderstanding.  However,
>> https://github.com/openstack/requirements/blob/master/README.rst says:
>>
>>> For upper-constraints.txt changes
>>>
>>> If the change was proposed by the OpenStack CI bot, then if the
>>> change has passed CI, only one reviewer is needed and they should +2
>>> +A without thinking about things.
>>>
>>> If the change was not proposed by the OpenStack CI bot, and does not
>>> include a global-requirements.txt change, then it should be rejected:
>>> the CI bot will generate an appropriate change itself. Ask in
>>> #openstack-infra if the bot needs to be run more quickly.
>> Doesn't that mean that [3] should have been rejected, and hence already
>> cover the recent situation?
>>
>> Neil
>>
>>
>> __
>> 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
>
>


__
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

Re: [openstack-dev] [Openstack] [Neutron] [Docs] Definition of a provider Network

[Neil Jerram]

On 19/01/16 07:36, Andreas Scheuring wrote:
> Hi everybody, 
>
> I stumbled over a definition that explains the difference between a
> Provider network and a self service network. [1] 

I've also spent time trying to understand this, so am happy to offer
that understanding here (for checking?)...

I believe the _definition_ of a 'provider' network is that it is a
network provisioned by the cloud operator - as opposed to 'tenant'
networks that are provisioned by non-admin tenants aka users aka projects.

(I've not seen the term 'Self service' before, but presumably it means
what I'm calling 'tenant'.

Corollaries - but not strictly part of the definition - are that:

- Provider networks typically 'map more closely' in some sense onto the
cloud's underlying physical network than tenant networks do.  The
'provider' API extension - which is usually limited by policy to
operators only, and hence can only be used with provider networks -
allows the operator to specify that mapping, for example which VLAN to
map on to.  Tenant networks are typically implemented with additional
layers of encapsulation, in comparison with provider networks, in order
to allow many tenant networks to coexist on the same compute hosts and
yet be isolatable from each other.

- Provider networks typically use the real IP address space, whereas
tenant networks typically use private IP address space so that multiple
tenant networks can use the same IP addresses.

The network that is on the external side of a Neutron Router has its
router:external property True, and also has to be a provider network. 
Floating IPs come from a subnet that is associated with that provider
network.

It's possible to attach VMs directly to a provider network, as well as
to tenant networks.

>
> To summarize it says:
> - Provider Network: primarily uses layer2 services

I don't know what this means.  All networks have a layer 2 somewhere.

>  and vlan segmentation

Yes, but they don't have to.  A provider network can be 'flat', which
means that its VM interfaces are bridged onto one of the physical
interfaces of the compute host (and it is assumed that all hosts'
physical interfaces are themselves bridged together).  So then any VLAN
that a VM used would be trunked through the physical network.

> and cannot be used for advanced services (fwaas,..)

(I didn't know that, but OK.)

> - Self-service Network: is Neutron configured to use a overlay network

Grammar?

> and supports advanced services (fwaas,..)
>
>
> But my understanding is more like this:
> - Provider Network: The Openstack user needs information about the
> underlying network infrastructure to create a virtual network that
> exactly matches this infrastructure. 

Agreed, if s/user/operator/ and s/virtual//.  OpenStack _users_ cannot
create provider networks, and I wouldn't call a provider network 'virtual'.


>
> - Self service network: The Openstack user can create virtual networks
> without knowledge about the underlaying infrastructure on the data
> network. This can also include vlan networks, if the l2 plugin/agent was
> configured accordingly.

Agreed.
>
>
> Did the meaning of a provider network change in the meantime, or is my
> understanding just wrong?
>
> Thanks!
>
>
>
>
> [1]
> http://docs.openstack.org/liberty/install-guide-rdo/overview.html#id4
>
>


__
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

[openstack-dev] [neutron][networking-calico] To be or not to be an ML2 mechanism driver?

[Neil Jerram]

networking-calico [1] is currently implemented as an ML2 mechanism
driver, but
I'm wondering if it might be better as its own core plugin, and I'm
looking for
input about the implications of that, or for experience with that kind of
change; and also for experience and understanding of hybrid ML2
networking.

Here the considerations that I'm aware of:

* Why change from ML2 to core plugin?

- It could be seen as resolving a conceptual mismatch. 
networking-calico uses
  IP routing to provide L3 connectivity between VMs, whereas ML2 is
ostensibly
  all about layer 2 mechanisms.  Arguably it's the Wrong Thing for a
L3-based
  network to be implemented as an ML2 driver, and changing to a core plugin
  would fix that.

  On the other hand, the current ML2 implementation seems to work fine,
and I
  think that the L2 focus of ML2 may be seen as traditional assumption just
  like the previously assumed L2 semantics of neutron Networks; and it
may be
  that the scope of 'ML2' could and should be expanded to both L2- and
L3-based
  implementations, just as [2] is proposing to expand the scope of the
neutron
  Network object to encompass L3-only behaviour as well as L2/L3.

- Some simplification of the required config.  A single 'core_plugin =
calico'
  setting could replace 'core_plugin = ml2' plus a handful of ML2 settings.

- Code-wise, it's a much smaller change than you might imagine, because
the new
  core plugin can still derive from ML2, and so internally retain the ML2
  coding architecture.

* Why stay as an ML2 driver?

- Perhaps because of ML2's support for multiple networking
implementations in
  the same cluster.  To the extent that it makes sense, I'd like
  networking-calico networks to coexist with other networking
implementations
  in the same data center.

  But I'm not sure to what extent such hybrid networking is a real
thing, and
  this is the main point on which I'd appreciate input.  In principle ML2
  supports multiple network Types and multiple network Mechanisms, but I
wonder
  how far that really works - or is useful - in practice.

  Let's look at Types first.  ML2 supports multiple provider network types,
  with the Type for each network being specified explicitly by the
provider API
  extension (provider:network_type), or else defaulting to the
  'external_network_type' ML2 config setting.  However, would a cloud
operator
  ever actually use more than one provider Type?  My understanding is that
  provider networks are designed to map closely onto the real network, and I
  guess that an operator would also favour a uniform design there, hence
just
  using a single provider network Type.

  For tenant networks ML2 allows multiple network Types to be configured
in the
  'tenant_network_types' setting.  However, if my reading of the code is
  correct, only the first of these Types will ever be used for a tenant
network
  - unless the system runs out of the 'resources' needed for that Type, for
  example if the first Type is 'vlan' but there are no VLAN IDs left to use.
  Is that a feature that is used in practice, within a given
deployment?  For
  exampe, to first use VLANs for tenant networks, then switch to
something else
  when those run out?

  ML2 also supports multiple mechanism drivers.  When a new Port is being
  created, ML2 calls each mechanism driver to give it the chance to do
binding
  and connectivity setup for that Port.  In principle, if mechanism
drivers are
  present, I guess each one is supposed to look at some of the available
Port
  data - and perhaps the network Type - and thereby infer whether it
should be
  responsible for that Port, and so do the setup for it.  But I wonder if
  anyone runs a cloud where that really happens?  If so, have I got it
right?


All in all, if hybrid ML2 networking is a really used thing, I'd like to
make
sure I fully understand it, and would tend to prefer networking-calico
remaining as an ML2 mechanism driver.  (Which means I also need to discuss
further about conceptually extending 'ML2' to L3-only implementations, and
raise another point about what happens when the service_plugin that you need
for some extension - say a floating IP - depends on which mechanism
driver was
used to set up the relevant Port...)  But if not, perhaps it would be a
better
choice for networking-calico to be its own core plugin.

Thanks for reading!  What do you think?

   Neil


[1] http://docs.openstack.org/developer/networking-calico/
[2] https://review.openstack.org/#/c/225384/


__
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

[openstack-dev] [neutron] https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers

[Neil Jerram]

Is there any part of the cited wiki page that is still relevant?I've just been 
asked whether networking-calico (a backend project that I work on) should be 
listed there, and I think the answer is no because that page is out of date now.

If that's right, could/should it be deleted?

Thanks,
Neil

__
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

Re: [openstack-dev] [neutron] https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers

[Neil Jerram]

Thanks!

On 28/01/16 00:23, Armando M. wrote:
> I'll kill it, as this should be superseded by the in-tree devref version.
>
> Thanks for pointing my attention to it.
>
> On 27 January 2016 at 23:40, Neil Jerram  <mailto:neil.jer...@metaswitch.com>> wrote:
>
> Is there any part of the cited wiki page that is still
> relevant?I've just been asked whether networking-calico (a backend
> project that I work on) should be listed there, and I think the
> answer is no because that page is out of date now. 
>
> If that's right, could/should it be deleted? 
>
> Thanks, 
> Neil 
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


__
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

Re: [openstack-dev] [all] the trouble with names

[Neil Jerram]

On 04/02/16 11:40, Sean Dague wrote:
> What options do we have?
>
> 1) Use the names we already have: nova, glance, swift, etc.
>
> Upside, collision problem is solved. Downside, you need a secret decoder
> ring to figure out what project does what.

This is my preference.  Yes, it means that there is an education hurdle
for anyone new to OpenStack to overcome.  But once that is done, there
is a concise and precise term that they and we can all use and understand.

To look at the case that I'm most familiar with:  For me the pervasive
use of 'OpenStack Networking' - rather than 'Neutron' - in docs is both
cumbersome and potentially confusing.  'Networking' can have different
connotations outside the OpenStack context from those inside, and often
doc must talk about both those concepts at the same time.  It would be
much simpler, IMO, just to say 'Neutron' when that is what we mean.

Regards,
Neil


__
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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Neil Jerram]

On 04/02/16 22:39, Assaf Muller wrote:
> On Thu, Feb 4, 2016 at 5:55 PM, Sean M. Collins  wrote:
>> On Thu, Feb 04, 2016 at 04:20:50AM EST, Assaf Muller wrote:
>>
>>> Currently I don't understand why
>>> being a part of the stadium is good or bad for a networking project,
>>> or why does it matter.
>>
>> I think the issue is of public perception.

I agree.  Being 'out' can matter, in some sense, if you are competing -
whether for money, mindshare or whatever - with another project or
approach that is 'in'.  Because it can appear to casual observers that
your project is less 'official', 'blessed', likely to be long term
supported, etc. etc.

But all of that can be mitigated if the criteria are clearly specified
and understand, and uniformly applied.

> That's what I was trying to point out. But it must be something other
> than perception, otherwise we could remove the inclusion list
> altogether. A project would not be in or out.

I'm afraid I don't understand here.

>
>> As others have stated, the
>> issue is the "in" vs. "out" problem. We had a similar situation
>> with 3rd party CI, where we had a list of drivers that were "nice" and
>> had CI running vs drivers that were "naughty" and didn't. Prior to the
>> vendor decomposition effort, We had a multitude of drivers that were
>> in-tree, with the public perception that drivers that were in Neutron's
>> tree were "sanctioned" by the Neutron project.
>>
>> That may not have been the intention, but that's what I think happened.

Precisely.

As some others have said, I see the current discussion as being about
the chain of accountability, from a stadium project, through Neutron, up
to the OpenStack TC and board.  IIUC, Armando and other cores feel that
there is a gap there - because they can't reasonably understand and
vouch for all the stadium projects to the same standard they can for
core Neutron.  Plus it seems (from the current
https://review.openstack.org/#/c/275888/9 text) that there is a desire
for strong core team overlap between openstack/neutron and all Neutron
stadium projects.

As the lead of networking-calico, I think it's a reasonable call to say
that networking-calico (and similar projects) should therefore be
OpenStack big tent projects, rather than Neutron stadium, and hence the
reviews I've just left.

Regards,
Neil


__
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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Neil Jerram]

On 05/02/16 10:59, Thierry Carrez wrote:
> Hi everyone,
>
> Even before OpenStack had a name, our "Four Opens" principles were 
> created to define how we would operate as a community. The first open, 
> "Open Source", added the following precision: "We do not produce 'open 
> core' software". What does this mean in 2016 ?
>
> Back in 2010 when OpenStack was started, this was a key difference with 
> the other open source cloud platform (Eucalyptus) which was following an 
> Open Core strategy with a crippled community edition and an "enterprise 
> version". OpenStack was then the property of a single entity 
> (Rackspace), so giving strong signals that we would never follow such a 
> strategy was essential to form a real community.
>
> Fast-forward today, the open source project is driven by a non-profit 
> independent Foundation, which could not even do an "enterprise edition" 
> if it wanted to. However, member companies build "enterprise products" 
> on top of the Apache-licensed upstream project. And we have drivers that 
> expose functionality in proprietary components. So what does it mean to 
> "not do open core" in 2016 ? What is acceptable and what's not ? It is 
> time for us to refresh this.
>
> My personal take on that is that we can draw a line in the sand for what 
> is acceptable as an official project in the upstream OpenStack open 
> source effort. It should have a fully-functional, production-grade open 
> source implementation. If you need proprietary software or a commercial 
> entity to fully use the functionality of a project or getting serious 
> about it, then it should not be accepted in OpenStack as an official 
> project. It can still live as a non-official project and even be hosted 
> under OpenStack infrastructure, but it should not be part of 
> "OpenStack". That is how I would interpret "no open core" in OpenStack 2016.
>
> Of course, the devil is in the details, especially around what I mean by 
> "fully-functional" and "production-grade". Is it just an API/stability 
> thing, or does performance/scalability come into account ? There will 
> always be some subjectivity there, but I think it's a good place to start.
>
> Comments ?
>

This sounds right to me.

It looks like there may soon be a group of projects wanting to move from
Neutron stadium governance to OpenStack big tent governance, and I
presume this criterion should apply to those too.

Neil


__
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

Re: [openstack-dev] [all] the trouble with names

[Neil Jerram]

On 05/02/16 13:50, Dean Troyer wrote:
> On Fri, Feb 5, 2016 at 7:13 AM, Neil Jerram  <mailto:neil.jer...@metaswitch.com>> wrote:
>
> On 04/02/16 11:40, Sean Dague wrote:
> > What options do we have?
> >
> > 1) Use the names we already have: nova, glance, swift, etc.
> >
> > Upside, collision problem is solved. Downside, you need a secret decoder
> > ring to figure out what project does what.
>
> This is my preference.  Yes, it means that there is an education hurdle
> for anyone new to OpenStack to overcome.  But once that is done, there
> is a concise and precise term that they and we can all use and
> understand.
>
>
> Have a look at the browser User-Agent headers and let me know how that
> has worked out for them:
>
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.103 Safari/537.36
>
> Two of those product/code names are lies for compatibility purposes.  We
> (OpenStack) should not be promoting that sort of nonsense on our users
> just to save us a little bit of inconvenience in the development process.

I'm not clear how that's a good analogy.  Is it?

> To add something positive to the discussion, we should remember how much
> of OpenStack consists of plugin-capable architecture, specifically so
> that out-of-tree components can be accommodated for whatever reason.
> The projects play the role of arbitrator of namespaces in the case of
> many back-end drivers.

Perhaps my response here is overly detailed, but it appears that you're 
making a quite detailed technical point.  So:

1. Actually, at least for Neutron ML2 drivers, Neutron does not provide 
namespace arbitration.  There is a setup.cfg entry point space with the 
name 'neutron.ml2.mechanism_drivers', and each 3rd party driver adds its 
name to that space.  But there is no explicit protocol here (i.e. where 
networking-calico would say 'Can I use the name calico?' and Neutron 
might answer 'Yes').  De facto we just hope that there will never be 
clashing names in a given deployment.

2. Note that the names used here are project or code names.  For example 
'calico', not 'OpenStack L3-only Networking'.

>  Having someone do this for OpenStack as a whole
> is a necessary part of having a community-wide namespace such as service
> types.

Yes, but that doesn't necessarily mean 'OpenStack Networking' rather 
than 'Neutron', I think.

Neil



__
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

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

[Neil Jerram]

On 05/02/16 16:31, Pavel Bondar wrote:
> On 05.02.2016 12:28, Salvatore Orlando wrote:
>>
>>
>> On 5 February 2016 at 04:12, Armando M. > > wrote:
>>
>>
>>
>> On 4 February 2016 at 08:22, John Belamaric
>> <jbelama...@infoblox.com> wrote:
>>
>>
>> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin > > wrote:
>> >
>> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar > > wrote:
>> >> I am trying to bring more attention to [1] to make final decision 
>> on
>> >> approach to use.
>> >> There are a few point that are not 100% clear for me at this 
>> point.
>> >>
>> >> 1) Do we plan to switch all current clouds to pluggable ipam
>> >> implementation in Mitaka?

I possibly shouldn't comment at all, as I don't know the history, and 
wasn't around when the fundamental design decisions here were being made.

However, it seems a shame to me that this was done in a way that needs a 
DB migration at all.  (And I would have thought it possible for the 
default pluggable IPAM driver to use the same DB state as the 
non-pluggable IPAM backend, given that it is delivering the same 
semantics.)  Without that, I believe it should be a no-brainer to switch 
unconditionally to the pluggable IPAM backend.

Sorry if that's unhelpful...

Neil


__
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

Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases for multiple L3 backends

[Neil Jerram]

On 01/02/16 14:11, Kevin Benton wrote:
> Hi all,
>
> I've been working on an implementation of the multiple L3 backends
> RFE[1] using the flavor framework and I've run into some snags with the
> use-cases.[2]

Is there any good documentation for flavors yet?  I recall looking 
unsuccessfully, a few months ago.

Neil


__
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

[openstack-dev] [neutron] Reading an updated port's fixed IPs in mech driver update_port_postcommit

[Neil Jerram]

I think there's something I'm not understanding about how Neutron's DB 
tables are related, and when one can safely read 
believed-to-be-committed information from them...


My project's mechanism driver is handling a port update in which the 
fixed IPs are changing; specifically, a second fixed IP has been added 
to the port.  It does this (for a reason I can explain if needed) by 
calling db.get_port(), in the update_port_postcommit hook.


But we observe that the result of db.get_port() does not include the new 
fixed IP.  Even though we're in the postcommit hook, and hence we assume 
that all the changes for that port have by now been committed.


What are we misunderstanding here?  My guess is that this is something 
to do with 'fixed_ips' not being a column directly in the Ports table, 
but instead calculated from relationships between the port ID and 
another (IPAllocation) table.  We've seen a similar problem in the past 
with binding:host_id, for which the same is true, i.e. info is in the 
separate portbindings table.


Or could it be that the transaction hasn't really been closed yet, when 
update_port_postcommit hook is called?


(This is with Icehouse-level code, so it could be something that's been 
fixed...)


Many thanks,
Neil

__
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

Re: [openstack-dev] [neutron] Reading an updated port's fixed IPs in mech driver update_port_postcommit

[Neil Jerram]

Thanks, Kevin, but I believe we're already doing what you advise; please 
see 
https://github.com/Metaswitch/calico/blob/master/calico/openstack/mech_calico.py#L346-348


Is there a way of checking that there aren't still any open 
transactions, when update_port_postcommit is called?


Thanks,
Neil


On 07/07/15 15:57, Kevin Benton wrote:

It sounds like something is starting a transaction before calling
update_port on the core plugin. This will prevent the transaction from
being completely closed even though ML2 is in the post_commit phase.

In your db.get_port call, make sure you are using the same DB session
from the context that was passed into update_port_postcommit and that
will make sure you always have access to the current state even if the
transaction isn't closed.

On Tue, Jul 7, 2015 at 5:35 AM, Neil Jerram mailto:neil.jer...@metaswitch.com>> wrote:

I think there's something I'm not understanding about how Neutron's
DB tables are related, and when one can safely read
believed-to-be-committed information from them...

My project's mechanism driver is handling a port update in which the
fixed IPs are changing; specifically, a second fixed IP has been
added to the port.  It does this (for a reason I can explain if
needed) by calling db.get_port(), in the update_port_postcommit hook.

But we observe that the result of db.get_port() does not include the
new fixed IP.  Even though we're in the postcommit hook, and hence
we assume that all the changes for that port have by now been committed.

What are we misunderstanding here?  My guess is that this is
something to do with 'fixed_ips' not being a column directly in the
Ports table, but instead calculated from relationships between the
port ID and another (IPAllocation) table.  We've seen a similar
problem in the past with binding:host_id, for which the same is
true, i.e. info is in the separate portbindings table.

Or could it be that the transaction hasn't really been closed yet,
when update_port_postcommit hook is called?

(This is with Icehouse-level code, so it could be something that's
been fixed...)

Many thanks,
 Neil

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Kevin Benton


__
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



__
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

Re: [openstack-dev] [Openstack] Rescinding the M name decision

[Neil Jerram]

In the hope of forestalling an unnecessary sub-thread...

Mita was #1 in the vote, so has presumably already been ruled out by 
OpenStack's legal review.


On 09/07/15 13:14, Mark Carlson wrote:

Isn't Mita a trademark of Kyocera they use for their copier business?

Folks should read up on Musashi Miyamoto 
https://en.m.wikipedia.org/wiki/Musashi_Miyamoto if you want a name that 
resonates with our Japanese colleagues.

-- mark


On Jul 8, 2015, at 11:48 PM, Somanchi Trinath  
wrote:

My Vote to "Mita" . :)

-Original Message-
From: Monty Taylor [mailto:mord...@inaugust.com]
Sent: Wednesday, July 08, 2015 8:10 PM
To: OpenStack Development Mailing List (not for usage questions); Openstack 
Users
Subject: [openstack-dev] Rescinding the M name decision

Hi everyone!

In light of issues raised concerning the initially selected name for the M 
release (Meiji), that name will not be used.

It turns out fully open community and fully inclusive collaboration is a hard 
thing to get right. On the one hand, we do not want to exclude anyone's input 
or contribution. On the other hand, we do not want the result of that openness 
to result in effective exclusion or seeming persecution of a minority group.

We tried very hard with this naming election to ensure that everyone was able 
to participate in nominations, and that everyone was able to participate in 
elections without the sense that someone had arbitrarily limited anyone else's 
contribution unduly.

There are ways in which this was successful and ways in which is was not. 
Clearly the cultural and historical connotations of this choice are an area 
where the democratic process did not serve us, and I expect us to circle back 
and do work to figure out how to do better in our next iteration.

The foundation team is doing legal due diligence on the next set of names in 
the list below (#4-6) and we expect to have an update within a week. If anyone 
has concerns about any of these potential choices, please raise them now.

1. Mita (三田)  (Condorcet winner: wins contests with all other choices) 2. 
Minato (港)  loses to Mita (三田) by 954–913 3. Meiji (明治)  loses to Mita (三田) by 
1034–873, loses to Minato (港)
by 1052–879
4. Mitaka (三鷹)  loses to Mita (三田) by 1094–702, loses to Meiji (明
治) by 1012–870
5. Musashi (武蔵)  loses to Mita (三田) by 1093–829, loses to Mitaka (三
鷹) by 971–892
6. Meguro (目黒)  loses to Mita (三田) by 1137–690, loses to Musashi (武
蔵) by 958–872
7. Minami (みなみ)  loses to Mita (三田) by 1183–621, loses to Meguro
(目黒) by 858–857
8. Mejiro (目白)  loses to Mita (三田) by 1294–485, loses to Minami (み
なみ) by 990–658
9. Mizuho (瑞穂)  loses to Mita (三田) by 1338–421, loses to Mejiro (目
白) by 905–625
10. Musashino (武蔵野)  loses to Mita (三田) by 1472–305, loses to Mizuho (瑞穂) by 
1034–456 11. Marunouchi (丸の内)  loses to Mita (三田) by 1505–275, loses to 
Musashino (武蔵野) by 931–481

Monty

__
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
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openst...@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


__
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



__
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

Re: [openstack-dev] [Openstack-operators] [Openstack] Rescinding the M name decision

[Neil Jerram]

On 10/07/15 10:19, Thierry Carrez wrote:


Part of the confusion here is that we are not naming "releases". We are
naming release *cycles*. We are giving a name to a period of time,
basically. In that period of time, various version numbers for various
components will be released. Saying "Glance 12.0.0 was released in
OpenStack 13 cycle" is not really helping.

We won't run out of letters, because the names can cycle back to A
(potentially using a new theme, away from "geographic features near
where the corresponding design summit happened").

So while we could technically name a release cycle "14", I feel it's a
bit more difficult to rally around a number than a name. Also, numbers
wouldn't really solve the perceived issues with names: numbers happen to
also be culturally meaningful. You don't have a 13th floor in many US
buildings. In China, building miss the 4th floor instead. 9 is feared in
Japan. And don't talk about 39 to Afghans.

I think "growing up" is accepting the pain that comes with picking a
good name, rather than sidestepping the issue.


+1 to all that.  Nicely put.

Neil

__
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

Re: [openstack-dev] [neutron] Reading an updated port's fixed IPs in mech driver update_port_postcommit

[Neil Jerram]

Sorry to leave this unanswered.

It happens every time (as far as we've tested so far).

A pragmatic fix appears to be to explicitly requery the IPAllocation 
table, as you can see in the two commits here:

https://github.com/Metaswitch/calico/commit/5512ce7dd50db414f161bddcef17b0846a1466ac
https://github.com/Metaswitch/calico/commit/4ecaf3568af52ef9cc29662a3b94672540056f05

But still it seems a shame if this is needed.

Neil


On 07/07/15 22:32, Kevin Benton wrote:

How often does this happen? Is it on every call? If not, is it possible
the forking logic in require_state is messing up the DB handle when it's
invoked?

One way to make sure there aren't open transactions for testing is to
just remove the "subtransactions=True" statement from update_port in the
ML2 plugin.

On Jul 7, 2015 8:33 AM, "Neil Jerram" mailto:neil.jer...@metaswitch.com>> wrote:

Thanks, Kevin, but I believe we're already doing what you advise;
please see

https://github.com/Metaswitch/calico/blob/master/calico/openstack/mech_calico.py#L346-348

Is there a way of checking that there aren't still any open
transactions, when update_port_postcommit is called?

Thanks,
 Neil


On 07/07/15 15:57, Kevin Benton wrote:

It sounds like something is starting a transaction before calling
update_port on the core plugin. This will prevent the
transaction from
being completely closed even though ML2 is in the post_commit phase.

In your db.get_port call, make sure you are using the same DB
session
from the context that was passed into update_port_postcommit and
that
will make sure you always have access to the current state even
if the
transaction isn't closed.

On Tue, Jul 7, 2015 at 5:35 AM, Neil Jerram
mailto:neil.jer...@metaswitch.com>
<mailto:neil.jer...@metaswitch.com
<mailto:neil.jer...@metaswitch.com>>> wrote:

 I think there's something I'm not understanding about how
Neutron's
 DB tables are related, and when one can safely read
 believed-to-be-committed information from them...

 My project's mechanism driver is handling a port update in
which the
 fixed IPs are changing; specifically, a second fixed IP has
been
 added to the port.  It does this (for a reason I can explain if
 needed) by calling db.get_port(), in the
update_port_postcommit hook.

 But we observe that the result of db.get_port() does not
include the
 new fixed IP.  Even though we're in the postcommit hook,
and hence
 we assume that all the changes for that port have by now
been committed.

 What are we misunderstanding here?  My guess is that this is
 something to do with 'fixed_ips' not being a column
directly in the
 Ports table, but instead calculated from relationships
between the
 port ID and another (IPAllocation) table.  We've seen a similar
 problem in the past with binding:host_id, for which the same is
 true, i.e. info is in the separate portbindings table.

 Or could it be that the transaction hasn't really been
closed yet,
 when update_port_postcommit hook is called?

 (This is with Icehouse-level code, so it could be something
that's
 been fixed...)

 Many thanks,
  Neil



__
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>

<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Kevin Benton



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http:

Re: [openstack-dev] How to get the Physical switch data at the openstack neutron

[Neil Jerram]

Hi there!

On 15/07/15 14:02, Ram Mallagundla wrote:

Hi All,


I am working on  to display the physical switch topology at the 
Horizon , i mean the if there are four switches are interconnected . 
need display same topology at the openstack Horizon.



is there any way to get the physical switch topology ??


No, I believe not.  It's not part of Neutron's job to expose the 
physical network topology.


That said, you may want to look at 
https://review.openstack.org/#/c/196812/, which is a proposal for 
creating Neutron networks in a way that reflects the underlying physical 
topology.


Regards,
Neil

__
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

[openstack-dev] [neutron] What does flavor mean for a network?

[Neil Jerram]

I've been reading available docs about the forthcoming Neutron flavors 
framework, and am not yet sure I understand what it means for a network.


Is it a way for an admin to provide a particular kind of network, and 
then for a tenant to know what they're attaching their VMs to?


How does it differ from provider:network-type?  (I guess, because the 
latter is supposed to be for implementation consumption only - but is 
that correct?)


Thanks,
Neil


__
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

Re: [openstack-dev] [neutron] What does flavor mean for a network?

[Neil Jerram]

Thanks everyone for your responses...

On 15/07/15 21:01, Doug Wiegley wrote:
That begins to looks like nova’s metadata tags and scheduler, which is 
a valid use case. The underpinnings of flavors could do this, but it’s 
not in the initial implementation.


doug

On Jul 15, 2015, at 12:38 PM, Kevin Benton <mailto:blak...@gmail.com>> wrote:


Wouldn't it be valid to assign flavors to groups of provider 
networks? e.g. a tenant wants to attach to a network that is wired up 
to a 40g router so he/she chooses a network of the "fat pipe" flavor.


Indeed.

Otherwise, why does 'flavor:network' exist at all in the current codebase?

As the code currently stands, 'flavor:network' appears to be consumed 
only by agent/linux/interface.py, with the logic that if the 
interface_driver setting is set to MetaInterfaceDriver, the interface 
driver class that is actually used for a particular network will be 
derived by using the network's 'flavor:network' value as a lookup key in 
the dict specified by the meta_flavor_driver_mappings setting.


Is that an intended part of the flavors design?

I hope it doesn't sound like I'm just complaining!  My reason for asking 
these questions is that I'm working at 
https://review.openstack.org/#/c/198439/ on a type of network that works 
through routing on each compute host instead of bridging, and two of the 
consequences of that are that


(1) there will not be L2 broadcast connectivity between the instances 
attached to such a network, whereas there would be with all existing 
Neutron network types


(2) the DHCP agent needs some changes to provide DHCP service on 
unbridged TAP interfaces.


Probably best here not to worry too much about the details.  But, at a 
high level:


- there is an aspect of the network's behavior that needs to be 
portrayed in the UI, so that tenants/projects can know when it is 
appropriate to attach instances to that network


- there is an aspect of the network's implementation that the DHCP agent 
needs to be aware of, so that it can adjust accordingly.


I believe the flavor:network 'works', for these purposes, in the senses 
that it is portrayed in the UI, and that it is available to software 
components such as the DHCP agent.  So I was wondering whether 
'flavor:network' would be the correct location in principle for a value 
identifying this kind of network, according to the intention of the 
flavors enhancement.





On Wed, Jul 15, 2015 at 10:40 AM, Madhusudhan Kandadai 
<mailto:madhusudhan.openst...@gmail.com>> wrote:




On Wed, Jul 15, 2015 at 9:25 AM, Kyle Mestery
mailto:mest...@mestery.com>> wrote:

On Wed, Jul 15, 2015 at 10:54 AM, Neil Jerram
mailto:neil.jer...@metaswitch.com>> wrote:

I've been reading available docs about the forthcoming
Neutron flavors framework, and am not yet sure I
understand what it means for a network.


In reality, this is envisioned more for service plugins (e.g.
flavors of LBaaS, VPNaaS, and FWaaS) than core neutron resources.

Yes. Right put. This is for service plugins and its part of
extensions than core network resources//


Is it a way for an admin to provide a particular kind of
network, and then for a tenant to know what they're
attaching their VMs to?


I'll defer to Madhu who is implementing this, but I don't
believe that's the intention at all.

Currently, an admin will be able to assign particular flavors,
unfortunately, this is not going to be tenant specific flavors.



To be clear - I wasn't suggesting or asking for tenant-specific 
flavors.  I only meant that a tenant might choose which network to 
attach a particular set of VMs to, depending on the flavors of the 
available networks.  (E.g. as in Kevin's example above.)



As you might have seen in the review, we are just using tenant_id
to bypass the keystone checks implemented in base.py and it is
not stored in the db as well. It is something to do in the future
and documented the same in the blueprint.


How does it differ from provider:network-type?  (I guess,
because the latter is supposed to be for implementation
consumption only - but is that correct?)


Flavors are created and curated by operators, and consumed by
API users.

+1



Many thanks,
Neil

__
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

[openstack-dev] [neutron] 'routed' network type, DHCP agent + devstack support - review requested

[Neil Jerram]

Hi Neutron folk!

I'd like to give an update on and encourage wide review of my work on
a type of network that connects VMs through IP routing instead of
through bridging and tunneling at L2.  I believe the core Neutron
pieces of this are now complete and ready for detailed review and
potential merging.

The change at [1] creates and describes a new 'routed' value for
provider:network_type.  It means that a compute host handles data
to/from the relevant TAP interfaces by routing it, and specifically
that those TAP interfaces are not bridged.  It is the job of a
particular mechanism driver and agent implementation to set up the
required routing rules, and my team's Calico project [2] is one
example of that, although not the only possible example.

The DHCP agent needs enhancement to provide DHCP service to routed TAP
interfaces, and the change for that is at [3].

A devstack plugin is included in the Calico repository at [4]. Using
this it is possible to see 'routed' networking in action, using the
Calico mechanism driver and agent, simply by running devstack with the
following in local.conf:

  enable_plugin calico https://github.com/Metaswitch/calico routed

Demonstration steps once stack.sh completes are suggested at [5].

[1] https://review.openstack.org/#/c/198439/
[2] http://projectcalico.org/
[3] https://review.openstack.org/#/c/197578/
[4] https://github.com/Metaswitch/calico/tree/routed
[5] https://github.com/Metaswitch/calico/blob/routed/devstack/README.rst

FYI I also plan to propose a networking-calico project (or continue
proposing, given [6]), to contain the Calico mechanism driver and
devstack plugin pieces that are currently in [4], so that all of
Calico's OpenStack-specific code is under the Neutron big tent.  But I
believe that can be decoupled from review of the core Neutron changes
proposed above.

[6] https://review.openstack.org/#/c/194709/

Please do let me know if you have thoughts or comments on this.

Many thanks,
 Neil


__
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

Re: [openstack-dev] [Neutron] HELP CONFIRM OR DISCUSS:create a port when network contain ipv4 subnets and ipv6 subnets, allocate ipv6 address to the port.

[Neil Jerram]

I am not completely sure, but I believe that the primary associations 
are that:


- a port is attached to a particular network

- a network may have an IPv4 subnet and/or an IPv6 subnet

- therefore, when a port is created, it gets an IPv4 address, and/or an 
IPv6 address, according to the subnets that are associated with the network.


Then the question is: what difference does it make if you add 
"--fixed-ip subnet_id=$[ipv4_subnet_id]" to your port creation command?


Unfortunately I don't know the answer to that.  However I do know that 
you can use "neutron port-update --fixed-ip ..." to _add_ an additional 
IP address to an existing port.  Therefore, and also considering your 
observations, I would guess that the effect of "--fixed_ip ..." is 
always strictly additional to the basic IP address allocation behaviour 
that you get based on the network and subnet associations.


Hope that may help...

Neil


On 20/07/15 04:26, zhaobo wrote:

Hi ,
Could anyone please check the bug below?
https://bugs.launchpad.net/neutron/+bug/1467791

This bug description:
When the created network contains one ipv4 subnet and an ipv6 subnet 
which turned on slaac or stateless.

When I create a port use cmd like:
neutron port-create --fixed-ip subnet_id=$[ipv4_subnet_id] 
$[network_id/name]
The specified fixed-ip is ipv4_subnet, but the returned port contained 
the ipv6 subnet.



If user just want a port with ipv4 , why returned port had allocated 
an ipv6 address.
And I know this is an design behavior from 
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/multiple-ipv6-prefixes.html#proposed-change

But we are still confused about this operation.

Thank you anyone could help for confirm this issue , and wish you 
return the message asap.


ZhaoBo




__
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



__
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