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 - ジェームズ  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  wrote:

>
>
> On Mon, Apr 10, 2017 at 4:49 PM, Martinx - ジェームズ <
> thiagocmarti...@gmail.com> wrote:
>
>>
>>
>> On 8 April 2017 at 00:37, Martinx - ジェームズ 
>> 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 

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

[Martinx - ジェームズ]

On 11 April 2017 at 11:08, Russell Bryant  wrote:

>
>
> On Mon, Apr 10, 2017 at 4:49 PM, Martinx - ジェームズ <
> thiagocmarti...@gmail.com> wrote:
>
>>
>>
>> On 8 April 2017 at 00:37, Martinx - ジェームズ 
>> 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 

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

[Martinx - ジェームズ]

On 8 April 2017 at 00:37, Martinx - ジェームズ  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 Visor is!

Sorry about mixing subjects, let's keep this one clear for OVN 

[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  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> 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.

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

[openstack-dev] CONSOLE_TYPE=AUTO does not auto-detects SPICE

[Martinx - ジェームズ]

Guys,

 Currently, I need to force:

 CONSOLE_TYPE=SPICE

 Otherwise, if "CONSOLE_TYPE=AUTO", Horizon does not auto-detect SPICE and
points to VNC, even if there is no VNC console configured in Nova.

 Is this a bug?

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] 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  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  wrote:
> Mike Bayer  wrote:
>
>>
>>
>> On 01/04/2016 06:59 AM, Ihar Hrachyshka wrote:
>>>
>>> Martinx - ジェームズ  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] The command "neutron-db-manage" of 8.0.0~b1 fails

[Martinx - ジェームズ]

On 4 January 2016 at 01:28, Mike Bayer  wrote:
>
>
> On 01/03/2016 05:15 PM, Martinx - ジェームズ 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?
>
> this is a new error added to MySQL as of version 5.6.7:
>
> https://dev.mysql.com/doc/refman/5.6/en/error-messages-server.html#error_er_fk_column_cannot_change
>
> some discussion is at http://stackoverflow.com/a/17019351/34549.
>
> the issue here is either that the table contains NULL values or that the
> BIGINT datatype is not compatible with the column to which the foreign
> key refers.
>
> This error looks familiar but I don't recall if I saw it specific to
> Neutron already having this issue before.
>

Wow! Thank you! It is working now!

What I did?


To turn off foreign key constraint globally, by running directly on
MySQL root shell:

SET GLOBAL FOREIGN_KEY_CHECKS=0;

and remember to set it back when you are done... Then, neutron-db-manage worked!

su -s /bin/sh -c "neutron-db-manage --config-file
/etc/neutron/neutron.conf --config-file
/etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron

After that, I re-enabled foreign_key_checks:

SET GLOBAL FOREIGN_KEY_CHECKS=1;

Apparently, people will face this problem while trying Mitaka on
Xenial... Isn't "neutron-db-manage" aware of this new feature /
situation of MySQL 5.6?

Should I fill a bug report on Launchpad about this?

Continuing my tests now...   :-D

Thanks again!
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] [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  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 
> 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

Re: [openstack-dev] OpenStack Juno is completely broken in Trusty + Linux 3.19!

[Martinx - ジェームズ]

On Thu, May 7, 2015 at 4:26 PM Martinx - ジェームズ 
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] 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 - ジェームズ 
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

[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] 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 - ジェームズ  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] [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)  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 - ジェームズ" 
> 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  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] [Heat] Juno RC2 available

[Martinx - ジェームズ]

Congrats  :-D

On 9 October 2014 09:52, Thierry Carrez  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 - ジェームズ]

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  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

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 - ジェームズ 
wrote:

> About this
> https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/juno-staging ?
>
> On 27 September 2014 13:12, John Griffith 
> 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 - ジェームズ]

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

On 27 September 2014 13:12, John Griffith  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  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 - ジェームズ
>  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  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 

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  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/i4GhZsFD3OJ

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

[Martinx - ジェームズ]

Sounds impressive!   :-D


On 1 September 2014 23:52, Xu Han Peng  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"  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
> norma

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  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 :
>
> 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
>>> 
>>>
>>>
>>> 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  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 
> wrote:
>
>> On Thu, Jul 10, 2014 at 4:30 AM, shihanzhang 
>> 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"  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" 
>> >>> 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" 
>> > 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

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

[Martinx - ジェームズ]

I know!   :-P


On 16 August 2014 21:17, Adam Lawson  wrote:

> Also, don't forget that AD != LDAP. ;)
> On Aug 16, 2014 5:16 PM, "Adam Lawson"  wrote:
>
>> Doesn't Murano address this already?
>> On Aug 16, 2014 2:35 PM, "Martinx - ジェームズ" 
>> 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  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] 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  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 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  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] 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
, 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] [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  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  wrote:

> On 7 July 2014 11:37, Sean Dague  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] cloud-init IPv6 support

