Re: [openstack-dev] Ocata - Networking OVN - option "neutron_sync_mode = repair" looks broken

[Martinx - ジェームズ]

BUG reported: https://bugs.launchpad.net/neutron/+bug/1689880

On 10 May 2017 at 10:49, Martinx - ジェームズ <thiagocmarti...@gmail.com> wrote:

> Hello,
>
>  I'm playing with Networking OVN, and planning to deploy it into
> production in a couple weeks.
>
>  After deploying everything and starting using OVN, with Floating IPs,
> multiple compute nodes and everything else, I can say that it looks
> awesome! Way better than "neutron-*-agents".
>
>  However, I noted that after running:
>
> ---
>  systemctl restart neutron-server
> ---
>
>  Literally ALL my stacks, on all projects, becomes unreachable!!!
>
>  After double checking everything, I did one single change in my
> ml2_conf.ini, from:
>
> ---
> neutron_sync_mode = repair
> ---
>
>  To:
>
> ---
> # neutron_sync_mode = off
> ---
>
>  Then, problem solved!
>
>  Now, I can restart the neutron-server without any problems!
>
>  Deep inside me, I'm freaking out with this... Because this whole OVN
> solution looks very, very delicate. I mean, what to do if this happens
> again?
>
>  Ask ALL my customers to rebuild their stacks?!
>
>  How to REALLY repair OVN?
>
>  Now that the problem is solved, I'll keep trying to use and stress test
> it even more but, I'm losing confidence on Networking OVN on its current
> state.
>
>  I'm using Ubuntu 16.04 with Kernel 4.8 (HWE), plus Ocata from Cloud
> Archive.
>
> Cheers!
> Thiago
>
__
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] Ocata - Networking OVN - option "neutron_sync_mode = repair" looks broken

[Martinx - ジェームズ]

Hello,

 I'm playing with Networking OVN, and planning to deploy it into production
in a couple weeks.

 After deploying everything and starting using OVN, with Floating IPs,
multiple compute nodes and everything else, I can say that it looks
awesome! Way better than "neutron-*-agents".

 However, I noted that after running:

---
 systemctl restart neutron-server
---

 Literally ALL my stacks, on all projects, becomes unreachable!!!

 After double checking everything, I did one single change in my
ml2_conf.ini, from:

---
neutron_sync_mode = repair
---

 To:

---
# neutron_sync_mode = off
---

 Then, problem solved!

 Now, I can restart the neutron-server without any problems!

 Deep inside me, I'm freaking out with this... Because this whole OVN
solution looks very, very delicate. I mean, what to do if this happens
again?

 Ask ALL my customers to rebuild their stacks?!

 How to REALLY repair OVN?

 Now that the problem is solved, I'll keep trying to use and stress test it
even more but, I'm losing confidence on Networking OVN on its current state.

 I'm using Ubuntu 16.04 with Kernel 4.8 (HWE), plus Ocata from Cloud
Archive.

Cheers!
Thiago
__
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] Ocata - Ubuntu 16.04 - OVN does not work with DPDK

[Martinx - ジェームズ]

On 11 April 2017 at 11:08, Russell Bryant <rbry...@redhat.com> wrote:

>
>
> On Mon, Apr 10, 2017 at 4:49 PM, Martinx - ジェームズ <
> thiagocmarti...@gmail.com> wrote:
>
>>
>>
>> On 8 April 2017 at 00:37, Martinx - ジェームズ <thiagocmarti...@gmail.com>
>> wrote:
>>
>>> Guys,
>>>
>>>  I manage to deploy Ocata on Ubuntu 16.04 with OVN for the first time
>>> ever, today!
>>>
>>>  It looks very, very good... OVN L3 Router is working, OVN DHCP
>>> working... bridge mappings "br-ex" on each compute node... All good!
>>>
>>>  Then, I've said: time for DPDK!
>>>
>>>  I manage to use OVS with DPDK easily on top of Ubuntu (plus Ocata Cloud
>>> Archive) with plain KVM, no OpenStack, so, I have experience about how to
>>> setup DPDK, OVS+DPDK, Libvirt vhostuser, KVM and etc...
>>>
>>>  After configuring DPDK on a compute node, I tried the following
>>> instructions:
>>>
>>>  https://docs.openstack.org/developer/networking-ovn/dpdk.html
>>>
>>>  It looks quite simple!
>>>
>>>  To make things even simpler, I have just 1 controller, and 1 compute
>>> node, to begin with, before enabling DPDK at the compute node and changing
>>> the "br-int" datapath, I deleted all OVN Routers and all Neutron Networks
>>> and Subnets, that was previously working with regular OVS (no DPDK).
>>>
>>>  Then, after enabling DPDK and updating the "br-int" and the "br-ex"
>>> interfaces, right after connecting the "OVN L3 Router" into the "ext-net /
>>> br-ex" network, the following errors appeared on OpenvSwitch logs of the
>>> related compute node (OpenFlow error):
>>>
>>>
>>>  * After connecting OVN L3 Router against the "ext-net / br-ex" Flat /
>>> VLAN Network:
>>>
>>>  ovs-vswitchd.log:
>>>
>>>  http://paste.openstack.org/show/605800/
>>>
>>>  ovn-controller.log:
>>>
>>>  http://paste.openstack.org/show/605801/
>>>
>>>
>>>  Also, after connecting the OVN L3 Router into the local (GENEVE)
>>> network, very similar error messages appeared on OpenvSwitch logs...
>>>
>>>
>>>  * After connecting OVN L3 Router on a "local" GENEVE Network:
>>>
>>>  ovs-vswitchd.log:
>>>
>>>  http://paste.openstack.org/show/605804/
>>>
>>>  ovn-controller.log:
>>>
>>>  http://paste.openstack.org/show/605805/
>>>
>>>
>>>  * Output of "ovs-vsctl show" at the single compute node, after plugging
>>> the OVN L3 Router against the two networks (external / GENEVE):
>>>
>>>  http://paste.openstack.org/show/605806/
>>>
>>>
>>>  Then, I tried to launch an Instance anyway and, for my surprise, the
>>> Instance was created! Using vhostuser OVS+DPDK socket!
>>>
>>>  Also, the Instance got its IP! Which is great!
>>>
>>>  However, the Instance can not ping its OVN L3 Router (its default
>>> gateway), with or without any kind of security groups applied, no deal...
>>> :-(
>>>
>>>  BTW, the Instance did not received the ARP stuff of the OVN L3 Router,
>>> I mean, for the instance, the gateway IP on "arp -an" shows "".
>>>
>>>
>>>  * The ovs-vswitchd.log after launching an Instance on top of
>>> OVN/OVS+DPDK:
>>>
>>>  http://paste.openstack.org/show/605807/
>>>
>>>  * The output of "ovs-vsctl show" after launching the above instance:
>>>
>>>  http://paste.openstack.org/show/605809/ - Line 33 is the dpdkvhostuser
>>>
>>>
>>>  Just to give another try, I started a second Instance, to see if the
>>> Instances can ping each other... Also did not worked, the Instances can not
>>> ping each other.
>>>
>>>
>>>  So, from what I'm seeing, OVN on top of DPDK does not work.
>>>
>>>  Any tips?
>>>
>>>
>>>  NOTE:
>>>
>>>  I tried to enable "hugepages" on my OpenStack's flavor, just in case...
>>> Then, I found another bug, it doesn't even boot the Instance:
>>>
>>>  https://bugs.launchpad.net/cloud-archive/+bug/1680956
>>>
>>>
>>>  For now, I'll deploy Ocata with regular OVN, no DPDK, but, my goal with
>>> this cloud is for high performance networks, s

Re: [openstack-dev] Ocata - Ubuntu 16.04 - OVN does not work with DPDK

[Martinx - ジェームズ]

On 11 April 2017 at 11:08, Russell Bryant <rbry...@redhat.com> wrote:

>
>
> On Mon, Apr 10, 2017 at 4:49 PM, Martinx - ジェームズ <
> thiagocmarti...@gmail.com> wrote:
>
>>
>>
>> On 8 April 2017 at 00:37, Martinx - ジェームズ <thiagocmarti...@gmail.com>
>> wrote:
>>
>>> Guys,
>>>
>>>  I manage to deploy Ocata on Ubuntu 16.04 with OVN for the first time
>>> ever, today!
>>>
>>>  It looks very, very good... OVN L3 Router is working, OVN DHCP
>>> working... bridge mappings "br-ex" on each compute node... All good!
>>>
>>>  Then, I've said: time for DPDK!
>>>
>>>  I manage to use OVS with DPDK easily on top of Ubuntu (plus Ocata Cloud
>>> Archive) with plain KVM, no OpenStack, so, I have experience about how to
>>> setup DPDK, OVS+DPDK, Libvirt vhostuser, KVM and etc...
>>>
>>>  After configuring DPDK on a compute node, I tried the following
>>> instructions:
>>>
>>>  https://docs.openstack.org/developer/networking-ovn/dpdk.html
>>>
>>>  It looks quite simple!
>>>
>>>  To make things even simpler, I have just 1 controller, and 1 compute
>>> node, to begin with, before enabling DPDK at the compute node and changing
>>> the "br-int" datapath, I deleted all OVN Routers and all Neutron Networks
>>> and Subnets, that was previously working with regular OVS (no DPDK).
>>>
>>>  Then, after enabling DPDK and updating the "br-int" and the "br-ex"
>>> interfaces, right after connecting the "OVN L3 Router" into the "ext-net /
>>> br-ex" network, the following errors appeared on OpenvSwitch logs of the
>>> related compute node (OpenFlow error):
>>>
>>>
>>>  * After connecting OVN L3 Router against the "ext-net / br-ex" Flat /
>>> VLAN Network:
>>>
>>>  ovs-vswitchd.log:
>>>
>>>  http://paste.openstack.org/show/605800/
>>>
>>>  ovn-controller.log:
>>>
>>>  http://paste.openstack.org/show/605801/
>>>
>>>
>>>  Also, after connecting the OVN L3 Router into the local (GENEVE)
>>> network, very similar error messages appeared on OpenvSwitch logs...
>>>
>>>
>>>  * After connecting OVN L3 Router on a "local" GENEVE Network:
>>>
>>>  ovs-vswitchd.log:
>>>
>>>  http://paste.openstack.org/show/605804/
>>>
>>>  ovn-controller.log:
>>>
>>>  http://paste.openstack.org/show/605805/
>>>
>>>
>>>  * Output of "ovs-vsctl show" at the single compute node, after plugging
>>> the OVN L3 Router against the two networks (external / GENEVE):
>>>
>>>  http://paste.openstack.org/show/605806/
>>>
>>>
>>>  Then, I tried to launch an Instance anyway and, for my surprise, the
>>> Instance was created! Using vhostuser OVS+DPDK socket!
>>>
>>>  Also, the Instance got its IP! Which is great!
>>>
>>>  However, the Instance can not ping its OVN L3 Router (its default
>>> gateway), with or without any kind of security groups applied, no deal...
>>> :-(
>>>
>>>  BTW, the Instance did not received the ARP stuff of the OVN L3 Router,
>>> I mean, for the instance, the gateway IP on "arp -an" shows "".
>>>
>>>
>>>  * The ovs-vswitchd.log after launching an Instance on top of
>>> OVN/OVS+DPDK:
>>>
>>>  http://paste.openstack.org/show/605807/
>>>
>>>  * The output of "ovs-vsctl show" after launching the above instance:
>>>
>>>  http://paste.openstack.org/show/605809/ - Line 33 is the dpdkvhostuser
>>>
>>>
>>>  Just to give another try, I started a second Instance, to see if the
>>> Instances can ping each other... Also did not worked, the Instances can not
>>> ping each other.
>>>
>>>
>>>  So, from what I'm seeing, OVN on top of DPDK does not work.
>>>
>>>  Any tips?
>>>
>>>
>>>  NOTE:
>>>
>>>  I tried to enable "hugepages" on my OpenStack's flavor, just in case...
>>> Then, I found another bug, it doesn't even boot the Instance:
>>>
>>>  https://bugs.launchpad.net/cloud-archive/+bug/1680956
>>>
>>>
>>>  For now, I'll deploy Ocata with regular OVN, no DPDK, but, my goal with
>>> this cloud is for high performance networks, s

Re: [openstack-dev] Ocata - Ubuntu 16.04 - OVN does not work with DPDK

[Martinx - ジェームズ]

On 8 April 2017 at 00:37, Martinx - ジェームズ <thiagocmarti...@gmail.com> wrote:

> Guys,
>
>  I manage to deploy Ocata on Ubuntu 16.04 with OVN for the first time
> ever, today!
>
>  It looks very, very good... OVN L3 Router is working, OVN DHCP working...
> bridge mappings "br-ex" on each compute node... All good!
>
>  Then, I've said: time for DPDK!
>
>  I manage to use OVS with DPDK easily on top of Ubuntu (plus Ocata Cloud
> Archive) with plain KVM, no OpenStack, so, I have experience about how to
> setup DPDK, OVS+DPDK, Libvirt vhostuser, KVM and etc...
>
>  After configuring DPDK on a compute node, I tried the following
> instructions:
>
>  https://docs.openstack.org/developer/networking-ovn/dpdk.html
>
>  It looks quite simple!
>
>  To make things even simpler, I have just 1 controller, and 1 compute
> node, to begin with, before enabling DPDK at the compute node and changing
> the "br-int" datapath, I deleted all OVN Routers and all Neutron Networks
> and Subnets, that was previously working with regular OVS (no DPDK).
>
>  Then, after enabling DPDK and updating the "br-int" and the "br-ex"
> interfaces, right after connecting the "OVN L3 Router" into the "ext-net /
> br-ex" network, the following errors appeared on OpenvSwitch logs of the
> related compute node (OpenFlow error):
>
>
>  * After connecting OVN L3 Router against the "ext-net / br-ex" Flat /
> VLAN Network:
>
>  ovs-vswitchd.log:
>
>  http://paste.openstack.org/show/605800/
>
>  ovn-controller.log:
>
>  http://paste.openstack.org/show/605801/
>
>
>  Also, after connecting the OVN L3 Router into the local (GENEVE) network,
> very similar error messages appeared on OpenvSwitch logs...
>
>
>  * After connecting OVN L3 Router on a "local" GENEVE Network:
>
>  ovs-vswitchd.log:
>
>  http://paste.openstack.org/show/605804/
>
>  ovn-controller.log:
>
>  http://paste.openstack.org/show/605805/
>
>
>  * Output of "ovs-vsctl show" at the single compute node, after plugging
> the OVN L3 Router against the two networks (external / GENEVE):
>
>  http://paste.openstack.org/show/605806/
>
>
>  Then, I tried to launch an Instance anyway and, for my surprise, the
> Instance was created! Using vhostuser OVS+DPDK socket!
>
>  Also, the Instance got its IP! Which is great!
>
>  However, the Instance can not ping its OVN L3 Router (its default
> gateway), with or without any kind of security groups applied, no deal...
> :-(
>
>  BTW, the Instance did not received the ARP stuff of the OVN L3 Router, I
> mean, for the instance, the gateway IP on "arp -an" shows "".
>
>
>  * The ovs-vswitchd.log after launching an Instance on top of OVN/OVS+DPDK:
>
>  http://paste.openstack.org/show/605807/
>
>  * The output of "ovs-vsctl show" after launching the above instance:
>
>  http://paste.openstack.org/show/605809/ - Line 33 is the dpdkvhostuser
>
>
>  Just to give another try, I started a second Instance, to see if the
> Instances can ping each other... Also did not worked, the Instances can not
> ping each other.
>
>
>  So, from what I'm seeing, OVN on top of DPDK does not work.
>
>  Any tips?
>
>
>  NOTE:
>
>  I tried to enable "hugepages" on my OpenStack's flavor, just in case...
> Then, I found another bug, it doesn't even boot the Instance:
>
>  https://bugs.launchpad.net/cloud-archive/+bug/1680956
>
>
>  For now, I'll deploy Ocata with regular OVN, no DPDK, but, my goal with
> this cloud is for high performance networks, so, I need DPDK, and I also
> need GENEVE and Provider Networks, everything on top of DPDK.
>
> ---
>  After researching more about this "high perf networks", I found this:
>
>  * DPDK-like performance in Linux kernel with XDP !
>
>  http://openvswitch.org/support/ovscon2016/7/0930-pettit.pdf
>
>  https://www.iovisor.org/technology/xdp
>  https://www.iovisor.org/technology/ebpf
>
>  https://qmonnet.github.io/whirl-offload/2016/09/01/dive-into-bpf/
>
>  But I have no idea about how to use OpenvSwitch with this thing, however,
> if I can achieve DPDK-Like performance, without DPDK, using just plain
> Linux, I'm a 100% sure that I'll prefer it!
>
>  I'm okay to give OpenvSwitch + DPDK another try, even knowing that it
> [OVS] STILL have serious problems (https://bugs.launchpad.net/
> ubuntu/+source/openvswitch/+bug/1577088)...
> ---
>
>  OpenStack on Ubuntu rocks!   :-D
>
> Thanks!
> Thiago
>

I just realized how cool IO Vis

[openstack-dev] Ocata - Ubuntu 16.04 - OVN does not work with DPDK

[Martinx - ジェームズ]

Guys,

 I manage to deploy Ocata on Ubuntu 16.04 with OVN for the first time ever,
today!

 It looks very, very good... OVN L3 Router is working, OVN DHCP working...
bridge mappings "br-ex" on each compute node... All good!

 Then, I've said: time for DPDK!

 I manage to use OVS with DPDK easily on top of Ubuntu (plus Ocata Cloud
Archive) with plain KVM, no OpenStack, so, I have experience about how to
setup DPDK, OVS+DPDK, Libvirt vhostuser, KVM and etc...

 After configuring DPDK on a compute node, I tried the following
instructions:

 https://docs.openstack.org/developer/networking-ovn/dpdk.html

 It looks quite simple!

 To make things even simpler, I have just 1 controller, and 1 compute node,
to begin with, before enabling DPDK at the compute node and changing the
"br-int" datapath, I deleted all OVN Routers and all Neutron Networks and
Subnets, that was previously working with regular OVS (no DPDK).

 Then, after enabling DPDK and updating the "br-int" and the "br-ex"
interfaces, right after connecting the "OVN L3 Router" into the "ext-net /
br-ex" network, the following errors appeared on OpenvSwitch logs of the
related compute node (OpenFlow error):


 * After connecting OVN L3 Router against the "ext-net / br-ex" Flat / VLAN
Network:

 ovs-vswitchd.log:

 http://paste.openstack.org/show/605800/

 ovn-controller.log:

 http://paste.openstack.org/show/605801/


 Also, after connecting the OVN L3 Router into the local (GENEVE) network,
very similar error messages appeared on OpenvSwitch logs...


 * After connecting OVN L3 Router on a "local" GENEVE Network:

 ovs-vswitchd.log:

 http://paste.openstack.org/show/605804/

 ovn-controller.log:

 http://paste.openstack.org/show/605805/


 * Output of "ovs-vsctl show" at the single compute node, after plugging
the OVN L3 Router against the two networks (external / GENEVE):

 http://paste.openstack.org/show/605806/


 Then, I tried to launch an Instance anyway and, for my surprise, the
Instance was created! Using vhostuser OVS+DPDK socket!

 Also, the Instance got its IP! Which is great!

 However, the Instance can not ping its OVN L3 Router (its default
gateway), with or without any kind of security groups applied, no deal...
:-(

 BTW, the Instance did not received the ARP stuff of the OVN L3 Router, I
mean, for the instance, the gateway IP on "arp -an" shows "".


 * The ovs-vswitchd.log after launching an Instance on top of OVN/OVS+DPDK:

 http://paste.openstack.org/show/605807/

 * The output of "ovs-vsctl show" after launching the above instance:

 http://paste.openstack.org/show/605809/ - Line 33 is the dpdkvhostuser


 Just to give another try, I started a second Instance, to see if the
Instances can ping each other... Also did not worked, the Instances can not
ping each other.


 So, from what I'm seeing, OVN on top of DPDK does not work.

 Any tips?


 NOTE:

 I tried to enable "hugepages" on my OpenStack's flavor, just in case...
Then, I found another bug, it doesn't even boot the Instance:

 https://bugs.launchpad.net/cloud-archive/+bug/1680956


 For now, I'll deploy Ocata with regular OVN, no DPDK, but, my goal with
this cloud is for high performance networks, so, I need DPDK, and I also
need GENEVE and Provider Networks, everything on top of DPDK.

---
 After researching more about this "high perf networks", I found this:

 * DPDK-like performance in Linux kernel with XDP !

 http://openvswitch.org/support/ovscon2016/7/0930-pettit.pdf

 https://www.iovisor.org/technology/xdp
 https://www.iovisor.org/technology/ebpf

 https://qmonnet.github.io/whirl-offload/2016/09/01/dive-into-bpf/

 But I have no idea about how to use OpenvSwitch with this thing, however,
if I can achieve DPDK-Like performance, without DPDK, using just plain
Linux, I'm a 100% sure that I'll prefer it!

 I'm okay to give OpenvSwitch + DPDK another try, even knowing that it
[OVS] STILL have serious problems (
https://bugs.launchpad.net/ubuntu/+source/openvswitch/+bug/1577088)...
---

 OpenStack on Ubuntu rocks!   :-D

Thanks!
Thiago
__
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] OpenStack Newton B3 for Ubuntu 16.04 LTS and Ubuntu 16.10

[Martinx - ジェームズ]

On 8 September 2016 at 14:40, Corey Bryant 
wrote:

> Hi All,
>
> The Ubuntu OpenStack team is pleased to announce the general availability
> of OpenStack Newton B3 milestone in Ubuntu 16.10 and for Ubuntu 16.04 LTS
> via the Ubuntu Cloud Archive.
>
> Ubuntu 16.04 LTS
> 
> You can enable the Ubuntu Cloud Archive pocket for OpenStack Newton on
> Ubuntu 16.04 installations by running the following commands:
>
> sudo add-apt-repository cloud-archive:newton
> sudo apt update
>
> The Ubuntu Cloud Archive for Newton includes updates for Aodh, Barbican,
> Ceilometer, Cinder, Designate, Glance, Heat, Horizon, Ironic (6.1.0),
> Keystone, Manila, Networking-OVN, Neutron, Neutron-FWaaS, Neutron-LBaaS,
> Neutron-VPNaaS, Nova, and Trove.
>
> You can see the full list of packages and versions at [0].
>
> Ubuntu 16.10
> --
> No extra steps required; just start installing OpenStack!
>
> Branch Package Builds
> ---
> If you want to try out the latest master branch updates, or updates to
> stable branches, we are delivering continuously integrated packages on each
> upstream commit in the following PPA’s:
>
>sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty
>sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
>sudo add-apt-repository ppa:openstack-ubuntu-testing/newton
>
> bear in mind these are built per-commitish (30 min checks for new commits
> at the moment) so ymmv from time-to-time.
>
> Reporting bugs
> 
> Any issues please report bugs using the 'ubuntu-bug' tool:
>
>   sudo ubuntu-bug nova-conductor
>
> this will ensure that bugs get logged in the right place in Launchpad.
>
> Thanks and have fun!
>
> Regards,
>
> Corey
> (on behalf of the Ubuntu OpenStack team)
>
> [0] http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-arc
> hive/newton_versions.html
>
>
That's awesome!

I think that we also need new OpenvSwitch (2.6) and new DPDK-16.07 inside
of UCA (Xenial) too...

I can't find those packages neither here:

https://launchpad.net/~openstack-ubuntu-testing/+
archive/ubuntu/newton?field.series_filter=xenial

Nor here:

https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/newton-staging

I just sent an e-mail to Christian Ehrhardt about this...

Cheers!
Thiago
__
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] OpenStack Newton B1 for Ubuntu 16.04 LTS and Ubuntu 16.10

[Martinx - ジェームズ]

I can't wait to try "VLAN Aware VMs"... But it is not there yet... Maybe on
Newton B2...

https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms

This is *very* important for NFV Instances on OpenStack... Many telcos
needs this...

Cheers!
Thiago

On 14 June 2016 at 07:25, Jeffrey Zhang  wrote:

> Very Cool! Wait this for long.
> we(kolla project) will enable the ubuntu binary deploy gate in the CI.
>
> On Mon, Jun 13, 2016 at 8:54 PM, Corey Bryant 
> wrote:
>
>> Hi All,
>>
>> The Ubuntu OpenStack team is pleased to announce the general availability
>> of the OpenStack Newton B1 milestone in Ubuntu 16.10 and for Ubuntu 16.04
>> LTS via the Ubuntu Cloud Archive.
>>
>> Ubuntu 16.04 LTS
>> 
>>
>> You can enable the Ubuntu Cloud Archive pocket for OpenStack Newton on
>> Ubuntu 16.04 installations by running the following commands:
>>
>> echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu
>> xenial-updates/newton main" | sudo tee
>> /etc/apt/sources.list.d/newton-uca.list
>> sudo apt-get install -y ubuntu-cloud-keyring
>> sudo apt-get update
>>
>> The Ubuntu Cloud Archive for Newton includes updates for Cinder,
>> Designate, Glance, Heat, Horizon, Keystone, Manila, Neutron, Neutron-FWaaS,
>> Neutron-LBaaS, Neutron-VPNaaS, Nova, and Swift (2.8.0).
>>
>> You can check out the full list of packages and versions at [0].
>>
>> Ubuntu 16.10
>> --
>>
>> No extra steps required; just start installing OpenStack!
>>
>> Branch Package Builds
>> ---
>>
>> We’ve resurrected the branch package builds of OpenStack projects that we
>> had in place a while back - if you want to try out the latest master branch
>> updates, or updates to stable branches, the following PPA’s are now
>> up-to-date and maintained:
>>
>>sudo add-apt-repository ppa:openstack-ubuntu-testing/liberty
>>sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka
>>sudo add-apt-repository ppa:openstack-ubuntu-testing/newton
>>
>> bear in mind these are built per-commit-ish (30 min checks for new
>> commits at the moment) so ymmv from time-to-time.
>>
>> Reporting bugs
>> -
>>
>> Any issues please report bugs using the 'ubuntu-bug' tool:
>>
>>   sudo ubuntu-bug nova-conductor
>>
>> this will ensure that bugs get logged in the right place in Launchpad.
>>
>> Thanks and have fun!
>>
>> Regards,
>> Corey
>> (on behalf of the Ubuntu OpenStack team)
>>
>> [0]
>> http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/newton_versions.html
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
> __
> 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] [Monasca] influxDB clustering and HA will be "commercial option".

[Martinx - ジェームズ]

On 30 May 2016 at 11:59, Jaesuk Ahn  wrote:

> Hi, Monasca developers and users,
>
>
> https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/
> "For our current and future customers, we’ll be offering clustering and
> high availability through Influx Cloud, our managed hosting offering, and
> Influx Enterprise, our on-premise offering, in the coming months.”
>
>
> It seems like “clustering” and “high availablity” of influxDB will be
> available only in commercial version.
> Monasca is currently leveraging influxDB as a metrics and alarm database.
> Beside vertical, influxDB is currently only an open source option to use.
>
> With this update stating “influxDB open source sw version will not have
> clustering / ha feature”,
> I would like to know if there has been any discussion among monasca
> community to add more database backend rather than influxDB, especially
> OpenTSDB.
>
>
> Thank you.
>
>
>
>
>
> --
> Jaesuk Ahn, Ph.D.
> Software Defined Infra Tech. Lab.
> SKT
>


What about Prometheus?

https://prometheus.io/

https://prometheus.io/docs/introduction/comparison/

Cheers!
Thiago
__
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][L2GW] Mitaka release of L2 Gateway now available

[Martinx - ジェームズ]

On 11 May 2016 at 16:05, Sukhdev Kapur  wrote:

>
> Folks,
>
> I am happy to announce that Mitaka release for L2 Gateway is released and
> now available at https://pypi.python.org/pypi/networking-l2gw.
>
> You can install it by using "pip install networking-l2gw"
>
> This release has several enhancements and fixes for issues discovered in
> liberty release.
>
> Thanks
> Sukhdev Kapur
>
>
Sounds very interesting!

Currently, I have a DPDK App that is a L2 Bridge, however, when I bridge
two Neutron Networks together (under the same L2 broadcast domain),
OpenStack itself is "not aware" of this!

Basically, OpenStack doesn't "knows" that a "regular Instance" is a L2
Bridge, which make things very weird for NFV applications like mine.

So, my question is: can this "L2 Gateway" help my setup? I mean, can I use
"L2 Gateway" to tell: "Hey, OpenStack, those two Networks X & Y are in
fact, just one. Is this possible?

Cheers!
Thiago
__
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] Mitaka - OVS Firewall Driver, not working = OVSFWPortNotFound

