Re: [openstack-dev] Why need br-int and br-tun in openstack neutron

[Mike Kolesnik]

- Original Message -
> Comments in-line.
> 
> - Original Message -
> > On 23 May 2015 at 04:43, Assaf Muller < amul...@redhat.com > wrote:
> > 
> > 
> > 
> > There's no real reason as far as I'm aware, just an implementation
> > decision.
> > 
> > This is inaccurate. There is a reason(s), and this has been asked before:
> > 
> > http://lists.openstack.org/pipermail/openstack/2014-March/005950.html
> 
> This link is to a thread asking why do we connect a Linux bridge between a
> tap
> device and br-int (For security groups).
> 
> > http://lists.openstack.org/pipermail/openstack/2014-April/006865.html
> 
> This link is to this thread itself.

No it's from another author but just the same text (almost exactly).
i.e. https://www.diffchecker.com/xl98zm9a

Either it's the same poster or some freak coincidence, or just some copy paste..

Also Vivek gave the correct answer on that thread:
http://lists.openstack.org/pipermail/openstack/2014-April/006868.html

In a nutshell, decoupling the overlay layer from the VM connectivity.
VMs are always connected to the br-int the same way, but the overlay
(vxlan/gre or vlans) is connected differently.

> 
> > 
> > In a nutshell, the design decision that led to the existing architecture is
> > due to the way OVS handles packets and interact with netfilter.
> 
> I think you're talking about the bridge between a tap device and br-int and
> not about br-tun.
> 
> > 
> > The fact that we keep asking the same question clearly shows lack of
> > documentation, both developer and user facing.
> > 
> > I'll get this fixed once and for all.
> 
> Thank you.
> 
> > 
> > Thanks,
> > Armando
> > 
> > 
> > 
> > 
> > 
> > 
> > On 21 במאי 2015, at 01:48, Na Zhu < na...@cn.ibm.com > wrote:
> > 
> > 
> > 
> > 
> > 
> > 
> > Dear,
> > 
> > 
> > When OVS plugin is used with GRE option in Neutron, I see that each compute
> > node has br-tun and br-int bridges created.
> > 
> > I'm trying to understand why we need the additional br-tun bridge here.
> > Can't we create tunneling ports in br-int bridge, and have br-int relay
> > traffic between VM ports and tunneling ports directly? Why do we have to
> > introduce another br-tun bridge?
> > 
> > 
> > Regards,
> > Juno Zhu
> > Staff Software Engineer, System Networking
> > China Systems and Technology Lab (CSTL), IBM Wuxi
> > Email: na...@cn.ibm.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
> > 
> > __
> > 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

[openstack-dev] [keystone] Reminder, no meeting 5/26

[Morgan Fainberg]

Since we are so close to the summit still and a number of people will be either 
on break or traveling, we will skip the next meeting and resume normal meeting 
scheduling on 6/2. 

Hope everyone enjoyed the summit!

--Morgan

Sent via mobile
__
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][DB] neutron DB migration scripts

[Zang, Rui]

Greetings,

Forgive my alembic ignorance. I am writing some vender specific code that wants 
to create new DB tables for neutron. I have read the 
neutron/db/migration/README file, but still have something unclear.
My current understanding is that for DB tables creation, I have to do 
"something" with neutron/db/migration/ .

What I have done were:
- Copied neutron/db/migration/alembic.ini to $my_plugin_directory
- Ran `neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file 
$my_plugin_directory/alembic.ini revision -m "my plugin init ops" 
--autogenerate`. This autogenerate command generated a 
neutron/db/migrations/alembic_migrations/versions/ 
ee78798e4af_my_plugin_init_ops.py file. But this file is completely irrelevant 
with my targeted changes. So I replaced the upgrade() method with the DB table 
creation code.
- Then ran `neutron-db-manager upgrade` to upgrade to  revision ee78798e4af 
manually, I saw the tables were created.

So the questions are:
* there are scripts in neutron/db/migration/alembic_migrations/ that without a 
revision prefix, like l3_init_ops.py, they are not in the "versions" directory. 
What are they for?

* Should I just keep the "ee78798e4af_my_plugin_init_ops.py" file? Seems the 
metadata files are no longer usable.

