Re: [openstack-dev] [nova][neutron] numa aware vswitch

[Guo, Ruijing]

Hi, Stephen, Sean

It worked as expected.

Thanks,
-Ruijing

-Original Message-
From: Stephen Finucane [mailto:sfinu...@redhat.com] 
Sent: Monday, August 27, 2018 5:37 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [nova][neutron] numa aware vswitch

On Mon, 2018-08-27 at 10:24 +0100, Sean Mooney wrote:
> 
> 
> On Mon 27 Aug 2018, 04:20 Guo, Ruijing,  wrote:
> > Hi, Stephen,
> > 
> > After setting flavor, VM was created in node 0 (expect in node1). How to 
> > debug it?
> > 
> > Nova.conf
> > [neutron]
> > physnets = physnet0,physnet1
> > 
> > [neutron_physnet_physnet1]
> > numa_nodes = 1
> 
> Have you enabled the numa topology filter its off by default and without it 
> the numa aware vswitch code is disabled.

Yeah, make sure this is enabled. You should turn on debug-level logging as this 
will give you additional information about how things are being scheduled. 
Also, is this a new deployment? If not, you're going to need to upgrade and 
restart all the nova-* services since there are object changes which will need 
to be propagated.

Stephen

> > openstack network create net1 --external 
> > --provider-network-type=vlan --provider-physical-network=physnet1 
> > --provider-segment=200 ...
> > openstack server create --flavor 1 --image=cirros-0.3.5-x86_64-disk 
> > --nic net-id=net1 vm1
> > 
> > 
> > 1024
> > 
> > 
> >   
> > 
> > available: 2 nodes (0-1)
> > node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23 node 0 size: 
> > 64412 MB node 0 free: 47658 MB node 1 cpus: 8 9 10 11 12 13 14 15 24 
> > 25 26 27 28 29 30 31 node 1 size: 64502 MB node 1 free: 44945 MB 
> > node distances:
> > node   0   1 
> >   0:  10  21 
> >   1:  21  10
> > 
> > Thanks,
> > -Ruijing
> > 
> > -Original Message-
> > From: Stephen Finucane [mailto:sfinu...@redhat.com]
> > Sent: Saturday, August 25, 2018 12:15 AM
> > To: OpenStack Development Mailing List (not for usage questions) 
> > 
> > Subject: Re: [openstack-dev] [nova][neutron] numa aware vswitch
> > 
> > On Fri, 2018-08-24 at 09:13 -0500, Matt Riedemann wrote:
> > > On 8/24/2018 8:58 AM, Stephen Finucane wrote:
> > > > Using this won't add a NUMA topology - it'll just control how 
> > > > any topology present will be mapped to the guest. You need to 
> > > > enable dedicated CPUs or a explicitly request a NUMA topology 
> > > > for this to work.
> > > > 
> > > > openstack flavor set --property hw:numa_nodes=1 1
> > > > 
> > > > 
> > > > 
> > > > openstack flavor set --property hw:cpu_policy=dedicated 1
> > > > 
> > > > 
> > > > This is perhaps something that we could change in the future, 
> > > > though I haven't given it much thought yet.
> > > 
> > > Looks like the admin guide [1] should be updated to at least refer 
> > > to the flavor user guide on setting up these types of flavors?
> > > 
> > > [1]
> > > https://docs.openstack.org/nova/latest/admin/networking.html#numa-
> > > affi
> > > nity
> > 
> > Good idea.
> > 
> > https://review.openstack.org/596393
> > 
> > Stephen


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

Re: [openstack-dev] [nova][neutron] numa aware vswitch

[Guo, Ruijing]

Hi, Stephen,

After setting flavor, VM was created in node 0 (expect in node1). How to debug 
it?

Nova.conf
[neutron]
physnets = physnet0,physnet1

[neutron_physnet_physnet1]
numa_nodes = 1

openstack network create net1 --external --provider-network-type=vlan 
--provider-physical-network=physnet1 --provider-segment=200
...
openstack server create --flavor 1 --image=cirros-0.3.5-x86_64-disk --nic 
net-id=net1 vm1


1024


  

available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 0 size: 64412 MB
node 0 free: 47658 MB
node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31
node 1 size: 64502 MB
node 1 free: 44945 MB
node distances:
node   0   1 
  0:  10  21 
  1:  21  10

Thanks,
-Ruijing

-Original Message-
From: Stephen Finucane [mailto:sfinu...@redhat.com] 
Sent: Saturday, August 25, 2018 12:15 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [nova][neutron] numa aware vswitch

On Fri, 2018-08-24 at 09:13 -0500, Matt Riedemann wrote:
> On 8/24/2018 8:58 AM, Stephen Finucane wrote:
> > Using this won't add a NUMA topology - it'll just control how any 
> > topology present will be mapped to the guest. You need to enable 
> > dedicated CPUs or a explicitly request a NUMA topology for this to 
> > work.
> > 
> > openstack flavor set --property hw:numa_nodes=1 1
> > 
> > 
> > 
> > openstack flavor set --property hw:cpu_policy=dedicated 1
> > 
> > 
> > This is perhaps something that we could change in the future, though 
> > I haven't given it much thought yet.
> 
> Looks like the admin guide [1] should be updated to at least refer to 
> the flavor user guide on setting up these types of flavors?
> 
> [1] 
> https://docs.openstack.org/nova/latest/admin/networking.html#numa-affi
> nity

Good idea.

https://review.openstack.org/596393

Stephen


__
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] [nova][neutron] numa aware vswitch

[Guo, Ruijing]

Hi, All,

I am verifying numa aware vwitch features 
(https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-vswitches.html).
 But the result is not my expectation.

What I missing?


Nova configuration:

[filter_scheduler]
track_instance_changes = False
enabled_filters = 
RetryFilter,AvailabilityZoneFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter,SameHostFilter,DifferentHostFilter,NUMATopologyFilter

[neutron]
physnets = physnet0,physnet1

[neutron_physnet_physnet0]
numa_nodes = 0

[neutron_physnet_physnet1]
numa_nodes = 1


ml2 configuration:

[ml2_type_vlan]
network_vlan_ranges = physnet0,physnet1
[ovs]
vhostuser_socket_dir = /var/lib/libvirt/qemu
bridge_mappings = physnet0:br-physnet0,physnet1:br-physnet1


command list:

openstack network create net0 --external --provider-network-type=vlan 
--provider-physical-network=physnet0 --provider-segment=100
openstack network create net1 --external --provider-network-type=vlan 
--provider-physical-network=physnet1 --provider-segment=200
openstack subnet create --network=net0 --subnet-range=192.168.1.0/24 
--allocation-pool start=192.168.1.200,end=192.168.1.250 --gateway 192.168.1.1 
subnet0
openstack subnet create --network=net1 --subnet-range=192.168.2.0/24 
--allocation-pool start=192.168.2.200,end=192.168.2.250 --gateway 192.168.2.1 
subnet1
openstack server create --flavor 1 --image=cirros-0.3.5-x86_64-disk --nic 
net-id=net0 vm0
openstack server create --flavor 1 --image=cirros-0.3.5-x86_64-disk --nic 
net-id=net1 vm1