[Martinx - ジェームズ]

Guys,

 I'm trying to enable OVS Firewall Driver in my Cloud Env but, it is not
working...

 I'm trying to replace the following line (openvswitch_agent.ini config
across the cloud):

---
 firewall_driver =
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
---

 By this:

---
 firewall_driver = openvswitch
---

 But it does not work in a multi-node env (all-in-one looks good).

 I'm seeing the following error on Neutron OpenvSwitch Agents, while trying
to launch Instances:

 "OVSFWPortNotFound" Port "is not managed by this agent"

 Full log putput:

 http://paste.openstack.org/show/495252/

 The result is that instances are inaccessible from its Floating IP.
Rolling back to OVSHybrid, all goo again.

 What am I missing?

Thanks!
Thiago
__
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] Mitaka, Xenial, OVS Firewall Driver, DPDK, VXLAN and Provider Networks

[Martinx - ジェームズ]

Hey guys!

 Next Ubuntu and Mitaka are promising something ultra mega cool!

 Look at this!

---
root@mitaka-1:~# apt install neutron-openvswitch-agent
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  dpdk libdpdk0 openvswitch-common openvswitch-switch
---

 Xenial will brings DPDK-2.2 fully supported for 5 years!

 However, I am curious about the following scenarios:

 Will be possible to use, at the same time (same Network and Compute nodes
/ Host Aggregate):

 1- Regular OVS bridges without DPDK for VXLAN Networks, with
OVS-Firewall-Driver and;

 2- OVS powered by DPDK for Provider Networks only ( without any firewall,
current case anyway, due to https://bugs.launchpad.net/neutron/+bug/1531205
).

?

 I have NFV Instances that are also, DPDK L2 Bridges running on KVM Guest /
VirtIO, that are physically wired using Provider Networks (flat and vlans).

 So, for the Instance's vNICs (eth1 and eth2) that are used as a L2 bridge,
I don't want any kind of ovs-firewall (I'm not affected by LP #1531205 on
this case) and I want OVS+DPDK under it but, for SSH into the Instance to
manage it (via its eth0), it is still using regular VXLAN with Security
Groups - OVS-Firewall from now on (no need for DPDK under eth0 / VXLAN).

 I'm curious about this specially because the OVS Ubuntu package, makes use
of Debian's Alternatives subsystem, and we need to choose one OVS
(default), or another (with DPDK), via "update-alternatives", so, will be
possible to select OVS with DPDK but, use regular bridges with it as well
(for VXLAN networks)?

 If yes, how to create a VXLAN network with regular OVS and another
FLAT/VLAN network with OVS+DPDK ?

 Thanks in advance!

Best,
Thiago
__
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] Questions regarding image "location" and glanceclient behaviour ...

[Martinx - ジェームズ]

>
> > But this procedure will force me to download all images in advance,
> which I
> > can not do.
> >
> > I NEED the previous behavior, where Glance download the images by itself,
> > on demand.
> >
> > How to do this with V2 ?
>
> You can use glance image-create without passing it any image data. You
> should then be able to use location-add and I believe Glance will download
> the image itself in that case.
>
> Cheers,
> --
> Ian Cordasco
>

That is good news! I am going to try it right now!

Thank you!

Cheers!
Thiago
__
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] Questions regarding image "location" and glanceclient behaviour ...

[Martinx - ジェームズ]

But this procedure will force me to download all images in advance, which I
can not do.

I NEED the previous behavior, where Glance download the images by itself,
on demand.

How to do this with V2 ?

On 18 February 2016 at 01:47, Fei Long Wang <feil...@catalyst.net.nz> wrote:

> Glance v2 doesn't support 'location' anymore, now there are multi
> locations for image in V2. You can use 'glance location-add' after create
> the the image by 'glance image-create --file xxx'
>
>
> On 18/02/16 15:51, Martinx - ジェームズ wrote:
>
> Hey guys, any news about this?
>
> I want to use Glance v2 but, without --location that points to a URL and,
> for me, without it, it is impossible to use it (v2).
>
> So, any plans to bring back --location, I want to use v2 like this:
>
> --
> glance image-create --location
> http://uec-images.ubuntu.com/releases/14.04.3/release/ubuntu-14.04-server-cloudimg-amd64-disk1.img
> --name "Ubuntu 14.04.3 LTS - Trusty Tahr - 64-bit - Cloud Based Image"
> --visibility public --container-format bare --disk-format qcow2
> --
>
> But, "--location" isn't recognized anymore!
>
> Thanks!
> Thiago
>
>
> On 22 January 2014 at 14:30, Mark Washenberger <
> mark.washenber...@markwash.net> wrote:
>
>>
>>
>>
>> On Wed, Jan 22, 2014 at 1:05 AM, Public Mail < <kpublicm...@gmail.com>
>> kpublicm...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> I have two questions ...
>>>
>>> 1) Glance v1 APIs can take a --location argument when creating an
>>> image
>>>but v2 APIs can't - bug or feature? (Details below)
>>>
>>
>> I'd call that a missing feature. I think we probably need a glance
>> image-location-add command somewhere in the client. But fair warning, this
>> is typically a role-restricted operation.
>>
>>
>>>
>>> 2) How should glanceclient (v2 commands) handle reserved attributes?
>>> a) status quo: (Apparently) let the user set them but the server
>>>will return "attribute is reserved" error.  Pros: No missing
>>>functionality, no damage done.  Cons: Bad usability.
>>> b) hard-code list of reserved attributes in client and don't
>>> expose
>>>them to the user.
>>> Pros: quick to implement.
>>> Cons: Need to track reserved attributes in server
>>> implementation.
>>> c) get-reserved words from schema downloaded from server (and
>>> don't
>>>expose them to the user).
>>> Pros: Don't need to track server implmentation.
>>> Cons: Complex - reserved words can vary from command to
>>> command.
>>>
>>>   I personally favor (b) on the grounds that a client implementation
>>>   needs to closely understand server behaviour anyway so the sync-ing
>>>   of reserved attributes shouldn't be a big problem (*provided* the
>>>   list of reserved attributes is made available in the reference
>>>   documentation which doesn't seem to be the case currently).
>>>
>>
>>
>> We are in a bit of a bind with schemas--what's needed is schema resources
>> to represent each request and response, not just each resource. Because,
>> obviously, the things you can PATCH and POST are necessarily different than
>> the things you can GET in any service api. However, it is not clear to me
>> how we get from one schema per resource to one schema per request and
>> response in a backwards compatible way. So b) might be the only way to go.
>>
>>
>>
>>>
>>> So what does everybody think?
>>>
>>> 
>>> When using glance client's v1 interface I can image-create an image and
>>> specify the image file's location via the --location parameter.
>>> Alternatively I can image-create an empty image and then image-update the
>>> image's location to some url.
>>>
>>> However, when using the client's v2 commands I can neither image-create
>>> the
>>> file using the --location parameter, nor image-update the file later.
>>>
>>> When using image-create with --location, the client gives the following
>>> error (printed by warlock):
>>>
>>>   Unable to set 'locations' to '[u' <http://192.168.1.111/foo/bar%27>
>>> http://192.168.1.111/foo/bar']'
>>>
>>> This is because the schema dictates that the location should be an 

Re: [openstack-dev] Questions regarding image "location" and glanceclient behaviour ...

[Martinx - ジェームズ]

Hey guys, any news about this?

I want to use Glance v2 but, without --location that points to a URL and,
for me, without it, it is impossible to use it (v2).

So, any plans to bring back --location, I want to use v2 like this:

--
glance image-create --location
http://uec-images.ubuntu.com/releases/14.04.3/release/ubuntu-14.04-server-cloudimg-amd64-disk1.img
--name "Ubuntu 14.04.3 LTS - Trusty Tahr - 64-bit - Cloud Based Image"
--visibility public --container-format bare --disk-format qcow2
--

But, "--location" isn't recognized anymore!

Thanks!
Thiago


On 22 January 2014 at 14:30, Mark Washenberger <
mark.washenber...@markwash.net> wrote:

>
>
>
> On Wed, Jan 22, 2014 at 1:05 AM, Public Mail 
> wrote:
>
>> Hi All,
>>
>> I have two questions ...
>>
>> 1) Glance v1 APIs can take a --location argument when creating an
>> image
>>but v2 APIs can't - bug or feature? (Details below)
>>
>
> I'd call that a missing feature. I think we probably need a glance
> image-location-add command somewhere in the client. But fair warning, this
> is typically a role-restricted operation.
>
>
>>
>> 2) How should glanceclient (v2 commands) handle reserved attributes?
>> a) status quo: (Apparently) let the user set them but the server
>>will return "attribute is reserved" error.  Pros: No missing
>>functionality, no damage done.  Cons: Bad usability.
>> b) hard-code list of reserved attributes in client and don't
>> expose
>>them to the user.
>> Pros: quick to implement.
>> Cons: Need to track reserved attributes in server
>> implementation.
>> c) get-reserved words from schema downloaded from server (and
>> don't
>>expose them to the user).
>> Pros: Don't need to track server implmentation.
>> Cons: Complex - reserved words can vary from command to
>> command.
>>
>>   I personally favor (b) on the grounds that a client implementation
>>   needs to closely understand server behaviour anyway so the sync-ing
>>   of reserved attributes shouldn't be a big problem (*provided* the
>>   list of reserved attributes is made available in the reference
>>   documentation which doesn't seem to be the case currently).
>>
>
>
> We are in a bit of a bind with schemas--what's needed is schema resources
> to represent each request and response, not just each resource. Because,
> obviously, the things you can PATCH and POST are necessarily different than
> the things you can GET in any service api. However, it is not clear to me
> how we get from one schema per resource to one schema per request and
> response in a backwards compatible way. So b) might be the only way to go.
>
>
>
>>
>> So what does everybody think?
>>
>> 
>> When using glance client's v1 interface I can image-create an image and
>> specify the image file's location via the --location parameter.
>> Alternatively I can image-create an empty image and then image-update the
>> image's location to some url.
>>
>> However, when using the client's v2 commands I can neither image-create
>> the
>> file using the --location parameter, nor image-update the file later.
>>
>> When using image-create with --location, the client gives the following
>> error (printed by warlock):
>>
>>   Unable to set 'locations' to '[u'http://192.168.1.111/foo/bar']'
>>
>> This is because the schema dictates that the location should be an object
>> of the form [{"url": "string", "metadata": object}, ...] but there is no
>> way to specify such an object from the command line - I cannot specify a
>> string like '{"url": "192.168.1.111/foo/bar", "metadata": {}}' for there
>> is
>> no conversion from command line strings to python dicts nor is there any
>> conversion from a simple URL string to a suitable location object.
>>
>> If I modify glanceclient.v2.images.Controller.create to convert the
>> locations parameter from a URL string to the desired object then the
>> request goes through to the glance server where it fails with a 403 error
>> (Attribute 'locations' is reserved).
>>
>> So is this discrepancy between V1 & V2 deliberate (a feature :)) or is it
>> a
>> bug?
>> 
>>
>> ___
>> 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 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] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

[Martinx - ジェームズ]

On 31 January 2016 at 18:23, Steve Baker <sba...@redhat.com> wrote:
> On 29/01/16 09:45, Martinx - ジェームズ wrote:
>>
>> Guys,
>>
>>   This is important and Kilo is missing it:
>>
>>   https://review.openstack.org/#/c/179989/
>>
>>   Is it possible to backport it to Kilo 2015.1.3?
>>
>>   Currently, I am manually patching Kilo / Heat by using the following
>> diff:
>>
>>
>> https://review.openstack.org/gitweb?p=openstack%2Fheat.git;a=commitdiff;h=811c8714aa2442e68980561d3e8dd435378f164c
>>
>>   But it is a pain to maintain...
>>
>>
> Rather than carrying a backport you can always modify your templates to set
> port_security_enabled via the value_specs property:
>
>   value_specs: {port_security_enabled: false}

WoW! That is cool! I'm gonna try it now! Thank you!

__
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] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

[Martinx - ジェームズ]

Oh, that's okay... Thanks guys!:)

On 29 January 2016 at 06:39, Sergey Kraynev  wrote:
> Sean, thank you for the spotting.
>
> Martinx, According to the information mentioned by Sean, we unfortunately
> can not do it :(
>
> On 29 January 2016 at 10:45, Sean M. Collins  wrote:
>>
>> Kilo is in the "security supported" stage of the lifecycle. So no,
>> that's not going to get backported.
>>
>> http://docs.openstack.org/releases/index.html
>> --
>> Sean M. Collins
>>
>> __
>> 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
>
>
>
>
> --
> Regards,
> Sergey.
>
> __
> 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-dev] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

[Martinx - ジェームズ]

Guys,

 This is important and Kilo is missing it:

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

 Is it possible to backport it to Kilo 2015.1.3?

 Currently, I am manually patching Kilo / Heat by using the following diff:

 
https://review.openstack.org/gitweb?p=openstack%2Fheat.git;a=commitdiff;h=811c8714aa2442e68980561d3e8dd435378f164c

 But it is a pain to maintain...

Thanks!
Thiago

__
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] The command "neutron-db-manage" of 8.0.0~b1 fails

[Martinx - ジェームズ]

On 4 January 2016 at 12:20, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
> Mike Bayer <mba...@redhat.com> wrote:
>
>>
>>
>> On 01/04/2016 06:59 AM, Ihar Hrachyshka wrote:
>>>
>>> Martinx - ジェームズ <thiagocmarti...@gmail.com> wrote:
>>>
>>>> Guys,
>>>>
>>>>  I'm trying to experiment Mitaka on Ubuntu Xenial, which already have
>>>> beta version on its repositories, however, "neutron-db-manage" fails.
>>>>
>>>>  Here is the output of it:
>>>>
>>>>  http://paste.openstack.org/show/482920/
>>>>
>>>>  Any clue?
>>>>
>>>>  I'm using the Kilo instructions as a start point, of course, I'm
>>>> using new neutron.conf and new ml2_conf.ini as well.
>>>>
>>>> Thanks in advance!
>>>> Thiago
>>>
>>>
>>> I believe it was fixed in:
>>>
>>> https://review.openstack.org/#/c/253150/2/neutron/db/migration/alembic_migrations/versions/mitaka/contract/8a6d8bdae39_migrate_neutron_resources_table.py
>>
>>
>> doh and I'm the one who fixed it!
>
>
> Busy man you are.
>
>
> Ihar

LOL

AWESOME!

Thank you guys!

__
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] [networking-ovs-dpdk] availability

[Martinx - ジェームズ]

On 3 January 2016 at 23:41, Palanisamy, Prabhakaran (Contractor)
 wrote:
> Hi,
>
>
>
> Is networking-ovs-dpdk package available non devstack installation ??
>
>
>
> Thanks,
>
> PP

Hi,

Don't know if it will help you but, Ubuntu Xenial (development
branch), have interesting packages:

root@xenial-1:~# apt-cache search ovs dpdk
openvswitch-switch-dpdk - DPDK enabled Open vSwitch switch implementation
python-networking-ovs-dpdk - OpenStack virtual network service - Open
vSwitch DPDK ML2 mechanism driver

Also, Xenial will support DPDK 2.2 natively, for at least, 5 years.

I'm trying to experiment Mitaka beta release on Xenial these days...

Best,
Thiago

__
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] The command "neutron-db-manage" of 8.0.0~b1 fails

[Martinx - ジェームズ]

Guys,

 I'm trying to experiment Mitaka on Ubuntu Xenial, which already have
beta version on its repositories, however, "neutron-db-manage" fails.

 Here is the output of it:

 http://paste.openstack.org/show/482920/

 Any clue?

 I'm using the Kilo instructions as a start point, of course, I'm
using new neutron.conf and new ml2_conf.ini as well.

Thanks in advance!
Thiago

__
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] [ANN] OpenStack Kilo on Ubuntu fully automated with Ansible! Ready for NFV L2 Bridges via Heat!

[Martinx - ジェームズ]

Hey guys,

 I know, the Ansible deployment
(https://github.com/stackforge/os-ansible-deployment) is impressive...

 But, for our need, we required something much simpler, that could be
deployed in an all-in-one fashion, without LXC containers for each
service, Ansible against localhost to simplify even more and using
only one NIC to begin with (br-ex and vxlan data net are being used
against a dummy0 and dummy1 interfaces).

 So, the Stackforge deployments is far too much complex for what we need.

 We found some limitations and a serious bug on Linux (I'll report
later), when using it with Linux Bridges (OVS is a requirement here,
specially because we want to try DPDK later).


 Concerns about "stackforge/os-ansible-deployment":


 1- It does not make use of Ubuntu OpenStack packages, it installs
everything from Git and Python PIP (we don't like it this way, why not
use Ubuntu packages? No reason...);

 2- It uses Linux Bridges, but unfortunately, it is not ready yet for
NFV deployments (where an Instance acts as a L2 Bridge), it simple
doesn't work / can not be used for "L2-NFV" (we found a very serious
BUG on Linux);

 3- Very hard deployment procedure and it needs more that 1 physical
box (or more than one VM, 1 for Ansible host, 1 for controller and its
containers, 1 for Net node, and the compute nodes).


So, we need Open vSwitch (not supported by "os-ansible-deployment",
right?), OpenStack Ubuntu packages from Cloud Archive and a very
simple setup / topology (no containers / all-in-one physical box).

Basically, that's why I created this new Ansible playbook.

You can install OpenStack on Ubuntu LTS with 1 command:

---
bash <(curl -s 
https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install.sh)
---

Also, we need to patch Heat, to add support for "port_security_enabled
= False" via templates, that's why we're maintaining an Ubuntu PPA. To
backport things from Liberty, to Kilo.

We want to contribute with Ubuntu packaging, report bugs and etc,
that's why we're using it (instead of installation from Git).

Thoughts?

Best,
Thiago

On 26 August 2015 at 12:01, Kevin Carter <kevin.car...@rackspace.com> wrote:
> +1 I'd love to know this too.
>
> Additionally, if vagrant is something that is important to folks in the 
> greater community it would be great to get some of those bits upstreamed.
>
> Per the NFV options, I don't see much in the way of OSAD not being able to 
> support that presently, its really a matter of introducing the new 
> configuration options/package additions however I may be missing something 
> based on a cursory look at your published repository. If you're interested, I 
> would be happy to help you get the capabilities into OSAD so that the greater 
> community can benefit from some of the work you've done.
>
> --
>
> Kevin Carter
> IRC: cloudnull
>
>
> 
> From: Thierry Carrez <thie...@openstack.org>
> Sent: Wednesday, August 26, 2015 5:15 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [ANN] OpenStack Kilo on Ubuntu fully automated 
> with Ansible! Ready for NFV L2 Bridges via Heat!
>
> Martinx - ジェームズ wrote:
>>  I'm proud to announce an Ansible Playbook to deploy OpenStack on Ubuntu!
>>  Check it out!
>>  * https://github.com/sandvine/os-ansible-deployment-lite
>
> How does it compare with the playbooks developed as an OpenStack project
> by the OpenStackAnsible team[1] ?
>
> Any benefit, difference ? Anything you could contribute back there ? Any
> value in merging the two efforts ?
>
> [1] http://governance.openstack.org/reference/projects/openstackansible.html
>
> --
> Thierry Carrez (ttx)
>
> __
> 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-dev] [ANN] OpenStack Kilo on Ubuntu fully automated with Ansible! Ready for NFV L2 Bridges via Heat!

[Martinx - ジェームズ]

Hello Stackers!


 I'm proud to announce an Ansible Playbook to deploy OpenStack on Ubuntu!


 Check it out!


 * https://github.com/sandvine/os-ansible-deployment-lite


 Powered by Sandvine!   ;-)


 Basically, this is the automation of what we have documented here:


 * http://docs.openstack.org/kilo/install-guide/install/apt/content/


 Instructions:


 1- Install Ubuntu 14.04, fully upgraded (with
linux-generic-lts-vivid installed), plus /etc/hostname and
/etc/hosts configured according.


 2- Deploy OpenStack with 1 command:

   * Open vSwtich (default):

   bash (curl -s
https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install.sh)

   * Linux Bridges (alternative):

   bash (curl -s
https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install-lbr.sh)


 3- Launch a NFV L2 Stack:

   heat stack-create demo -f
~/os-ansible-deployment-lite/misc/os-heat-templates/nfv-l2-bridge-basic-stack-ubuntu-little.yaml



 IMPORTANT NOTES:

 Only runs the step 2 on top of a fresh installed Ubuntu 14.04! Can
be a Server or Desktop but, fresh installed. Do not pre-install MySQL,
RabbitMQ, Keystone, etc... Let Ansible to its magic!

 Also, make sure you can use sudo without password.



 Some features of our Ansible Playbook:


 1- Deploys OpenStack with one single command, in one physical box
(all-in-one), helper script (./os-deploy.sh) available;

 2- Supports NFV instances that can act as a L2 Bridge between two
VXLAN Networks;

 3- Plenty of Heat Templates;

 4- 100% Ubuntu based;

 5- Very simple setup (simpler topology; dummy interfaces for both
br-ex and vxlan; no containers for each service (yet));

 6- Ubuntu PPA available, with a few OpenStack patches backported from
Liberty, to Kilo (to add port_security_enabled Heat support);

 https://launchpad.net/~sandvine/+archive/ubuntu/cloud-archive-kilo/

 7- Only requires one physical ethernet card;

 8- Both Linux Bridges and Open vSwitch deployments are supported;

 9- Planning to add DPDK support;

 10- Multi-node support under development;

 11- IPv6 support comming...


 * Notes about Vagrant support:

 Under development (it doesn't work yet).

 There is a preliminary Vagrant support (there is still a bug on MySQL
startup, pull requests are welcome).

 Just git clone our Ansible playbooks and run vagrant up (or
./os-deploy-vagrant.sh to auto-config your Ansible vars / files for
you).

 We tried it only with Mac / VirtualBox but, it does not support
VT-in-VT (nested virtualization), so, we're looking for KVM / Libvirt
on Ubuntu Desktop instead. But it would be nice to, at least, launch
OpenStack in a VirtualBox on you Mac...  =)


 Hope you guys enjoy it!

Cheers!
Thiago

__
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] OpenStack Juno is completely broken in Trusty + Linux 3.19!

[Martinx - ジェームズ]

Guys,

 I just upgraded my Trusty servers, that I'm running OpenStack Juno, to
Linux 3.19, which is already available at Proposed repository.

 OpenStack is dead here, no connectivity for the tenants.

 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1452868

 I appreciate any help!

 It works okay with Linux 3.19.

Best,
Thiago
__
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 Juno is completely broken in Trusty + Linux 3.19!

[Martinx - ジェームズ]

I meatn, it works okay with Linux 3.16, not 3.19. Sorry...

On Thu, May 7, 2015 at 4:26 PM Martinx - ジェームズ thiagocmarti...@gmail.com
wrote:

 Guys,

  I just upgraded my Trusty servers, that I'm running OpenStack Juno, to
 Linux 3.19, which is already available at Proposed repository.

  OpenStack is dead here, no connectivity for the tenants.

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1452868

  I appreciate any help!

  It works okay with Linux 3.19.

 Best,
 Thiago

__
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 Juno is completely broken in Trusty + Linux 3.19!

[Martinx - ジェームズ]

On Thu, May 7, 2015 at 4:26 PM Martinx - ジェームズ thiagocmarti...@gmail.com
wrote:

 Guys,

  I just upgraded my Trusty servers, that I'm running OpenStack Juno, to
 Linux 3.19, which is already available at Proposed repository.

  OpenStack is dead here, no connectivity for the tenants.

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1452868

  I appreciate any help!

  It works okay with Linux 3.19.

 Best,
 Thiago


First things first.

I'm so sorry about this crossposting, I'll not do it again. I'm tired and
I'm not feeling well today, huge headache... I'll only crosspost again, my
apologies now.

Secondly, only after a complete power cycle, Juno with Trusty + Linux 3.19
is working. Tenants have connectivity again.

 So far, the only error that I'm still seeing, is the following:

---
== /var/log/neutron/ovs-cleanup.log ==
2015-05-07 13:30:57.384 881 TRACE neutron Command: ['sudo',
'/usr/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'link',
'delete', 'tap3da8f4fe-55']
2015-05-07 13:30:57.384 881 TRACE neutron Exit code: 2
2015-05-07 13:30:57.384 881 TRACE neutron Stdout: ''
2015-05-07 13:30:57.384 881 TRACE neutron Stderr: 'RTNETLINK answers:
Operation not supported\n'
---

 I'll clean up everything, bridges and Namespaces, to see if the problem
persists. I saw this problem in a lab as well, I'll reset the databases and
tenants to start over again, with Linux 3.19 from the beginning.

 Again, forgive-me about the crossposting and about the buzz.

Best Regards,
Thiago
__
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] Time to Samba! :-)

[Martinx - ジェームズ]

Just for the record, they are watching us!:-O

https://aws.amazon.com/blogs/aws/new-aws-directory-service/

Best!
Thiago

On 16 August 2014 16:03, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 Hey Stackers,

  I'm wondering here... Samba4 is pretty solid (up coming 4.2 rocks), I'm
 using it on a daily basis as an AD DC controller, for both Windows and
 Linux Instances! With replication, file system ACLs - cifs, built-in LDAP,
 dynamic DNS with Bind9 as a backend (no netbios) and etc... Pretty cool!

  In OpenStack ecosystem, there are awesome solutions like Trove, Solum,
 Designate and etc... Amazing times BTW! So, why not try to integrate
 Samba4, working as an AD DC, within OpenStack itself?!

  If yes, then, what is the best way/approach to achieve this?!

  I mean, for SQL, we have Trove, for iSCSI, Cinder, Nova uses Libvirt...
 Don't you guys think that it is time to have an OpenStack project for LDAP
 too? And since Samba4 come with it, plus DNS, AD, Kerberos and etc, I think
 that it will be huge if we manage to integrate it with OpenStack.

  I think that it would be nice to have, for example: domains, users and
 groups management at Horizon, and each tenant with its own Administrator
 (not the Keystone global admin) (to mange its Samba4 domains), so, they
 will be able to fully manage its own account, while allowing Keystone to
 authenticate against these users...

  Also, maybe Designate can have support for it too! I don't know for
 sure...

  Today, I'm doing this Samba integration manually, I have an external
 Samba4, from OpenStack's point of view, then, each tenant/project, have its
 own DNS domains, when a instance boots up, I just need to do something like
 this (bootstrap):

 --
 echo 127.0.1.1 instance-1.tenant-1.domain-1.com instance-1  /etc/hosts
 net ads join -U administrator
 --

  To make this work, the instance just needs to use Samba4 AD DC as its
 Name Servers, configured at its /etc/resolv.conf, delivered by DHCP
 Agent. The packages `samba-common-bin` and `krb5-user` are also required.
 Including a ready to use smb.conf file.

  Then, ping instance-1.tenant-1.domain-1.com worldwide! It works for
 both IPv4 and IPv6!!

  Also, Samba4 works okay with Disjoint Namespaces
 http://technet.microsoft.com/en-us/library/cc731929(v=ws.10).aspx, so,
 each tenant can have one or more domains and subdomains! Like *.
 realm.domain.com, *.domain.com, *.cloud-net-1.domain.com,
 *.domain2.com... All dynamic managed by Samba4 and Bind9!

  What about that?!

 Cheers!
 Thiago

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

Re: [openstack-dev] [Heat] Juno RC2 available

[Martinx - ジェームズ]

Congrats  :-D

On 9 October 2014 09:52, Thierry Carrez thie...@openstack.org wrote:

 Hello everyone,

 One week to final release! Due to a number of issues discovered in the
 published Heat 2014.2 RC1, we generated a new Juno release candidate.
 You can find the list of bugfixes in this RC and a link to a source
 tarball at:

 https://launchpad.net/heat/juno/juno-rc2

 Unless new release-critical issues are found that warrant a release
 candidate respin, this RC2 will be formally released as Heat 2014.2 on
 October 16. You are therefore strongly encouraged to test and validate
 this tarball !

 Alternatively, you can directly test the proposed/juno branch at:
 https://github.com/openstack/heat/tree/proposed/juno

 If you find an issue that could be considered release-critical, please
 file it at:

 https://bugs.launchpad.net/heat/+filebug

 and tag it *juno-rc-potential* to bring it to the release crew's
 attention.

 Regards,

 --
 Thierry Carrez (ttx)

 ___
 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] [Neutron] Proposing to disallow updates of IPv6 attributes on subnets

[Martinx - ジェームズ]

Ah okay... That's seems to be perfect fine... Thank you!   :-)