[Martinx - ジェームズ]

Let me talk a bit about this...   :-)


On 7 July 2014 14:43, Andrew Mann  wrote:

> What's the use case for an IPv6 endpoint? This service is just for
> instance metadata, so as long as a requirement to support IPv4 is in place,
> using solely an IPv4 endpoint avoids a number of complexities:
> - Which one to try first?
>
- Which one is authoritative?
>

Only 1, IPv6 metadata network via link-local (fe80::)...


> - Are both required to be present? I.e. can an instance really not have
> any IPv4 support and expect to work?
>

No.

Yes, I have tons of IPv6-Only machines, to reach IPv4, I'm using the couple
DNS64 + NAT64. I see no use for IPv4 anymore... IPv4 can be deployed only
at the border (i.e. as a legacy Floating IPv4 using NAT46)...

- I'd presume the IPv6 endpoint would have to be link-local scope? Would
> that mean that each subnet would need a compute metadata endpoint?
>

Good question... Apparently, IPv6 Link-Local fe80:: is the equivalent of
169.254 in IPv4 world...

Just my two bitcents...   ;-)


>
>
> On Mon, Jul 7, 2014 at 12:28 PM, Vishvananda Ishaya  > wrote:
>
>> I haven’t heard of anyone addressing this, but it seems useful.
>>
>> Vish
>>
>> On Jul 7, 2014, at 9:15 AM, Nir Yechiel  wrote:
>>
>> > AFAIK, the cloud-init metadata service can currently be accessed only
>> by sending a request to http://169.254.169.254, and no IPv6 equivalent
>> is currently implemented. Does anyone working on this or tried to address
>> this before?
>> >
>> > Thanks,
>> > Nir
>> >
>> > ___
>> > 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
>>
>>
>
>
> --
> Andrew Mann
> DivvyCloud Inc.
> www.divvycloud.com
>
> ___
> 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  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  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=id&id=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 - ジェームズ  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=id&id=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=id&id=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 - ジェームズ  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/host

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 wrote:

>  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 - ジェームズ 
> 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  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 wrote:
>>
>>>  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  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 wrote:
>
>> 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  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" 
> 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" 
> 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
>
>
>
>  
>
>
> ___
> 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  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  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] [Devstack] [IPv6]

[Martinx - ジェームズ]

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


On 16 April 2014 12:03, Robert Li (baoli)  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 - ジェームズ]

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 - ジェームズ  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 - ジェームズ  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 - ジェームズ 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 

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 - ジェームズ  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 - ジェームズ  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 - ジェームズ 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| Va

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 - ジェームズ  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 - ジェームズ  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
>>|
>&g

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 - ジェームズ  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 - ジェームズ  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 

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 - ジェームズ  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  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 - ジェームズ]

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  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 - ジェームズ]

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  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.l

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  wrote:

>
>
> On 4/10/2014 10:41 AM, Martinx - ジェームズ wrote:
>
>> Mmm... Okay, sorry!:-)
>>
>>
>> On 10 April 2014 12:37, Ben Nemec > <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
>> 2

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

[Martinx - ジェームズ]

Mmm... Okay, sorry!:-)


On 10 April 2014 12:37, Ben Nemec  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
>> 

[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] [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  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 
> 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] 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 wrote:

> 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] [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 wrote:

> 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] 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  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] 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  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 - ジェームズ]

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 wrote:

> 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 - ジェームズ]

Okay, cool! I'll... Tks!


On 2 April 2014 12:49, Collins, Sean wrote:

> 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

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 wrote:

> 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 - ジェームズ]

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 wrote:

> 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

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

[Martinx - ジェームズ]

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
___
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 wrote:

>  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 wrote:
>
>>  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 - ジェームズ]

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 wrote:

>  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 - ジェームズ]

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 wrote:

>  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

[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] 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  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)" 
> 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

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 - ジェームズ  wrote:

> Sure! I'll...=)
>
>
> On 2 February 2014 13:32, Dolph Mathews  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 - ジェームズ]

Sure! I'll...=)


On 2 February 2014 13:32, Dolph Mathews  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 - ジェームズ  > 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

[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] [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 wrote:

> > 2014/1/16 NOTSU Arata :
> > > 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  wrote:

>
> 在 2014年1月8日，20:24，Nir Yechiel  写道：
>
> 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 ), 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 wrote:

> 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  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  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  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

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  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) wrote:

> On Nov 19, 2013, at 7:23 PM, Martinx - ジェームズ 
> 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 - ジェームズ 
> 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

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 - ジェームズ 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:
>
> ---
> 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

[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