* I assume if the revision file ("ee78798e4af_my_plugin_init_ops.py" in my 
case) is already there before devstack is started, the new tables will be 
created by devstack as other tables, right?

* Anything what I did wrong or missing?

Thanks,
Rui Zang 


__
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] [akanda] Monday dev meeting cancelled

[sean roberts]

Agenda would be to review the summit design session. I will put notes on
the ML on this.

-- 
~sean
__
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] Add tap device to ovs bridge when attach an interface to vm.

[zhi]

Hi, all. I want to add tap device to br-ex rather than linux bridge when
attaching an interface to a vm. I find some code in
nova/virt/libvirt/vif.py in function plug_ovs_hybrid like this "
utils.execute('brctl', 'addbr', br_name, run_as_root=True) ".
I find no place which add tap device to linux bridge. Does libvirt do it?
Could some helps me? thx.
__
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] [openstackclient] [magnum] Review of object and actions for magnumclient implementation

[Steve Martinelli]

Hey Ronald,

Thanks for asking first, as more folks are adopting OSC plugins for their 
respective clients we should probably streamline this a bit, but the ML 
works for now.

Just 2 remarks... 

I'd actually prefer 'replication controller' (which you prefer) instead of 
'rc' (as adrian suggested). The reason for this is that in OSC we try not 
to abbreviate when possible. 

Also, instead of 'update', is this analogous to user update or volume 
update? We've been using the key term 'set' instead wherever possible.

For a complete list of current commands in vanilla OSC: 
http://docs.openstack.org/developer/python-openstackclient/command-list.html 
(see the lack of update :))

Thanks,

Steve Martinelli
OpenStack Keystone Core

Adrian Otto  wrote on 05/24/2015 10:35:12 PM:

> From: Adrian Otto 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 05/24/2015 10:35 PM
> Subject: Re: [openstack-dev] [openstackclient] [magnum] Review of 
> object and actions for magnumclient implementation
> 
> Thanks for taking the initiative on this! Remarks in-line...
> 
> On May 24, 2015, at 11:20 AM, Ronald Bradford  
wrote:

> I have outlined in the blueprint  (https://blueprints.launchpad.net/
> python-openstackclient/+spec/magnum-support) the object and actions 
> mappings that are currently available in the magnumclient.
> I have separated the list of actions that are presently used and 
> actions that are not for review and discussion. Specifically These 
> actions DO NOT match.
> bay [ update ]
> Ok.
> container [ execute | start | stop ]
> Consider using exec instead of execute. This would more closely 
> match the docker CLI, and improves usability. Consider patching this
> in the API and python-magnumclient to keep it consistent. This will 
> tighten up the user experience for those using both Magnum through 
> OSC and Docker natively on Docker Swarm bays.
> 
> Start and stop are ok.
> pod [ update ]
> Ok.
> replication controller [ update ]
> Use "rc" here so we do not have a two word noun.
> service [ update ]
> Ok.
> 
> Thanks,
> 
> Adrian
> I would appreciate feedback on if these actions "update", "execute",
> "start" and "stop" are appropriate to use.
> Regards
> Ronald
> 
__
> 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] Why need br-int and br-tun in openstack neutron

[YAMAMOTO Takashi]

>> There's no real reason as far as I'm aware, just an implementation decision.
>> 
>> This is inaccurate. There is a reason(s), and this has been asked before:
>> 
>> http://lists.openstack.org/pipermail/openstack/2014-March/005950.html
> 
> This link is to a thread asking why do we connect a Linux bridge between a tap
> device and br-int (For security groups).
> 
>> http://lists.openstack.org/pipermail/openstack/2014-April/006865.html
> 
> This link is to this thread itself.
> 
>> 
>> In a nutshell, the design decision that led to the existing architecture is
>> due to the way OVS handles packets and interact with netfilter.
> 
> I think you're talking about the bridge between a tap device and br-int and
> not about br-tun.

sure, these are separate topics.

FYI, ofagent uses a single openflow bridge (ie. no br-tun)
but for SGs still needs LBs as ovs-agent does.

YAMAMOTO Takashi

__
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] Why need br-int and br-tun in openstack neutron

[Assaf Muller]

Comments in-line.