On 9 October 2014 10:22, Robert Li (baoli) ba...@cisco.com wrote:

  Hi Thiago,

  A couple of things to consider:
   — As it is now, it doesn’t seem to be fully functional if you change
 your subnet to use SLAAC. The addresses that were assigned to your existing
 ports in neutron wouldn’t be updated/changed. So basically, you can not
 simply make an API call to change the subnet and expect that everything
 will be setup correctly. Not mention that currently subnet api to update
 the modes can’t even be invoked.

— if you want to use SLAAC, there might be a couple of ways to do that
 . Once multiple prefix is supported, you can create a new slaac
 subnet in the same network. Obviously you need to use a different prefix.
 Later, you can remove the previous subnet.
 . For now, you can create a new network with a slaac subnet. And
 attach your VMs to this new network. Once it’s done, you can remove the
 previous network.

  Hope that it helps
 Robert

   On 10/8/14, 10:25 PM, Martinx - ジェームズ thiagocmarti...@gmail.com
 wrote:

   Hi!

  Currently, I have IceHouse up and running (Ubuntu 14.04.1) with VLAN
 Provider Network + static IPv6.

  I created the subnet(s) like this (one for each tenant):

  --
 neutron net-create --tenant-id $ID --provider:physical_network=physnet1
 --provider:network_type=vlan --provider:segmentation_id=200 physnet1-vlan200

  neutron subnet-create --ip-version 6 --disable-dhcp --tenant-id $ID
 physnet1-vlan200 2001:db8:1::/64 --allocation-pool
 start=2001:db8:1::8000,end=2001:db8:1:0::::fffe
  --

  This new BUGs means that, after upgrading to Juno, I'll not be able to
 update / convert this static network to SLAAC ?!?!

  If yes, how can I force the update without breaking the production
 environment? Is there a procedure to follow?

  I'm not using Neutron L3 Router and I have no plans to use GRE/VXLAN,
 neither a radvd controlled by Neutron. My upstream router already have
 radvd ready.

  Thanks!
 Thiago

 On 7 October 2014 13:21, Henry Gessau ges...@cisco.com wrote:

 A number of bugs[1][2][3] have been filed which are related to updating
 the
 IPv6 attributes after a subnet has been created.

 In the reviews[4][5] for the fixes for [1] and [2] some shortcomings and
 questions have been raised, which were discussed in today's IPv6 IRC
 meeting[6].

 Summary:
 In Juno we are not ready for allowing the IPv6 attributes on a subnet to
 be
 updated after the subnet is created, because:
 - The implementation for supporting updates is incomplete.
 - Perceived lack of usefulness, no good use cases known yet.
 - Allowing updates causes more complexity in the code.
 - Have not tested that radvd, dhcp, etc. behave OK after update.

 Therefore we are proposing to change 'allow_put' to False for the two IPv6
 attributes, ipv6_ra_mode and ipv6_address_mode. This will prevent the
 modes
 from being updated via the PUT:subnets API.

 We would be interested to hear of any disagreements or questions.


 [1] https://launchpad.net/bugs/1362966
 [2] https://launchpad.net/bugs/1363064
 [3] https://launchpad.net/bugs/1373417
 [4] https://review.openstack.org/125328
 [5] https://review.openstack.org/117799
 [6]

 http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-10-07-15.01.log.html

 ___
 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] [OpenStack-Dev] [Test PPA's] Glance Test PPA's for Juno missing?

[Martinx - ジェームズ]

About this
https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/juno-staging ?

On 27 September 2014 13:12, John Griffith john.griffi...@gmail.com wrote:

 Hey Everyone,

 I've been trying some upgrade testing from Icehouse to Juno on running
 systems using the test PPA's but I'm running into problems with Glance.
 Glance fails to update because of python-sqlalchemy deps, poking around I
 noticed the test PPA list [1] doesn't seem to have a Juno version for
 Glance, and I'm assuming this is likely the reason I'm stuck.

 Does anybody know why the Glance packages aren't being built by the test
 bot?  Or if there's another way I can install the glance portion for the
 upgrade tests?

 Thanks,
 John

 [1]: https://launchpad.net/~openstack-ubuntu-testing-bot/+ppa-packages

 ___
 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] [OpenStack-Dev] [Test PPA's] Glance Test PPA's for Juno missing?

[Martinx - ジェームズ]

Also here:
http://docs.openstack.org/trunk/install-guide/install/apt/content/ch_basic_environment.html
- there is add-apt-repository cloud-archive:juno but I'm not sure if it
is ready for tests...

Cheers!

On 27 September 2014 15:34, Martinx - ジェームズ thiagocmarti...@gmail.com
wrote:

 About this
 https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/juno-staging ?

 On 27 September 2014 13:12, John Griffith john.griffi...@gmail.com
 wrote:

 Hey Everyone,

 I've been trying some upgrade testing from Icehouse to Juno on running
 systems using the test PPA's but I'm running into problems with Glance.
 Glance fails to update because of python-sqlalchemy deps, poking around I
 noticed the test PPA list [1] doesn't seem to have a Juno version for
 Glance, and I'm assuming this is likely the reason I'm stuck.

 Does anybody know why the Glance packages aren't being built by the test
 bot?  Or if there's another way I can install the glance portion for the
 upgrade tests?

 Thanks,
 John

 [1]: https://launchpad.net/~openstack-ubuntu-testing-bot/+ppa-packages

 ___
 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] [OSSN 0020] Disassociating floating IPs does not terminate NAT connections with Neutron L3 agent

[Martinx - ジェームズ]

Awesome! Hope it reaches Juno!   :-)
This is important...

Best,
Thiago

On 16 September 2014 13:17, Carl Baldwin c...@ecbaldwin.net wrote:

 Hi,

 There is current work in review to use conntrack to terminate these
 connections [1][2] much like you suggested.  I hope to get this in to
 RC1 but it needs another iteration.

 For Kilo, I'd like to explore stateless forwarding for floating ips.
 Since conntrack is the root of the security issue in the first place,
 the idea here is to eliminate it from the floating ip data path
 altogether [3].  The patch I have up is really just a placeholder with
 some notes on how it might be accomplished.  My hope is that this
 stateless NAT for floating ips could ease some of the pressure that
 I've observed on conntrack and increase performance.  It needs some
 more investigation.

 Carl

 [1] https://bugs.launchpad.net/neutron/+bug/1334926
 [2] https://review.openstack.org/#/c/103475
 [3] https://review.openstack.org/#/c/121689/

 On Mon, Sep 15, 2014 at 11:46 PM, Martinx - ジェームズ
 thiagocmarti...@gmail.com wrote:
  Hey stackers,
 
  Let me ask something about this... Why not use Linux Conntrack Table at
 each
  Tenant Namespace (L3 Router) to detect which connections were
  made/established over a Floating IP ?
 
  Like this, on the Neutron L3 Router:
 
  --
  apt-get install conntrack
 
  ip netns exec qrouter-09b72faa-a5ef-4a52-80b5-1dcbea23b1b6 conntrack -L |
  grep ESTABLISHED
 
  tcp  6 431998 ESTABLISHED src=192.168.3.5 dst=193.16.15.250
 sport=36476
  dport=8333 src=193.16.15.250 dst=187.1.93.67 sport=8333 dport=36476
  [ASSURED] mark=0 use=1
  --
 
  Floating IP: 187.1.93.67
  Instance IP: 192.168.3.5
 
  http://conntrack-tools.netfilter.org/manual.html#conntrack
 
  
 
  Or, as a workaround, right after removing the Floating IP, Neutron might
  insert a temporary firewall rule (for about 5~10 minutes?), to drop the
  connections of that previous Floating IP + Instance IP couple... It
 looks
  really ugly but, at least, it will make sure that nothing will pass right
  after removing a Floating IP... Effectively terminating (dropping) the
 NAT
  connections after disassociating a Floating IP... ;-)
 
  
 
  Also, I think that NFTables can bring some light here... I truly believe
  that if OpenStack moves to a NFTables_Driver, it will be much easier
 to:
  manage firewall rules, logging, counters, IDS/IPS, atomic replacements of
  rules, even NAT66... All under a single implementation... Maybe with some
  kind of real-time connection monitoring... I mean, with NFTables, it
  becomes easier to implement a firewall ruleset with a Intrusion
 Prevention
  System (IPS), take a look:
 
  https://home.regit.org/2014/02/suricata-and-nftables/
 
  So, if NFTables can make Suricata's life easier, why not give Suricata's
  power to Netutron L3 Router? Starting with a new NFTables_Driver...
  =)
 
  I'm not an expert on NFTables but, from what I'm seeing, it perfectly
 fits
  in OpenStack, in fact, NFTables will make OpenStack better.
 
  https://home.regit.org/2014/01/why-you-will-love-nftables/
 
  Best!
  Thiago
 
  On 15 September 2014 20:49, Nathan Kinder nkin...@redhat.com wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Disassociating floating IPs does not terminate NAT connections with
  Neutron L3 agent
  - ---
 
  ### Summary ###
  Every virtual instance is automatically assigned a private IP address.
  You may optionally assign public IP addresses to instances. OpenStack
  uses the term floating IP to refer to an IP address (typically
  public) that can be dynamically added to a running virtual instance.
  The Neutron L3 agent uses Network Address Translation (NAT) to assign
  floating IPs to virtual instances. Floating IPs can be dynamically
  released from a running virtual instance but any active connections are
  not terminated with this release as expected when using the Neutron L3
  agent.
 
  ### Affected Services / Software ###
  Neutron, Icehouse, Havana, Grizzly, Folsom
 
  ### Discussion ###
  When creating a virtual instance, a floating IP address is not
  allocated by default. After a virtual instance is created, a user can
  explicitly associate a floating IP address to that instance. Users can
  create connections to the virtual instance using this floating IP
  address. Also, this floating IP address can be disassociated from any
  running instance without shutting that instance down.
 
  If a user initiates a connection using the floating IP address, this
  connection remains alive and accessible even after the floating IP
  address is released from that instance. This potentially violates
  restrictive policies which are only being applied to new connections.
  These policies are ignored for pre-existing connections and the virtual
  instance remains accessible from the public network.
 
  This issue is only known to affect Neutron when using the L3 agent.
  Nova networking is not affected.
 
  ### Recommended

Re: [openstack-dev] [OSSN 0020] Disassociating floating IPs does not terminate NAT connections with Neutron L3 agent

[Martinx - ジェームズ]

Hey stackers,

Let me ask something about this... Why not use Linux Conntrack Table at
each Tenant Namespace (L3 Router) to detect which connections were
made/established over a Floating IP ?

Like this, on the Neutron L3 Router:

--
apt-get install conntrack

ip netns exec qrouter-09b72faa-a5ef-4a52-80b5-1dcbea23b1b6 conntrack -L |
grep ESTABLISHED

tcp  6 431998 ESTABLISHED src=192.168.3.5 dst=193.16.15.250 sport=36476
dport=8333 src=193.16.15.250 dst=187.1.93.67 sport=8333 dport=36476
[ASSURED] mark=0 use=1
--

Floating IP: 187.1.93.67
Instance IP: 192.168.3.5

http://conntrack-tools.netfilter.org/manual.html#conntrack



Or, *as a workaround*, right after removing the Floating IP, Neutron might
insert a temporary firewall rule (for about 5~10 minutes?), to drop the
connections of that previous Floating IP + Instance IP couple... It looks
really ugly but, at least, it will make sure that nothing will pass right
after removing a Floating IP... Effectively terminating (dropping) the NAT
connections after disassociating a Floating IP... ;-)



Also, I think that NFTables can bring some light here... I truly believe
that if OpenStack moves to a NFTables_Driver, it will be much easier to:
manage firewall rules, logging, counters, IDS/IPS, atomic replacements of
rules, even NAT66... All under a single implementation... Maybe with some
kind of real-time connection monitoring... I mean, with NFTables, it
becomes easier to implement a firewall ruleset with a Intrusion Prevention
System (IPS), take a look:

https://home.regit.org/2014/02/suricata-and-nftables/

So, if NFTables can make Suricata's life easier, why not give Suricata's
power to Netutron L3 Router? Starting with a new NFTables_Driver... =)

I'm not an expert on NFTables but, from what I'm seeing, it perfectly fits
in OpenStack, in fact, NFTables will make OpenStack better.

https://home.regit.org/2014/01/why-you-will-love-nftables/

Best!
Thiago

On 15 September 2014 20:49, Nathan Kinder nkin...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Disassociating floating IPs does not terminate NAT connections with
 Neutron L3 agent
 - ---

 ### Summary ###
 Every virtual instance is automatically assigned a private IP address.
 You may optionally assign public IP addresses to instances. OpenStack
 uses the term floating IP to refer to an IP address (typically
 public) that can be dynamically added to a running virtual instance.
 The Neutron L3 agent uses Network Address Translation (NAT) to assign
 floating IPs to virtual instances. Floating IPs can be dynamically
 released from a running virtual instance but any active connections are
 not terminated with this release as expected when using the Neutron L3
 agent.

 ### Affected Services / Software ###
 Neutron, Icehouse, Havana, Grizzly, Folsom

 ### Discussion ###
 When creating a virtual instance, a floating IP address is not
 allocated by default. After a virtual instance is created, a user can
 explicitly associate a floating IP address to that instance. Users can
 create connections to the virtual instance using this floating IP
 address. Also, this floating IP address can be disassociated from any
 running instance without shutting that instance down.

 If a user initiates a connection using the floating IP address, this
 connection remains alive and accessible even after the floating IP
 address is released from that instance. This potentially violates
 restrictive policies which are only being applied to new connections.
 These policies are ignored for pre-existing connections and the virtual
 instance remains accessible from the public network.

 This issue is only known to affect Neutron when using the L3 agent.
 Nova networking is not affected.

 ### Recommended Actions ###
 There is unfortunately no easy way to detect which connections were
 made over a floating IP address from a virtual instance, as the NAT is
 performed at the Neutron router. The only safe way of terminating all
 connections made over a floating IP address is to terminate the virtual
 instance itself.

 The following recommendations should be followed when using the Neutron
 L3 agent:

 - - Only attach a floating IP address to a virtual instance when that
 instance should be accessible from networks outside the cloud.
 - - Terminate or stop the instance along with disassociating the floating
 IP address to ensure that all connections are closed.

 The Neutron development team plans to address this issue in a future
 version of Neutron.

 ### Contacts / References ###
 This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0020
 Original LaunchPad Bug : https://bugs.launchpad.net/neutron/+bug/1334926
 OpenStack Security ML : openstack-secur...@lists.openstack.org
 OpenStack Security Group : https://launchpad.net/~openstack-ossg
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJUF3r6AAoJEJa+6E7Ri+EVo+AH/i4GhZsFD3OJWlasq+XxkqqO
 

Re: [openstack-dev] [neutron][IPv6] Neighbor Discovery for HA

[Martinx - ジェームズ]

Sounds impressive!   :-D


On 1 September 2014 23:52, Xu Han Peng pengxu...@gmail.com wrote:

  Anthony,

 Thanks for your reply.

 If HA method like VRRP are used for IPv6 router, according to the VRRP RFC
 with IPv6 included, the servers should be auto-configured with the active
 router's LLA as the default route before the failover happens and still
 remain that route after the failover. In other word, there should be no
 need to use two LLAs for default route of a subnet unless load balance is
 required.

 When the backup router become the master router, the backup router should
 be responsible for sending out an unsolicited ND neighbor advertisement
 with the associated LLA (the previous master's LLA) immediately to update
 the bridge learning state and sending out router advertisement with the
 same options with the previous master to maintain the route and bridge
 learning.

 This is shown in http://tools.ietf.org/html/rfc5798#section-4.1 and the
 actions backup router should take after failover is documented here:
 http://tools.ietf.org/html/rfc5798#section-6.4.2. The need for immediate
 messaging sending and periodic message sending is documented here:
 http://tools.ietf.org/html/rfc5798#section-2.4

 Since the keepalived manager support for L3 HA is merged:
 https://review.openstack.org/#/c/68142/43. And keepalived release 1.2.0
 supports VRRP IPv6 features ( http://www.keepalived.org/changelog.html,
 see Release 1.2.0 | VRRP IPv6 Release). I think we can check if keepalived
 can satisfy our requirement here and if that will cause any conflicts with
 RADVD.

 Thoughts?

 Xu Han


 On 08/28/2014 10:11 PM, Veiga, Anthony wrote:



   Anthony and Robert,

 Thanks for your reply. I don't know if the arping is there for NAT, but I
 am pretty sure it's for HA setup to broadcast the router's own change since
 the arping is controlled by send_arp_for_ha config. By checking the man
 page of arping, you can find the arping -A we use in code is sending out
 ARP REPLY instead of ARP REQUEST. This is like saying I am here instead
 of where are you. I didn't realized this either until Brain pointed this
 out at my code review below.


  That’s what I was trying to say earlier.  Sending out the RA is the same
 effect.  RA says “I’m here, oh and I’m also a router” and should supersede
 the need for an unsolicited NA.  The only thing to consider here is that
 RAs are from LLAs.  If you’re doing IPv6 HA, you’ll need to have two
 gateway IPs for the RA of the standby to work.  So far as I know, I think
 there’s still a bug out on this since you can only have one gateway per
 subnet.



 http://linux.die.net/man/8/arping

 https://review.openstack.org/#/c/114437/2/neutron/agent/l3_agent.py

 Thoughts?

 Xu Han


 On 08/27/2014 10:01 PM, Veiga, Anthony wrote:


 Hi Xuhan,

  What I saw is that GARP is sent to the gateway port and also to the
 router ports, from a neutron router. I’m not sure why it’s sent to the
 router ports (internal network). My understanding for arping to the gateway
 port is that it is needed for proper NAT operation. Since we are not
 planning to support ipv6 NAT, so this is not required/needed for ipv6 any
 more?


  I agree that this is no longer necessary.


  There is an abandoned patch that disabled the arping for ipv6 gateway
 port:  https://review.openstack.org/#/c/77471/3/neutron/agent/l3_agent.py

  thanks,
 Robert

   On 8/27/14, 1:03 AM, Xuhan Peng pengxu...@gmail.com wrote:

   As a follow-up action of yesterday's IPv6 sub-team meeting, I would
 like to start a discussion about how to support l3 agent HA when IP version
 is IPv6.

  This problem is triggered by bug [1] where sending gratuitous arp packet
 for HA doesn't work for IPv6 subnet gateways. This is because neighbor
 discovery instead of ARP should be used for IPv6.

  My thought to solve this problem turns into how to send out neighbor
 advertisement for IPv6 routers just like sending ARP reply for IPv4 routers
 after reading the comments on code review [2].

  I searched for utilities which can do this and only find a utility
 called ndsend [3] as part of vzctl on ubuntu. I could not find similar
 tools on other linux distributions.

  There are comments in yesterday's meeting that it's the new router's job
 to send out RA and there is no need for neighbor discovery. But we didn't
 get enough time to finish the discussion.


  Because OpenStack runs the l3 agent, it is the router.  Instead of
 needing to do gratuitous ARP to alert all clients of the new MAC, a simple
 RA from the new router for the same prefix would accomplish the same,
 without having to resort to a special package to generate unsolicited NA
 packets.  RAs must be generated from the l3 agent anyway if it’s the
 gateway, and we’re doing that via radvd now.  The HA failover simply needs
 to start the proper radvd process on the secondary gateway and resume
 normal operation.


  Can you comment your thoughts about how to solve this problem in this
 

Re: [openstack-dev] [Heat][Docker] How to Dockerize your applications with OpenStack Heat in simple steps

[Martinx - ジェームズ]

Hey Stackers! Wait!   =)

Let me ask something...

Why are you guys using Docker within a VM?!?! What is the point of doing
such thing?!

I thought Docker was here to entirely replace the virtualization layer,
bringing a bare metal-cloud, am I right?!

Tks!
Thiago


On 26 August 2014 05:45, Marouen Mechtri mechtri.mar...@gmail.com wrote:

 Hi Angus,

 We are not using nova-docker driver to deploy docker containers.

 In our manual, we are using Heat (thanks to the docker plugin) to deploy
 docker containers and nova is just used to deploy VM. Inside this VM
 heat deploy the docker software. The figure below describes the
 interactions between different components.

 Regards,
 Marouen


  [image: Images intégrées 1]




 2014-08-26 0:13 GMT+02:00 Angus Salkeld asalk...@mirantis.com:

 This seems misleading as there is no description on setting up nova-docker
 or using the heat docker container.

 -Angus



 On Tue, Aug 26, 2014 at 5:56 AM, Marouen Mechtri 
 mechtri.mar...@gmail.com wrote:

  Hi all,

 I want to present you our guide for Docker containers deployment with
 OpenStack Heat.
 In this guide we dockerize and deploy a lamp application on two
 containers.


 https://github.com/MarouenMechtri/OpenStack-Heat-Installation/blob/master/Docker-containers-deployment-with-OpenStack-Heat.rst
 https://github.com/MarouenMechtri/OpenStack-Heat-Installation/blob/master/OpenStack-Heat-Installation.rst


 Hope it will be helpful for many people. Please let us know your
 opinion about it.

 Regards,
 Marouen Mechtri

 ___
 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


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

Re: [openstack-dev] [neutron]Performance of security group

[Martinx - ジェームズ]

+1 NFTablesDriver!

Also, NFTables, AFAIK, improves IDS systems, like Suricata, for example:
https://home.regit.org/2014/02/suricata-and-nftables/

Then, I'm wondering here... What benefits might come for OpenStack Nova /
Neutron, if it comes with a NFTables driver, instead of the current
IPTables?!

* Efficient Security Group design?
* Better FWaaS, maybe with NAT(44/66) support?
* Native support for IPv6, with the defamed NAT66 built-in, simpler
Floating IP implementation, for both v4 and v6 networks under a single
implementation (*I don't like NAT66, I prefer a `routed Floating IPv6`
version*)?
* Metadata over IPv6 still using NAT(66) (*I don't like NAT66*), single
implementation?
* Suricata-as-a-Service?!

It sounds pretty cool!   :-)


On 20 August 2014 23:16, Baohua Yang yangbao...@gmail.com wrote:

 Great！
 We met similar problems.
 The current mechanisms produce too many iptables rules, and it's hard to
 debug.
 Really look forward to seeing a more efficient security group design.


 On Thu, Jul 10, 2014 at 11:44 PM, Kyle Mestery mest...@noironetworks.com
 wrote:

 On Thu, Jul 10, 2014 at 4:30 AM, shihanzhang ayshihanzh...@126.com
 wrote:
 
  With the deployment 'nova + neutron + openvswitch', when we bulk create
  about 500 VM with a default security group, the CPU usage of
 neutron-server
  and openvswitch agent is very high, especially the CPU usage of
 openvswitch
  agent will be 100%, this will cause creating VMs failed.
 
  With the method discussed in mailist:
 
  1) ipset optimization   (https://review.openstack.org/#/c/100761/)
 
  3) sg rpc optimization (with fanout)
  (https://review.openstack.org/#/c/104522/)
 
  I have implement  these two scheme in my deployment,  when we again bulk
  create about 500 VM with a default security group, the CPU usage of
  openvswitch agent will reduce to 10%, even lower than 10%, so I think
 the
  iprovement of these two options are very efficient.
 
  Who can help us to review our spec?
 
 This is great work! These are on my list of things to review in detail
 soon, but given the Neutron sprint this week, I haven't had time yet.
 I'll try to remedy that by the weekend.

 Thanks!
 Kyle

 Best regards,
  shihanzhang
 
 
 
 
 
  At 2014-07-03 10:08:21, Ihar Hrachyshka ihrac...@redhat.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 Oh, so you have the enhancement implemented? Great! Any numbers that
 shows how much we gain from that?
 
 /Ihar
 
 On 03/07/14 02:49, shihanzhang wrote:
  Hi, Miguel Angel Ajo! Yes, the ipset implementation is ready, today
  I will modify my spec, when the spec is approved, I will commit the
  codes as soon as possilbe!
 
 
 
 
 
  At 2014-07-02 10:12:34, Miguel Angel Ajo majop...@redhat.com
  wrote:
 
  Nice Shihanzhang,
 
  Do you mean the ipset implementation is ready, or just the
  spec?.
 
 
  For the SG group refactor, I don't worry about who does it, or
  who takes the credit, but I believe it's important we address
  this bottleneck during Juno trying to match nova's scalability.
 
  Best regards, Miguel Ángel.
 
 
  On 07/02/2014 02:50 PM, shihanzhang wrote:
  hi Miguel Ángel and Ihar Hrachyshka, I agree with you that
  split  the work in several specs, I have finished the work (
  ipset optimization), you can do 'sg rpc optimization (without
  fanout)'. as the third part(sg rpc optimization (with fanout)),
  I think we need talk about it, because just using ipset to
  optimize security group agent codes does not bring the best
  results!
 
  Best regards, shihanzhang.
 
 
 
 
 
 
 
 
  At 2014-07-02 04:43:24, Ihar Hrachyshka ihrac...@redhat.com
  wrote:
  On 02/07/14 10:12, Miguel Angel Ajo wrote:
 
  Shihazhang,
 
  I really believe we need the RPC refactor done for this cycle,
  and given the close deadlines we have (July 10 for spec
  submission and July 20 for spec approval).
 
  Don't you think it's going to be better to split the work in
  several specs?
 
  1) ipset optimization   (you) 2) sg rpc optimization (without
  fanout) (me) 3) sg rpc optimization (with fanout) (edouard, you
  , me)
 
 
  This way we increase the chances of having part of this for the
  Juno cycle. If we go for something too complicated is going to
  take more time for approval.
 
 
  I agree. And it not only increases chances to get at least some of
  those highly demanded performance enhancements to get into Juno,
  it's also the right thing to do (c). It's counterproductive to
  put multiple vaguely related enhancements in single spec. This
  would dim review focus and put us into position of getting
  'all-or-nothing'. We can't afford that.
 
  Let's leave one spec per enhancement. @Shihazhang, what do you
  think?
 
 
  Also, I proposed the details of 2, trying to bring awareness
  on the topic, as I have been working with the scale lab in Red
  Hat to find and understand those issues, I have a very good
  knowledge of the problem and I believe I could make a very fast
  advance on the issue at the RPC level.
 

[openstack-dev] Time to Samba! :-)

[Martinx - ジェームズ]

Hey Stackers,

 I'm wondering here... Samba4 is pretty solid (up coming 4.2 rocks), I'm
using it on a daily basis as an AD DC controller, for both Windows and
Linux Instances! With replication, file system ACLs - cifs, built-in LDAP,
dynamic DNS with Bind9 as a backend (no netbios) and etc... Pretty cool!

 In OpenStack ecosystem, there are awesome solutions like Trove, Solum,
Designate and etc... Amazing times BTW! So, why not try to integrate
Samba4, working as an AD DC, within OpenStack itself?!

 If yes, then, what is the best way/approach to achieve this?!

 I mean, for SQL, we have Trove, for iSCSI, Cinder, Nova uses Libvirt...
Don't you guys think that it is time to have an OpenStack project for LDAP
too? And since Samba4 come with it, plus DNS, AD, Kerberos and etc, I think
that it will be huge if we manage to integrate it with OpenStack.

 I think that it would be nice to have, for example: domains, users and
groups management at Horizon, and each tenant with its own Administrator
(not the Keystone global admin) (to mange its Samba4 domains), so, they
will be able to fully manage its own account, while allowing Keystone to
authenticate against these users...

 Also, maybe Designate can have support for it too! I don't know for sure...

 Today, I'm doing this Samba integration manually, I have an external
Samba4, from OpenStack's point of view, then, each tenant/project, have its
own DNS domains, when a instance boots up, I just need to do something like
this (bootstrap):

--
echo 127.0.1.1 instance-1.tenant-1.domain-1.com instance-1  /etc/hosts
net ads join -U administrator
--

 To make this work, the instance just needs to use Samba4 AD DC as its Name
Servers, configured at its /etc/resolv.conf, delivered by DHCP Agent. The
packages `samba-common-bin` and `krb5-user` are also required. Including a
ready to use smb.conf file.

 Then, ping instance-1.tenant-1.domain-1.com worldwide! It works for both
IPv4 and IPv6!!

 Also, Samba4 works okay with Disjoint Namespaces
http://technet.microsoft.com/en-us/library/cc731929(v=ws.10).aspx, so,
each tenant can have one or more domains and subdomains! Like *.
realm.domain.com, *.domain.com, *.cloud-net-1.domain.com, *.domain2.com...
All dynamic managed by Samba4 and Bind9!

 What about that?!

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

Re: [openstack-dev] Time to Samba! :-)

[Martinx - ジェームズ]

I think that it would be great too! OpenLDAP-as-a-Service... With
multi-domain support! :-)

Nevertheless, last time I used Samba, was back in 2001... It is impressive
these days! It worth take a look... I'm using it for about two months now,
it is great!