vm0 and vm1 are created but numa is not enabled:
  1
  
1024
  






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

Re: [openstack-dev] [nova] Discussions for DPDK support in OpenStack

[Guo, Ruijing]

Get information that  DPDK removed ivshmem
from http://dpdk.org/ml/archives/dev/2016-July/044552.html

-Original Message-
From: TETSURO NAKAMURA [mailto:nakamura.tets...@lab.ntt.co.jp] 
Sent: Friday, April 28, 2017 12:23 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova] Discussions for DPDK support in OpenStack

Hi Nova team,

I'm writing this e-mail because I'd like to have a discussion about DPDK 
support at OpenStack Summit in Boston.

We have developed a dpdk-based patch panel named SPP[1], and we'd like to start 
working on Openstack (ML2 driver) to develop "networking-spp".

Especially, we'd like to use DPDK-ivshmem that was used to be used to create 
"dpdkr" interface in ovs-dpdk[2].

We have issued a blueprint[3] for that use case.

As we are attending Boston Summit, could you have a discussion with us at the 
Summit?

[1] http://www.dpdk.org/browse/apps/spp/
[2]
http://openvswitch.org/support/dist-docs-2.5/INSTALL.DPDK.md.html#L446-L490
[3] https://blueprints.launchpad.net/nova/+spec/libvirt-options-for-dpdk

Sincerely,

--
Tetsuro Nakamura  NTT Network Service Systems 
Laboratories
TEL:0422 59 6914(National)/+81 422 59 6914(International) 3-9-11, Midori-Cho 
Musashino-Shi, Tokyo 180-8585 Japan



__
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] [third-party][ci] openstack CI VM template

[Guo, Ruijing]

Hi, CI Team,

I'd like to know if openstack CI VM support nested virtualization.

Thanks,
-Ruijing
__
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 jenkins failure

[Guo, Ruijing]

Hi,

There are lots of openstack Jenkins failure. Anyone from 
infrastructure
 team look at the issue?

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

Re: [openstack-dev] [Fuel] Getting rid of ISO

[Guo, Ruijing]

Hi, Vladimir

Any guide to install from rpm?

Thanks,
-Ruijing
From: Vladimir Kozhukalov [mailto:vkozhuka...@mirantis.com]
Sent: Tuesday, August 16, 2016 4:58 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Fuel] Getting rid of ISO

Dear colleagues,
We finally have working custom deployment job that deploys Fuel admin node 
using online RPM repositories (not ISO) on vanilla Centos 7.0.

Currently all Fuel system and deployment tests use ISO and we are planning to 
re-implement all these jobs (including BVT, SWARM, and Fuel CI jobs) to exclude 
ISO from the pipeline. That will allow us to get rid of ISO as our deliverable 
and instead rely totally on package repositories. Linux distributions like 
Ubuntu, Debian, RHEL, etc. are already delivered via ISO/qcow2/etc. images and 
we'd better stop reinventing a wheel and support our own ISO build code. That 
will allow us to make Fuel admin node deployment more flexible.

I will infrom about our next steps here in the thread.

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

Re: [openstack-dev] [Fuel] Getting rid of ISO

[Guo, Ruijing]

Congratuations. any plan to have fuel docker image?

From: Oleg Gelbukh [mailto:ogelb...@mirantis.com]
Sent: Thursday, September 8, 2016 4:28 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Fuel] Getting rid of ISO

Congratulations, Vladimir, that's a huge step in a right direction for Fuel.

--
Best regards,
Oleg Gelbukh

On Wed, Sep 7, 2016 at 6:47 AM, Vladimir Kozhukalov 
> wrote:
Dear colleagues,
I'm glad to announce that we have working BVT jobs on Fuel CI that do not use 
ISO but instead deploy Fuel admin node from packages onto vanilla Centos 7.
Please take a look at [1]. There are jobs '10.0.repos.*' [2], [3], [4].
We continue to work on re-implementing review jobs like this one [5] for 
example.


[1] https://ci.fuel-infra.org/view/BVT/
[2] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.snapshot/
[3] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.main.ubuntu.bvt_2/
[4] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.main.ubuntu.smoke_neutron/
[5] 
https://ci.fuel-infra.org/job/master.fuel-astute.pkgs.ubuntu.review_astute_patched/



Vladimir Kozhukalov

On Thu, Sep 1, 2016 at 1:13 PM, Roman Prykhodchenko 
> wrote:
This is so awesome! Thanks!

On Tue, Aug 16, 2016 at 4:30 PM Jay Pipes 
> wrote:
On 08/16/2016 04:58 AM, Vladimir Kozhukalov wrote:
> Dear colleagues,
>
> We finally have working custom deployment job that deploys Fuel admin
> node using online RPM repositories (not ISO) on vanilla Centos 7.0.

Bravo! :)

> Currently all Fuel system and deployment tests use ISO and we are
> planning to re-implement all these jobs (including BVT, SWARM, and Fuel
> CI jobs) to exclude ISO from the pipeline. That will allow us to get rid
> of ISO as our deliverable and instead rely totally on package
> repositories. Linux distributions like Ubuntu, Debian, RHEL, etc. are
> already delivered via ISO/qcow2/etc. images and we'd better stop
> reinventing a wheel and support our own ISO build code. That will allow
> us to make Fuel admin node deployment more flexible.
>
> I will infrom about our next steps here in the thread.

Thanks, Vova, this is an excellent step forward for ease-of-use with Fuel.

Nice work,
-jay

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

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


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

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

Re: [openstack-dev] [Fuel] Fuel 9.0 is released

[Guo, Ruijing]

Can we support alternative way to download ISO since p2p may be prevented in 
some company IT?

Thanks,
-Ruijing

From: Vladimir Kozhukalov [mailto:vkozhuka...@mirantis.com]
Sent: Thursday, April 21, 2016 10:52 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Fuel] Fuel 9.0 is released


Dear all,


I am glad to announce Mitaka release of Fuel (a.k.a Fuel 9.0) - deployment

and lifecycle management tool for OpenStack.


This release introduces support for OpenStack Mitaka and adds

a number of new features and enhancements.


Some highlights:
- Support lifecycle management operations (a.k.a ‘day 2’ operations).
Now cluster settings tab on UI is unlocked after deployment
(cluster configuration could be changed). [1]
- Support of custom deployment graphs. Default deployment graph
could be overridden either by plugins or by a user. [2]
- Support of DPDK capabilities [3]
- Support of Huge Pages capabilities [4]
- Support of CPU pinning (NUMA) capabilities [5]
- Support of QoS capabilities [6]
- Support of SR-IOV capabilities [7]
- Support of multipath devices [8]
- Support of deployment using UCA packages [9]