- Original Message -
> On 23 May 2015 at 04:43, Assaf Muller < amul...@redhat.com > wrote:
> 
> 
> 
> There's no real reason as far as I'm aware, just an implementation decision.
> 
> This is inaccurate. There is a reason(s), and this has been asked before:
> 
> http://lists.openstack.org/pipermail/openstack/2014-March/005950.html

This link is to a thread asking why do we connect a Linux bridge between a tap
device and br-int (For security groups).

> http://lists.openstack.org/pipermail/openstack/2014-April/006865.html

This link is to this thread itself.

> 
> In a nutshell, the design decision that led to the existing architecture is
> due to the way OVS handles packets and interact with netfilter.

I think you're talking about the bridge between a tap device and br-int and
not about br-tun.

> 
> The fact that we keep asking the same question clearly shows lack of
> documentation, both developer and user facing.
> 
> I'll get this fixed once and for all.

Thank you.

> 
> Thanks,
> Armando
> 
> 
> 
> 
> 
> 
> On 21 במאי 2015, at 01:48, Na Zhu < na...@cn.ibm.com > wrote:
> 
> 
> 
> 
> 
> 
> Dear,
> 
> 
> When OVS plugin is used with GRE option in Neutron, I see that each compute
> node has br-tun and br-int bridges created.
> 
> I'm trying to understand why we need the additional br-tun bridge here.
> Can't we create tunneling ports in br-int bridge, and have br-int relay
> traffic between VM ports and tunneling ports directly? Why do we have to
> introduce another br-tun bridge?
> 
> 
> Regards,
> Juno Zhu
> Staff Software Engineer, System Networking
> China Systems and Technology Lab (CSTL), IBM Wuxi
> Email: na...@cn.ibm.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
> 
> __
> 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] [openstackclient] [magnum] Review of object and actions for magnumclient implementation

[Adrian Otto]

Thanks for taking the initiative on this! Remarks in-line...

On May 24, 2015, at 11:20 AM, Ronald Bradford 
mailto:m...@ronaldbradford.com>> wrote:


I have outlined in the blueprint  
(https://blueprints.launchpad.net/python-openstackclient/+spec/magnum-support) 
the object and actions mappings that are currently available in the 
magnumclient.

I have separated the list of actions that are presently used and actions that 
are not for review and discussion. Specifically These actions DO NOT match.

bay [ update ]

Ok.

container [ execute | start | stop ]

Consider using exec instead of execute. This would more closely match the 
docker CLI, and improves usability. Consider patching this in the API and 
python-magnumclient to keep it consistent. This will tighten up the user 
experience for those using both Magnum through OSC and Docker natively on 
Docker Swarm bays.

Start and stop are ok.

pod [ update ]

Ok.

replication controller [ update ]

Use "rc" here so we do not have a two word noun.

service [ update ]

Ok.

Thanks,

Adrian

I would appreciate feedback on if these actions "update", "execute", "start" 
and "stop" are appropriate to use.

Regards

Ronald

__
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] [heat][nova]: anti-affinity policy via heat in IceHouse?

[Fox, Kevin M]

Yeah. I dont have an example with both in it but, server group:
https://github.com/EMSL-MSC/heat-templates/blob/master/cfn/389/389_BaseCluster.yaml

And template that launches an instance with it:
https://github.com/EMSL-MSC/heat-templates/blob/master/cfn/389/389_Server.yaml

Thanks,
Kevin


From: Daniel Comnea
Sent: Sunday, May 24, 2015 3:24:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [heat][nova]: anti-affinity policy via heat in 
IceHouse?

Thanks Kevin !

Would you have an example?

Much appreciated,
Dani


On Sun, May 24, 2015 at 12:28 AM, Fox, Kevin M 
mailto:kevin@pnnl.gov>> wrote:
It works with heat. You can use a scheduler hint on the instance and the server 
group resource to make a new one.

Thanks,
Kevin


From: Daniel Comnea
Sent: Saturday, May 23, 2015 3:17:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [heat][nova]: anti-affinity policy via heat in 
IceHouse?

Hi,

I'm aware of the anti-affinity policy which you can create via nova cli and 
associated instances with it.
I'm also aware of the default policies in nova.conf

by creating instances via HEAT is any alternatives to create instances part of 
anti-affinity group?

Thx,
Dani

__
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] usefulness of device parameter at volumeAttachment

[Fox, Kevin M]