Cheers!


On 16 August 2014 18:01, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Martinx - ジェームズ's message of 2014-08-16 12:03:20 -0700:
  Hey Stackers,
 
   I'm wondering here... Samba4 is pretty solid (up coming 4.2 rocks), I'm
  using it on a daily basis as an AD DC controller, for both Windows and
  Linux Instances! With replication, file system ACLs - cifs, built-in
 LDAP,
  dynamic DNS with Bind9 as a backend (no netbios) and etc... Pretty cool!
 
   In OpenStack ecosystem, there are awesome solutions like Trove, Solum,
  Designate and etc... Amazing times BTW! So, why not try to integrate
  Samba4, working as an AD DC, within OpenStack itself?!
 

 But, if we did that, what would be left for us to reinvent in our own
 slightly different way?

 ___
 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] Status of Neutron IPv6 dual stack

[Martinx - ジェームズ]

Guys,

Just for the record, I'm using IceHouse in a Dual-Stacked environment (with
security groups working) but, Instance's IPv6 address are static (no
upstream SLAAC, arrived in Juno-2, I think) and the topology is `VLAN
Provider Networks`, no Neutron L3 Router. Where each VLAN have v4/v6 addrs,
same upstream router (also dual-stacked - still no radvd enabled).

Looking forward to start testing L3 + IPv6 in K...

Best,
Thiago


On 16 August 2014 16:21, Harm Weites h...@weites.com wrote:

 Hi Dane,

 Thanks, that looks promising. Once support for multiple v6 addresses on
 gateway ports is added I'll be happy to give this a go. Should it work
 just fine with an otherwise Icehouse based deployment?

 Regards,
 Harm

 op 16-08-14 20:31, Dane Leblanc (leblancd) schreef:
  Hi Harm:
 
  Can you take a look at the following, which should address this:
 
 https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes
 
  There are some diffs out for review for this blueprint:
 https://review.openstack.org/#/c/113339/
  but the change to support 1 V4 + multiple V6 addresses on a gateway port
 hasn't been added yet. I should be adding this soon.
 
  There was a request for a Juno feature freeze exception for this
 blueprint, but there's been no response, so this may not get approved until
 K release.
 
  -Dane
 
  -Original Message-
  From: Harm Weites [mailto:h...@weites.com]
  Sent: Saturday, August 16, 2014 2:22 PM
  To: openstack-dev@lists.openstack.org
  Subject: [openstack-dev] Status of Neutron IPv6 dual stack
 
  Hi,
 
  Given the work on [1] has been abandoned, I'm wondering what the current
 status of going dual stack is. Of course, given Neutron got something like
 that on it's roadmap.
 
  The initial BP [2] aimed for Havana and Icehouse, and I'm unaware of
 something similar to achieve a dual stack network. What are the options, if
 any? To my knowledge it all comes down to supporting multiple exterior
 interfaces (networks) on a l3-agent, which is currently limited to just 1:
 either IP4 or IP6.
 
  [1] https://review.openstack.org/#/c/77471/
  [2]
 
 https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port
 
  Regards,
  Harm
 
  ___
  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

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

Re: [openstack-dev] Time to Samba! :-)

[Martinx - ジェームズ]

I know!   :-P


On 16 August 2014 21:17, Adam Lawson alaw...@aqorn.com wrote:

 Also, don't forget that AD != LDAP. ;)
 On Aug 16, 2014 5:16 PM, Adam Lawson alaw...@aqorn.com wrote:

 Doesn't Murano address this already?
 On Aug 16, 2014 2:35 PM, Martinx - ジェームズ thiagocmarti...@gmail.com
 wrote:

 I think that it would be great too! OpenLDAP-as-a-Service... With
 multi-domain support! :-)

 Nevertheless, last time I used Samba, was back in 2001... It is
 impressive these days! It worth take a look... I'm using it for about two
 months now, it is great!

 Cheers!


 On 16 August 2014 18:01, Clint Byrum cl...@fewbar.com wrote:

 Excerpts from Martinx - ジェームズ's message of 2014-08-16 12:03:20 -0700:
  Hey Stackers,
 
   I'm wondering here... Samba4 is pretty solid (up coming 4.2 rocks),
 I'm
  using it on a daily basis as an AD DC controller, for both Windows and
  Linux Instances! With replication, file system ACLs - cifs, built-in
 LDAP,
  dynamic DNS with Bind9 as a backend (no netbios) and etc... Pretty
 cool!
 
   In OpenStack ecosystem, there are awesome solutions like Trove,
 Solum,
  Designate and etc... Amazing times BTW! So, why not try to integrate
  Samba4, working as an AD DC, within OpenStack itself?!
 

 But, if we did that, what would be left for us to reinvent in our own
 slightly different way?

 ___
 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


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

Re: [openstack-dev] [Neutron] [Spec freeze exception] Support Stateful and Stateless DHCPv6 by dnsmasq

[Martinx - ジェームズ]

Just a note... This is huge!! Great news!! Nevertheless, if Juno comes only
with SLAAC, I'll be very, very happy!;-)

Nice job guys!


On 23 July 2014 01:06, Xu Han Peng pengxu...@gmail.com wrote:

  I would like to request one Juno Spec freeze exception for Support
 Stateful and Stateless DHCPv6 by dnsmasq BP.

 This BP is an important part if IPv6 support in Juno. Router advertisement
 support by RADVD has been merged and this BP is planned for configure
 OpenStack dnsmasq to co-work with router advertisement from either external
 router or OpenStack managed RADVD to get IPv6 network fully functional.
 This BP also supports dnsmasq to work independently for DHCPv6 subnet.
 Without this BP, only SLAAC mode is enabled without any stateful/stateless
 DHCPv6 support.

 The spec is under review:
 https://review.openstack.org/#/c/102411/

 Code change for this BP is submitted as well for a while:
 https://review.openstack.org/#/c/106299/

 Thanks,
 Xu Han

 ___
 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] How to patch Horizon to change Shut Off Instance function?

[Martinx - ジェームズ]

Hello Stackers!

 I need to change the behavior of Shut Off Instance at Horizon, it needs
to gracefully halt the instance via ACPI, instead of just destroying it.

 How can I do that?!

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

Re: [openstack-dev] [Neutron] cloud-init IPv6 support

[Martinx - ジェームズ]

A bit more...


I have OpenStack IceHouse with Trusty up and running, *almost* in an
IPv6-Only environment, *there is only one place* that I'm still using IPv4,
which is:


1- For Metadata Network.


This means that, soon as OpenStack enables Metadata over IPv6, I'll kiss
goodbye IPv4. For real, I can not handle IPv4 networks anymore... So many
NAT tables and overlay networks, that it creeps me out!!  lol


NOTE: I'm using VLAN Provider Networks with static (no support for SLAAC
upstream routers in OpenStack yet) IPv6 address for my tenants, so, I'm not
using GRE/VXLAN tunnels, and that is another place of OpenStack that still
depends on IPv4, for its tunnels...


As I said, everything else is running over IPv6, like RabbitMQ, MySQL,
Keystone, Nova, Glance, Cinder, Neutron (API endpoint), SPICE Consoles and
Servers, the entire Management Network (private IPv6 address space -
fd::/64) and etc... So, why do we need IPv4? I don't remember... :-P

Well, Amazon doesn't support IPv6... Who will be left behind with smelly
IPv4 and ugly VPCs topologies?! Not us.  ;-)

Best!
Thiago


On 7 July 2014 15:50, Ian Wells ijw.ubu...@cack.org.uk wrote:

 On 7 July 2014 11:37, Sean Dague s...@dague.net wrote:

  When it's on a router, it's simpler: use the nexthop, get that metadata
  server.

 Right, but that assumes router control.


 It does, but then that's the current status quo - these things go on
 Neutron routers (and, by extension, are generally not available via
 provider networks).

   In general, anyone doing singlestack v6 at the moment relies on
  config-drive to make it work.  This works fine but it depends what
  cloud-init support your application has.

 I think it's also important to realize that the metadata service isn't
 OpenStack invented, it's an AWS API. Which means I don't think we really
 have the liberty to go changing how it works, especially with something
 like IPv6 support.


 Well, as Amazon doesn't support ipv6 we are the trailblazers here and we
 can do what we please.  If you have a singlestack v6 instance there's no
 compatibility to be maintained with Amazon, because it simply won't work on
 Amazon.  (Also, the format of the metadata server maintains compatibility
 with AWS but I don't think it's strictly AWS any more; the config drive
 certainly isn't.)


 I'm not sure I understand why requiring config-drive isn't ok. In our
 upstream testing it's a ton more reliable than the metadata service due
 to all the crazy networking things it's doing.

 I'd honestly love to see us just deprecate the metadata server.


 The metadata server could potentially have more uses in the future - it's
 possible to get messages out of it, rather than just one time config - but
 yes, the config drive is so much more sensible.  For the server, and once
 you're into Neutron, then you end up with many problems - which interface
 to use, how to get your network config when important details are probably
 on the metadata server itself...

 ___
 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] [Neutron][IPv6] Neutron IPv6 in Icehouse and further

[Martinx - ジェームズ]

Hi! I'm waiting for that too...

Currently, I'm running IceHouse with static IPv6 address, with the topology
VLAN Provider Networks and, to make it easier, I'm counting on the
following blueprint:

https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac

...but, I'm not sure if it will be enough to enable basic IPv6 support
(without using Neutron as Instance's default gateway)...

Cheers!
Thiago


On 26 June 2014 19:35, Maksym Lobur mlo...@mirantis.com wrote:

 Hi Folks,

 Could you please tell what is the current state of IPv6 in Neutron? Does
 it have DHCPv6 working?

 What is the best point to start hacking from? Devstack stable/icehouse or
 maybe some tag? Are there any docs / raw deployment guides?
 I see some patches not landed yet [1] ... I assume it won't work without
 them, right?

 Somehow I can't open any of the code reviews from the [2] (Not Found)

 [1]
 https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:%255E.*%255Cipv6.*,n,z
 [2] https://wiki.openstack.org/wiki/Neutron/IPv6

  Best regards,
 Max Lobur,
 Python Developer, Mirantis, Inc.

 Mobile: +38 (093) 665 14 28
 Skype: max_lobur

 38, Lenina ave. Kharkov, Ukraine
 www.mirantis.com
 www.mirantis.ru

 ___
 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] Missing button to send Ctrl+Alt+Del for SPICE Console

[Martinx - ジェームズ]

Hello Stackers!

I'm using SPICE Consoles now but, there is no button to send Ctrl + Alt +
Del to a Windows Instance, so, it becomes very hard to log in into those
guests...

Can you guys enable it at Horizon?!

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

[openstack-dev] Need help to patch IceHouse to enable emulated sound board.

[Martinx - ジェームズ]

Guys,

Sorry to ask this here but, how can I enable an emulated sound board for
KVM Instances on IceHouse with Ubuntu 14.04?

I already have configured the SPICE Consoles for my Cloud for Desktops
and, the only missing piece of configuration in now the sound device for
Instances (specially Windows Instances).

Can you guys help me?!

I tried here:

https://ask.openstack.org/en/question/27471/how-to-enable-emulated-ich6-sound-board-on-a-kvm-instance-in-icehouse/

...but, no one was able to help me there...

I really appreciate any help!

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

Re: [openstack-dev] [IceHouse][Neutron][Ubuntu 14.04] Error: Failed to delete network

[Martinx - ジェームズ]

Hi Aaron!

The BUG report https://bugs.launchpad.net/neutron/+bug/1322945 is about
this problem, I posted there the instructions to reproduce it...

Basically, after attaching a private IPv6 subnet to your L3 Router, it will
break the External Network and its Floating IPs, then, it becomes
impossible to delete that External Network... It enters in a stuck
state...

Regards,
Thiago


On 27 May 2014 18:34, Aaron Rosen aaronoro...@gmail.com wrote:

 Hi,

 can you open a bug report on this and provide your setup configuration? I
 just tested this with ML2 and wasn't able to reproduce the issue.

 arosen@arosen-MacBookPro:~/devstack$ neutron net-create asdf
  --provider:network_type vlan  --provider:segmentation_id 124
 --provider:physical_network  asdf
 Unable to create the network. The VLAN 124 on physical network asdf is in
 use.

 arosen@arosen-MacBookPro:~/devstack$ neutron net-delete asdf
 Deleted network: asdf

 Thanks,

 Aaron


 On Fri, May 23, 2014 at 10:52 AM, Martinx - ジェームズ 
 thiagocmarti...@gmail.com wrote:

 Guys,

 I'm trying to delete a network in Neutron but it is failing, from Horizon
 it triggers the error message above (subject), and from CLI, it shows this:

 ---
 root@psuaa-1:~# neutron net-delete a1654832-8aac-42d5-8837-6d27b7421892
 Request Failed: internal server error while processing your request.
 ---

 The logs shows:

 ---
 == /var/log/neutron/server.log ==
 2014-05-21 11:49:54.242 5797 INFO neutron.wsgi [-] (5797) accepted
 ('2804:290:4:dead::10', 56908, 0, 0)

 2014-05-21 11:49:54.245 5797 INFO urllib3.connectionpool [-] Starting new
 HTTP connection (1): psuaa-1.mng.tcmc.com.br
 2014-05-21 11:49:54.332 5797 INFO neutron.wsgi
 [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] 2804:290:4:dead::10 - -
 [21/May/2014 11:49:54] GET
 /v2.0/networks.json?fields=idid=a1654832-8aac-42d5-8837-6d27b7421892
 HTTP/1.1 200 251 0.089015

 2014-05-21 11:49:54.334 5797 INFO neutron.wsgi
 [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] (5797) accepted
 ('2804:290:4:dead::10', 56910, 0, 0)

 2014-05-21 11:49:54.380 5797 ERROR neutron.api.v2.resource
 [req-f216416d-8433-444f-9108-f4a17f5bf49d None] delete failed
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource Traceback
 (most recent call last):
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py, line 87, in
 resource
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource result =
 method(request=request, **args)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/api/v2/base.py, line 449, in
 delete
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 obj_deleter(request.context, id, **kwargs)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/plugin.py, line 494,
 in delete_network
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 self.type_manager.release_segment(session, segment)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/managers.py, line
 101, in release_segment
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 driver.obj.release_segment(session, segment)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 AttributeError: 'NoneType' object has no attribute 'obj'
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 2014-05-21 11:49:54.383 5797 INFO neutron.wsgi
 [req-f216416d-8433-444f-9108-f4a17f5bf49d None] 2804:290:4:dead::10 - -
 [21/May/2014 11:49:54] DELETE
 /v2.0/networks/a1654832-8aac-42d5-8837-6d27b7421892.json HTTP/1.1 500 296
 0.048123
 ---

 What can I do to delete a net that doesn't want to be deleted? Do I
 just need to clean some tables directly on mysql, for example... ?

 NOTE: I'm double posting it here on dev list, because on user list no one
 seems to be able to help me... Sorry BTW...   :)

 Tks!
 Thiago

 ___
 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] [IceHouse][Neutron][Ubuntu 14.04] Error: Failed to delete network

[Martinx - ジェームズ]

Guys,

I now how to reproduce this and I filled a BUG report about it, here:

https://bugs.launchpad.net/neutron/+bug/1322945

It seems that a regular user can breaks the Neutron L3 Router, by Adding a
Interface to its Namespace Router, that is attached to a IPv6 private
subnet, it also breaks an admin External Network... Seems to be serious
(I think).

Regards,
Thiago


On 23 May 2014 14:52, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 Guys,

 I'm trying to delete a network in Neutron but it is failing, from Horizon
 it triggers the error message above (subject), and from CLI, it shows this:

 ---
 root@psuaa-1:~# neutron net-delete a1654832-8aac-42d5-8837-6d27b7421892
 Request Failed: internal server error while processing your request.
 ---

 The logs shows:

 ---
 == /var/log/neutron/server.log ==
 2014-05-21 11:49:54.242 5797 INFO neutron.wsgi [-] (5797) accepted
 ('2804:290:4:dead::10', 56908, 0, 0)

 2014-05-21 11:49:54.245 5797 INFO urllib3.connectionpool [-] Starting new
 HTTP connection (1): psuaa-1.mng.tcmc.com.br
 2014-05-21 11:49:54.332 5797 INFO neutron.wsgi
 [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] 2804:290:4:dead::10 - -
 [21/May/2014 11:49:54] GET
 /v2.0/networks.json?fields=idid=a1654832-8aac-42d5-8837-6d27b7421892
 HTTP/1.1 200 251 0.089015

 2014-05-21 11:49:54.334 5797 INFO neutron.wsgi
 [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] (5797) accepted
 ('2804:290:4:dead::10', 56910, 0, 0)

 2014-05-21 11:49:54.380 5797 ERROR neutron.api.v2.resource
 [req-f216416d-8433-444f-9108-f4a17f5bf49d None] delete failed
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource Traceback (most
 recent call last):
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py, line 87, in
 resource
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource result =
 method(request=request, **args)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/api/v2/base.py, line 449, in
 delete
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 obj_deleter(request.context, id, **kwargs)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/plugin.py, line 494,
 in delete_network
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 self.type_manager.release_segment(session, segment)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
 /usr/lib/python2.7/dist-packages/neutron/plugins/ml2/managers.py, line
 101, in release_segment
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 driver.obj.release_segment(session, segment)
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource AttributeError:
 'NoneType' object has no attribute 'obj'
 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
 2014-05-21 11:49:54.383 5797 INFO neutron.wsgi
 [req-f216416d-8433-444f-9108-f4a17f5bf49d None] 2804:290:4:dead::10 - -
 [21/May/2014 11:49:54] DELETE
 /v2.0/networks/a1654832-8aac-42d5-8837-6d27b7421892.json HTTP/1.1 500 296
 0.048123
 ---

 What can I do to delete a net that doesn't want to be deleted? Do I
 just need to clean some tables directly on mysql, for example... ?

 NOTE: I'm double posting it here on dev list, because on user list no one
 seems to be able to help me... Sorry BTW...   :)

 Tks!
 Thiago

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

[openstack-dev] [IceHouse][Neutron][Ubuntu 14.04] Error: Failed to delete network

[Martinx - ジェームズ]

Guys,

I'm trying to delete a network in Neutron but it is failing, from Horizon
it triggers the error message above (subject), and from CLI, it shows this:

---
root@psuaa-1:~# neutron net-delete a1654832-8aac-42d5-8837-6d27b7421892
Request Failed: internal server error while processing your request.
---

The logs shows:

---
== /var/log/neutron/server.log ==
2014-05-21 11:49:54.242 5797 INFO neutron.wsgi [-] (5797) accepted
('2804:290:4:dead::10', 56908, 0, 0)

2014-05-21 11:49:54.245 5797 INFO urllib3.connectionpool [-] Starting new
HTTP connection (1): psuaa-1.mng.tcmc.com.br
2014-05-21 11:49:54.332 5797 INFO neutron.wsgi
[req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] 2804:290:4:dead::10 - -
[21/May/2014 11:49:54] GET
/v2.0/networks.json?fields=idid=a1654832-8aac-42d5-8837-6d27b7421892
HTTP/1.1 200 251 0.089015

2014-05-21 11:49:54.334 5797 INFO neutron.wsgi
[req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] (5797) accepted
('2804:290:4:dead::10', 56910, 0, 0)

2014-05-21 11:49:54.380 5797 ERROR neutron.api.v2.resource
[req-f216416d-8433-444f-9108-f4a17f5bf49d None] delete failed
2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource Traceback (most
recent call last):
2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py, line 87, in
resource
2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource result =
method(request=request, **args)
2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py, line 449, in
delete
2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
obj_deleter(request.context, id, **kwargs)
2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/plugin.py, line 494,
in delete_network
2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
self.type_manager.release_segment(session, segment)
2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/managers.py, line
101, in release_segment
2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
driver.obj.release_segment(session, segment)
2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource AttributeError:
'NoneType' object has no attribute 'obj'
2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
2014-05-21 11:49:54.383 5797 INFO neutron.wsgi
[req-f216416d-8433-444f-9108-f4a17f5bf49d None] 2804:290:4:dead::10 - -
[21/May/2014 11:49:54] DELETE
/v2.0/networks/a1654832-8aac-42d5-8837-6d27b7421892.json HTTP/1.1 500 296
0.048123
---

What can I do to delete a net that doesn't want to be deleted? Do I
just need to clean some tables directly on mysql, for example... ?

NOTE: I'm double posting it here on dev list, because on user list no one
seems to be able to help me... Sorry BTW...   :)

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

Re: [openstack-dev] [Neutron][IPv6] Small feedback about Management Network API Endpoints

[Martinx - ジェームズ]

Guys,

I did a few changes on my environment (OpenStack IceHouse on IPv6),
everything seems to be working smoothly now...

Just deployed Heat on IPv6 too...

I didn't tested Ceilomenter and Cinder Volume (iSCSI traffic) with IPv6
yet...

I'm writing a new Multinode Quick Guide to deploy OpenStack IceHouse on
an (almost) IPv6-Only environment.

Nevertheless, OpenStack still depends on an IPv4-Only networks for
Metadata, for GRE / VXLAN tunnels and for Project Subnets (no Neutron
IPv6 yet), everything else (Management, APIs and Endpoints) seems to be
working with IPv6 (including RabbitMQ, MySQL, Keystone, Nova, Glance,
Neutron (API/Endpoint), Horizon, SPICE Consoles, Heat, Cinder (APIs /
Management (iSCSI not tests with IPv6 yet))...

Soon as I finish the new guide, I'll post it here...

BTW, because of Glance can't use Proxy to download Images, I configured a
NAT64/DNS64 here, so, it can reach the old Internet infrastructure
normally...

Best!
Thiago


On 13 May 2014 03:17, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 Guys,

 I'm running OpenStack IceHouse configured with IPv6 in almost every part
 of it, I can say that both `Management Network` and `API Endpoints` works
 with IPv6, but, there are still only three places that I am unable to use
 it with IPv6, which is:


 1- Metadata (no IPv6 here, the equivalent of 169.254.0.0/16 for IPv6 is
 the subnet fe80::/64, am I right?);

 2- VXLAN / GRE tunnels, precisely at `local_ip` in ml2_conf.ini (it
 doesn't work when with IPv6);

 3- Tenant subnet (IPv6 works with Flat Networks and statically/manually
 configured, no SLAAC and no Neutron L3 with IPv6 yet).


 NOTE: I still did not tested Heat, Cinder or Swift.


 Everything else is working with IPv6!

 Here is a few more details about my environment:

 Controller's /etc/network/interface file:

 ---
 # This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface
 auto lo
 iface lo inet loopback

 # The primary network interface
 #
 # OpenStack API Endpoints
 auto eth0
 iface eth0 inet6 static
 address 2804:29X:Y:dead::10
 netmask 64
 gateway 2804:29X:Y:dead::1
 dns-domain tcmc.com.br
 dns-search tcmc.com.br
 dns-nameservers 2804:29X:4::1 2001:129X:2bX::1

 # OpenStack - Management
 auto eth1
 iface eth1 inet6 static
 address fddc:3c8c:6e8c:b129::10
 netmask 64

 # Legacy - Only required because of Metadata, it doesn't have an IPv6
 # equivalent service for subnet IPv4 = 169.254.0.0/16 (IPv6 = fc80::/64)
 iface eth1 inet static
 address 192.168.5.10
 netmask 24
 ---

 Network Node /etc/network/interfaces file:

 ---
 # This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface.
 auto lo
 iface lo inet loopback

 #
 # Reachable from the Internet.
 #

 # The primary network interface. Node Internet access.
 auto eth0
 iface eth0 inet6 static
 address 2804:29X:Y:dead::20
 netmask 64
  gateway 2804:29X:Y:dead::1
 dns-domain tcmc.com.br
 dns-search tcmc.com.br
 dns-nameservers 2804:290:4::1 2001:1291:2bf::1

 #
 # Unreachable from the Internet.
 #

 # OpenStack - Management
 auto eth1
 iface eth1 inet6 static
 address fddc:3c8c:6e8c:b129::20
 netmask 64

 # Legacy - Only required because of Metadata, it doesn't have an IPv6
 # equivalent service for subnet IPv4 = 169.254.0.0/16 (IPv6 = fc80::/64).
 iface eth1 inet static
 address 192.168.5.20
 netmask 24

 # VXLAN Traffic - Not working right now with IPv6.
 auto eth2
 iface eth2 inet6 static
 address fda2:c917:cd2e:0552::20
 netmask 64

 # Legacy - Only required because Neutron doesn't support VXLAN tunnels on
 top
 # of a IPv6 network.
 iface eth2 inet static
 address 192.168.6.20
 netmask 24

 #
 # Reachable from the Internet only from within each Namespace router.
 #

 # Bridge br-ex attached here, this is the WAN Port of tenant's routers.
 auto eth3
 iface eth3 inet manual
 up ip addr add 0/0 dev eth3
  up ip link set dev $IFACE up
 up ip link set $IFACE promisc on
  up ethtool --offload $IFACE gro off
 down ip link set $IFACE promisc off
  down ip link set $IFACE down
 ---


 Common /etc/hosts file across the Cloud:

 ---
 127.0.0.1   localhost.localdomain   localhost

 # The following lines are desirable for IPv6 capable hosts
 ::1 localhost ip6-localhost ip6-loopback
 ff02::1 ip6-allnodes
 ff02::2 ip6-allrouters

 # OpenStack APIs Endpoints
 2804:29X:Y:dead::10 psuaa-1.tcmc.com.br psuaa-1
 2804:29X:Y:dead::20 psuab-1.tcmc.com.br psuab-1
 2804:29X:Y:dead::30 psuac-1.tcmc.com.br psuac-1
 2804:29X:Y:dead::1000   psuah-1.tcmc.com.br psuah-1

  # OpenStack Management - MySQL, RabbitMQ, SPICE, Glance...
 fddc:3c8c:6e8c:b129::10 psuaa

Re: [openstack-dev] [Neutron][IPv6] Privacy extension

[Martinx - ジェームズ]

Precisely Anthony! We talked about this topic (Non-NAT Floating IPv6)
here, on the following thread:

--
[openstack-dev] [Neutron][IPv6] Idea: Floating IPv6 - Without any kind of
NAT:
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026871.html
--

:-D

About IPv6 Privacy Extensions, well, if it is too hard to implement, I
think that it can be postponed... And only the IPv6 self-generated by SLAAC
and previously calculated by Neutron itself (based on Instance's MAC
address), should be allowed to pass/work for now...

-
 Thiago


On 16 May 2014 12:12, Veiga, Anthony anthony_ve...@cable.comcast.comwrote:

  I’ll take this one a step further.  I think one of the methods for
 getting (non-NAT) floating IPs in IPv6 would be to push a new, extra
 address to the same port.  Either by crafting an extra, unicast RA to the
 specific VM or providing multiple IA_NA fields in the DHCPv6 transaction.
  This would require multiple addresses to be allowed on a single MAC.
 -Anthony

   From: Martinx - ジェームズ thiagocmarti...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: Thursday, May 15, 2014 at 14:18
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron][IPv6] Privacy extension

   Hello!

  I agree that there is no need for Privacy Extensions in a Cloud
 environment, since MAC address are fake... No big deal...

  Nevertheless, I think that should be nice to allow 1 Instance to have
 more than 1 IPv6 addr, since IPv6 is (almost) virtually unlimited... This
 way, a VM with, for example, a range of IPv6s to it, can have a shared host
 environment when each website have its own IPv6 address (I prefer to use
 IP-Based virtualhosts on Apache, instead of Name-Based)...

  Cheers!
 Thiago


 On 15 May 2014 14:22, Ian Wells ijw.ubu...@cack.org.uk wrote:

  I was just about to respond to that in the session when we ran out of
 time.  I would vote for simply insisting that VMs run without the privacy
 extension enabled, and only permitting the expected ipv6 address based on
 MAC.  Its primary purpose is to conceal your MAC address so that your IP
 address can't be used to track you, as I understand it, and I don't think
 that's as relevant in a cloud environment and where the MAC addresses are
 basically fake.  Someone interested in desktop virtualisation with
 Openstack may wish to contradict me...
  --
  Ian.


  On 15 May 2014 09:30, Shixiong Shang sparkofwisdom.cl...@gmail.comwrote:

  Hi, guys:

  Nice to meet with all of you in the technical session and design
 session. I mentioned the challenge of privacy extension in the meeting, but
 would like to hear your opinions of how to address the problem. If you have
 any comments or suggestions, please let me know. I will create a BP for
 this problem.

  Thanks!

  Shixiong


  *Shixiong Shang*

  *!--- Stay Hungry, Stay Foolish ---!*


  ___
 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


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

Re: [openstack-dev] [Neutron][IPv6] Privacy extension

[Martinx - ジェームズ]

Hello!

I agree that there is no need for Privacy Extensions in a Cloud
environment, since MAC address are fake... No big deal...

Nevertheless, I think that should be nice to allow 1 Instance to have more
than 1 IPv6 addr, since IPv6 is (almost) virtually unlimited... This way, a
VM with, for example, a range of IPv6s to it, can have a shared host
environment when each website have its own IPv6 address (I prefer to use
IP-Based virtualhosts on Apache, instead of Name-Based)...

Cheers!
Thiago


On 15 May 2014 14:22, Ian Wells ijw.ubu...@cack.org.uk wrote:

 I was just about to respond to that in the session when we ran out of
 time.  I would vote for simply insisting that VMs run without the privacy
 extension enabled, and only permitting the expected ipv6 address based on
 MAC.  Its primary purpose is to conceal your MAC address so that your IP
 address can't be used to track you, as I understand it, and I don't think
 that's as relevant in a cloud environment and where the MAC addresses are
 basically fake.  Someone interested in desktop virtualisation with
 Openstack may wish to contradict me...
 --
 Ian.


 On 15 May 2014 09:30, Shixiong Shang sparkofwisdom.cl...@gmail.comwrote:

 Hi, guys:

 Nice to meet with all of you in the technical session and design session.
 I mentioned the challenge of privacy extension in the meeting, but would
 like to hear your opinions of how to address the problem. If you have any
 comments or suggestions, please let me know. I will create a BP for this
 problem.

 Thanks!

 Shixiong


  *Shixiong Shang*

  *!--- Stay Hungry, Stay Foolish ---!*


 ___
 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] B203 table 6 for Neutron//Re: SDN NBI Core APIs consumed by OpenStack: Wednesday May 14th at 10:30-11am in the developer lounge at 3rd floor