Please be aware that it is not intended for production use and

there are still about 90 known High bugs [10]. We are planning

to address them all in Fuel 9.0.1 release which is scheduled

for late June [11].


We are looking forward to your feedback.
Great work, Fuel team. Thanks to everyone.


[1] 
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/unlock-settings-tab.rst

[2] 
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/execute-custom-graph.rst

[1] 
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/support-dpdk.rst

[3] 
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/execute-custom-graph.rst
[4] 
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/support-hugepages.rst
[5] 
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/support-numa-cpu-pinning.rst
[6] 
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/support-qos.rst
[7] 
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/support-sriov.rst
[8] 
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/fc-multipath-disks.rst
[9] https://blueprints.launchpad.net/fuel/+spec/deploy-with-uca-packages

[10] https://goo.gl/qXfrhQ

[11] https://wiki.openstack.org/wiki/Fuel/9.0_Release_Schedule


Learn more about Fuel:
https://wiki.openstack.org/wiki/Fuel

How we work:
https://wiki.openstack.org/wiki/Fuel/How_to_contribute

Specs for features in 9.0 and other Fuel releases:
http://specs.openstack.org/openstack/fuel-specs/

ISO image:
http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-9.0.iso.torrent

Test results of the release build:
https://ci.fuel-infra.org/job/9.0-community.test_all/61/

Documentation:
http://docs.openstack.org/developer/fuel-docs/


RPM packages:
http://mirror.fuel-infra.org/mos-repos/centos/mos9.0-centos7/

DEB packages:
http://mirror.fuel-infra.org/mos-repos/ubuntu/9.0/
Vladimir Kozhukalov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] Restart openstack service

[Guo, Ruijing]

If you can commit it to devstack, it will benefit everyone

-Original Message-
From: Tony Breeds [mailto:t...@bakeyournoodle.com] 
Sent: Friday, August 14, 2015 12:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [devstack] Restart openstack service

On Fri, Aug 14, 2015 at 04:01:20AM +, Guo, Ruijing wrote:
 Yes. I like this idea to restart all services including nova, neutron, 
 cinder, etc:)

You can *probably* use 

HOST=devstack.domain ./stack-smash.sh '.*'

to restart all the services running under devstack.

Note my list of windows is taken from my typical run and isn't comprehensive

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

Re: [openstack-dev] [devstack] Restart openstack service

[Guo, Ruijing]

Yes. I like this idea to restart all services including nova, neutron, cinder, 
etc:)

-Original Message-
From: Tony Breeds [mailto:t...@bakeyournoodle.com] 
Sent: Friday, August 14, 2015 11:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [devstack] Restart openstack service

On Fri, Aug 14, 2015 at 11:31:07AM +0800, Rui Chen wrote:
 I use *screen* in devstack, Ctrl+c kill services, then restart it in 
 console.
 
 Please try the following cmd in your devstack environment, and read 
 some docs.
 
 *screen -r stack*
 
 http://www.ibm.com/developerworks/cn/linux/l-cn-screen/

It's not baked into devstack but I have a script called 'stack-smash.sh' which 
I run like

HOST=devstack.domain ./stack-smash.sh nova

to restart all the nova services in a running devstack.

---
#!/opt/local/bin/bash

if [ -z $1 ] ; then
set -- nova
fi

if [ -z $HOST ] ; then
echo HOST= $0 $@ 2
exit 1
fi

for service in $@ ; do
pattern=''

case $service in
nova)   pattern=^n- ;;
glance) pattern=^g- ;;
cinder) pattern=^c- ;;
keystone)   pattern=^key;;
*)  pattern=$service;;
esac

for win in  key key-access g-reg g-api n-api n-cond n-crt n-net \
n-sch n-novnc n-cauth n-sproxy n-cpu c-api c-sch c-vol ; do

[ -z $pattern ]  continue

if [[ $win =~ $pattern ]] ; then
echo -n Killing window=$win for service=$service
ssh $HOST -qt screen -S stack -p $win -X stuff '' # this is a 
literal control-C
sleep 1s
ssh $HOST -qt screen -S stack -p $win -X stuff '!!\\n'
sleep 1s
echo  ... done.

fi
done
done
---

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

Re: [openstack-dev] [devstack] Restart openstack service

[Guo, Ruijing]

I need to reboot hosts and restart openstack services. In this case, screen may 
not help.


From: Rui Chen [mailto:chenrui.m...@gmail.com]
Sent: Friday, August 14, 2015 11:31 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [devstack] Restart openstack service

I use screen in devstack, Ctrl+c kill services, then restart it in console.

Please try the following cmd in your devstack environment, and read some docs.

screen -r stack

http://www.ibm.com/developerworks/cn/linux/l-cn-screen/



2015-08-14 11:20 GMT+08:00 Guo, Ruijing 
ruijing@intel.commailto:ruijing@intel.com:
It is very useful to restart openstack services in devstack so that we don’t 
need to unstack and stack again.

How much effort to support restarting openstack? Anyone is interested in that?

Thanks,
-Ruijing

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [devstack] Restart openstack service

[Guo, Ruijing]

It is very useful to restart openstack services in devstack so that we don’t 
need to unstack and stack again.

How much effort to support restarting openstack? Anyone is interested in that?

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

[openstack-dev] [nova] upgrade_levels in nova upgrade

[Guo, Ruijing]

Hi, All,

In existing design, we need to reconfig nova.conf and restart nova service 
during post-upgrade cleanup
As https://www.rdoproject.org/Upgrading_RDO_To_Icehouse:

I propose to send RPC message to remove RPC API version pin.



1.   Stop services  (same with existing)

2.   Upgrade packages (same with existing)

3.   Upgrade DB schema (same with existint)

4.   Start service with upgrade  (add upgrade parameter so that nova will 
use old version of RPC API. We may add more parameter for other purpose 
including query upgrade progress)

5.   Send RPC message to remove RPC API version pin. (we don't need to 
reconfig nova.conf and restart nova service)

What do you think?

Thanks,
-Ruijing


__
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] [puppet] puppet support for openstack rolling upgrade

[Guo, Ruijing]

Hi,

I understand openstack puppet support fresh installation. I'd like to know 
openstack puppet support rolling upgrade.

1. DB Rolling upgrade
2. openstack configuration upgrade.
3. software package upgrade.
4. service rolling upgrade

Thanks
-Ruijing

__
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] [puppet] Openstack Cluster Management

[Guo, Ruijing]

Apache Ambari(https://ambari.apache.org/) is to manage Hadoop cluster. Is it 
possible to port ambari framework to manage Openstack cluster.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] neutron DB upgrade

[Guo, Ruijing]

Somebody can help me to understand why neutron DB is needed upgrade even in 
refresh installation unlike other components.

From my understanding,  DB upgrade is risky and needed when upgrade.

Release A should have schema A and Release B should have schema B.

Only upgrade A to B need to upgrade DB.