Honestly, I dont know. I dont use either. Just heard it was broken in kvm, but 
it was there because of xen.

Thanks,
Kevin


From: Géza Gémes
Sent: Sunday, May 24, 2015 1:07:01 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] usefulness of device parameter at 
volumeAttachment

libvirt/xen or xenapi? PVM or HVM?

Thank you!

Geza

On 05/23/2015 02:21 PM, Fox, Kevin M wrote:
I believe xen supports it.

Thanks,
Kevin


From: Géza Gémes
Sent: Saturday, May 23, 2015 2:00:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova] usefulness of device parameter at 
volumeAttachment

Hi,

When someone calls nova volume-attach or the block-device-mapping
parameter at boot, it is possible to specify a device name for the
guest. However I couldn't find any guest OS which would honor this. E.g.
with libvirt/kvm, if the guest has two virtio disks already (vda and
vdb), specifying vdf would be ignored and the disk will be attached as
vdc in the guest.
I propose to deprecate this option and at boot where it is not optional
to accept only auto as an option.

Best regards,

Geza

__
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] [openstackclient] [magnum] Review of object and actions for magnumclient implementation

[Hongbin Lu]

Hi Ronald,

I think the “update” action is definitely appropriate to use, since it is not 
specific to magnum (Heat and Ironic use it as well). By looking through the 
existing list of actions [1], it looks the start/stop actions fits into the 
openstackclient resume/suspend actions. The “execute” action looks to be 
magnum-specific, and it is rarely used. We could either skip adding it to 
openstackclient or propose a new action in here.

Thanks,
Hongbin

[1] http://docs.openstack.org/developer/python-openstackclient/commands.html

From: Ronald Bradford [mailto:m...@ronaldbradford.com]
Sent: May-24-15 2:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [openstackclient] [magnum] Review of object and 
actions for magnumclient implementation


I have outlined in the blueprint  
(https://blueprints.launchpad.net/python-openstackclient/+spec/magnum-support) 
the object and actions mappings that are currently available in the 
magnumclient.

I have separated the list of actions that are presently used and actions that 
are not for review and discussion. Specifically These actions DO NOT match.

bay [ update ]
container [ execute | start | stop ]
pod [ update ]
replication controller [ update ]
service [ update ]

I would appreciate feedback on if these actions "update", "execute", "start" 
and "stop" are appropriate to use.

Regards

Ronald
__
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] Why need br-int and br-tun in openstack neutron

[Daniel Comnea]

On Sun, May 24, 2015 at 5:46 PM, Armando M.  wrote:

> On 23 May 2015 at 04:43, Assaf Muller  wrote:
>
>> There's no real reason as far as I'm aware, just an implementation
>> decision.
>>
>
> This is inaccurate. There is a reason(s), and this has been asked before:
>
> http://lists.openstack.org/pipermail/openstack/2014-March/005950.html
> http://lists.openstack.org/pipermail/openstack/2014-April/006865.html
>
> In a nutshell, the design decision that led to the existing architecture
> is due to the way OVS handles packets and interact with netfilter.
>
> The fact that we keep asking the same question clearly shows lack of
> documentation, both developer and user facing.
>
> I'll get this fixed once and for all.
>
[DC]: and very much appreciate your initiative !!

>
> Thanks,
> Armando
>
>
>>
>>
>>
>> On 21 במאי 2015, at 01:48, Na Zhu  wrote:
>>
>> Dear,
>>
>>
>> When OVS plugin is used with GRE option in Neutron, I see that each
>> compute
>> node has br-tun and br-int bridges created.
>>
>> I'm trying to understand why we need the additional br-tun bridge here.
>> Can't we create tunneling ports in br-int bridge, and have br-int relay
>> traffic between VM ports and tunneling ports directly? Why do we have to
>> introduce another br-tun bridge?
>>
>>
>> Regards,
>> Juno Zhu
>> Staff Software Engineer, System Networking
>> China Systems and Technology Lab (CSTL), IBM Wuxi
>> Email: na...@cn.ibm.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
>>
>>
>> __
>> 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] [openstackclient] [magnum] Review of object and actions for magnumclient implementation

[Ronald Bradford]