[Martinx - ジェームズ]

Hello!

This is very an interesting topic!

I would like to talk about one idea I had, which is related to: 1.9. API
for VPN.

I think it would be awesome, for example, when dealing with IPv6-Only
Projects (Tenants) Networks, the VPNs should use `Opportunistic
Encryption`, this way, the VPNs will be established by default without
any user interaction. Then, IPSec VPN for `IPv6 - IPv6` subnets will be
always there, safely interconnecting the subnets, everywhere, even across
different Regions or across different Projects (old Tenants
terminology).

I already started a topic about this but, I'm a bit busy these days... I'll
reply there and I'm drawing a blueprint for it...

Best!
Thiago


On 14 May 2014 12:16, Tina TSOU tina.tsou.zout...@huawei.com wrote:

   Dear all,

  Below is the main conclusion from this meeting.

  We will work on the following SDN NBI Core APIs at the priority per
 Neutron's interest.
 2, 7, 10, 9, 11.

  1.2 APIs for connection between OpenStack Neutron and controller

 OpenStack is widely used and deployed in cloud scenarios.OpenStack-based
 data center is becoming mainstream.

 There should be APIs for connection between SDN controller and OpenStack
 Neutron.



 1.7 APIs for Virtual-Tenant-Network (VTN)

 VTN allows users and developers to design and deploy virtual networks
 without the need to know the physical network. This is very useful in
 data center.

 There should be APIs for virtual tenant network.


  1.10 APIs for QoS

 QoS is usually for end user application. For example, the UC-SDN-Use-Case
 needs the network to guarantee its flow QoS to improve the user’s QoE.

 There should be APIs for QoS.


  1.9 APIs for VPN

 VPN is also widely use in enterprise network, interconnectionbetween data
 centers and mobile environments.

 The management and operation of VPN are necessary. There should be APIs
 for VPN.

 The VPN may include the following type

 L2 VPN

 L3 VPN


  1.11 APIs for network stats/state

 The network stats/state is needed by application so that the application can
 react with the corresponding policy.

 There should be APIs for network stats/state.


  Thank you,
 Tina

 On May 14, 2014, at 10:00 AM, Tina TSOU tina.tsou.zout...@huawei.com
 wrote:

Dear all,

  Place is changed to B203 table 6 for Networking (Neutron), Design Summit
 Pod area.


  Thank you,
 Tina

 On May 13, 2014, at 10:00 PM, Tina TSOU tina.tsou.zout...@huawei.com
 wrote:

   Dear Stackers,



 We are setting up a meeting to SDN NBI Core APIs consumed by OpenStack.
 Attached is the material for your reading pleasure.



 The meeting is planned for:

 *Wednesday May 14th at 10:30-11am in the developer lounge
 at 3rd floor .*

 Look forward to meeting many of you then.





 Thank you,

 Tina



  NBI Core APIs.docx


 ___
 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] [Neutron][IPv6] Small feedback about Management Network API Endpoints

[Martinx - ジェームズ]

Guys,

I'm running OpenStack IceHouse configured with IPv6 in almost every part of
it, I can say that both `Management Network` and `API Endpoints` works with
IPv6, but, there are still only three places that I am unable to use it
with IPv6, which is:


1- Metadata (no IPv6 here, the equivalent of 169.254.0.0/16 for IPv6 is the
subnet fe80::/64, am I right?);

2- VXLAN / GRE tunnels, precisely at `local_ip` in ml2_conf.ini (it doesn't
work when with IPv6);

3- Tenant subnet (IPv6 works with Flat Networks and statically/manually
configured, no SLAAC and no Neutron L3 with IPv6 yet).


NOTE: I still did not tested Heat, Cinder or Swift.


Everything else is working with IPv6!

Here is a few more details about my environment:

Controller's /etc/network/interface file:

---
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
#
# OpenStack API Endpoints
auto eth0
iface eth0 inet6 static
address 2804:29X:Y:dead::10
netmask 64
gateway 2804:29X:Y:dead::1
dns-domain tcmc.com.br
dns-search tcmc.com.br
dns-nameservers 2804:29X:4::1 2001:129X:2bX::1

# OpenStack - Management
auto eth1
iface eth1 inet6 static
address fddc:3c8c:6e8c:b129::10
netmask 64

# Legacy - Only required because of Metadata, it doesn't have an IPv6
# equivalent service for subnet IPv4 = 169.254.0.0/16 (IPv6 = fc80::/64)
iface eth1 inet static
address 192.168.5.10
netmask 24
---

Network Node /etc/network/interfaces file:

---
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface.
auto lo
iface lo inet loopback

#
# Reachable from the Internet.
#

# The primary network interface. Node Internet access.
auto eth0
iface eth0 inet6 static
address 2804:29X:Y:dead::20
netmask 64
 gateway 2804:29X:Y:dead::1
dns-domain tcmc.com.br
dns-search tcmc.com.br
dns-nameservers 2804:290:4::1 2001:1291:2bf::1

#
# Unreachable from the Internet.
#

# OpenStack - Management
auto eth1
iface eth1 inet6 static
address fddc:3c8c:6e8c:b129::20
netmask 64

# Legacy - Only required because of Metadata, it doesn't have an IPv6
# equivalent service for subnet IPv4 = 169.254.0.0/16 (IPv6 = fc80::/64).
iface eth1 inet static
address 192.168.5.20
netmask 24

# VXLAN Traffic - Not working right now with IPv6.
auto eth2
iface eth2 inet6 static
address fda2:c917:cd2e:0552::20
netmask 64

# Legacy - Only required because Neutron doesn't support VXLAN tunnels on
top
# of a IPv6 network.
iface eth2 inet static
address 192.168.6.20
netmask 24

#
# Reachable from the Internet only from within each Namespace router.
#

# Bridge br-ex attached here, this is the WAN Port of tenant's routers.
auto eth3
iface eth3 inet manual
up ip addr add 0/0 dev eth3
 up ip link set dev $IFACE up
up ip link set $IFACE promisc on
 up ethtool --offload $IFACE gro off
down ip link set $IFACE promisc off
 down ip link set $IFACE down
---


Common /etc/hosts file across the Cloud:

---
127.0.0.1   localhost.localdomain   localhost

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

# OpenStack APIs Endpoints
2804:29X:Y:dead::10 psuaa-1.tcmc.com.br psuaa-1
2804:29X:Y:dead::20 psuab-1.tcmc.com.br psuab-1
2804:29X:Y:dead::30 psuac-1.tcmc.com.br psuac-1
2804:29X:Y:dead::1000   psuah-1.tcmc.com.br psuah-1

# OpenStack Management - MySQL, RabbitMQ, SPICE, Glance...
fddc:3c8c:6e8c:b129::10 psuaa-1.mng.tcmc.com.br psuaa-1.mng
fddc:3c8c:6e8c:b129::20 psuab-1.mng.tcmc.com.br psuab-1.mng
fddc:3c8c:6e8c:b129::1000   psuah-1.mng.tcmc.com.br psuah-1.mng

# VXLAN Network - Project's subnet - DOESN'T WORK WITH IPv6
fda2:c917:cd2e:0552::20 psuab-1.vxlan.tcmc.com.br
psuab-1.vxlan
fda2:c917:cd2e:0552::1000   psuah-1.vxlan.tcmc.com.br
psuah-1.vxlan

# Cinder Network - iSCSI Traffic
fd72:3148:4c74:2f60::30 psuac-1.blk.tcmc.com.br psuac-1.blk
fd72:3148:4c74:2f60::1000   psuah-1.blk.tcmc.com.br psuah-1.blk
---

NOTE: Those private IPv6 subnets was generated here:
http://www.simpledns.com/private-ipv6.aspx

Then, for example, I configured `auth_host` under `[keystone_authtoken]`
poiting to `psuaa-1.mng.tcmc.com.br` and `auth_uri` poiting to
`http://psuaa-1.tcmc.com.br:5000`.

But, as I figured out, Metadata doesn't work with IPv6, which means that
`metadata_host / metadata_listen` is configured to `192.168.5.10` at
Controller's nova.conf (it doesn't work when I tried it with `
fddc:3c8c:6e8c:b129::10`) and, at my Network Node, the `local_ip` at
`ml2_conf.ini` points 

Re: [openstack-dev] [Neutron][Nova][Designate][L3][IPv6] Discussion about Cross-Project Integration of DNS at Summit

[Martinx - ジェームズ]

Carl,

Let me ask you something...

If my cloud is IPv6-Only based (that's my intention), which blueprint will
fit on it (internal-dns-resolution or external-dns-resolution) ?

Since IPv6 is all public, don't you think that we (might) need a new
blueprint for IPv6-Only, like just dns-resolution?

BTW, maybe this dns-resolution for IPv6-Only networks (if desired) might
also handle the IPv4 Floating IPs (in a NAT46 fashion)... My plan is to
have IPv4 only at the border (i.e. only at the qg-* interface within the
Namespace router (NAT46 will happen here)), so, the old internet
infrastructure will be able to reach a IPv6-Only project subnet using a
well know FQDN DNS IPv4 entry...

Best!
Thiago


On 29 April 2014 17:09, Carl Baldwin c...@ecbaldwin.net wrote:

 The design summit discussion topic I submitted [1] for my DNS
 blueprints [2][3][4] and this one [5] just missed the cut for the
 design session schedule.  It stung a little to be turned down but I
 totally understand the time and resource constraints that drove the
 decision.

 I feel this is an important subject to discuss because the end result
 will be a better cloud user experience overall.  The design summit
 could be a great time to bring together interested parties from
 Neutron, Nova, and Designate to discuss the integration that I propose
 in these blueprints.

 DNS for IPv6 in Neutron is also something I would like to discuss.
 Mostly, I'd like to get a good sense for where this is at currently
 with the current Neutron dns implementation (dnsmasq) and how it will
 fit in.

 I've created an etherpad to help us coordinate [6].  If you are
 interested, please go there and help me flesh it out.

 Carl Baldwin
 Neutron L3 Subteam

 [1] http://summit.openstack.org/cfp/details/403
 [2] https://blueprints.launchpad.net/neutron/+spec/internal-dns-resolution
 [3] https://blueprints.launchpad.net/nova/+spec/internal-dns-resolution
 [4] https://blueprints.launchpad.net/neutron/+spec/external-dns-resolution
 [5] https://blueprints.launchpad.net/neutron/+spec/dns-subsystem
 [6] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate

 ___
 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] [Neutron][Nova][Designate][L3][IPv6] Discussion about Cross-Project Integration of DNS at Summit

[Martinx - ジェームズ]

I'll be an alpha / beta tester, for sure!!   :-D

I'm very interested on DNS for IPv6 in Neutron (and in Horizon too)... Hope
to see it in Juno!!

IPv6 (with a perfect DNS setup) is very important...

Best!
Thiago

On 29 April 2014 17:09, Carl Baldwin c...@ecbaldwin.net wrote:

 The design summit discussion topic I submitted [1] for my DNS
 blueprints [2][3][4] and this one [5] just missed the cut for the
 design session schedule.  It stung a little to be turned down but I
 totally understand the time and resource constraints that drove the
 decision.

 I feel this is an important subject to discuss because the end result
 will be a better cloud user experience overall.  The design summit
 could be a great time to bring together interested parties from
 Neutron, Nova, and Designate to discuss the integration that I propose
 in these blueprints.

 DNS for IPv6 in Neutron is also something I would like to discuss.
 Mostly, I'd like to get a good sense for where this is at currently
 with the current Neutron dns implementation (dnsmasq) and how it will
 fit in.

 I've created an etherpad to help us coordinate [6].  If you are
 interested, please go there and help me flesh it out.

 Carl Baldwin
 Neutron L3 Subteam

 [1] http://summit.openstack.org/cfp/details/403
 [2] https://blueprints.launchpad.net/neutron/+spec/internal-dns-resolution
 [3] https://blueprints.launchpad.net/nova/+spec/internal-dns-resolution
 [4] https://blueprints.launchpad.net/neutron/+spec/external-dns-resolution
 [5] https://blueprints.launchpad.net/neutron/+spec/dns-subsystem
 [6] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate

 ___
 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] [NEUTRON] [IPv6] [VPNaaS] - IPSec by default on each Tenant router, the beginning of the Opportunistic Encryption era (rfc4322 ?)...

[Martinx - ジェームズ]

Guys,

I here thinking about IPSec when with IPv6 and, one of the first
ideas/wishes of IPv6 scientists, was to always deploy it with IPSec
enabled, always (I've heard). But, this isn't well diffused by now. Who is
actually using IPv6 Opportunistic Encryption?!

For example: With O.E., we'll be able to make a IPv6 IPSec VPN with Google,
so we can ping6 google.com safely... Or with Twitter, Facebook! Or
whatever! That is the purpose of Opportunistic Encryption, am I right?!

Then, with OpenStack, we might have a muiti-Region or even a multi-AZ
cloud, based on the topology Per-Tenant Routers with Private Networks,
for example, so, how hard it will be to deploy the Namespace routers with
IPv6+IPSec O.E. just enabled by default?

I'm thinking about this:


* IPv6 Tenant 1 subnet A - IPv6 Router + IPSec O.E. - *Internet
IPv6* - IPv6 Router + IPSec O.E. - IPv6 Tenant 1 subnet B


So, with O.E., it will be simpler (from the tenant's point of view) to
safely interconnect multiple tenant's subnets, don't you guys think?!

Amazon in the other hand, for example, provides things like VPC Peering,
or VPN Instances, or NAT instances, as a solution to interconnect
creepy IPv4 networks... We don't need none of this kind of solutions when
with IPv6... Right?!

Basically, the OpenStack VPNaaS (O.E.) will come enabled at the Namespace
Router by default, without the tenant even knowing it is there, but of
course, we can still show that IPv6-IPSec-VPN at the Horizon Dashboard,
when established, just for fun... But tenants will never need to think
about it...   =)

And to share the IPSec keys, the stuff required for Opportunistic
Encryption to gracefully works, each OpenStack in the wild, can become a
*pod*, which will form a network of *pods*, I mean, independently owned
*pods* which interoperate to form the *Opportunistic Encrypt Network of
OpenStack Clouds*.

I'll try to make a comparison here, as an analogy, do you guys have ever
heard about the DIASPORA* Project? No, take a look:
http://en.wikipedia.org/wiki/Diaspora_(social_network)

I think that, OpenStack might be for the Opportunistic Encryption, what
DIASPORA* Project is for Social Networks!

If OpenStack can share its keys (O.E. stuff) in someway, with each other,
we can easily build a huge network of OpenStacks, and then, each one will
naturally talk with each other, using a secure connection.

I would love to hear some insights from you guys!

Please, keep in mind that I never deployed a IPSec O.E. before, this is
just an idea I had... If I'm wrong, ignore this e-mail.


References:

https://tools.ietf.org/html/rfc4322

https://groups.google.com/d/msg/ipv6hackers/3LCTBJtr-eE/Om01uHUcf9UJ

http://www.inrialpes.fr/planete/people/chneuman/OE.html


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

Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

BTW, the VNC Consoles are now working in a Dual-Stacked fashion (both
vncserver 5900 and novncproxy 6080 traffics goes via IPv6). ;-)

Guide updated...

Cheers!
Thiago

On 15 April 2014 19:57, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 Hello Stackers!

 I just finished the OpenStack IPv6 Quick Guide, it is hosted here:


 Ultimate OpenStack IceHouse Guide - ML2 Flat Network - IPv6-Friendly:

 https://gist.github.com/tmartinx/9177697


 Almost everything is working with IPv6, including OpenStack Management
 (APIs / Endpoints) and, of course, the Instances. Only NoVNC (TCP port
 6080) and Metadata isn't working with IPv6 (yet).

 Also, the IPv6 configuration is static, no auto-configuration right now.

 My idea is to enable SLAAC on this environment, so, there will be no need
 for static IPs and manual intervention. I think we're almost there! What do
 you guys think?

 BTW, sorry about tons of e-mails I sent before, I'll not do that again.

 Cheers!
 Thiago


 On 12 April 2014 04:09, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 BTW, I think that the following patches are also important / relevant to
 begin with:

 ---
 4. Two Attributes Proposal to Control IPv6 RA Announcement and Address
 Assignment
https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes
Patchset: Create new IPv6 attributes for Subnets.
 https://review.openstack.org/#/c/52983/
Patchset: Add support to DHCP agent for BP ipv6-two-attributes.
 https://review.openstack.org/70649
Patchset: Calculate stateless IPv6 address.
 https://review.openstack.org/56184
Patchset: Permit ICMPv6 RAs only from known routers.
 https://review.openstack.org/#/c/72252/
 ...
 8. Provider Networking - upstream SLAAC support
 https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac
Patchset: Ensure that that all fixed ips for a port belong to a
 subnet using DHCP. https://review.openstack.org/#/c/64578/
 ---

 But I'm not sure about the easiest path we can follow... From what I'm
 seeing, Neutron just needs to calculate Instance's IPv6 address based on
 SLAAC, then Instance's IPv6 address will match (Neutron - upstream
 SLAAC), in the end of the day.

 Also, review 72252 is very important!

 Regards,
 Thiago


 On 12 April 2014 01:34, Martinx - ジェームズ thiagocmarti...@gmail.comwrote:

 Cool! Instance shows an IPv6 address and it clearly isn't generated by
 EUI-64 (SLAAC) but, at least, I can use static IPv6!  YAY!

 ---
 root@controller:~# nova list

 +--+--+++-+---+
 | ID   | Name | Status | Task State
 | Power State | Networks  |

 +--+--+++-+---+
 | 1654644d-6d52-4760-b147-4b88769a6fc2 | trusty-2 | ACTIVE | -
  | Running | sharednet1=10.33.14.23, 2001:1291:2bf:fffb::3 |

 +--+--+++-+---+

 root@controller:~# ssh -i ~/xxx.pem ubuntu@10.33.14.23

 ubuntu@trusty-2:~$ sudo ip -6 a a 2001:1291:2bf:fffb::3/64 dev eth0

 ubuntu@trusty-2:~$ sudo ip -6 r a default via 2001:1291:2bf:fffb::1

 ubuntu@trusty-2:~$ ping6 -c 1 google.com
 PING google.com(2800:3f0:4004:801::100e) 56 data bytes
 64 bytes from 2800:3f0:4004:801::100e: icmp_seq=1 ttl=54 time=49.6 ms

 --- google.com ping statistics ---
 1 packets transmitted, 1 received, 0% packet loss, time 0ms
 rtt min/avg/max/mdev = 49.646/49.646/49.646/0.000 ms
 ---

 IPv6 up and running and OpenStack is aware of both IPv4 and IPv6
 instance's addresses! Security Group is also taking care of ip6tables.

 I'm pretty sure that if I start radvd on upstream router right now, all
 instances will generate its own IPv6 based on their respective MAC address.
 But then, the IPv6 will differ from what OpenStack thinks that each
 instance have.

 So many e-mails, sorry BTW! :-P

 Best,
 Thiago

 On 12 April 2014 01:11, Martinx - ジェームズ thiagocmarti...@gmail.comwrote:

 In fact, neutron accepted the following command:

 ---
 root@controller:~# neutron subnet-create --ip-version 6 --disable-dhcp
 --tenant-id 5e0106fa81104c5cbe21e1ccc9eb1a36 sharednet1
 2001:1291:2bf:fffb::/64
 Created a new subnet:

 +--+-+
 | Field| Value
   |

 +--+-+
 | allocation_pools | {start: 2001:1291:2bf:fffb::2, end:
 2001:1291:2bf:fffb::::fffe} |
 | cidr | 2001:1291:2bf:fffb::/64
   |
 | dns_nameservers  |
   |
 | enable_dhcp  | False

Re: [openstack-dev] [Devstack] [IPv6]

[Martinx - ジェームズ]

Awesome!! I'll check this today! Tks!


On 16 April 2014 12:03, Robert Li (baoli) ba...@cisco.com wrote:

 Hi folks,

 If you want to use IPv6 with devstack, Check this out
 https://review.openstack.org/87987. The commit message has all the details
 on how to use it.

 thanks,
 Robert


 ___
 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] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

Hello Stackers!

I just finished the OpenStack IPv6 Quick Guide, it is hosted here:


Ultimate OpenStack IceHouse Guide - ML2 Flat Network - IPv6-Friendly:

https://gist.github.com/tmartinx/9177697


Almost everything is working with IPv6, including OpenStack Management
(APIs / Endpoints) and, of course, the Instances. Only NoVNC (TCP port
6080) and Metadata isn't working with IPv6 (yet).

Also, the IPv6 configuration is static, no auto-configuration right now.

My idea is to enable SLAAC on this environment, so, there will be no need
for static IPs and manual intervention. I think we're almost there! What do
you guys think?

BTW, sorry about tons of e-mails I sent before, I'll not do that again.

Cheers!
Thiago


On 12 April 2014 04:09, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 BTW, I think that the following patches are also important / relevant to
 begin with:

 ---
 4. Two Attributes Proposal to Control IPv6 RA Announcement and Address
 Assignment
https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes
Patchset: Create new IPv6 attributes for Subnets.
 https://review.openstack.org/#/c/52983/
Patchset: Add support to DHCP agent for BP ipv6-two-attributes.
 https://review.openstack.org/70649
Patchset: Calculate stateless IPv6 address.
 https://review.openstack.org/56184
Patchset: Permit ICMPv6 RAs only from known routers.
 https://review.openstack.org/#/c/72252/
 ...
 8. Provider Networking - upstream SLAAC support
 https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac
Patchset: Ensure that that all fixed ips for a port belong to a
 subnet using DHCP. https://review.openstack.org/#/c/64578/
 ---

 But I'm not sure about the easiest path we can follow... From what I'm
 seeing, Neutron just needs to calculate Instance's IPv6 address based on
 SLAAC, then Instance's IPv6 address will match (Neutron - upstream
 SLAAC), in the end of the day.

 Also, review 72252 is very important!

 Regards,
 Thiago


 On 12 April 2014 01:34, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 Cool! Instance shows an IPv6 address and it clearly isn't generated by
 EUI-64 (SLAAC) but, at least, I can use static IPv6!  YAY!

 ---
 root@controller:~# nova list

 +--+--+++-+---+
 | ID   | Name | Status | Task State |
 Power State | Networks  |

 +--+--+++-+---+
 | 1654644d-6d52-4760-b147-4b88769a6fc2 | trusty-2 | ACTIVE | -  |
 Running | sharednet1=10.33.14.23, 2001:1291:2bf:fffb::3 |

 +--+--+++-+---+

 root@controller:~# ssh -i ~/xxx.pem ubuntu@10.33.14.23

 ubuntu@trusty-2:~$ sudo ip -6 a a 2001:1291:2bf:fffb::3/64 dev eth0

 ubuntu@trusty-2:~$ sudo ip -6 r a default via 2001:1291:2bf:fffb::1

 ubuntu@trusty-2:~$ ping6 -c 1 google.com
 PING google.com(2800:3f0:4004:801::100e) 56 data bytes
 64 bytes from 2800:3f0:4004:801::100e: icmp_seq=1 ttl=54 time=49.6 ms

 --- google.com ping statistics ---
 1 packets transmitted, 1 received, 0% packet loss, time 0ms
 rtt min/avg/max/mdev = 49.646/49.646/49.646/0.000 ms
 ---

 IPv6 up and running and OpenStack is aware of both IPv4 and IPv6
 instance's addresses! Security Group is also taking care of ip6tables.

 I'm pretty sure that if I start radvd on upstream router right now, all
 instances will generate its own IPv6 based on their respective MAC address.
 But then, the IPv6 will differ from what OpenStack thinks that each
 instance have.

 So many e-mails, sorry BTW! :-P

 Best,
 Thiago

 On 12 April 2014 01:11, Martinx - ジェームズ thiagocmarti...@gmail.comwrote:

 In fact, neutron accepted the following command:

 ---
 root@controller:~# neutron subnet-create --ip-version 6 --disable-dhcp
 --tenant-id 5e0106fa81104c5cbe21e1ccc9eb1a36 sharednet1
 2001:1291:2bf:fffb::/64
 Created a new subnet:

 +--+-+
 | Field| Value
 |

 +--+-+
 | allocation_pools | {start: 2001:1291:2bf:fffb::2, end:
 2001:1291:2bf:fffb::::fffe} |
 | cidr | 2001:1291:2bf:fffb::/64
 |
 | dns_nameservers  |
 |
 | enable_dhcp  | False
 |
 | gateway_ip   | 2001:1291:2bf:fffb::1
 |
 | host_routes  |
 |
 | id   | 8685c917-e8df-4741-987c-6a531dca9fcd

Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

BTW, I think that the following patches are also important / relevant to
begin with:

---
4. Two Attributes Proposal to Control IPv6 RA Announcement and Address
Assignment
   https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes
   Patchset: Create new IPv6 attributes for Subnets.
https://review.openstack.org/#/c/52983/
   Patchset: Add support to DHCP agent for BP ipv6-two-attributes.
https://review.openstack.org/70649
   Patchset: Calculate stateless IPv6 address.
https://review.openstack.org/56184
   Patchset: Permit ICMPv6 RAs only from known routers.
https://review.openstack.org/#/c/72252/
...
8. Provider Networking - upstream SLAAC support
https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac
   Patchset: Ensure that that all fixed ips for a port belong to a
subnet using DHCP. https://review.openstack.org/#/c/64578/
---

But I'm not sure about the easiest path we can follow... From what I'm
seeing, Neutron just needs to calculate Instance's IPv6 address based on
SLAAC, then Instance's IPv6 address will match (Neutron - upstream
SLAAC), in the end of the day.

Also, review 72252 is very important!

Regards,
Thiago


On 12 April 2014 01:34, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 Cool! Instance shows an IPv6 address and it clearly isn't generated by
 EUI-64 (SLAAC) but, at least, I can use static IPv6!  YAY!

 ---
 root@controller:~# nova list

 +--+--+++-+---+
 | ID   | Name | Status | Task State |
 Power State | Networks  |

 +--+--+++-+---+
 | 1654644d-6d52-4760-b147-4b88769a6fc2 | trusty-2 | ACTIVE | -  |
 Running | sharednet1=10.33.14.23, 2001:1291:2bf:fffb::3 |

 +--+--+++-+---+

 root@controller:~# ssh -i ~/xxx.pem ubuntu@10.33.14.23

 ubuntu@trusty-2:~$ sudo ip -6 a a 2001:1291:2bf:fffb::3/64 dev eth0

 ubuntu@trusty-2:~$ sudo ip -6 r a default via 2001:1291:2bf:fffb::1

 ubuntu@trusty-2:~$ ping6 -c 1 google.com
 PING google.com(2800:3f0:4004:801::100e) 56 data bytes
 64 bytes from 2800:3f0:4004:801::100e: icmp_seq=1 ttl=54 time=49.6 ms

 --- google.com ping statistics ---
 1 packets transmitted, 1 received, 0% packet loss, time 0ms
 rtt min/avg/max/mdev = 49.646/49.646/49.646/0.000 ms
 ---

 IPv6 up and running and OpenStack is aware of both IPv4 and IPv6
 instance's addresses! Security Group is also taking care of ip6tables.

 I'm pretty sure that if I start radvd on upstream router right now, all
 instances will generate its own IPv6 based on their respective MAC address.
 But then, the IPv6 will differ from what OpenStack thinks that each
 instance have.

 So many e-mails, sorry BTW! :-P

 Best,
 Thiago

 On 12 April 2014 01:11, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 In fact, neutron accepted the following command:

 ---
 root@controller:~# neutron subnet-create --ip-version 6 --disable-dhcp
 --tenant-id 5e0106fa81104c5cbe21e1ccc9eb1a36 sharednet1
 2001:1291:2bf:fffb::/64
 Created a new subnet:

 +--+-+
 | Field| Value
 |

 +--+-+
 | allocation_pools | {start: 2001:1291:2bf:fffb::2, end:
 2001:1291:2bf:fffb::::fffe} |
 | cidr | 2001:1291:2bf:fffb::/64
 |
 | dns_nameservers  |
 |
 | enable_dhcp  | False
 |
 | gateway_ip   | 2001:1291:2bf:fffb::1
 |
 | host_routes  |
 |
 | id   | 8685c917-e8df-4741-987c-6a531dca9fcd