In the same time,  can we separate neutron DB as vendor DB  non-vendor DB?

1.  For that case, we can upgrade vendor DB if we use some vendor scenario.

2. we already separate vendor code from neutron code base.

Thanks,
-Ruijing

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

Re: [openstack-dev] [neutron] neutron DB upgrade

[Guo, Ruijing]

Thanks for your detail explanation.

I agree with you that we still use DB upgrade when fresh installation.

Yes. It happened to me that unused vendor DB upgrade failure causes neutron DB 
upgrade failure.
I have little concerns about adding whole DB upgrade in one directory 
alembic_migrations/versions.

It is difficult for devops to debug/workaround the issue.

I suggest to separate according to components or enforce file name as 
Revision_component_desctiption.py.

If I don’t use the component and DB for that component upgrade fails, I can 
safely delete *component*.

Thanks,
-Ruijing


From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Tuesday, April 21, 2015 9:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] neutron DB upgrade



On 21 April 2015 at 14:25, Guo, Ruijing 
ruijing@intel.commailto:ruijing@intel.com wrote:
Somebody can help me to understand why neutron DB is needed upgrade even in 
refresh installation unlike other components.

From my understanding,  DB upgrade is risky and needed when upgrade.

Alembic is a fairly reliable tool for managing DB upgrades.
Also there are enough tests in place to ensure the sanity of each db 
migration and that the DB schema is always in sync with business logic's data 
model.


Release A should have schema A and Release B should have schema B.

This will make really difficult doing testing during the development cycle. 
While all interim migrations added during the release cycle can be squashed 
into a single migration provided at release time, this action will probably 
transform a relatively safe process into a risky one, as there will be little 
time to react to issues introduced by that single migration.


Only upgrade A to B need to upgrade DB.

This is what happens for most users. However there still are a few which more 
or less closely follow trunk - that is to say they're not tied to any specific 
release.
Also, this does not apply to developers and CI (which is ultimately one of the 
principal tools we use to ensure what we deliver is not completely rubbish).


In the same time,  can we separate neutron DB as vendor DB  non-vendor DB?

We had vendor or plugin specific migrations until Juno. When he had these kind 
of conditional migrations doing DB upgrades was very risky. DB schema 
management has become a lot simpler and safer since we unified the schema.

However, as a part of the vendor plugin split out there will be eventually a 
next step where all vendor-specific tables are moved into their own dbs.
Are tables for plugins which are not ML2 causing you any problem?


1.  For that case, we can upgrade vendor DB if we use some vendor scenario.

2. we already separate vendor code from neutron code base.

Thanks,
-Ruijing

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

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

Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd

[Guo, Ruijing]

Hi, Edgar,

The following documents are still in private branch:

Scenario 1a - Legacy Content - Ready for conversion to 
RSThttps://github.com/ionosphere80/openstack-networking-guide/blob/master/scenario-legacy-ovs/scenario-legacy-ovs.md
Scenario 1b - Legacy Content - Ready for conversion to 
RSThttps://github.com/ionosphere80/openstack-networking-guide/blob/master/scenario-legacy-lb/scenario-legacy-lb.md
Scenario 2 - High availability (DVR and Open vSwitch) Content - Ready for 
conversion to 
RSThttps://github.com/ionosphere80/openstack-networking-guide/blob/master/scenario-dvr/scenario-dvr.md
Scenario 3b - High availability (L3 HA and Linux Bridge) Content - Work in 
Progresshttps://github.com/phil-hopkins-a/openstack-networking-guide

Thanks,
-Ruijing

From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Tuesday, April 21, 2015 10:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 
23rd

Hello,

Which Docs are you referring?  Please, point me to the specific Docs in private 
branches to find out the process to move them to public.

Thanks,

Edgar

From: Guo, Ruijing ruijing@intel.commailto:ruijing@intel.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, April 20, 2015 at 9:52 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 
23rd

Hi, Edgar

Some docs are still in private branch. Can we move to public branch for 
reviewing  submitting patches?

Thanks,
-Ruijing

From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Saturday, April 18, 2015 2:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd

Hello Folks,

I would like to invite all available contributors to help us to complete the 
OpenStack Networking Guide.

We are having a Networking Doc Day on April 23rd in order to review the current 
guide and make a big push on its content.
Let's use both the Neutron and Docs IRC channels:
#openstack-neutron
#openstack-doc

All the expected content is being described in the TOC:
https://wiki.openstack.org/wiki/NetworkingGuide/TOC

Information for Doc contributors in here:
https://wiki.openstack.org/wiki/Documentation/HowTo#Edit_OpenStack_RST_and.2For_DocBook_documentation

We have prepared an etherpad to coordinate who is doing what:
https://etherpad.openstack.org/p/networking-guide

There are so many ways you can contribute:

  *   Assign to yourself one of the available chapters
  *   Review the current content and open bugs if needed
  *   Review the existing gerrit commit if you are familiar with the information
  *   Be available on IRC to answer some questions about configuration details 
or functionality
  *   Cheering at the contributors!
Do not hesitate in contacting me for any questions.

Cheers!

Edgar Magana
IRC: emagana
emag...@gmail.commailto:emag...@gmail.com
edgar.mag...@workday.commailto:edgar.mag...@workday.com
__
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] [docs] Networking Guide Doc Day - April 23rd

[Guo, Ruijing]

Hi, Edgar

Some docs are still in private branch. Can we move to public branch for 
reviewing  submitting patches?

Thanks,
-Ruijing

From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Saturday, April 18, 2015 2:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd

Hello Folks,

I would like to invite all available contributors to help us to complete the 
OpenStack Networking Guide.

We are having a Networking Doc Day on April 23rd in order to review the current 
guide and make a big push on its content.
Let's use both the Neutron and Docs IRC channels:
#openstack-neutron
#openstack-doc

All the expected content is being described in the TOC:
https://wiki.openstack.org/wiki/NetworkingGuide/TOC

Information for Doc contributors in here:
https://wiki.openstack.org/wiki/Documentation/HowTo#Edit_OpenStack_RST_and.2For_DocBook_documentation

We have prepared an etherpad to coordinate who is doing what:
https://etherpad.openstack.org/p/networking-guide

There are so many ways you can contribute:

  *   Assign to yourself one of the available chapters
  *   Review the current content and open bugs if needed
  *   Review the existing gerrit commit if you are familiar with the information
  *   Be available on IRC to answer some questions about configuration details 
or functionality
  *   Cheering at the contributors!
Do not hesitate in contacting me for any questions.

Cheers!

Edgar Magana
IRC: emagana
emag...@gmail.commailto:emag...@gmail.com
edgar.mag...@workday.commailto:edgar.mag...@workday.com
__
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] openwrt VM as service

[Guo, Ruijing]

Service VM is a good way to go.

Possibly we need to change metadata proxy in neutron for VM based L3:

https://blueprints.launchpad.net/neutron/+spec/metadata-overlapping-networks