I have outlined in the blueprint  (
https://blueprints.launchpad.net/python-openstackclient/+spec/magnum-support)
the object and actions mappings that are currently available in the
magnumclient.

I have separated the list of actions that are presently used and actions
that are not for review and discussion. Specifically These actions DO NOT
match.

bay [ update ]
container [ execute | start | stop ]
pod [ update ]
replication controller [ update ]
service [ update ]

I would appreciate feedback on if these actions "update", "execute",
"start" and "stop" are appropriate to use.

Regards

Ronald
__
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] [TripleO] HA CI job is green, please consider it when merging patches

[James Slagle]

On Fri, May 22, 2015 at 1:49 AM, Jiří Stránský  wrote:
> Hi all,
>
> after an epic battle with bugs this week, we have a passing CI job for HA.
>
> Looking at the jobs which ran during last night, the success rate is decent
> (14 all-green runs vs. just 1 run where HA job was the sole CI failure).
>
> I'm a bit reluctant still to say "let's make it voting" right now, but i
> think we should be heading that way gradually. If you see a failed HA CI job
> from now on, there's some chance it points out some real issue. Please try
> to go through the logs before overriding its vote and merging a patch with
> red HA CI. If the patch in question is not critical with regards to time,
> recheck is an option :)

Great work folks. I'd like to echo the above as well...let's keep the
HA job green until we get enough confidence in it to make it voting
asap.

>
>
> Thanks
>
> Jirka
>
> __
> 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



-- 
-- James Slagle
--

__
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] [barbican] Nominating Kaitlin Farr for barbican-core

[Chad Lung]

+1

Chad Lung
EMC Cloud Services


>* I would like to nominate Kaitlin Farr for barbican-core.
*>>* Kaitlin has been contributing to the project for a long time, both by
*>* contributing code to Barbican, python-barbicanclient and Castellan,
*>* and also by providing valuable reviews. [1]
*>>* As a reminder to the rest of the core team, we use the process
*>* outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam
 to add
*>* members to the barbican-core team.
*>>* Thanks,
*>* Douglas Mendizábal*
__
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] Why need br-int and br-tun in openstack neutron

[Armando M.]

On 23 May 2015 at 04:43, Assaf Muller  wrote:

> There's no real reason as far as I'm aware, just an implementation
> decision.
>

This is inaccurate. There is a reason(s), and this has been asked before:

http://lists.openstack.org/pipermail/openstack/2014-March/005950.html
http://lists.openstack.org/pipermail/openstack/2014-April/006865.html

In a nutshell, the design decision that led to the existing architecture is
due to the way OVS handles packets and interact with netfilter.

The fact that we keep asking the same question clearly shows lack of
documentation, both developer and user facing.

I'll get this fixed once and for all.

Thanks,
Armando


>
>
>
> On 21 במאי 2015, at 01:48, Na Zhu  wrote:
>
> Dear,
>
>
> When OVS plugin is used with GRE option in Neutron, I see that each
> compute
> node has br-tun and br-int bridges created.
>
> I'm trying to understand why we need the additional br-tun bridge here.
> Can't we create tunneling ports in br-int bridge, and have br-int relay
> traffic between VM ports and tunneling ports directly? Why do we have to
> introduce another br-tun bridge?
>
>
> Regards,
> Juno Zhu
> Staff Software Engineer, System Networking
> China Systems and Technology Lab (CSTL), IBM Wuxi
> Email: na...@cn.ibm.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
>
>
> __
> 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] [rally][summit] Rally summit updates

[Lingxian Kong]

Thanks Boris for the updates!

On Sun, May 24, 2015 at 3:20 PM, Boris Pavlovic  wrote:
> Hi stackers,
>
>
> For those who don't want to miss anything related to Rally on summit I make
> a
> small blogpost that covers most interesting things:
>
> http://boris-42.me/rally-on-openstack-summit-in-vancouver/
>
>
> Best regards,
> Boris Pavlovic
>
> __
> 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!
---
Lingxian Kong

__
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] Why need br-int and br-tun in openstack neutron

[Assaf Muller]

The OVS agent has been implemented under the assumption that you're working 
with two bridges, it's a requirement. It creates the tunneling bridge if you 
enable tunneling, you can't have it any other way.



> On 24 במאי 2015, at 03:52, Daniel Comnea  wrote:
> 
> 
> 
>> On Sat, May 23, 2015 at 12:43 PM, Assaf Muller  wrote:
>> There's no real reason as far as I'm aware, just an implementation decision.
> [DC]: in this case wouldn't this bee seen suitable as best practicies vs what 
> every blog/ manual is suggesting? 
>> 
>> 
>> 
>> On 21 במאי 2015, at 01:48, Na Zhu  wrote:
>> 
>>> Dear,
>>> 
>>> 
>>> When OVS plugin is used with GRE option in Neutron, I see that each compute 
>>> node has br-tun and br-int bridges created. 
>>> 
>>> I'm trying to understand why we need the additional br-tun bridge here. 
>>> Can't we create tunneling ports in br-int bridge, and have br-int relay 
>>> traffic between VM ports and tunneling ports directly? Why do we have to 
>>> introduce another br-tun bridge?  
>>> 
>>> 
>>> Regards,
>>> Juno Zhu
>>> Staff Software Engineer, System Networking
>>> China Systems and Technology Lab (CSTL), IBM Wuxi
>>> Email: na...@cn.ibm.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
>> 
>> __
>> 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] [heat][nova]: anti-affinity policy via heat in IceHouse?

[Daniel Comnea]

Thanks Kevin !

Would you have an example?

Much appreciated,
Dani


On Sun, May 24, 2015 at 12:28 AM, Fox, Kevin M  wrote:

>  It works with heat. You can use a scheduler hint on the instance and the
> server group resource to make a new one.
>
> Thanks,
> Kevin
>
> --
> *From:* Daniel Comnea
> *Sent:* Saturday, May 23, 2015 3:17:11 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [heat][nova]: anti-affinity policy via heat in
> IceHouse?
>
> Hi,
>
>  I'm aware of the anti-affinity policy which you can create via nova cli
> and associated instances with it.
>  I'm also aware of the default policies in nova.conf
>
>  by creating instances via HEAT is any alternatives to create instances
> part of anti-affinity group?
>
>  Thx,
>  Dani
>
> __
> 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] usefulness of device parameter at volumeAttachment

[Géza Gémes]

libvirt/xen or xenapi? PVM or HVM?

Thank you!

Geza

On 05/23/2015 02:21 PM, Fox, Kevin M wrote:

I believe xen supports it.

Thanks,
Kevin *
*

*From:* Géza Gémes
*Sent:* Saturday, May 23, 2015 2:00:32 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* [openstack-dev] [nova] usefulness of device parameter at 
volumeAttachment


Hi,

When someone calls nova volume-attach or the block-device-mapping
parameter at boot, it is possible to specify a device name for the
guest. However I couldn't find any guest OS which would honor this. E.g.
with libvirt/kvm, if the guest has two virtio disks already (vda and
vdb), specifying vdf would be ignored and the disk will be attached as
vdc in the guest.
I propose to deprecate this option and at boot where it is not optional
to accept only auto as an option.

Best regards,

Geza

__
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] Why need br-int and br-tun in openstack neutron

[Daniel Comnea]

On Sat, May 23, 2015 at 12:43 PM, Assaf Muller  wrote:

> There's no real reason as far as I'm aware, just an implementation
> decision.
>
[DC]: in this case wouldn't this bee seen suitable as best practicies vs
what every blog/ manual is suggesting?

>
>
>
> On 21 במאי 2015, at 01:48, Na Zhu  wrote:
>
> Dear,
>
>
> When OVS plugin is used with GRE option in Neutron, I see that each
> compute
> node has br-tun and br-int bridges created.
>
> I'm trying to understand why we need the additional br-tun bridge here.
> Can't we create tunneling ports in br-int bridge, and have br-int relay
> traffic between VM ports and tunneling ports directly? Why do we have to
> introduce another br-tun bridge?
>
>
> Regards,
> Juno Zhu
> Staff Software Engineer, System Networking
> China Systems and Technology Lab (CSTL), IBM Wuxi
> Email: na...@cn.ibm.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
>
>
> __
> 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] [rally][summit] Rally summit updates

[Boris Pavlovic]

Hi stackers,


For those who don't want to miss anything related to Rally on summit I make
a
small blogpost that covers most interesting things:

http://boris-42.me/rally-on-openstack-summit-in-vancouver/


Best regards,
Boris Pavlovic
__
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