|
 | ip_version   | 6
 |
 | name |
 |
 | network_id   | 17cda0fb-a59b-4a7e-9d96-76d0670bc95c
|
 | tenant_id| 5e0106fa81104c5cbe21e1ccc9eb1a36
|

 +--+-+
 ---

 Where gateway_ip 2001:1291:2bf:fffb::1 is my upstream SLAAC router
 (radvd stopped for now).

 Diving: I think I'll put my OVS bridge br-eth0 (bridge_mappings =
 physnet1:br-eth0) on top of a VLAN but, I'll not tell OpenStack to use
 vlan, I'll keep using flat but, on top of a hidden vlan... eheh   :-P

 I'll keep testing to see how far I can go...:-)

 Cheers!


 On 12 April 2014 00:42, Martinx

Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

Hey Thomas!

That's an amazing list!   :-D

Okay, I'll drop by on IRC anytime soon to chat with you guys, tk for the
invite!

About DHCPv6 support, yes, I agree with you, it can be postponed (in fact,
I don't think I'll ever use it). Radvd should be enough for me.

I think that we need to start with the simplest configuration possible,
that I think it is this one:


8- Provider Networking - upstream SLAAC support:
https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac


Please, Collins, can you confirm this for us: is this above blueprint the
easiest to achieve (or almost)?! If not, which one is closest to be ready
for tests?!

Nevertheless, from what I'm seeing, that this is, in fact, the simplest
blueprint / topology we can start testing, so, I'm finishing a Quick
Guide for our tests (more commits to it comming - cleanup). It perfect
fits into the proposed blueprint topology, which is upstream router (no
L3, no gre/vxlan tunnels, no Floating IPs, no NAT even for IPv4)...


Here it is:

Ultimate OpenStack IceHouse Guide - IPv6-Friednly:
https://gist.github.com/tmartinx/9177697


My current plan is, if you guys can read this page (not all of it) for a
moment, at the step 5.2.1. Creating the Flat Neutron Network, I would
like to do, basically this:

neutron subnet-create --ip-version 6 --tenant-id $ADMIN_TENANT_ID
sharednet1 2001:db8:1:1::/64 --dns_nameservers list=true
2001:4860:4860::8844 2001:4860:4860::

...Into that Simple Flat Network Right after applying the patch for
upstream SLAAC / ipv6-provider-nets-slaac at the IceHouse lab I have, it
is up and running now. You guys can easily replicated it with 3 KVM Virtual
Machines (1 gateway (dual-stacked) / 1 controller / 1 compute).

BTW, which extra options for subnet-create, the blueprint
ipv6-provider-nets-slaac covers, if any?

--ipv6_ra_mode XXX --ipv6_address_mode YYY ?

Here at my lab, my upstream SLAAC already have radvd ready, IPv6
connectivity okay and etc, I think I have everything ready to start testing
it.

Cheers!
Thiago