Thanks,
-Ruijing


From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Friday, April 17, 2015 1:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] openwrt VM as service

As mentioned earlier in this thread there are few VM based L3 implementations 
already in neutron - from Cisco (CSR) and Brocade (Vyatta vRouter). Both 
extends off neutron L3 service-plugin framework. And they both have been 
decomposed in the current Kilo cycle into stackforge. So all you need is 
another L3 service-plugin for openwrt hosted in stackforge. I don't see any 
framework level enhancements required to support this.

However I do see some value in extracting common elements off these 
service-VM implementations - particularly related to launching the VM, 
plumbing the ports, etc into an utility library (oslo? tacker?).

- Sridhar

On Thu, Apr 16, 2015 at 2:06 PM, Sławek Kapłoński 
sla...@kaplonski.plmailto:sla...@kaplonski.pl wrote:
Hello,

--
Pozdrawiam
Sławek Kapłoński
sla...@kaplonski.plmailto:sla...@kaplonski.pl

On Wed, Apr 15, 2015 at 11:06:49PM +0200, Salvatore Orlando wrote:
 I think this work falls into the service VM category.

 openwrt unlike other service VMs used for networking services (like
 cloudstack's router vm) is very lightweight, and it's fairly easy to
 provision such VMs on the fly. It should be easy also to integrate with a
 ML2 control plane or even with other plugins.

 It is a decent alternative to the l3 agent. Possibly to the dhcp agent as
 well. As I see this as an alternative to part of the reference control
 plane, I expect it to provide its own metadata proxy. The only change in
 neutron would be some sort of configurability in the metadata proxy
 launcher (assuming you do not provide DHCP as well via openwrt, in which
 case the problem would not exist, probably).

 It's not my call about whether this should live in neutron or not. My vote
 is not - simply because I believe that neutron is not a control plane, and
 everything that is control plane or integration with it should live outside
 of neutron, including our agents.

 On the other hand, I don't really see what the 'aaS' part of this. You're
 not exposing anything as a service specific to openwrt, are you?

I told here only my (maybe not good) idea that instead of openwrt as a
service which will provide router functionalities in vm maybe better
would be to provide some mechanism to make possibility to connect
different vms which provide such router functionalities (something like
service here).


 Salvatore



 On 15 April 2015 at 22:06, Sławek Kapłoński 
 sla...@kaplonski.plmailto:sla...@kaplonski.pl wrote:

  Hello,
 
  I agree. IMHO it should be maybe something like *aaS deployed on VM. I
  think that Octavia is something like that for LBaaS now.
  Maybe it could be something like RouteraaS which will provide all such
  functions in VM?
 
  --
  Best regards / Pozdrawiam
  Sławek Kapłoński
  sla...@kaplonski.plmailto:sla...@kaplonski.pl
 
  On Wed, Apr 15, 2015 at 11:55:06AM -0500, Dean Troyer wrote:
   On Wed, Apr 15, 2015 at 2:37 AM, Guo, Ruijing 
   ruijing@intel.commailto:ruijing@intel.com
  wrote:
  
  I’d like to propose openwrt VM as service.
   
   
   
What’s openWRT VM as service:
   
   
   
a)Tenant can download openWRT VM from
http://downloads.openwrt.org/
   
b)Tenant can create WAN interface from external public
  network
   
c)Tenant can create private network and create instance
  from
private network
   
d)Tenent can configure openWRT for several services
  including
DHCP, route, QoS, ACL and VPNs.
   
  
  
   So first off, I'll be the first on in line to promote using OpenWRT for
  the
   basis of appliances for this sort of thing.  I use it to overcome the
  'joy'
   of VirtualBox's local networking and love what it can do in 64M RAM.
  
   However, what you are describing are services, yes, but I think to focus
  on
   the OpenWRT part of it is missing the point.  For example, Neutron has a
   VPNaaS already, but I agree it can also be built using OpenWRT and
   OpenVPN.  I don't think it is a stand-alone service though, using a
   combination of Heat/{ansible|chef|puppet|salt}/any other
   deployment/orchestration can get you there.  I have a shell script
   somewhere for doing exactly that on AWS from way back.
  
   What I've always wanted was an image builder that would customize the
   packages pre-installed.  This would be especially useful for disposable
   ramdisk-only or JFFS images that really can't install additional
  packages.
   Such a front-end to the SDK/imagebuilder sounds like about half of what
  you
   are talking about above.
  
   Also, FWIW, a while back I

Re: [openstack-dev] [neutron] openwrt VM as service

[Guo, Ruijing]

Hi,

Yes. The idea is to integrate openwrt with openstack.

Possibly RouteraaS(RTasS) like LBaaS is the best way to go.

Combination of heat/puppet/chef and neutron  openwrt modification is 
integration content.

Neutron provides L2 functions including create/delete port/interface. All 
L3/VPN functions are provided by RTaaS.

So tenant can choose L3 functions from neutron or from RTaaS.

After integration, we can fix the gap between openwrt  openstack.


Thanks,
-Ruijing

From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Thursday, April 16, 2015 5:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] openwrt VM as service

I think this work falls into the service VM category.

openwrt unlike other service VMs used for networking services (like 
cloudstack's router vm) is very lightweight, and it's fairly easy to provision 
such VMs on the fly. It should be easy also to integrate with a ML2 control 
plane or even with other plugins.

It is a decent alternative to the l3 agent. Possibly to the dhcp agent as well. 
As I see this as an alternative to part of the reference control plane, I 
expect it to provide its own metadata proxy. The only change in neutron would 
be some sort of configurability in the metadata proxy launcher (assuming you do 
not provide DHCP as well via openwrt, in which case the problem would not 
exist, probably).

It's not my call about whether this should live in neutron or not. My vote is 
not - simply because I believe that neutron is not a control plane, and 
everything that is control plane or integration with it should live outside of 
neutron, including our agents.

On the other hand, I don't really see what the 'aaS' part of this. You're not 
exposing anything as a service specific to openwrt, are you?

Salvatore



On 15 April 2015 at 22:06, Sławek Kapłoński 
sla...@kaplonski.plmailto:sla...@kaplonski.pl wrote:
Hello,

I agree. IMHO it should be maybe something like *aaS deployed on VM. I
think that Octavia is something like that for LBaaS now.
Maybe it could be something like RouteraaS which will provide all such
functions in VM?

--
Best regards / Pozdrawiam
Sławek Kapłoński
sla...@kaplonski.plmailto:sla...@kaplonski.pl

On Wed, Apr 15, 2015 at 11:55:06AM -0500, Dean Troyer wrote:
 On Wed, Apr 15, 2015 at 2:37 AM, Guo, Ruijing 
 ruijing@intel.commailto:ruijing@intel.com wrote:

I’d like to propose openwrt VM as service.
 
 
 
  What’s openWRT VM as service:
 
 
 
  a)Tenant can download openWRT VM from
  http://downloads.openwrt.org/
 
  b)Tenant can create WAN interface from external public network
 
  c)Tenant can create private network and create instance from
  private network
 
  d)Tenent can configure openWRT for several services including
  DHCP, route, QoS, ACL and VPNs.
 


 So first off, I'll be the first on in line to promote using OpenWRT for the
 basis of appliances for this sort of thing.  I use it to overcome the 'joy'
 of VirtualBox's local networking and love what it can do in 64M RAM.

 However, what you are describing are services, yes, but I think to focus on
 the OpenWRT part of it is missing the point.  For example, Neutron has a
 VPNaaS already, but I agree it can also be built using OpenWRT and
 OpenVPN.  I don't think it is a stand-alone service though, using a
 combination of Heat/{ansible|chef|puppet|salt}/any other
 deployment/orchestration can get you there.  I have a shell script
 somewhere for doing exactly that on AWS from way back.

 What I've always wanted was an image builder that would customize the
 packages pre-installed.  This would be especially useful for disposable
 ramdisk-only or JFFS images that really can't install additional packages.
 Such a front-end to the SDK/imagebuilder sounds like about half of what you
 are talking about above.

 Also, FWIW, a while back I packaged up a micro cloud-init replacement[0] in
 shell that turns out to be really useful.  It's based on something I
 couldn't find again to give proper attribution so if anyone knows who
 originated this I'd be grateful.

 dt

 [0] https://github.com/dtroyer/openwrt-packages/tree/master/rc.cloud
 --

 Dean Troyer
 dtro...@gmail.commailto:dtro...@gmail.com
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] openwrt VM as service

[Guo, Ruijing]

I’d like to propose openwrt VM as service.

What’s openWRT VM as service:

a)Tenant can download openWRT VM from http://downloads.openwrt.org/
b)Tenant can create WAN interface from external public network
c)Tenant can create private network and create instance from 
private network
d)Tenent can configure openWRT for several services including DHCP, 
route, QoS, ACL and VPNs.

What’s need to change in neutron:

a)Neutron support to create port for openWRT VM. (I assume it 
already support it and just integrate it)
b)Move metadata proxy to openWRT VM.

Why openstack need it?

a)It is easy for tenant to configure/customize  network service.
Especially, openstack doesn’t support specified VPN.  Tenent can configure VPN 
and don’t need develop new one and request cloud admin to deploy new VPN.
b)It is easy for openstack to deploy new network service.

Case 1: SNAT load balance. (We may propose it in neutron)

Currently, neutron l3 support one gateway IP. Neutron L3 does SNAT from private 
network to public network.

   Private network -SNAT--- public network

If the public network is down, all private network cannot access to external 
network.

If we do SNAT load balance, private network can do SNAT to 2 public network.
How to implement in openwrt VM:

1.Create port1 from public network 1
2.Create port2 from public network 2
3.Create port3 from private network
4.Create openwrt VM including port1, port2 and port3
5.Configure openwrt to do SNAT load balance from private network to 
public network 1 and publice network2

Case 2: VPN Service

I want to use OpenVPN. Without openwrt VM, I need to develop OpenVPN as VPN 
plugin and ask  openstack admin to deploy it (possibly, openstack cloud admin 
reject it)

How to implement in openwrt VM:

1.Create port1 from public network 1
2.Create port2 from private network
3.Create vpn server/client
4.NAT from private network to vpn network

What do you think?

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

[openstack-dev] [neutron] [devstack] neutron router ID is not set

[Guo, Ruijing]

Hi, All,

When Q_USE_NAMESPACE=False, router id is set by

create_neutron_initial_network
_neutron_configure_router_v4
_neutron_set_router_id

function _neutron_set_router_id {
if [[ $Q_USE_NAMESPACE == False ]]; then
iniset $Q_L3_CONF_FILE DEFAULT router_id $ROUTER_ID
fi
}

create_neutron_initial_network is called after neturon service is enabled.

However, router_id in l3 conf is expected to be set before neutron service is 
enabled.

Is it a bug?


Thanks,
-Ruijing
__
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] [cinder] FCoE support in openstack

[Guo, Ruijing]

Hi,

I saw openstack cinder already supported iscsi  FC and didn’t support FCoE. 
Any plan to support it?

Is there any BP to cover it? If not, I may draft for it.

Thanks,
-Ruijing
__
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] VLAN trunking network for NFV

[Guo, Ruijing]

I am trying to understand how guest os use trunking network.

If guest os use bridge like Linuxbride and OVS, how we launch it and how 
libvirt to support it?

Thanks,
-Ruijing


From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Wednesday, March 25, 2015 2:18 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] VLAN trunking network for NFV

That spec ensures that you can tell what the plugin is doing.  You can ask for 
a VLAN transparent network, but the cloud may tell you it can't make one.

The OVS driver in Openstack drops VLAN tagged packets, I'm afraid, and the spec 
you're referring to doesn't change that.  The spec does ensure that if you try 
and create a VLAN trunk on a cloud that uses the OVS driver, you'll be told you 
can't.  in the future, the OVS driver can be fixed, but that's how things stand 
at present.  Fixing the OVS driver really involves getting in at the OVS flow 
level - can be done, but we started with the basics.
If you want to use a VLAN trunk using the current code, I recommend VXLAN or 
GRE along with the Linuxbridge driver, both of which support VLAN transparent 
networking.  If they're configured and you ask for a VLAN trunk you'll be told 
you got one.
--
Ian.


On 24 March 2015 at 09:43, Daniele Casini 
daniele.cas...@dektech.com.aumailto:daniele.cas...@dektech.com.au wrote:
Hi all:

in reference to the following specification about the creation of VLAN trunking 
network for NFV

https://review.openstack.org/#/c/136554/3/specs/kilo/nfv-vlan-trunks.rst

I would like to better understand how the tagged traffic will be realized. In 
order to explain myself, I report the following use case:

A VNF is deployed in one VM, which has a trunk port carrying traffic for two 
VLANs over a single link able to transport more than one VLAN through a single 
integration-bridge (br-int) port. So, How does br-int manage the VLAN-ID? In 
other words, what are the action performed by the br-int when a VM forwards 
traffic to another host?
Does it put an additional tag or replace the existing one keeping the match 
with a table or something like that?

Thank you very much.

Daniele


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [devstack]Failure retrieving TENANT_ID for demo

[Guo, Ruijing]

1.   Probem description (compute/network node without keystone service is 
unsuccessfully deployed)

I use devstack to deploy mini-cluster. In controller node, keystone service is 
enabled and in compute/network node, keystone service is not enabled.

Controller node is deployed and compute/ successfully network is unsuccessfully 
deployed with following failure:

2015-02-27 06:32:20.337 | ERROR: openstack Authentication type must be selected 
with --os-auth-type
2015-02-27 06:32:20.355 | + TENANT_ID=
2015-02-27 06:32:20.359 | + die_if_not_set 530 TENANT_ID 'Failure retrieving 
TENANT_ID for demo'
2015-02-27 06:32:20.359 | + local exitcode=0
2015-02-27 06:32:20.366 | [Call Trace]
2015-02-27 06:32:20.366 | ./stack.sh:1203:create_neutron_initial_network
2015-02-27 06:32:20.366 | /opt/stack/devstack/lib/neutron:530:die_if_not_set
2015-02-27 06:32:20.366 | /opt/stack/devstack/functions-common:308:die
2015-02-27 06:32:20.363 | [ERROR] /opt/stack/devstack/functions-common:530 
Failure retrieving TENANT_ID for demo


2.   Root-cause



a.   The following variables are exported when keystone is enable.
if is_service_enabled keystone; then
…
 export OS_AUTH_URL=$SERVICE_ENDPOINT
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=$ADMIN_PASSWORD
export OS_REGION_NAME=$REGION_NAME
fi


b.  Neutron use the above exported varables:

function create_neutron_initial_network {

TENANT_ID=$(openstack project list | grep  demo  | get_field 1)

die_if_not_set $LINENO TENANT_ID Failure retrieving TENANT_ID for demo


3.   Solutions

Solution 1: enable keystone for all nodes when using devstack.


Solution 2: export the above variables if keystone is not enabled.

Solution 3: fix in devstack as:

--- stack.sh.orig   2015-02-28 00:24:31.784321431 +
+++ stack.sh2015-02-28 00:26:22.594307057 +
@@ -973,13 +973,14 @@
 # Begone token-flow auth
 unset OS_TOKEN OS_URL

-# Set up password-flow auth creds now that keystone is bootstrapped
-export OS_AUTH_URL=$SERVICE_ENDPOINT
-export OS_TENANT_NAME=admin
-export OS_USERNAME=admin
-export OS_PASSWORD=$ADMIN_PASSWORD
-export OS_REGION_NAME=$REGION_NAME
fi
+
+# Set up password-flow auth creds now that keystone is bootstrapped
+export OS_AUTH_URL=$SERVICE_ENDPOINT
+export OS_TENANT_NAME=admin
+export OS_USERNAME=admin
+export OS_PASSWORD=$ADMIN_PASSWORD
+export OS_REGION_NAME=$REGION_NAME

I’d like to create bug in devstack and provide patch for it. Any thought?

Thanks,
-Ruijing


__
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] [cinder] documenting volume replication

[Guo, Ruijing]

Hi, Ronen

3) I mean storage based replication. In normal, volume replication support FC 
or iSCSI. We need to setup FC or iSCSI before we do volume replication.

Case 1)

Host --FC--Storage A ---iSCSI  Storage B FC- Host

Case 2)

Host --FC--Storage A ---FC  Storage B FC- Host

As above diagram, we need to setup connection (iSCSI or FC) between storage A 
and Storage B.

For FC, we need to zone storage A  storage B in FC switch.

Thanks,
-Ruijing

From: Ronen Kat [mailto:ronen...@il.ibm.com]
Sent: Sunday, February 15, 2015 4:46 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] documenting volume replication

Hi Ruijing,

Thanks for the comments.
Re (1) - driver can implement replication in any means the driver see fit. It 
can be exported and be available to the scheduler/drive via the capabilities 
or driver extra-spec prefixes.
Re (3) - Not sure I see how this relates to storage side replication, do you 
refer to host side replication?

Ronen



From:Guo, Ruijing 
ruijing@intel.commailto:ruijing@intel.com
To:OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date:15/02/2015 03:41 AM
Subject:Re: [openstack-dev] [cinder] documenting volume replication




Hi, Ronen,

I don't know how to edit 
https://etherpad.openstack.org/p/cinder-replication-redoc and add some comments 
in email.

1. We may add asynchronized and synchronized type for replication.
2. We may add CG for replication
3. We may add to initialize connection for replication

Thanks,
-Ruijing

From: Ronen Kat [mailto:ronen...@il.ibm.com]
Sent: Tuesday, February 3, 2015 9:41 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [cinder] documenting volume replication

As some of you are aware the spec for replication is not up to date,
The current developer documentation, 
http://docs.openstack.org/developer/cinder/api/cinder.volume.driver.html, cover 
replication but some folks indicated that it need additional details.

In order to get the spec and documentation up to date I created an Etherpad to 
be a base for the update.
The Etherpad page is on 
https://etherpad.openstack.org/p/cinder-replication-redoc

I would appreciate if interested parties would take a look at the Etherpad, add 
comments, details, questions and feedback.

Ronen, 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto: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] [cinder] documenting volume replication

[Guo, Ruijing]

Hi, Ronen,

I don't know how to edit 
https://etherpad.openstack.org/p/cinder-replication-redoc and add some comments 
in email.


1. We may add asynchronized and synchronized type for replication.

2. We may add CG for replication

3. We may add to initialize connection for replication

Thanks,
-Ruijing

From: Ronen Kat [mailto:ronen...@il.ibm.com]
Sent: Tuesday, February 3, 2015 9:41 PM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [cinder] documenting volume replication

As some of you are aware the spec for replication is not up to date,
The current developer documentation, 
http://docs.openstack.org/developer/cinder/api/cinder.volume.driver.html, cover 
replication but some folks indicated that it need additional details.

In order to get the spec and documentation up to date I created an Etherpad to 
be a base for the update.
The Etherpad page is on 
https://etherpad.openstack.org/p/cinder-replication-redoc

I would appreciate if interested parties would take a look at the Etherpad, add 
comments, details, questions and feedback.

Ronen,
__
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] moving openvswitch ports between namespaces considered harmful

[Guo, Ruijing]

In short term, we use veth pairs with namespace to fix the issue if performance 
is not impacted (Hopefully:)

If performance downgrade too much, we may consider the following:

1) DHCP agent: use veth pairs with namespace since it is not critical path.

2) L3 agent: don't create port in OSV.  Connect L3 agent without open switch

VM --- Linux Bridge --- open switch -- (int-br-eth, phy-br-eth) --- 
physical switch  vlan interface with namespace --- L3agent

In long term, we may implement namespace and remove linux bridge.

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Friday, February 13, 2015 8:15 PM
To: openstack-dev
Cc: Jiri Benc; jpi...@redhat.com
Subject: [openstack-dev] [neutron] moving openvswitch ports between namespaces 
considered harmful

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi neutroners,

we** had several conversations recently with our Red Hat fellows who work on 
openvswitch (Jiri Benc and Jiri Pirko) regarding the way neutron utilizes their 
software. Those were beneficial to both sides to understand what we do right 
and wrong. I was asked to share some of the points from those discussions with 
broader community.

===

One of the issues that came up during discussions is the way neutron connects 
ovs ports to namespaces. The short story is that openvswitch is not designed 
with namespaces in mind, and the fact that moving its ports into a different 
namespace works for neutron is mere coincidence, and is actually considered as 
a bug by openvswitch guys.

It's not just broken in theory from software design standpoint, but also in 
practice. Specifically,

1. ovsdb dump does not work properly for namespaces:
- - https://bugzilla.redhat.com/show_bug.cgi?id=1160340

This results in wrong statistics and other data collected for these ports;

2. We suspect that the following kernel crash is triggered because of our usage 
of the feature that is actually a bug:
- - https://bugs.launchpad.net/neutron/+bug/1418097

Quoting Jiri Benc,

The problem is openvswitch does not support its ports to be moved to a 
different name space. The fact that it's possible to do that is a bug - such 
operation should have been denied. Unfortunately, due to a missing check, it's 
not been denied. Such setup does not work reliably, though, and leads to 
various issues from incorrect resource accounting to kernel crashes.

We're aware of the bug but we don't have any easy way to fix it. The most 
obvious option, disabling moving of ovs ports to different name spaces, would 
be easy to do but it would break Neutron. The other option, making ovs to work 
across net name spaces, is hard and will require addition of different kernel 
APIs and large changes in ovs user space daemons. This constitutes tremendous 
amount of work.

The tracker bug on openvswitch side is:
- - https://bugzilla.redhat.com/show_bug.cgi?id=1160340

So in the best case, we may expect openvswitch to properly support the feature 
in long term, but short term it won't work, especially while neutron expects 
other features implemented in openvswitch for it (like NAT, or connection 
tracking, or ipv6 tunnel endpoints, to name a few).

We could try to handle the issue neutron side. We can fix it by utilizing veth 
pairs to get into namespaces, but it may mean worse performance, and will 
definitely require proper benchmarking to see whether we can live with 
performance drop.

===

There were other suggestions on how we can enhance our way of usage of 
openvswitch. Among those, getting rid of linux bridge used for security groups, 
with special attention on getting rid of ebtables
(sic!) for they are a lot slower than iptables; getting rid of veth pair for 
instance ports.

===

I really encourage everyone to check the following video from devconf.cz 2015 
on all that and more at:

- - https://www.youtube.com/watch?v=BlLD-qh9EBQ

Among other things, you will find presentation of plotnetcfg tool to create 
nice graphs of openstack state.

If you're lazy enough and want to switch directly to the analysis of neutron 
problems, skip to ~18:00.

I also encourage to check our the video around 30:00 on the way out of 
openvswitch for neutron (tc/eBPF). As crazy as encouraging.

===

While at it, I encourage everyone interested in controlling switches the open 
source way to check out presentation of the new kernel subsystem for that (I 
guess vaporware atm):

- - https://www.youtube.com/watch?v=awekaJ7xWuw

===

So, that's what I have for you now. I really want to hear from everyone what is 
our plan to solve the problem neutron side.

Comments?

/Ihar

**Jakub Libosvar and me
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU3eq+AAoJEC5aWaUY1u57uyIH/2MRnU7Xr2ivfzDsqg1T1djN
WgE6j87hVyIUnw/p/+vD1eDpOURPmZUcE/S7B6SCVv5KNB+j0pr22os5JM0cjCox
zt63xz4GR/LibiJhyPnWtmSOqYdGFeTIdOj2TvovvOqtmI4MRmHoZy4fwShq0jXd
RX00Z/o2DCxB+0KfJYQiWbFgXO43/zrdNGe9ME3XWI5TvVXQx49DMwv5K1jYN45Q

Re: [openstack-dev] [cinder] Fixing stuck volumes - part II

[Guo, Ruijing]

Force is a good idea. I'd like to add 2 comments:


1)  It is option instead of new command. IOW, detach with force option 
instead of force-detach.

2)  Can we extend to another command: delete LUN/snapshot with force?

Thanks,
-Ruijing

From: Vishvananda Ishaya [mailto:vishvana...@gmail.com]
Sent: Thursday, February 12, 2015 8:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Fixing stuck volumes - part II


On Feb 11, 2015, at 3:45 PM, D'Angelo, Scott 
scott.dang...@hp.commailto:scott.dang...@hp.com wrote:


At the cinder mid-cycle it was decided that the best way to fix volumes stuck 
in 'attaching' or 'detaching' was NOT to fix the broken reset-state command. 
The doc string and help message for reset-state have been modified to warn the 
user that the tool only affects Cinder DB and can cause problems. But, 
ultimately, a separate command to 'force-detach' would be better. I've 
abandoned the original BP/spec for reset-state involving the driver.

I have looked at the existing function 'force-detach' in Cinder and it seems to 
work...except that Nova must be involved. Nova uses the BlockDeviceMapping 
table to keep track of attached volumes and, if Nova is not involved, a 
force-detach'ed volume will not be capable of being re-attached.
So, my plan is to submit a blueprint + spec for Novaclient to add a 
'force-detach' command. This is technically fairly simple and only involves 
stripping away the checks for proper state in Nova, and calling Cinder 
force-detach. I don't plan on asking for an exception to feature freeze, unless 
there is optimism from the community that this could possible get in for L.
The existing Cinder force-detach calls terminate_connection() and 
detach_volume().  I assume detach_volume() is covered by the Volume Detach 
minimum feature? I see many drivers have terminate_connection(), but not all. I 
believe this will not be a minimum feature, but others may disagree.

If you are going to add a force-detach command to nova, I think it would be 
good to make it detach even if the cinder request fails. Currently if you try 
to detach a volume (or terminate an instance with an attached volume), if 
cinder is down or the volume node where the volume resides is down, nova 
refuses to continue, which is pretty bad user experience.

Vish



thanks,
scottda
scott.dang...@hp.commailto:scott.dang...@hp.com


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.orgmailto: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] Questions about remote replication

[Guo, Ruijing]

Replication should be in 2 backends. You may look at 
http://www.emc.com/collateral/white-papers/h12079-vnx-replication-technologies-overview-wp.pdf

Thanks,
-Ruijing

From: Chenzongliang [mailto:chenzongli...@huawei.com]
Sent: Thursday, February 12, 2015 9:20 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Questions about remote replication


According to the blueprint 
description(https://blueprints.launchpad.net/cinder/+spec/volume-replication)
The Create volume with the replication enabled:
* the Scheduler selects two hosts for volume placement and sets up the 
replication
The DB entry

When reading the related scheduling module code, I can not found the process 
about this. I want to know where is to implemented this part of flow?If there 
is, whether the two volumes in different backend?

__
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] [CINDER] discussion about Volume Delete API

[Guo, Ruijing]

In http://developer.openstack.org/api-ref-blockstorage-v2.html, delete volume 
preconditions:


Preconditions

· Volume status must be available, in-use, error, or error_restoring.



I think we may change to following statements:



Preconditions

· Volume status must be creating, available, error, or error_restoring. 
(add creating and remove in-use)



1)If LUN is attached (in-use), we cannot delete LUN.

2)Event LUN is creating (hung in create), we may delete LUN.



__
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