On 11 April 2014 03:26, Thomas Goirand z...@debian.org wrote:

 On 04/08/2014 03:10 AM, Martinx - ジェ�`ムズ wrote:
  Hi Thomas!
 
  It will be a honor for me to join Debian OpenStack packaging team! I'm
  in!! :-D
 
  Listen, that neutron-ipv6.patch I have, doesn't apply against
  neutron-2014.1.rc1, here is it:
 
  neutron-ipv6.patch: http://paste.openstack.org/show/74857/
 
  I generated it from the commands that Xuhan Peng told me to do, few
  posts back, which are:
 
  --
  git fetch https://review.openstack.org/openstack/neutron
  refs/changes/49/70649/15
  git format-patch -1 --stdout FETCH_HEAD  neutron-ipv6.patch
  --
 
  But, as Collins said, even if the patch applies successfully against
  neutron-2014.1.rc1 (or newer), it will not pass the tests, so, there is
  still a lot of work to do, to enable Neutron with IPv6 but, I think we
  can start working on this patches and start testing whatever is already
  there (related to IPv6).
 
  Best!
  Thiago

 Hi Thiago,

 It's my view that we'd better keep each patch separated, so that they
 can evolve over time, as they are accepted or fixed in
 review.openstack.org. On the Debian packaging I do, each and every patch
 has to comply with the DEP3 patch header specifications [1].
 Specifically, I do insist that the Origin: field is set with the
 correct gerrit review URL, so that we can easily find out which patch
 comes from where. The Last-Update field is also important, so we know
 which version of the patch is in.

 Also, at eNovance, we are currently in the process of selecting which
 patch should get in, and which patch shouldn't. Currently, we are
 tracking the below patches:

 1. Support IPv6 SLAAC mode in dnsmasq
 https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac
Patchset: Add support to DHCP agent for BP ipv6-two-attributes:
 https://review.openstack.org/#/c/70649/

 2. Bind dnsmasq in qrouter- namespace.

 https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace
Patchset: Add support to DHCP agent for BP ipv6-two-attributes:
 https://review.openstack.org/#/c/70649/

 3. IPv6 Feature Parity
 https://blueprints.launchpad.net/neutron/+spec/ipv6-feature-parity
Definition: Superseded.

 4. Two Attributes Proposal to Control IPv6 RA Announcement and Address
 Assignment
https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes
Patchset: Create new IPv6 attributes for Subnets.
 https://review.openstack.org/#/c/52983/
Patchset: Add support to DHCP agent for BP ipv6-two-attributes.
 https://review.openstack.org/70649
Patchset: Calculate stateless IPv6 address.
 https://review.openstack.org/56184
Patchset: Permit ICMPv6 RAs only from known routers.
 https://review.openstack.org/#/c/72252/

 5. Support IPv6 DHCPv6 Stateless mode in dnsmasq

 https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless
Patchset: Add support to DHCP agent for BP 

Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

Hey guys!

My OpenStack Instance have IPv6 connectivity! Using ML2 / Simple Flat
Network... For the first time ever! Look:

---
administrative@controller:~$ nova boot --image
70f335e3-798b-4031-9773-a640970a8bdf --key-name Key trusty-1

administrative@controller:~$ ssh -i ~/test.pem ubuntu@10.33.14.21

ubuntu@trusty-1:~$ sudo ip -6 a a 2001:1291:2bf:fffb::300/64 dev eth0

ubuntu@trusty-1:~$ sudo ip -6 r a default via 2001:1291:2bf:fffb::1

ubuntu@trusty-1:~$ ping6 -c 1 google.com

PING google.com(2800:3f0:4004:801::1000) 56 data bytes
64 bytes from 2800:3f0:4004:801::1000: icmp_seq=1 ttl=54 time=55.1 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 55.121/55.121/55.121/0.000 ms

-
# From my Laptop (and from another IPv6 block):
testuser@macbuntu:~$ telnet 2001:1291:2bf:fffb::300 22
Trying 2001:1291:2bf:fffb::300...
Connected to 2001:1291:2bf:fffb::300.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.6p1 Ubuntu-2
---

But, OpenStack / Neutron isn't aware of that fixed IPv6 (
2001:1291:2bf:fffb::300) I just configured within the trusty-1 Instance,
so, I think we just need:

- Blueprint ipv6-provider-nets-slaac ready;
- Start radvd on upstream router (2001:1291:2bf:fffb::1).

Am I right?!

In fact, apparently, Security Groups is also working! I can ssh into
trusty-1 through IPv6 right now, but can't access port 80 of it (it is
closed buy 22 is open to the world)...

Maybe it will also work with VLANs...

BTW, I just realized that both the physical servers, controllers, networks
and compute nodes and etc, can be installed under a single IPv6 /64 subnet!
Since the openstack will random generate the MAC address (plus SLAAC),
IPv6s will never conflict.

Best!
Thiago


On 12 April 2014 00:09, Thomas Goirand z...@debian.org wrote:

 On 04/11/2014 10:52 PM, Collins, Sean wrote:
  Many of those patches are stale - please join us in the subteam IRC
  meeting if you wish to coordinate development of IPv6 features, so that
  we can focus on updating them and getting them merged. At this point
  simply applying them to the Icehouse tree is not enough.

 When and where is the next meeting?

 Thomas


 ___
 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] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

In fact, neutron accepted the following command:

---
root@controller:~# neutron subnet-create --ip-version 6 --disable-dhcp
--tenant-id 5e0106fa81104c5cbe21e1ccc9eb1a36 sharednet1
2001:1291:2bf:fffb::/64
Created a new subnet:
+--+-+
| Field| Value
  |
+--+-+
| allocation_pools | {start: 2001:1291:2bf:fffb::2, end:
2001:1291:2bf:fffb::::fffe} |
| cidr | 2001:1291:2bf:fffb::/64
  |
| dns_nameservers  |
  |
| enable_dhcp  | False
  |
| gateway_ip   | 2001:1291:2bf:fffb::1
  |
| host_routes  |
  |
| id   | 8685c917-e8df-4741-987c-6a531dca9fcd
 |
| ip_version   | 6
  |
| name |
  |
| network_id   | 17cda0fb-a59b-4a7e-9d96-76d0670bc95c
 |
| tenant_id| 5e0106fa81104c5cbe21e1ccc9eb1a36
 |
+--+-+
---

Where gateway_ip 2001:1291:2bf:fffb::1 is my upstream SLAAC router
(radvd stopped for now).

Diving: I think I'll put my OVS bridge br-eth0 (bridge_mappings =
physnet1:br-eth0) on top of a VLAN but, I'll not tell OpenStack to use
vlan, I'll keep using flat but, on top of a hidden vlan... eheh   :-P

I'll keep testing to see how far I can go...:-)

Cheers!


On 12 April 2014 00:42, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 Hey guys!

 My OpenStack Instance have IPv6 connectivity! Using ML2 / Simple Flat
 Network... For the first time ever! Look:

 ---
 administrative@controller:~$ nova boot --image
 70f335e3-798b-4031-9773-a640970a8bdf --key-name Key trusty-1

 administrative@controller:~$ ssh -i ~/test.pem ubuntu@10.33.14.21

 ubuntu@trusty-1:~$ sudo ip -6 a a 2001:1291:2bf:fffb::300/64 dev eth0

 ubuntu@trusty-1:~$ sudo ip -6 r a default via 2001:1291:2bf:fffb::1

 ubuntu@trusty-1:~$ ping6 -c 1 google.com

 PING google.com(2800:3f0:4004:801::1000) 56 data bytes
 64 bytes from 2800:3f0:4004:801::1000: icmp_seq=1 ttl=54 time=55.1 ms

 --- google.com ping statistics ---
 1 packets transmitted, 1 received, 0% packet loss, time 0ms
 rtt min/avg/max/mdev = 55.121/55.121/55.121/0.000 ms

 -
 # From my Laptop (and from another IPv6 block):
 testuser@macbuntu:~$ telnet 2001:1291:2bf:fffb::300 22
 Trying 2001:1291:2bf:fffb::300...
 Connected to 2001:1291:2bf:fffb::300.
 Escape character is '^]'.
 SSH-2.0-OpenSSH_6.6p1 Ubuntu-2
 ---

 But, OpenStack / Neutron isn't aware of that fixed IPv6 (
 2001:1291:2bf:fffb::300) I just configured within the trusty-1 Instance,
 so, I think we just need:

 - Blueprint ipv6-provider-nets-slaac ready;
 - Start radvd on upstream router (2001:1291:2bf:fffb::1).

 Am I right?!

 In fact, apparently, Security Groups is also working! I can ssh into
 trusty-1 through IPv6 right now, but can't access port 80 of it (it is
 closed buy 22 is open to the world)...

 Maybe it will also work with VLANs...

 BTW, I just realized that both the physical servers, controllers, networks
 and compute nodes and etc, can be installed under a single IPv6 /64 subnet!
 Since the openstack will random generate the MAC address (plus SLAAC),
 IPv6s will never conflict.

 Best!
 Thiago


 On 12 April 2014 00:09, Thomas Goirand z...@debian.org wrote:

 On 04/11/2014 10:52 PM, Collins, Sean wrote:
  Many of those patches are stale - please join us in the subteam IRC
  meeting if you wish to coordinate development of IPv6 features, so that
  we can focus on updating them and getting them merged. At this point
  simply applying them to the Icehouse tree is not enough.

 When and where is the next meeting?

 Thomas


 ___
 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] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

Cool! Instance shows an IPv6 address and it clearly isn't generated by
EUI-64 (SLAAC) but, at least, I can use static IPv6!  YAY!

---
root@controller:~# nova list
+--+--+++-+---+
| ID   | Name | Status | Task State |
Power State | Networks  |
+--+--+++-+---+
| 1654644d-6d52-4760-b147-4b88769a6fc2 | trusty-2 | ACTIVE | -  |
Running | sharednet1=10.33.14.23, 2001:1291:2bf:fffb::3 |
+--+--+++-+---+

root@controller:~# ssh -i ~/xxx.pem ubuntu@10.33.14.23

ubuntu@trusty-2:~$ sudo ip -6 a a 2001:1291:2bf:fffb::3/64 dev eth0

ubuntu@trusty-2:~$ sudo ip -6 r a default via 2001:1291:2bf:fffb::1

ubuntu@trusty-2:~$ ping6 -c 1 google.com
PING google.com(2800:3f0:4004:801::100e) 56 data bytes
64 bytes from 2800:3f0:4004:801::100e: icmp_seq=1 ttl=54 time=49.6 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 49.646/49.646/49.646/0.000 ms
---

IPv6 up and running and OpenStack is aware of both IPv4 and IPv6 instance's
addresses! Security Group is also taking care of ip6tables.

I'm pretty sure that if I start radvd on upstream router right now, all
instances will generate its own IPv6 based on their respective MAC address.
But then, the IPv6 will differ from what OpenStack thinks that each
instance have.

So many e-mails, sorry BTW! :-P

Best,
Thiago

On 12 April 2014 01:11, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 In fact, neutron accepted the following command:

 ---
 root@controller:~# neutron subnet-create --ip-version 6 --disable-dhcp
 --tenant-id 5e0106fa81104c5cbe21e1ccc9eb1a36 sharednet1
 2001:1291:2bf:fffb::/64
 Created a new subnet:

 +--+-+
 | Field| Value
   |

 +--+-+
 | allocation_pools | {start: 2001:1291:2bf:fffb::2, end:
 2001:1291:2bf:fffb::::fffe} |
 | cidr | 2001:1291:2bf:fffb::/64
   |
 | dns_nameservers  |
   |
 | enable_dhcp  | False
   |
 | gateway_ip   | 2001:1291:2bf:fffb::1
   |
 | host_routes  |
   |
 | id   | 8685c917-e8df-4741-987c-6a531dca9fcd
|
 | ip_version   | 6
   |
 | name |
   |
 | network_id   | 17cda0fb-a59b-4a7e-9d96-76d0670bc95c
|
 | tenant_id| 5e0106fa81104c5cbe21e1ccc9eb1a36
|

 +--+-+
 ---

 Where gateway_ip 2001:1291:2bf:fffb::1 is my upstream SLAAC router
 (radvd stopped for now).

 Diving: I think I'll put my OVS bridge br-eth0 (bridge_mappings =
 physnet1:br-eth0) on top of a VLAN but, I'll not tell OpenStack to use
 vlan, I'll keep using flat but, on top of a hidden vlan... eheh   :-P

 I'll keep testing to see how far I can go...:-)

 Cheers!


 On 12 April 2014 00:42, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 Hey guys!

 My OpenStack Instance have IPv6 connectivity! Using ML2 / Simple Flat
 Network... For the first time ever! Look:

 ---
 administrative@controller:~$ nova boot --image
 70f335e3-798b-4031-9773-a640970a8bdf --key-name Key trusty-1

 administrative@controller:~$ ssh -i ~/test.pem ubuntu@10.33.14.21

 ubuntu@trusty-1:~$ sudo ip -6 a a 2001:1291:2bf:fffb::300/64 dev eth0

 ubuntu@trusty-1:~$ sudo ip -6 r a default via 2001:1291:2bf:fffb::1

 ubuntu@trusty-1:~$ ping6 -c 1 google.com

 PING google.com(2800:3f0:4004:801::1000) 56 data bytes
 64 bytes from 2800:3f0:4004:801::1000: icmp_seq=1 ttl=54 time=55.1 ms

 --- google.com ping statistics ---
 1 packets transmitted, 1 received, 0% packet loss, time 0ms
 rtt min/avg/max/mdev = 55.121/55.121/55.121/0.000 ms

 -
 # From my Laptop (and from another IPv6 block):
 testuser@macbuntu:~$ telnet 2001:1291:2bf:fffb::300 22
 Trying 2001:1291:2bf:fffb::300...
 Connected to 2001:1291:2bf:fffb::300.
 Escape character is '^]'.
 SSH-2.0-OpenSSH_6.6p1 Ubuntu-2
 ---

 But, OpenStack / Neutron isn't aware of that fixed IPv6 (
 2001:1291:2bf:fffb::300) I just configured within the trusty-1 Instance,
 so, I think we just need:

 - Blueprint ipv6-provider-nets-slaac ready;
 - Start radvd on upstream

[openstack-dev] Error while creating an Instance - IceHouse / Ubuntu 14.04

[Martinx - ジェームズ]

Guys,

I'm trying to create an Instance here at my lab but, I'm seeing the
following error:

command: nova boot --image dda95a36-71e0-4474-b3e2-4f5ceef79c14 --flavor 2
my_first_vm

nova-api.log:

---
2014-04-10 03:37:02.250 1743 ERROR nova.api.openstack.wsgi [-] Exception
handling resource: multi() got an unexpected keyword argument 'body'
2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi Traceback (most
recent call last):
2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi   File
/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py, line 983, in
_process_stack
2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi
action_result = self.dispatch(meth, request, action_args)
2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi   File
/usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py, line 1070,
in dispatch
2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi return
method(req=request, **action_args)
2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi TypeError:
multi() got an unexpected keyword argument 'body'
2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi
2014-04-10 03:37:02.285 1743 INFO nova.osapi_compute.wsgi.server [-]
2001:1291:2bf:fffa::500 POST
/c24d0871dbd4461da2c854d493ec7cd7/os-server-external-events HTTP/1.1
status: 400 len: 274 time: 0.0363338
 ---

and at neutron/server.log:

---
2014-04-10 03:37:02.287 2298 ERROR neutron.notifiers.nova [-] Failed to
notify nova on events: [{'status': 'completed', 'tag':
u'9b1e88f0-cb88-4c89-8a20-bac8ef2e9f9e', 'name': 'network-vif-plugged',
'server_uuid': u'649273f9-e382-4fda-9b9a-40201bdc1684'}]
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova Traceback (most
recent call last):
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
/usr/lib/python2.7/dist-packages/neutron/notifiers/nova.py, line 187, in
send_events
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
batched_events)
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
/usr/lib/python2.7/dist-packages/novaclient/v1_1/contrib/server_external_events.py,
line 39, in create
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
return_raw=True)
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
/usr/lib/python2.7/dist-packages/novaclient/base.py, line 152, in _create
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova _resp, body =
self.api.client.post(url, body=body)
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
/usr/lib/python2.7/dist-packages/novaclient/client.py, line 286, in post
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova return
self._cs_request(url, 'POST', **kwargs)
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
/usr/lib/python2.7/dist-packages/novaclient/client.py, line 260, in
_cs_request
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova **kwargs)
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
/usr/lib/python2.7/dist-packages/novaclient/client.py, line 242, in
_time_request
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova resp, body =
self.request(url, method, **kwargs)
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
/usr/lib/python2.7/dist-packages/novaclient/client.py, line 236, in
request
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova raise
exceptions.from_response(resp, body, url, method)
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova BadRequest: The
server could not comply with the request since it is either malformed or
otherwise incorrect. (HTTP 400)
2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
---

Anyway, I'm seeing that the qemu process got started but, its state remains
spawning... Few minutes later, qemu process died...

nova-compute.log:

---
2014-04-10 03:41:59.461 1431 WARNING nova.virt.libvirt.driver
[req-7dce4196-58c9-4cc2-bfe4-06c3bd710870 6c2d4385df4d40a2804de042bb6b3466
5e0106fa81104c5cbe21e1ccc9eb1a36] Timeout waiting for vif plugging callback
for instance 649273f9-e382-4fda-9b9a-40201bdc1684
---

I'm trying it with Neutron ML2 Flat, latest packages from Ubuntu 14.04,
with IPv6 for APIs and Endpoints (not trying IPv6 for tenants subnet yet)...

Tips?!

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

Re: [openstack-dev] Error while creating an Instance - IceHouse / Ubuntu 14.04

[Martinx - ジェームズ]

Mmm... Okay, sorry!:-)


On 10 April 2014 12:37, Ben Nemec openst...@nemebean.com wrote:

 This sounds like a question for the users list, since you're using distro
 packages: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

 Thanks.

 -Ben


 On 04/10/2014 01:45 AM, Martinx - ジェームズ wrote:

 Guys,

 I'm trying to create an Instance here at my lab but, I'm seeing the
 following error:

 command: nova boot --image dda95a36-71e0-4474-b3e2-4f5ceef79c14
 --flavor 2 my_first_vm

 nova-api.log:

 ---
 2014-04-10 03:37:02.250 1743 ERROR nova.api.openstack.wsgi [-] Exception
 handling resource: multi() got an unexpected keyword argument 'body'
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi Traceback
 (most recent call last):
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi   File
 /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py, line 983,
 in _process_stack
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi
 action_result = self.dispatch(meth, request, action_args)
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi   File
 /usr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py, line
 1070, in dispatch
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi return
 method(req=request, **action_args)
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi TypeError:
 multi() got an unexpected keyword argument 'body'
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi
 2014-04-10 03:37:02.285 1743 INFO nova.osapi_compute.wsgi.server [-]
 2001:1291:2bf:fffa::500 POST
 /c24d0871dbd4461da2c854d493ec7cd7/os-server-external-events HTTP/1.1
 status: 400 len: 274 time: 0.0363338
 ---

 and at neutron/server.log:

 ---
 2014-04-10 03:37:02.287 2298 ERROR neutron.notifiers.nova [-] Failed to
 notify nova on events: [{'status': 'completed', 'tag':
 u'9b1e88f0-cb88-4c89-8a20-bac8ef2e9f9e', 'name': 'network-vif-plugged',
 'server_uuid': u'649273f9-e382-4fda-9b9a-40201bdc1684'}]
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova Traceback
 (most recent call last):
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-packages/neutron/notifiers/nova.py, line 187,
 in send_events
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
 batched_events)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-packages/novaclient/v1_1/
 contrib/server_external_events.py,
 line 39, in create
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
 return_raw=True)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-packages/novaclient/base.py, line 152, in
 _create
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova _resp,
 body = self.api.client.post(url, body=body)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-packages/novaclient/client.py, line 286, in
 post
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova return
 self._cs_request(url, 'POST', **kwargs)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-packages/novaclient/client.py, line 260, in
 _cs_request
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova **kwargs)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-packages/novaclient/client.py, line 242, in
 _time_request
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova resp, body
 = self.request(url, method, **kwargs)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-packages/novaclient/client.py, line 236, in
 request
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova raise
 exceptions.from_response(resp, body, url, method)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova BadRequest:
 The server could not comply with the request since it is either
 malformed or otherwise incorrect. (HTTP 400)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
 ---

 Anyway, I'm seeing that the qemu process got started but, its state
 remains spawning... Few minutes later, qemu process died...

 nova-compute.log:

 ---
 2014-04-10 03:41:59.461 1431 WARNING nova.virt.libvirt.driver
 [req-7dce4196-58c9-4cc2-bfe4-06c3bd710870
 6c2d4385df4d40a2804de042bb6b3466 5e0106fa81104c5cbe21e1ccc9eb1a36]
 Timeout waiting for vif plugging callback for instance
 649273f9-e382-4fda-9b9a-40201bdc1684
 ---

 I'm trying it with Neutron ML2 Flat, latest packages from Ubuntu 14.04,
 with IPv6 for APIs and Endpoints (not trying IPv6 for tenants subnet
 yet)...

 Tips?!

 Thanks!
 Thiago


 ___
 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

Re: [openstack-dev] Error while creating an Instance - IceHouse / Ubuntu 14.04

[Martinx - ジェームズ]

Sounds like I'm facing BUG 1298640! Thank you!
I'll double check the new configuration scheme...

Cheers!
Thiago


On 10 April 2014 16:44, Matt Riedemann mrie...@linux.vnet.ibm.com wrote:



 On 4/10/2014 10:41 AM, Martinx - ジェームズ wrote:

 Mmm... Okay, sorry!:-)


 On 10 April 2014 12:37, Ben Nemec openst...@nemebean.com
 mailto:openst...@nemebean.com wrote:

 This sounds like a question for the users list, since you're using
 distro packages:
 http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack

 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

 Thanks.

 -Ben


 On 04/10/2014 01:45 AM, Martinx - ジェームズ wrote:

 Guys,

 I'm trying to create an Instance here at my lab but, I'm seeing
 the
 following error:

 command: nova boot --image dda95a36-71e0-4474-b3e2-__
 4f5ceef79c14

 --flavor 2 my_first_vm

 nova-api.log:

 ---
 2014-04-10 03:37:02.250 1743 ERROR nova.api.openstack.wsgi [-]
 Exception
 handling resource: multi() got an unexpected keyword argument
 'body'
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi
 Traceback
 (most recent call last):
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi   File
 /usr/lib/python2.7/dist-__packages/nova/api/openstack/__
 wsgi.py,

 line 983,
 in _process_stack
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi
 action_result = self.dispatch(meth, request, action_args)
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi   File
 /usr/lib/python2.7/dist-__packages/nova/api/openstack/__
 wsgi.py,

 line
 1070, in dispatch
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi
 return
 method(req=request, **action_args)
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi
 TypeError:
 multi() got an unexpected keyword argument 'body'
 2014-04-10 03:37:02.250 1743 TRACE nova.api.openstack.wsgi
 2014-04-10 03:37:02.285 1743 INFO nova.osapi_compute.wsgi.server
 [-]
 2001:1291:2bf:fffa::500 POST
 /__c24d0871dbd4461da2c854d493ec7c__d7/os-server-external-events

 HTTP/1.1
 status: 400 len: 274 time: 0.0363338
 ---

 and at neutron/server.log:

 ---
 2014-04-10 03:37:02.287 2298 ERROR neutron.notifiers.nova [-]
 Failed to
 notify nova on events: [{'status': 'completed', 'tag':
 u'9b1e88f0-cb88-4c89-8a20-__bac8ef2e9f9e', 'name':
 'network-vif-plugged',
 'server_uuid': u'649273f9-e382-4fda-9b9a-__40201bdc1684'}]

 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
 Traceback
 (most recent call last):
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-__packages/neutron/notifiers/__nova.py,
 line

 187,
 in send_events
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
 batched_events)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-__packages/novaclient/v1_1/__
 contrib/server_external___events.py,

 line 39, in create
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
 return_raw=True)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-__packages/novaclient/base.py, line

 152, in _create
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
 _resp,
 body = self.api.client.post(url, body=body)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-__packages/novaclient/client.py__,

 line 286, in post
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
 return
 self._cs_request(url, 'POST', **kwargs)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-__packages/novaclient/client.py__,

 line 260, in
 _cs_request
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
 **kwargs)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-__packages/novaclient/client.py__,

 line 242, in
 _time_request
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
 resp, body
 = self.request(url, method, **kwargs)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova   File
 /usr/lib/python2.7/dist-__packages/novaclient/client.py__,

 line 236, in
 request
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova
 raise
 exceptions.from_response(resp, body, url, method)
 2014-04-10 03:37:02.287 2298 TRACE neutron.notifiers.nova

Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

Amazing!!   :-D

I'll do my best to try to make this a reality, as fast as I can!

We really need to start evaluating Neutron IPv6, even on its simplest
topology (like Flat - provider network with external RA)...

Cheers!
Thiago


On 3 April 2014 16:43, Simon Leinen simon.lei...@switch.ch wrote:

 Martinx  writes:
  1- Create and maintain a Ubuntu PPA Archive to host Neutron with IPv6
  patches (from Nephos6 / Shixiong?).
 [...]
  Let me know if there are interest on this...

 Great initiative! We're building a new Icehouse cluster soon and are
 very interested in trying these packages, because we really want to
 support IPv6 properly.

 I see you already got some help from the developers - cool!
 --
 Simon.

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

Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

Hi Thomas!

It will be a honor for me to join Debian OpenStack packaging team! I'm in!!
:-D

Listen, that neutron-ipv6.patch I have, doesn't apply against
neutron-2014.1.rc1, here is it:

neutron-ipv6.patch: http://paste.openstack.org/show/74857/

I generated it from the commands that Xuhan Peng told me to do, few posts
back, which are:

--
git fetch https://review.openstack.org/openstack/neutronrefs/changes/49/70649/15
git format-patch -1 --stdout FETCH_HEAD  neutron-ipv6.patch
--

But, as Collins said, even if the patch applies successfully against
neutron-2014.1.rc1 (or newer), it will not pass the tests, so, there is
still a lot of work to do, to enable Neutron with IPv6 but, I think we can
start working on this patches and start testing whatever is already there
(related to IPv6).

Best!
Thiago


On 5 April 2014 03:36, Thomas Goirand z...@debian.org wrote:

 On 04/02/2014 02:33 AM, Martinx - ジェームズ wrote:
  Guys!
 
  I would like to do this:
 
 
  1- Create and maintain a Ubuntu PPA Archive to host Neutron with IPv6
  patches (from Nephos6 / Shixiong?).
 
 
  Why?
 
 
  Well, I'm feeling that Neutron with native and complete IPv6 support
  will be only available in October (or maybe later, am I right?) but, I
  really need this (Neutron IPv6) ASAP, so, I'm volunteering myself to
  create / maintain this PPA for Neutron with IPv6, until it reaches
 mainline.
 
  To be able to achieve it, I just need to know which files do I need to
  patch (the diff), then repackage Neutron deb packages but, I'll need
  help here, because I don't know where are those Neutron IPv6 patches
  (links?)...
 
  Let me know if there are interest on this...
 
  Thanks!
  Thiago

 Hi Martinx,

 If you would like to take care of maintaining the IPv6 patch for the
 life of Icehouse, then I'll happily use them in the Debian packages
 (note: I also produce Ubuntu packages, and maintain 10 repository mirrors).

 Also, if you would like to join the OpenStack packaging team in
 alioth.debian.org, and contribute to it at least for this IPv6 support,
 that'd be just great! I'm available if you need my help.

 Could you please point to me to the list of needed patches? I would need
 to keep them separated, in debian/patches, rather than pulling from a
 different git repository.

 Cheers,

 Thomas Goirand (zigo)


 ___
 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] [Neutron] [IPv6] Supporting upstream RAs

[Martinx - ジェームズ]

Awesome! I have a perfect lab to evaluate it...:-)

Just a curiosity, it will work with ML2 and Flat Network (dual-stacked with
IPv4)? I would like to try to fit this into a running lab environment, if
possible...

I mean, currently, I have a lab with Flat Network topology (Havana without
ML2), my lab network was created with:

---
neutron net-create --tenant-id $ADMIN_TENTANT_ID sharednet1 --shared
--provider:network_type flat --provider:physical_network physnet1

neutron subnet-create --ip-version 4 --tenant-id $ADMIN_TENANT_ID
sharednet1 10.33.14.0/24 --dns_nameservers list=true 8.8.8.8 8.8.4.4
---

Where physnet1 is a bridge_mappings = physnet1:br-eth0 pointing to my OVS
bridge br-eth0. IPv4 router 10.33.14.1 is upstream (provider /
external)...

Reference: https://gist.github.com/tmartinx/7019826

So, I'm wondering here, at my IPv4 router 10.33.14.1 (gateway of sharednet1
10.33.14.0/24 network), I already have a up and running RA daemon
(radvd.conf) working in a dual-stacked environment BUT, currently, of
course, the OpenStack Instances only gets an IPv4 from 10.33.14.0/24 subnet
(and from dhcp-agent from network+controller node).

Anyway, I would like to try this upstream RAs and SLAAC, like this:

---
neutron subnet-create --ip-version 6 --ipv6_ra_mode slaac
--ipv6_address_mode slaac --tenant-id $ADMIN_TENANT_ID sharednet1
2001:db8:1:1::/64
---

It works that way or, am I thinking it the wrong way?!

Also, my radvd.conf provides RDNSS/DNSSL and, my Ubuntu instances will have
the pacakge `rdnssd` installed, to deal with the resolv.conf properly.

Cheers!
Thiago


On 7 April 2014 16:24, Collins, Sean sean_colli...@cable.comcast.comwrote:

 I am currently working on a patch that allows upstream RAs and SLAAC
 configuration. Currently testing it in devstack - it's based on chunks
 of patchset 33 of this review that were skipped when Mark McClain
 committed patchset 34.

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

 Xu Han and Dazhao - do I have your permission to post a rebased version
 of this patch into Gerrit - I have set myself as the author and added
 you both as Co-Authors.

 --
 Sean M. Collins
 ___
 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] [Neutron] [IPv6] Supporting upstream RAs

[Martinx - ジェームズ]

Okay Collins! Got it... I remember that e-mail from Feb...
I understand it, no rush...   ^_^
Chat tomorrow, tks!

On 7 April 2014 17:35, Collins, Sean sean_colli...@cable.comcast.comwrote:

 Hi Martin,

 I previously posted to the mailing list with some information about our
 IPv6 lab environment and devstack setup.


 http://lists.openstack.org/pipermail/openstack-dev/2014-February/026589.html

 Keep in mind that code differs from what was eventually merged in
 upstream, so I would ask for your patience while I rebase some patches
 and submit them for review, to work with the two new IPv6 attributes.

 Please join us on the IRC channel tomorrow, if you are available.

 https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam

 --
 Sean M. Collins
 ___
 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] [neutron] Location of 'enable_security_group' key in ml2_conf.ini

[Martinx - ジェームズ]

Hi!

I faced this problem this weekend, look:
https://bugs.launchpad.net/bugs/1303517

Currently, my ml2_conf.ini contains:

---
[security_group]
enable_security_group = True

[securitygroup]
firewall_driver =
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
---

Best!
Thiago


On 7 April 2014 19:50, Akihiro Motoki amot...@gmail.com wrote:

 Hi Matt,

 Thanks for raising this. Both should be the same section.
 [securitygroup] section exists in Havana and previous releases and
 it is the right section name.

 When we introduced enable_security_group option, we seem to have added
 a new section
 accidentally. We don't intended to introduce a new section name.

 IMO, both firewall_driver and enable_security_group are placed in
 [securitygroup].
 It should be fixed ASAP. I will take care of it.

 Thanks,
 Akihiro


 On Tue, Apr 8, 2014 at 5:51 AM, Matt Kassawara mkassaw...@gmail.com
 wrote:
  I'm writing the ML2 configuration sections for the installation guide and
  found a potential location conflict for the 'enable_security_group' key
 in
  ml2_conf.ini. In the patch associated with this feature, the example
  configuration file has this key under [security_group].
 
 
 https://review.openstack.org/#/c/67281/33/etc/neutron/plugins/ml2/ml2_conf.ini
 
  The most recent gate from the milestone-proposed branch also has this key
  under [security_group].
 
 
 http://logs.openstack.org/76/85676/1/gate/gate-tempest-dsvm-neutron/80af0f6/logs/etc/neutron/plugins/ml2/ml2_conf.ini.txt.gz
 
  However, the code has this key under [securitygroup] with the
  'firewall_driver' key.
 
 
 https://github.com/openstack/neutron/blob/master/neutron/agent/securitygroups_rpc.py
 
  What's the proper location for the 'enable_security_group' key?
 
  Thanks,
  Matt
 
  ___
  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] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

Well, at first, I'm planning to maintain this Neutron IPv6 PPA repository
only for Ubuntu 14.04 anyway... But, of course, if new dnsmasq arrives into
Ubuntu 12.04 on Cloud Archive, I see no problem in working on it too...

On 3 April 2014 13:19, Collins, Sean sean_colli...@cable.comcast.comwrote:

 On Thu, Apr 03, 2014 at 02:28:39AM EDT, Sebastian Herzberg wrote:
  Concerning dnsmasq: There is still no 2.66 version in the repos for
 Ubuntu 12.04. You always need to remove 2.59 and dpkg a newer version into
 it.
 

 I think it was resolved with this bug:

 https://bugs.launchpad.net/neutron/+bug/129

 --
 Sean M. Collins
 ___
 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] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

Awesome guys! I'll do it!

I have the neutron-ipv6.patch that came from the output of git
format-patch -1 --stdout FETCH_HEAD but, it did not got applied
successfully against neutron-2014.1.rc1, look:

---
builder@neutron-dev-1:~/neutron/neutron-2014.1.rc1$ patch -p1 
../ipv6-bits/neutron-shixiong/neutron-ipv6.patch
patching file neutron/agent/l3_agent.py
Hunk #1 succeeded at 696 (offset 31 lines).
Hunk #2 succeeded at 722 (offset 31 lines).
patching file neutron/agent/linux/dhcp.py
Hunk #2 FAILED at 334.
Hunk #3 FAILED at 419.
Hunk #4 succeeded at 534 with fuzz 2 (offset 56 lines).
Hunk #5 succeeded at 548 (offset 56 lines).
Hunk #6 succeeded at 664 (offset 56 lines).
2 out of 6 hunks FAILED -- saving rejects to file
neutron/agent/linux/dhcp.py.rej
patching file neutron/common/constants.py
Hunk #1 succeeded at 113 (offset 1 line).
patching file neutron/tests/unit/test_dhcp_agent.py
Hunk #2 succeeded at 221 (offset 4 lines).
Hunk #3 succeeded at 260 (offset 4 lines).
patching file neutron/tests/unit/test_l3_agent.py
Hunk #1 succeeded at 145 (offset -1 lines).
patching file neutron/tests/unit/test_linux_dhcp.py
Hunk #6 succeeded at 578 (offset -1 lines).
Hunk #7 succeeded at 595 (offset -1 lines).
Hunk #8 succeeded at 666 (offset -1 lines).
Hunk #9 FAILED at 740.
Hunk #13 FAILED at 1068.
Hunk #14 FAILED at 1085.
Hunk #15 FAILED at 1110.
Hunk #16 FAILED at 1117.
Hunk #17 succeeded at 1101 with fuzz 1 (offset -34 lines).
Hunk #18 FAILED at 1162.
6 out of 18 hunks FAILED -- saving rejects to file
neutron/tests/unit/test_linux_dhcp.py.rej
---

It failed and I'm not a coder but, I think I can work on this (it might
take days) to build Neutron IPv6 Ubuntu packages for us... Nevertheless, if
someone (Shixiong ?  :-D ) can update it (to be applied on top of
neutron-2014.1.rc1), I think I'll be able to publish the packages on PPA on
the next day!

-

The CLI command may look like, for example, something below:

---
neutron subnet-create --ip-version 6 --ipv6_ra_mode off --ipv6_address_mode
off NETWORK CIDR
neutron subnet-create --ip-version 6 --ipv6_ra_mode off --ipv6_address_mode
dhcpv6-stateful NETWORK CIDR
neutron subnet-create --ip-version 6 --ipv6_ra_mode slaac
--ipv6_address_mode slaac NETWORK CIDR
neutron subnet-create --ip-version 6 --ipv6_ra_mode dhcpv6-stateful
--ipv6_address_mode off NETWORK CIDR
neutron subnet-create --ip-version 6 --ipv6_ra_mode dhcpv6-stateless
--ipv6_address_mode dhcpv6-stateless NETWORK CIDR
---

References:

neutron-ipv6.patch: http://paste.openstack.org/show/74857/

http://lists.openstack.org/pipermail/openstack-dev/2014-February/026589.html
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026809.html


Cheers!
Thiago


On 2 April 2014 08:44, Sebastian Herzberg sebastian.herzb...@gmail.comwrote:

 Hi,

 from my side there is definite interest in this, as the changes didn't
 make it yet.

 Thanks
 Sebastian
 ___
 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] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

LOL! AWESOME!! No problem... I know that you guys have a lot to do...   :-)

But, can this current neutron-ipv6.patch at least, be used to enable
Neutron IPv6 with RA (--ipv6_ra_mode slaac --ipv6_address_mode slaac) ?

Otherwise, is a nutshell, what can be achieved these days with the bleeding
edge Neutron IPv6 code?!

I'm watching https://review.openstack.org/#/c/70649/ :)

Tks Sean!
Thiago

On 2 April 2014 12:24, Collins, Sean sean_colli...@cable.comcast.comwrote:

 On Wed, Apr 02, 2014 at 11:13:32AM EDT, Martinx - ジェームズ wrote:
  Awesome guys! I'll do it!

 OK - so keep an eye on:

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

 Once it is rebased to solve the merge conflicts, and all the tests pass,
 then perhaps we can look into any of this backporting or PPA business.
 So keep your powder dry ;)

 --
 Sean M. Collins
 ___
 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] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it

[Martinx - ジェームズ]

Okay, cool! I'll... Tks!


On 2 April 2014 12:49, Collins, Sean sean_colli...@cable.comcast.comwrote:

 On Wed, Apr 02, 2014 at 11:40:39AM EDT, Martinx - ジェームズ wrote:
  But, can this current neutron-ipv6.patch at least, be used to enable
  Neutron IPv6 with RA (--ipv6_ra_mode slaac --ipv6_address_mode slaac) ?

 No, because even if you solved all the merge conflicts, the
 tests were not passing in the last patch set.

 Keep an eye on the ML and the subteam IRC meeting, I'll make sure to add
 an agenda item for next week to discuss backporting potential.

 --
 Sean M. Collins
 ___
 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] Neutron and IPv6 for IceHouse?

[Martinx - ジェームズ]

Hello Stackers!

Please, forgive me to ask this here but, I'm about to lose my budget to
deploy OpenStack in my ISP, because it does not support IPv6. There is no
more IPv4 around here and I can not grow without IPv6.

Please, I'm begging for you guys, pleeease, release IceHouse with IPv6!
Otherwise, I'll lose the opportunity and there will be no more OpenStack
around here... The company is about to give it up and look for another
solution... I'll lost more than a year of development and a lot of time and
money...

I know that none of you are responsible for this, of course, this is my own
problem but, I'm just trying to show for you guys, *that IPv6 is a
requirement*, OpenStack can not live without it any longer (I believe)...
Wait six more months is just out of the table (for me and for my company)...

I am not a coder but, I have a huge lab and I'm good in testing and
debugging softwares, please, let me know if there is anything that I can
do, to make this [Neutron with IPv6] a reality. Is it working with
Devstack?!

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

Re: [openstack-dev] Neutron and IPv6 for IceHouse?

[Martinx - ジェームズ]

Okay! Cool! I have router with radvd enabled, I'll plug my IceHouse into
that LAN to try it...

I really want to help (I can test it a lot)! And I'm looking for a Neutron
based router with RA.

Thank you Collins!


On 8 March 2014 21:55, Collins, Sean sean_colli...@cable.comcast.comwrote:

  Hi,

 We have a number of patches that are in in review for IPv6 support in
 Neutron.

 https://wiki.openstack.org/wiki/Neutron/IPv6

 Currently, we have two patches that have landed in Neutron and Nova that
 allows IPv6 to function correctly, when you have an external gateway/router
 set up and sending ICMPv6 RA packets. We are working on a series of patches
 that will make Neutron create IPv6 subnets, and launch dnsmasq with the
 correct configuration.

 Please join us on IRC, and post/read threads with the subject line of
 [Neutron][IPv6].

 https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam

 Sean M. Collins
   --
 *From:* Martinx - ジェームズ [thiagocmarti...@gmail.com]
 *Sent:* Saturday, March 08, 2014 3:11 PM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] Neutron and IPv6 for IceHouse?

   Hello Stackers!

  Please, forgive me to ask this here but, I'm about to lose my budget to
 deploy OpenStack in my ISP, because it does not support IPv6. There is no
 more IPv4 around here and I can not grow without IPv6.

  Please, I'm begging for you guys, pleeease, release IceHouse with IPv6!
 Otherwise, I'll lose the opportunity and there will be no more OpenStack
 around here... The company is about to give it up and look for another
 solution... I'll lost more than a year of development and a lot of time and
 money...

  I know that none of you are responsible for this, of course, this is my
 own problem but, I'm just trying to show for you guys, *that IPv6 is a
 requirement*, OpenStack can not live without it any longer (I believe)...
 Wait six more months is just out of the table (for me and for my company)...

  I am not a coder but, I have a huge lab and I'm good in testing and
 debugging softwares, please, let me know if there is anything that I can
 do, to make this [Neutron with IPv6] a reality. Is it working with
 Devstack?!

  Thanks!
 Thiago

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

Re: [openstack-dev] Neutron and IPv6 for IceHouse?

[Martinx - ジェームズ]

Mmm... But can I test those patches that are still under review, with
Devstack?
I meant, I would like to start testing a IPv6 provided by Neutron + RA, not
by external provider.

Tks!
Thiago


On 8 March 2014 21:58, Collins, Sean sean_colli...@cable.comcast.comwrote:

  Also, I posted an e-mail to the mailing list that discusses a branch of
 Neutron and Nova, that can be used with DevStack, which contains patches
 for using IPv6 with non-openstack gateways and routers - it contains
 patches that we have currently under review.


 http://lists.openstack.org/pipermail/openstack-dev/2014-February/026589.html

 Sean M. Collins
   --
 *From:* Martinx - ジェームズ [thiagocmarti...@gmail.com]
 *Sent:* Saturday, March 08, 2014 3:11 PM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] Neutron and IPv6 for IceHouse?

   Hello Stackers!

  Please, forgive me to ask this here but, I'm about to lose my budget to
 deploy OpenStack in my ISP, because it does not support IPv6. There is no
 more IPv4 around here and I can not grow without IPv6.

  Please, I'm begging for you guys, pleeease, release IceHouse with IPv6!
 Otherwise, I'll lose the opportunity and there will be no more OpenStack
 around here... The company is about to give it up and look for another
 solution... I'll lost more than a year of development and a lot of time and
 money...

  I know that none of you are responsible for this, of course, this is my
 own problem but, I'm just trying to show for you guys, *that IPv6 is a
 requirement*, OpenStack can not live without it any longer (I believe)...
 Wait six more months is just out of the table (for me and for my company)...

  I am not a coder but, I have a huge lab and I'm good in testing and
 debugging softwares, please, let me know if there is anything that I can
 do, to make this [Neutron with IPv6] a reality. Is it working with
 Devstack?!

  Thanks!
 Thiago

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

Re: [openstack-dev] Neutron and IPv6 for IceHouse?

[Martinx - ジェームズ]

Awesome! I'll start doing this tests tonight! Thanks a lot!

-
 Thiago


On 8 March 2014 22:08, Collins, Sean sean_colli...@cable.comcast.comwrote:

  Yes, you can test these patches that are under review, but be prepared
 to do some debugging/hacking. They were not merged for I-3 since there is
 still work being done on them. There is also some patches that are under
 review to start bringing up Neutron routers and do RAs, but it is still
 under development. See the IPv6 section of the wiki for a full list.

 Sean M. Collins
   --
 *From:* Martinx - ジェームズ [thiagocmarti...@gmail.com]
 *Sent:* Saturday, March 08, 2014 8:01 PM
 *To:* Collins, Sean
 *Cc:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] Neutron and IPv6 for IceHouse?

   Mmm... But can I test those patches that are still under review, with
 Devstack?
 I meant, I would like to start testing a IPv6 provided by Neutron + RA,
 not by external provider.

  Tks!
 Thiago


 On 8 March 2014 21:58, Collins, Sean sean_colli...@cable.comcast.comwrote:

  Also, I posted an e-mail to the mailing list that discusses a branch of
 Neutron and Nova, that can be used with DevStack, which contains patches
 for using IPv6 with non-openstack gateways and routers - it contains
 patches that we have currently under review.


 http://lists.openstack.org/pipermail/openstack-dev/2014-February/026589.html

 Sean M. Collins
   --
 *From:* Martinx - ジェームズ [thiagocmarti...@gmail.com]
 *Sent:* Saturday, March 08, 2014 3:11 PM
 *To:* OpenStack Development Mailing List
 *Subject:* [openstack-dev] Neutron and IPv6 for IceHouse?

 Hello Stackers!

  Please, forgive me to ask this here but, I'm about to lose my budget to
 deploy OpenStack in my ISP, because it does not support IPv6. There is no
 more IPv4 around here and I can not grow without IPv6.

  Please, I'm begging for you guys, pleeease, release IceHouse with IPv6!
 Otherwise, I'll lose the opportunity and there will be no more OpenStack
 around here... The company is about to give it up and look for another
 solution... I'll lost more than a year of development and a lot of time and
 money...

  I know that none of you are responsible for this, of course, this is my
 own problem but, I'm just trying to show for you guys, *that IPv6 is a
 requirement*, OpenStack can not live without it any longer (I
 believe)... Wait six more months is just out of the table (for me and for
 my company)...

  I am not a coder but, I have a huge lab and I'm good in testing and
 debugging softwares, please, let me know if there is anything that I can
 do, to make this [Neutron with IPv6] a reality. Is it working with
 Devstack?!

  Thanks!
 Thiago



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

Re: [openstack-dev] Feature freeze + Icehouse-3 milestone candidates available

[Martinx - ジェームズ]

AWESOME!!

If may I ask, does IPv6 bits got included into this milestone?! I'm very
anxious to start testing it with Ubuntu 14.04 plus the official devel
packages from Canonical.

Thanks a lot!!

Best,
Thiago

On 5 March 2014 17:46, Thierry Carrez thie...@openstack.org wrote:

 Hi everyone,

 We just hit feature freeze, so please do not approve changes that add
 features or new configuration options unless those have been granted a
 feature freeze exception.

 This is also string freeze, so you should avoid changing translatable
 strings. If you have to modify a translatable string, you should give a
 heads-up to the I18N team.

 Milestone-proposed branches were created for Horizon, Keystone, Glance,
 Nova, Neutron, Cinder, Heat and and Trove in preparation for the
 icehouse-3 milestone publication tomorrow.

 Ceilometer should follow in an hour.

 You can find candidate tarballs at:
 http://tarballs.openstack.org/horizon/horizon-milestone-proposed.tar.gz
 http://tarballs.openstack.org/keystone/keystone-milestone-proposed.tar.gz
 http://tarballs.openstack.org/glance/glance-milestone-proposed.tar.gz
 http://tarballs.openstack.org/nova/nova-milestone-proposed.tar.gz
 http://tarballs.openstack.org/neutron/neutron-milestone-proposed.tar.gz
 http://tarballs.openstack.org/cinder/cinder-milestone-proposed.tar.gz
 http://tarballs.openstack.org/heat/heat-milestone-proposed.tar.gz
 http://tarballs.openstack.org/trove/trove-milestone-proposed.tar.gz

 You can also access the milestone-proposed branches directly at:
 https://github.com/openstack/horizon/tree/milestone-proposed
 https://github.com/openstack/keystone/tree/milestone-proposed
 https://github.com/openstack/glance/tree/milestone-proposed
 https://github.com/openstack/nova/tree/milestone-proposed
 https://github.com/openstack/neutron/tree/milestone-proposed
 https://github.com/openstack/cinder/tree/milestone-proposed
 https://github.com/openstack/heat/tree/milestone-proposed
 https://github.com/openstack/trove/tree/milestone-proposed

 Regards,

 --
 Thierry Carrez (ttx)

 ___
 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] [neutron][IPv6] Testing functionality of IPv6 modes using Horizon

[Martinx - ジェームズ]

I'll wait for IceHouse-3 to arrives on Ubuntu 14.04 to start testing the
whole IPv6 features... Lab is ready, two /48 to play with...   =)


On 28 February 2014 12:55, Abishek Subramanian (absubram) 
absub...@cisco.com wrote:

 Hi,

 I just wanted to find out if anyone had been able to test using Horizon?
 Was everything ok?

 Additionally wanted to confirm - the two modes can be updated too yes
 when using neutron subnet-update?


 Thanks!

 On 2/18/14 12:58 PM, Abishek Subramanian (absubram) absub...@cisco.com
 wrote:

 Hi shshang, all,
 
 I have some preliminary Horizon diffs available and if anyone
 would be kind enough to patch them and try to test the
 functionality, I'd really appreciate it.
 I know I'm able to create subnets successfully with
 the two modes but if there's anything else you'd like
 to test or have any other user experience comments,
 please feel free to let me know.
 
 The diffs are at -  https://review.openstack.org/74453
 
 Thanks!!
 


 ___
 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] [Neutron][IPv6] Idea: Floating IPv6 - Without any kind of NAT

[Martinx - ジェームズ]

Hello Stackers!

It is very nice to watch the OpenStack evolution in IPv6! Great job guys!!


I have another idea:

Floating IP for IPv6, or just Floating IPv6


With IPv4, as we know, OpenStack have a feature called Floating IP, which
is basically a 1-to-1 NAT rule (within tenant's Namespace q-router). In
IPv4 networks, we need this Floating IP attached to a Instance, to be
able to reach it from the Internet (*I don't like it*). But, what is the
use case for a Floating IP when you have *no NAT** (as it is with IPv6)?!

At first, when with IPv6, I was planning to disable the Floating IP
feature entirely, by removing it from Dashboard and from APIs (even for
IPv4, if FWaaS can in somehow, be able to manage q-router IPv4 NAT rules,
and not only the iptables filter table) and, I just had an idea!

For IPv6, the Floating IP can still be used to allocate more (and more)
IPs to a Instance BUT, instead of creating a NAT rule (like it is for
IPv4), it will configure the DNSMasq (or something like it) to provide more
IPv6 address per MAC / Instance. That way, we can virtually
allocate unlimited IPs (v6) for each Instance!

It will be pretty cool to see the attached Floating IPv6, literally
floating around the tenant subnet, appearing inside the Instances itself
(instead of inside the tenant's Namespace), so, we'll be able to see it
(the Floating IPv6) with ip -6 address command within the attached
Instance!

The only problem I see with this is that, for IPv4, the allocated
Floating IPs
come from the External Network (neutron / --allocation-pool) and, for IPv6,
it will come from the tenant's IPv6 subnet itself... I think... Right?!

---
Why I want tons of IPv6 within each Instance?

A.: Because we can! I mean, we can go back to the days when we had 1
website per 1 public IP (i.e. using IP-Based Virtual Hosts with Apache - I
prefer this approach).

Also, we can try to turn the Floating IPv6, in some kind of Floating
IPv6 Range, this way, we can for example, allocate millions of IPs per
Instance, like this in DHCPv6: range6 2001:db8:1:1::1000
2001:db8:1:1000:1000;...
---

NOTE: I prefer multiple IPs per Instance, instead of 1 IP per Instance,
when using VT, unless, of course, the Instances are based on Docker, so,
with it, I can easily see millions of tiny instances, each of it with its
own IPv6 address, without the overhead of virtualized environment. So, with
Docker, this Floating IPv6 Range doesn't seems to be useful...


* I know that there is NAT66 out there but, who is actually using it?! I'll
never use this thing. Personally I dislike NAT very much, mostly because it
breaks the end-to-end Internet connectivity, effectively kicking you out
from the real Internet, and it is just a workaround created to deal with
IPv4 exaustion.


BTW, please guys, let me know if this isn't the right place to post ideas
for OpenStack / feature requests... I don't want to bloat this list with
undesirable messages.


Best Regards,
Thiago Martins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] keystone-manage db_sync doesn't work if [database] connection points to IPv6 address

[Martinx - ジェームズ]

Guys,

I'm trying to install IceHouse-2 in a dual-stacked environment (Ubuntu
14.04) but, keystone-manage db_sync doesn't work if db connection points
to a IPv6 address, like this:

My /etc/network/interfaces looks like:

---
# The loopback network interface
auto lo
iface lo inet loopback
iface lo inet6 loopback

auto eth0
# IPv6
iface eth0 inet6 static
address 2001:1291::fffa::
netmask 64
gateway 2001:1291::fffa::1
   # dns-* options are implemented by the resolvconf package, if
installed
dns-search domain.com
dns-nameservers 2001:4860:4860::8844
# IPv4
iface eth0 inet static
   address 192.168.XX.100
   netmask 24
   gateway 192.168.XX.1
   # dns-* options are implemented by the resolvconf package, if
installed
   dns-nameservers 8.8.4.4 8.8.8.8
   dns-search domain.com
---

My /etc/hosts contains:

---
2001:1291::fffa::controller-1.domain.com  controller-1
192.168.XX.100  controller-1.domain.com  controller-1
---

MySQL binds on both IPv4 and IPv6, my.cnf like this:

---
bind-address = ::
---

My /etc/keystone/keystone.conf contains:

---
connection = mysql://
keystoneUser:keystonep...@controller-1.domain.com/keystone
---

So, this way, keystone-manage db_sync does not work but, if I replace
keystone.conf connection line into this:

---
connection = mysql://keystoneUser:keystonep...@192.168.xx.100/keystone
---

It works! Then, after db_sync, I return it back to FQDN, where it resolves
to IPv6 address and it works fine...

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

Re: [openstack-dev] keystone-manage db_sync doesn't work if [database] connection points to IPv6 address

[Martinx - ジェームズ]

Sure! I'll...=)


On 2 February 2014 13:32, Dolph Mathews dolph.math...@gmail.com wrote:

 Can you open a bug for this at https://bugs.launchpad.net/keystone ?
 Thanks!

 On Sun, Feb 2, 2014 at 9:15 AM, Martinx - ジェームズ thiagocmarti...@gmail.com
  wrote:

 Guys,

 I'm trying to install IceHouse-2 in a dual-stacked environment (Ubuntu
 14.04) but, keystone-manage db_sync doesn't work if db connection points
 to a IPv6 address, like this:

 My /etc/network/interfaces looks like:

 ---
 # The loopback network interface
 auto lo
 iface lo inet loopback
 iface lo inet6 loopback

 auto eth0
 # IPv6
 iface eth0 inet6 static
 address 2001:1291::fffa::
 netmask 64
 gateway 2001:1291::fffa::1
# dns-* options are implemented by the resolvconf package, if
 installed
 dns-search domain.com
 dns-nameservers 2001:4860:4860::8844
 # IPv4
 iface eth0 inet static
address 192.168.XX.100
netmask 24
gateway 192.168.XX.1
# dns-* options are implemented by the resolvconf package, if
 installed
dns-nameservers 8.8.4.4 8.8.8.8
dns-search domain.com
 ---

 My /etc/hosts contains:

 ---
 2001:1291::fffa::controller-1.domain.com  controller-1
 192.168.XX.100  controller-1.domain.com  controller-1
 ---

 MySQL binds on both IPv4 and IPv6, my.cnf like this:

 ---
 bind-address = ::
 ---

 My /etc/keystone/keystone.conf contains:

 ---
 connection = mysql://
 keystoneUser:keystonep...@controller-1.domain.com/keystone
 ---

 So, this way, keystone-manage db_sync does not work but, if I replace
 keystone.conf connection line into this:

 ---
 connection = mysql://keystoneUser:keystonep...@192.168.xx.100/keystone
 ---

 It works! Then, after db_sync, I return it back to FQDN, where it
 resolves to IPv6 address and it works fine...

 Cheers!
 Thiago

 ___
 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] keystone-manage db_sync doesn't work if [database] connection points to IPv6 address

[Martinx - ジェームズ]

Done.

https://bugs.launchpad.net/keystone/+bug/1275615

I'll try it again tomorrow... Just to make sure it isn't me doing something
wrong...

Best!
Thiago


On 2 February 2014 15:58, Martinx - ジェームズ thiagocmarti...@gmail.com wrote:

 Sure! I'll...=)


 On 2 February 2014 13:32, Dolph Mathews dolph.math...@gmail.com wrote:

 Can you open a bug for this at https://bugs.launchpad.net/keystone ?
 Thanks!

 On Sun, Feb 2, 2014 at 9:15 AM, Martinx - ジェームズ 
 thiagocmarti...@gmail.com wrote:

 Guys,

 I'm trying to install IceHouse-2 in a dual-stacked environment (Ubuntu
 14.04) but, keystone-manage db_sync doesn't work if db connection points
 to a IPv6 address, like this:

 My /etc/network/interfaces looks like:

 ---
 # The loopback network interface
 auto lo
 iface lo inet loopback
 iface lo inet6 loopback

 auto eth0
 # IPv6
 iface eth0 inet6 static
 address 2001:1291::fffa::
 netmask 64
 gateway 2001:1291::fffa::1
# dns-* options are implemented by the resolvconf package, if
 installed
 dns-search domain.com
 dns-nameservers 2001:4860:4860::8844
 # IPv4
 iface eth0 inet static
address 192.168.XX.100
netmask 24
gateway 192.168.XX.1
# dns-* options are implemented by the resolvconf package, if
 installed
dns-nameservers 8.8.4.4 8.8.8.8
dns-search domain.com
 ---

 My /etc/hosts contains:

 ---
 2001:1291::fffa::controller-1.domain.com  controller-1
 192.168.XX.100  controller-1.domain.com  controller-1
 ---

 MySQL binds on both IPv4 and IPv6, my.cnf like this:

 ---
 bind-address = ::
 ---

 My /etc/keystone/keystone.conf contains:

 ---
 connection = mysql://
 keystoneUser:keystonep...@controller-1.domain.com/keystone
 ---

 So, this way, keystone-manage db_sync does not work but, if I replace
 keystone.conf connection line into this:

 ---
 connection = mysql://keystoneUser:keystonep...@192.168.xx.100/keystone
 ---

 It works! Then, after db_sync, I return it back to FQDN, where it
 resolves to IPv6 address and it works fine...

 Cheers!
 Thiago

 ___
 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] [Openstack] [Neutron] auto configration of local_ip

[Martinx - ジェームズ]

Guys,

Let me ask something about this...

Apparently, VXLAN can be easier to implement/maintain when using it with
IPv6 (read about it here: www.nephos6.com/pdf/OpenStack-on-IPv6.pdf), so,
I'm wondering if local_ip can be an IPv6 address (for IceHouse-3 / Ubuntu
14.04) and, of course, if it is better in the end of the day.

Thoughts?!

Cheers!
Thiago


On 16 January 2014 12:58, balaj...@freescale.com balaj...@freescale.comwrote:

  2014/1/16 NOTSU Arata no...@virtualtech.jp:
   The question is, what criteria is appropriate for the purpose. The
  criteria being mentioned so far in the review are:
  
   1. assigned to the interface attached to default gateway 2. being in
   the specified network (CIDR) 3. assigned to the specified interface
  (1 can be considered a special case of 3)
  
 
  For a certain deployment scenario, local_ip is totally different among
  those nodes, but if we consider local_ip as local_interface, it may
  match most of the nodes. I think it is more convenient to switch from
  ip to interface parameter.
 
 [P Balaji-B37839] We implemented this and using in our test setup. We are
 glad to share this through blue-print/Bug if anybody is interested.

 Regards,
 Balaji.P


 ___
 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] [neutron] Implement NAPT in neutron (https://blueprints.launchpad.net/neutron/+spec/neutron-napt-api)

[Martinx - ジェームズ]

Hi!

From a operator point of view, I think that it would be nice to give to the
FWaaS (IPv4 flavor), the ability to manage the tenant's NAT table, not only
the filter table, as it is today.

If fact, I don't know if it is out of the scope of FWaaS or not, it is just
an idea I had. Because right now, I need to create the so called NAT
Instance, with a Floating IPv4 attached to it, with a DNAT rule for each
internal service that I need to open to the Internet... It is terrible
BTW but, it is the IPv4-thinking... (Can't wait for IPv6 in IceHouse to
kiss NAT goodbye!)... Today, each tenant must have at least, two valid IPs
(v4), one for the router's gateway and another to the NAT Instance
(because FWaaS (or something else) doesn't handle the Tenant
Router/Namespace NAT table).

So, if the Tenant can manage its own Firewall-IPv4-NAT table, there at its
own Namespace Router, then, each will require only 1 valid Floating IPv4,
the one that come when he connects its router, with the External Network
(from allocation pool anyway)... Less waste of valid IPv4.

Regards,
Thiago


On 8 January 2014 13:36, Dong Liu willowd...@gmail.com wrote:


 在 2014年1月8日，20:24，Nir Yechiel nyech...@redhat.com 写道：

 Hi Dong,

 Can you please clarify this blueprint? Currently in Neutron, If an
 instance has a floating IP, then that will be used for both inbound and
 outbound traffic. If an instance does not have a floating IP, it can make
 connections out using the gateway IP (SNAT using PAT/NAT Overload). Does
 the idea in this blueprint is to implement PAT on both directions using
 only the gateway IP? Also, did you see this one [1]?

 Thanks,
 Nir

 [1] https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding



 I think my idea is duplicated with this one.
 https://blueprints.launchpad.net/neutron/+spec/access-vms-via-port-mapping

 Sorry for missing this.

 ___
 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] An idea: For an IPv6-only Tenant subnet: a Floating IP with NAT46 sounds needed...

[Martinx - ジェームズ]

Hello Stackers!

I have an idea:

In a IPv6-Only Tenant subnet, we can offer a solution to make its IPv6
network, reachable from the old Internet infrastructure (IPv4), how?


1- Floating IP (v4) based on NAT46.


That way, the attached Floating IP (when with NAT46), it will be a real
IPv4 address at the Namespace Router, and then, Linux (or a dual-stacked
reverse proxy? Load Balancer (aaS) with NAT46?) will do the NAT46 to make
an IPv6-only Instance, reachable from the IPv4-only-Internet.

Let me know what do you guys think about it!

Can't wait to try IceHouse with IPv6! :-D

Happy New Year!

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

Re: [openstack-dev] [Neutron][IPv6] Blueprint Bind dnsmasq in qrouter- namespace

[Martinx - ジェームズ]

Hello Stackers!

I agree with one namespace approach, if it is better for IPv6 (or even
for IPv4 and for operators).

And also, I think that, when with IPv6, we must do what is better for IPv6
networks... If things needs to be changed, lets do it!

BTW, one namespace with all the required services on it, makes more sense
to me either, this way, OpenStack can focus on namespace = tenant router,
with dhcp, dhcpv6, RA, filter, IPv4 NAT, etc, on it... Just like a real
world router...  OpenStack approach to present the Linux Namespace as a
router to tenants is awesome by itself!

Operators can learn the new way of doing things, now with IPv6, it can be
simpler! No NAT tables, pure routing, less namespaces to deal with, VXLAN
seems to work better when with IPv6 (nephos6 PDF have some notes about
it)...

I'm wondering about starting millions of tiny Docker Instances, each one
with its own public IPv6 address! This will be epic!   :-D

What about a Floating IP for IPv6?! I think we can provide a IPv6 Floating
IP (without any kind NAT, of course), so, this Floating IPv6 address
will appear *within* the attached Instance, instead of within its namespace
router, as it is with IPv4 (a NAT rule at the namespace router). What do
you guys think about this idea? This way, the namespace router will be used
to configure/deliver more IPv6 address for each Instance.

Another idea is: the Tenant IPv6 Namespace Router should provide a way (I
think), to deliver a range of IPv6 address (if possible), not only 1 per
Instance. This way, a Instance can have hundreds of web sites (Apache,
NGinx), each one with its own public IP (I prefer this Apache setup:
IP-Based http://httpd.apache.org/docs/2.2/vhosts/ip-based.html), because
I really like the idea of 1 public IP for each website, but not 1 Instance
for each website (perhaps with Docker it will be okay to have 1 Instance
per website).

Sorry to throw lots of subjects, I don't want to hijack the thread but, the
namespaces does lots of things anyway...   =P

NOTE: Can I start testing IPv6 tenant networks with Neutron 2014.1~b1 from
Ubuntu 14.04?!

Cheers!
Thiago


On 19 December 2013 23:31, Shixiong Shang sparkofwisdom.cl...@gmail.comwrote:

 Hi, Ian:

 The use case brought by Comcast team today during the ipv6 sub-team
 meeting actually proved the point I made here, instead of against it. If I
 didn’t explain it clearly in my previous email, here it is.

 I was questioning the design with two namespaces and I believe we can use
 a SINGLE namespace as the common container to host two services, i.e. DHCP
 and ROUTING. If your use case needs DHCP instance, but not ROUTING, then
 just launch dnsmasq in THE namespace with qr- interface; If your use case
 needs default GW, then add qg- interface in THE namespace. Whether it is
 called qdhcp or qrouter, I don’t care. It is just a label.

 People follow the routine to use it, simply because this is what OpenStack
 offers. But my question is, why? And why NOT we design the system in the
 way that qg- and qr- interface collocate in the same namespace?

 It is because we intentionally separate the service, now the system become
 clumsy and less efficient. As you can see in IPv6 cases, we are forced to
 deal with two namespaces now. It just doesn’t make any sense.

 Shixiong






 On Dec 19, 2013, at 7:27 PM, Ian Wells ijw.ubu...@cack.org.uk wrote:

 Per the discussions this evening, we did identify a reason why you might
 need a dhcp namespace for v6 - because networks don't actually have to have
 routers.  It's clear you need an agent in the router namespace for RAs and
 another one in the DHCP namespace for when the network's not connected to a
 router, though.

 We've not pinned down all the API details yet, but the plan is to
 implement an RA agent first, responding to subnets that router is attached
 to (which is very close to what Randy and Shixiong have already done).
 --
 Ian.


 On 19 December 2013 14:01, Randy Tuttle randy.m.tut...@gmail.com wrote:

 First, dnsmasq is not being moved. Instead, it's a different instance
 for the attached subnet in the qrouter namespace. If it's not in the
 qrouter namespace, the default gateway (the local router interface) will be
 the interface of qdhcp namespace interface. That will cause blackhole for
 traffic from VM. As you know, routing tables and NAT all occur in qrouter
 namespace. So we want the RA to contain the local interface as default
 gateway in qrouter namespace

 Randy

 Sent from my iPhone

 On Dec 19, 2013, at 4:05 AM, Xuhan Peng pengxu...@gmail.com wrote:

 I am reading through the blueprint created by Randy to bind dnsmasq into
 qrouter- namespace:


 https://blueprints.launchpad.net/neutron/+spec/dnsmasq-bind-into-qrouter-namespace

 I don't think I can follow the reason that we need to change the
 namespace which contains dnsmasq process and the device it listens to from
 qdhcp- to qrouter-. Why the original namespace design conflicts with the
 Router Advertisement sending 

Re: [openstack-dev] OpenStack Icehouse milestone 1 packages for Ubuntu

[Martinx - ジェームズ]

AWESOME! Do you know if we can start testing IPv6 tenants networks?

Tks!

On 12 December 2013 07:38, James Page james.p...@ubuntu.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi All

 As OpenStack Icehouse milestone 1 is now out, I thought it worth
 updating everyone on Ubuntu activities during the Icehouse development
 cycle.

 For release, Ubuntu will be providing Icehouse packages for both
 Ubuntu 14.04 and for Ubuntu 12.04 via the Ubuntu Cloud Archive (see
 [0]).  Right now, icehouse-1 can be tested either using the current
 Ubuntu development release (trusty) or using the icehouse-proposed
 pocket in the Cloud Archive for Ubuntu 12.04, which can be enabled on
 Ubuntu 12.04 systems by running:

  sudo add-apt-repository cloud-archive:icehouse-proposed

 The packages are currently a straight refresh of the Havana packages
 with any mandatory changes for Icehouse; expect more changes between
 now and Icehouse milestone 2, including switching to the ML2 plugin in
 Neutron as default and some re-jigging of the nova-compute-* packages
 to make installs for off-host non-libvirt hypervisors a little easier
 (see [1]).

 You can report any bugs on these packages on 12.04 and trusty using
 the ‘ubuntu-bug’ tool, for example:

 ubuntu-bug neutron-server

 Other notable upgrades alongside Icehouse include new versions of qemu
 (1.7.x), Ceph (0.72.x) and Open vSwitch (2.0.x).  If you are using
 Ubuntu trusty, you won’t need to use the openvswitch-datapath-dkms
 package any longer - the 3.12 kernel currently shipping supports both
 GRE and VXLAN overlay networking via the in-tree openvswitch kernel
 module.

 In addition to the milestone packaging that the Ubuntu Server team
 pushes to the development release and the Cloud Archive, you can
 always test with the latest trunk build packages and dependencies
 using the OpenStack Ubuntu Testing PPA:

 sudo add-apt-repository ppa:openstack-ubuntu-testing/icehouse

 This PPA publishes packages for 12.04 and trusty as well.  They are
 bleeding edge so may not always work - but hey - some folks like to
 live on the edge!

 Enjoy and happy testing!

 James (on behalf of the Ubuntu Server Team)

 - --
 James Page
 Technical Lead, Ubuntu Server Team

 [0] http://wiki.ubuntu.com/ServerTeam/CloudArchive
 [1]
 https://blueprints.launchpad.net/ubuntu/+spec/servercloud-1311-openstack
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.15 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJSqYQTAAoJEL/srsug59jDYzIP/2pN6Xs8dh0phrwXnaB3mHBM
 48H6aoM4BRscTApYFscQO6aWNz+z0nSJhTI72YaRJOulKPgHtYlJgp7hTPOUPbLs
 Qwo6QrsuSlmvgchBlFmYTWw3iAg2SX0Wz0UPFjWcg4Ru/qK+4+j8xkIonErO0Lnp
 KVGi43nL4DtvJs4ji2+wnGV4op7ETLENbSzQJRD+cenUkawTp5Y5xamn+fxo9Vzq
 I82/I5SYW6brUjGo3FbxxepHKwFnWjy/i4YiLa/GqjoRQ+cDY+Ayo3aFJN5J6VV8
 XaxRJk3/Yf7nSaAGEbhr2J9r/3+ztafviSEoJMiTPrUMyieN57ihhnvGKLeVwuuS
 QlAnNzgrhOwZf+sjdGgcbLml1d9Vto6G1+j79i/y0OE+Ke7EYxod8IToAELfrgNo
 VPww0zfTgs1Ip224quGylrtWEdnG+f9awtj/fKU0qqECQ+/6igQPnaAvCI19KN+N
 LJMN40yQeswcLW2VJ4PYRo3ZW/BKzB8IEq5H7Sdcl2jqSckjbCjnyLt6MwiIz6b2
 XXNR/wHM1dWyWwmhAB7vLbo1+A4CMCBIW4LhS/CC7WEfnyYTAzosuuWrb+KQv+77
 69e2Ir5CbdGEigea8XO+lPtgrzoBejyRrPBCVoGJZSUaMqQjmkh7k6WTpqwCOe7H
 3pnhE0lJD5QBkAUk/XwG
 =fRXG
 -END PGP SIGNATURE-

 ___
 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] Introducing myself - looking for a IPv6 topology

[Martinx - ジェームズ]

Cool!

Thank you Kyle! I'll try to join the today's IPv6 meeting...

Cheers!
Thiago


On 20 November 2013 01:08, Kyle Mestery (kmestery) kmest...@cisco.comwrote:

 On Nov 19, 2013, at 7:23 PM, Martinx - ジェームズ thiagocmarti...@gmail.com
 wrote:
 
  One more thing...
 
  I'm thinking about the use case for Floating IPs in a NAT-less IPv6
 OpenStack environment.
 
 
  I can think in two use cases in a IPv6-Only Tenant Subnet:
 
  1- the Floating IP might be used to allocate more IPv6 address for an
 Instance (since there is no plans for NAT66, I believe it is not desired)
 but, instead of allocating it from the allocation pool, get it from the
 tenant subnet directly. This way, the IPv6 Floating IP will appear within
 the Instance it self, not at the L3 Namespace Router as it is with IPv4
 today.
 
  2- we can provide a IPv4 Floating IP address (for a IPv6-Only tenant)
 and the L3 Namespace Router will do the NAT46. This way, the old Internet
 will be able to seamless reach a IPv6-Only network.
 
 
  What do you guys have in mind / roadmap?!
 
  Cheers!
  Thiago
 
 Hi Thiago:

 An IPV6 subteam in Neutron was formed for the Icehouse release. The
 team will have weekly meetings in #openstack-meeting-alt on freenode
 Thursday's at 2100 UTV. See the meeting page here [1]. If you're planning
 to work on IPV6 in any form, it would be great to participate in these and
 help shape the IPV6 direction for Neutron.

 Thanks, and welcome aboard!
 Kyle

 [1] https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam

 
 
  On 19 November 2013 22:57, Martinx - ジェームズ thiagocmarti...@gmail.com
 wrote:
  Hello Stackers!
 
  I'm Thiago and I'm here on dev list mostly to watch you guys...
 
  Nevertheless, I want to say that I would love to test in deep, the IPv6
 support in OpenStack IceHouse.
 
  At at glance, what I'm looking for is more or less specified here, as
 follows:




 ___
 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] Introducing myself - looking for a IPv6 topology

[Martinx - ジェームズ]

Hello Stackers!

I'm Thiago and I'm here on dev list mostly to watch you guys...

Nevertheless, I want to say that I would love to test in deep, the IPv6
support in OpenStack IceHouse.

At at glance, what I'm looking for is more or less specified here, as
follows:

---
I have 1 native IPv6 /48 block and I would like to provide 1 (or more) IPv6
/64 subnet for each tenant (automatically configured when tenant requests a
subnet, tenant does not need to type the IPv6 network address, it will
never overlap).

** I have no plans to support or test NAT66 **

I'm planning to use a dual-stack topology that is described in details here:

http://www.nephos6.com/pdf/OpenStack-on-IPv6.pdf

http://www.nephos6.com/


Also, I would like to give, for example, a range of IPv6 address for each
Instance, instead of just only 1 fixed IPv6 address (based on Instance's
Mac Address / EUI-64) plus a few temporary address, but instead, I would
like to provide ~1000 IPv6 address for each Instance (i.e. DHCPv6 with
range 2001:db8:1:1::1 2001:db8:1:1::1000 (or 2001:db8:1:1::1-1000). Of
course, assuming that IceHouse have native IPv6 support for IPv6 in first
place...

Desired: Dashboard should focus on DNSaaS, instead of IPs, when listing the
Instances.

OBS: I really want to achieve a NAT-Less OpenStack Cloud, powered by
IPv6... I know I still need IPv4 (for metadata for example) but, IPv6 is
the way to go, I believe that OpenStack have a great future with IPv6!
---

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

Re: [openstack-dev] Introducing myself - looking for a IPv6 topology

[Martinx - ジェームズ]

One more thing...

I'm thinking about the use case for Floating IPs in a NAT-less IPv6
OpenStack environment.


I can think in two use cases in a IPv6-Only Tenant Subnet:

1- the Floating IP might be used to allocate more IPv6 address for an
Instance (since there is no plans for NAT66, I believe it is not desired)
but, instead of allocating it from the allocation pool, get it from the
tenant subnet directly. This way, the IPv6 Floating IP will appear within
the Instance it self, not at the L3 Namespace Router as it is with IPv4
today.

2- we can provide a IPv4 Floating IP address (for a IPv6-Only tenant) and
the L3 Namespace Router will do the NAT46. This way, the old Internet
will be able to seamless reach a IPv6-Only network.


What do you guys have in mind / roadmap?!

Cheers!
Thiago



On 19 November 2013 22:57, Martinx - ジェームズ thiagocmarti...@gmail.comwrote:

 Hello Stackers!

 I'm Thiago and I'm here on dev list mostly to watch you guys...

 Nevertheless, I want to say that I would love to test in deep, the IPv6
 support in OpenStack IceHouse.

 At at glance, what I'm looking for is more or less specified here, as
 follows:

 ---
 I have 1 native IPv6 /48 block and I would like to provide 1 (or more)
 IPv6 /64 subnet for each tenant (automatically configured when tenant
 requests a subnet, tenant does not need to type the IPv6 network address,
 it will never overlap).

 ** I have no plans to support or test NAT66 **

 I'm planning to use a dual-stack topology that is described in details
 here:

 http://www.nephos6.com/pdf/OpenStack-on-IPv6.pdf

 http://www.nephos6.com/


 Also, I would like to give, for example, a range of IPv6 address for each
 Instance, instead of just only 1 fixed IPv6 address (based on Instance's
 Mac Address / EUI-64) plus a few temporary address, but instead, I would
 like to provide ~1000 IPv6 address for each Instance (i.e. DHCPv6 with
 range 2001:db8:1:1::1 2001:db8:1:1::1000 (or 2001:db8:1:1::1-1000). Of
 course, assuming that IceHouse have native IPv6 support for IPv6 in first
 place...

 Desired: Dashboard should focus on DNSaaS, instead of IPs, when listing
 the Instances.

 OBS: I really want to achieve a NAT-Less OpenStack Cloud, powered by
 IPv6... I know I still need IPv4 (for metadata for example) but, IPv6 is
 the way to go, I believe that OpenStack have a great future with IPv6!
 ---

 Best!
 Thiago

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

Re: [openstack-dev] [Openstack] [Neutron] Security groups issue when running latest libvirt?

[Martinx - ジェームズ]

That is true... Back to LibvirtHybridOVSBridgeDriver, Security Groups is
working again...


On 6 November 2013 15:03, Simon Pasquier simon.pasqu...@bull.net wrote:

 Answering myself as I investigated a little further and cross-posting to
 openstack-dev because I'd like to get feedback from Nova/Neutron devs.

 Users running Havana should configure libvirt_vif_driver=nova.virt.
 libvirt.vif.LibvirtHybridOVSBridgeDriver.
 This driver is still available in the Havana release although deprecated.
 AFAIU, this is the only option if you want effective security groups with
 KVM  OVS.

 For people using the master branch of nova, sorry but security groups are
 currently broken because LibvirtHybridOVSBridgeDriver is gone ([0]). Joe
 Gordon asked the Neutron devs about it few weeks ago [1] but no answer and
 in another review [2], the conclusion was that the Tempest tests passed
 with Neutron. However I don't see anywhere in the tests ([3], [4]) that we
 check if the security rules allow/block traffic.

 It would be nice if core devs could confirm or refute.

 Regards,

 Simon

 [0] https://review.openstack.org/#/c/49660/
 [1] http://lists.openstack.org/pipermail/openstack-dev/2013-
 October/016886.html
 [2] https://review.openstack.org/#/c/44349
 [3] https://github.com/openstack/tempest/blob/master/tempest/
 api/network/test_security_groups.py
 [4] https://github.com/openstack/tempest/blob/master/tempest/
 api/network/test_security_groups_negative.py

 Le 05/11/2013 14:57, Simon Pasquier a écrit :

  Hi all,

 I'm struggling with security groups on Havana with Neutron and OVS
 plugin (GRE tunnels). No problem to create/delete security group rules
 but even though iptables configuration is updated, traffic to my
 instances is never filtered [0].

 I'm running DevStack on 2 nodes (1 controller + 1 compute):
 - OS: Ubuntu 12.04.3 (LTS) with the Havana cloud archive repository.
 - Open vSwitch package version: 1.10.2-0ubuntu2~cloud0
 - libvirt package version: 1.1.1-0ubuntu8~cloud2
 - localrc, nova.conf, neutron.conf and ovs_neutron_plugin.ini files
 pasted at [1] (I didn't modify any of these files after the DevStack run)

 According to [2], [3] and [4], iptables is not compatible with TAP
 devices connectd directly to Open vSwitch ports, this is why there used
 to be the additional veth + bridge interfaces [5]. But in my setup, this
 is not the case anymore as shown in [6] ('ovs-vsctl show' +
 'iptables-save' ouptut). I've also pasted the libvirt XML configuration
 [7] that shows that the instance is directly connected to the Open
 vSwitch.

 Are the security groups supposed to work when the instance is directly
 connected to OVS? If yes, what am I doing wrong?

 Regards,

 [0] http://paste.openstack.org/show/50490/
 [1] http://paste.openstack.org/show/50448/
 [2] http://www.spinics.net/linux/fedora/libvirt-users/msg05384.html
 [3] http://openvswitch.org/pipermail/discuss/2013-October/011461.html
 [4]
 http://docs.openstack.org/havana/config-reference/content/under_the_hood_
 openvswitch.html

 [5]
 http://docs.openstack.org/havana/config-reference/
 content/figures/7/a/a/common/figures/under-the-hood-
 scenario-2-ovs-compute.png

 [6] http://paste.openstack.org/show/50486/
 [7] http://paste.openstack.org/show/50487/



 --
 Simon Pasquier
 Software Engineer
 Bull, Architect of an Open World
 Phone: + 33 4 76 29 71 49
 http://www.bull.com

 ___
 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-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev