[openstack-dev] ?????? Add tap device to ovs bridge when attach aninterface to vm.

[thuanqin]

Hi zhi,


I'm diving into nova vif codes this morning so I think I can give you an answer 
about it.


Your guess is correct. If you use libvirt, you can find a xml file in your nova 
data directory. You can find following codes in this xml file:



  
  
  
  
  




So, when nova-compute create and start this domain, it will plug dev 
'tap8b77eaa3-00' into bridge 'qbr8b77eaa3-00' by libvirtd automatically.


You can get more information from here: 
https://libvirt.org/formatdomain.html#elementsNICS


--  --
??: "zhi";;
: 2015??5??25??(??) 1:59
??: "openstack-dev"; 

: [openstack-dev] Add tap device to ovs bridge when attach aninterface to 
vm.



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

[openstack-dev] [tempest][qa][cinder] How to configure tempest with to test volume migration?

[Sheng Bo Hou]

Hi everyone,

I am planning to add test cases for volume migration for cinder into 
tempest. I am wondering how to enable multiple back-ends for cinder in 
tempest, and connect to different back-ends. For example, I configure one 
back-end for LVM and the other is for IBM Storwize V7000 driver. Then run 
the test named like test_volume_migration_LVM_Storwize to test
if the migration really works fine.

About the configuration, is this something tempest can do so far? Or is 
this something new we need to add?
Thank you very much.

Best wishes,
Vincent Hou (侯胜博)

Staff Software Engineer, Open Standards and Open Source Team, Emerging 
Technology Institute, IBM China Software Development Lab

Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com 
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang 
West Road, Haidian District, Beijing, P.R.C.100193
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193
__
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] xen project retrigger

[Gary Kotton]

Hi,
Anyone know how to retriever this CI?
Thanks
Gary
__
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] Setting cluster status when provisioning a node

[Aleksey Kasatkin]

AFAIC, there are several problems (in API) here:
1. We cannot stop/reset particular nodes.
2. Cluster status doesn't address changes which were done via CLI.
3. Cluster status in its current form is not enough to manage cluster (i.e.
to determine actions what can be applied to cluster at the moment). It
doesn't reflect the fact that some nodes can be in 'provisioned' state,
some are in 'provisioning', 'deploying', 'ready' statuses.

First two seem clear enough. We could add ability to stop/reset particular
nodes and reflect CLI-driven changes in the cluster status.
To address the last point my proposal was (bug/1449086/comments/7
) to break
status into several binary states, i.e. binaries: 'new', 'deployment',
'ready', etc., each of which is set to true when cluster has at least one
node in corresponding status (I united 'provisioning', 'provisioned' and
'deploying' into one as it is done now).

Now it looks more reasonable to me to keep the original status as is and
add bitwise one mentioned above (to address states of different nodes)
because 'error' state is determinative for cluster (when cluster is in
'error' state it is no matter that some nodes are in 'ready' state).
So,
cluster is in 'new' state when all nodes are in 'discover' state,
it is in 'operational' state when all nodes are in 'ready' state,
cluster is in 'deployment' state when not all of its nodes are in 'discover'
or 'ready' state but there are no nodes in 'error' and 'removing' states.
New bitwise status is actual in 'deployment' state of cluster. It gives to
UI/CLI sufficient data to determine what actions can be applied to cluster
at the moment.

I've combined some of the states combinations into the table:

'new' flag

'deployment' flag

'ready' flag

description, actions allowed

false

false

false

There are no nodes in cluster or all nodes are in 'error'/'removing' state.
Cluster is in 'new'/'error'/'remove' state here so we don't care about
these flags.

false

true

false

All nodes are under provisioning/deployment. Deployment can be stopped.

true

true

false

Part of nodes is in 'discover' state, remaining part is under
provisioning/deployment. Deployment can be started for the first part
or/and stopped for the second part of nodes.

true

false

true

Part of nodes is in 'discover' state, remaining part is in 'ready' state.
Deployment can be started for the first part and second part can be reset.

true

true

true

We have some nodes in every of the states: 'discover',
provisioning/deployment, 'ready'. So, we can allow different actions for
nodes in different states.

false

true

true

Part of nodes is under provisioning/deployment, remaining part is in
'ready' state. Deployment can be stopped for the first part and second part
can be reset.
I didn't show another 2 combinations here as they aren't related to
'deployment'
state of cluster (as well as the first one in the table).

Also, we should be careful with the order of nodes deployment/reset. I'm
not sure whether it is written in our docs that cluster may be
non-functional if user tries to deploy nodes in the wrong order (e.g.
computes first). We could show some warnings about that. Same applies to
selective reset if we will implement it.



Aleksey Kasatkin


On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko  wrote:

> Hi folks!
>
> Recently I encountered an issue [1] that the Deploy Changes button in the
> web ui is still active when a provisioning of single node is started using
> the command line client.
> The background for that issue is that the provisioning task does not seem
> to update the cluster status correctly and Nailgun’s API returns it as NEW
> even while some of the node are been provisioned.
>
> The reason for raising this thread in the mailing list is that
> provisioning a node is a feature for developers and basically end-users
> should not do that. What is the best solution for that: fix Nailgun to set
> the correct status, or make this provisioning feature available only for
> developers?
>
> 1. https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086
>
>
> - romcheg
>
>
> __
> 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] [oslo][service] oslo.service puplic repositiry review request

[Elena Ezhova]

Hi all,

The spec for the graduation of oslo.service [1] has merged. I created
review requests to project-config [2] and governance [3] and would really
welcome any reviews.

Thanks, Elena

[1] https://review.openstack.org/#/c/142659/9
[2] https://review.openstack.org/#/c/185324/
[3] https://review.openstack.org/#/c/185327/

On Thu, May 21, 2015 at 5:38 PM, Elena Ezhova  wrote:

> Hi, all!
>
> As the spec for the graduation of oslo.service [1] is about to merge I
> have created a public repository on github [2] with oslo.service initial
> version, which is the next step in graduation of a library according to [3].
>
> I would like to ask everyone interested to review it so we can proceed
> with the graduation process.
>
> Thanks, Elena
>
>
> [1] https://review.openstack.org/#/c/142659/9
> [2] https://github.com/eezhova/oslo.service
> [3] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary
>
__
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] xen project retrigger

[Bob Ball]

Hi Gary,

It should have been included in the comment - what was the changeset that 
failed?

For reference a recheck can be triggered with "xen: recheck"

Thanks,

Bob

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: 25 May 2015 16:21
To: OpenStack List
Subject: [openstack-dev] [nova] xen project retrigger

Hi,
Anyone know how to retriever this CI?
Thanks
Gary
__
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] Stepping down from Neutron core team

[Miguel Ángel Ajo]

Ahh, I missed this email while I was in the summit.

Thank you for so many years of hard work Salvatore, as Edgar said, your 
“pedant” comments
made it better.  I will miss your sense of humor ;)

Best,
Miguel Ángel Ajo


On Thursday, 21 de May de 2015 at 21:04, Gary Kotton wrote:

> -1
>  
> From: Carl Baldwin mailto:c...@ecbaldwin.net)>
> Reply-To: OpenStack List  (mailto:openstack-dev@lists.openstack.org)>
> Date: Thursday, May 21, 2015 at 11:32 AM
> To: OpenStack List  (mailto:openstack-dev@lists.openstack.org)>
> Subject: Re: [openstack-dev] [Neutron] Stepping down from Neutron core team
>  
>  
> On May 21, 2015 9:06 AM, "Kyle Mestery"  (mailto:mest...@mestery.com)> wrote:
> >
> > On Thu, May 21, 2015 at 8:58 AM, Salvatore Orlando  > (mailto:sorla...@nicira.com)> wrote:
> >>
> >> After putting the whole OpenStack networking contributors community 
> >> through almost 8 cycles of pedant comments and annoying "what if" 
> >> questions, it is probably time for me to relieve neutron contributors from 
> >> this burden.
> >>
> >> It has been a pleasure for me serving the Neutron community (or Quantum as 
> >> it was called at the time), and now it feel right - and probably overdue - 
> >> to relinquish my position as a core team member in a spirit of rotation 
> >> and alternation between contributors.
> >>
> >> Note: Before you uncork your champagne bottles, please be aware that I 
> >> will stay in the Neutron community as a contributors and I might still end 
> >> up reviewing patches.
> >>
> >> Thanks for being so understanding with my pedant remarks,
> >> Salvatore
> >>
> >
> > If I could -1 this as a patch, I would.
> >
> > But seriously. Salvatore, thanks for all the years of work you've put into 
> > Neutron. Please note that just because you've stepped down from the core 
> > reviewer team doesn't mean we won't be relying on you to be a part of the 
> > community.
> >
> > Thanks,
> > Kyle  
> Kyle, I think you should -2 this one.  ;)  Maybe we should put the core team 
> list in a repo just so you can.
> All joking aside, @Salv, I have appreciated your feedback much more than you 
> give yourself credit for, maybe more than I let on.  You don't need to be a 
> core to give it, so keep it coming.
> Carl
>  
>  
>  
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> (mailto: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] [tempest][qa][cinder] How to configure tempest with to test volume migration?

[Duncan Thomas]

There doesn't seem to be an existing tempest test for this.

I suggest writing the test so that it looks if there are two volume types
defined, and if so uses them. Ideally you should test migration to and from
lvm. There is offline migration (volume is available) and online migration
(volume is attached), which are two completely separate code paths.

Great to hear somebody I'd writing tests for this!
On 25 May 2015 10:24, "Sheng Bo Hou"  wrote:

> Hi everyone,
>
> I am planning to add test cases for volume migration for cinder into
> tempest. I am wondering how to enable multiple back-ends for cinder in
> tempest, and connect to different back-ends. For example, I configure one
> back-end for LVM and the other is for IBM Storwize V7000 driver. Then run
> the test named like test_volume_migration_LVM_Storwize to test
> if the migration really works fine.
>
> About the configuration, is this something tempest can do so far? Or is
> this something new we need to add?
> Thank you very much.
>
> Best wishes,
> Vincent Hou (侯胜博)
>
> Staff Software Engineer, Open Standards and Open Source Team, Emerging
> Technology Institute, IBM China Software Development Lab
>
> Tel: 86-10-82450778 Fax: 86-10-82453660
> Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com
> Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang
> West Road, Haidian District, Beijing, P.R.C.100193
> 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193
> __
> 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] python-fuelclient 6.1.0 is released

[Roman Prykhodchenko]

Oleg,

The backend part of the client was not changed dramatically due to requirements 
for backwards compatibility issues.
ATM we do have plans to support multiple versions of the Fuel API but the work 
is only being scoped now. The major technical issue is that Nailgun does not 
provide any versioning for it’s API so on the client side it’s only possible to 
support multiple versions of Fuel API on the very basic level when a version of 
the API is directly mapped to the version of Fuel.

I am not sure we will be able to support older versions of the API in the new 
Fuel Client due to lack of time. However, the structure of the client will 
allow to add that support in a pretty easy way.


- romcheg



> 19 трав. 2015 о 16:01 Oleg Gelbukh  написав(ла):
> 
> Roman,
> 
> This is awesome news! Thank you for this huge improvement for developers who 
> consume Fuel API.
> 
> Could you please elaborate on backwards compatibility between the new client 
> and older versions of Fuel API? For example, is it possible to use the new 
> client to work with Fuel 4.x? 5.x?
> 
> --
> Best regards,
> Oleg Gelbukh
> 
> On Fri, May 15, 2015 at 5:39 PM, Roman Prykhodchenko  > wrote:
> Hi folks!
> 
> I’m glad to announce that the first independent release of Fuel Client was 
> published to PyPi: https://pypi.python.org/pypi/python-fuelclient 
> 
> You can either download it from the web page or install with pip install 
> python-fuelclient.
> 
> What’s new:
> 
>  - Fuel client is now able to run most of it’s features remotely from Fuel’s 
> master node.
>  - Old CLI was deprecated, new fuel2 utility is a preview of the new Fuel 
> client which will be available in the next major release
>  - Versioning scheme of the Fuel Client is not tightly bound to Fuel’s 
> version scheme anymore.
>  - Other improvements and bug-fixes
> 
> 
> __
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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][oslo] RPC Asynchronous Communication

[Victor Stinner]

Hi Sahid,

There is a work-in-progress work to change how concurrency is handled in 
openstack processes:

"Replace eventlet with ???"
https://review.openstack.org/164035

The latest updates can be found in etherpads from the OpenStack Vancouver 
Summit:

- https://etherpad.openstack.org/p/liberty-cross-project-managing-concurrency
- https://etherpad.openstack.org/p/YVR-oslo-asyncio

No choice was made at Vancouver. In short, we should continue to investigate 
the different options (asyncio/trollius, threads, etc.) to get more information 
to be able to take a decision.

Victor

- Original Message -
> From: "Sahid Orentino Ferdjaoui" 
> To: openstack-dev@lists.openstack.org
> Sent: Thursday, May 7, 2015 11:34:51 AM
> Subject: [openstack-dev] [nova][oslo] RPC Asynchronous Communication
> 
> Hi,
> 
> The primary point of this expected discussion around asynchronous
> communication is to optimize performance by reducing latency.
> 
> For instance the design used in Nova and probably other projects let
> able to operate ascynchronous operations from two way.
> 
> 1. When communicate between inter-services
> 2. When communicate to the database
> 
> 1 and 2 are close since they use the same API but I prefer to keep a
> difference here since the high level layer is not the same.
> 
> From Oslo Messaging point of view we currently have two methods to
> invoke an RPC:
> 
>   Cast and Call: The first one is not bloking and will invoke a RPC
> without to wait any response while the second will block the
> process and wait for the response.
> 
> The aim is to add new method which will return without to block the
> process an object let's call it "Future" which will provide some basic
> methods to wait and get a response at any time.
> 
> The benefice from Nova will comes on a higher level:
> 
> 1. When communicate between services it will be not necessary to block
>the process and use this free time to execute some other
>computations.
> 
>   future = rpcapi.invoke_long_process()
>  ... do something else here ...
>   result = future.get_response()
> 
> 2. We can use the benefice of all of the work previously done with the
>Conductor and so by updating the framework Objects and Indirection
>Api we should take advantage of async operations to the database.
> 
>MyObject = MyClassObject.get_async()
>  ... do something else here ...
>MyObject.wait()
> 
>MyObject.foo = "bar"
>MyObject.save_async()
>  ... do something else here ...
>MyObject.wait()
> 
> All of this is to illustrate and have to be discussed.
> 
> I guess the first job needs to come from Oslo Messaging so the
> question is to know the feeling here and then from Nova since it will
> be the primary consumer of this feature.
> 
> https://blueprints.launchpad.net/nova/+spec/asynchronous-communication
> 
> Thanks,
> s.
> 
> __
> 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] [Solum] OpenStack Design Summit Solum sessions

[Thierry Carrez]

Gilbert Pilz wrote:
> Looking at the Design Summit schedule and list of Etherpads it appears that 
> there are no sessions scheduled for Solum. Is this correct?

Right, Solum is not (yet?) an OpenStack project (in the big-tent sense)
and therefore did not get a track at the L summit. AFAIK it did not
apply for an "ecosystem day" either (which was the way for non-OpenStack
projects to get space in Vancouver).

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Neutron] Stepping down from Neutron core team

[Somanchi Trinath]

My Score -1, Missing the comments.. ☹

From: Miguel Ángel Ajo [mailto:majop...@redhat.com]
Sent: Monday, May 25, 2015 2:57 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Stepping down from Neutron core team

Ahh, I missed this email while I was in the summit.

Thank you for so many years of hard work Salvatore, as Edgar said, your 
“pedant” comments
made it better.  I will miss your sense of humor ;)

Best,
Miguel Ángel Ajo


On Thursday, 21 de May de 2015 at 21:04, Gary Kotton wrote:
-1

From: Carl Baldwin mailto:c...@ecbaldwin.net>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 21, 2015 at 11:32 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Stepping down from Neutron core team


On May 21, 2015 9:06 AM, "Kyle Mestery" 
mailto:mest...@mestery.com>> wrote:
>
> On Thu, May 21, 2015 at 8:58 AM, Salvatore Orlando 
> mailto:sorla...@nicira.com>> wrote:
>>
>> After putting the whole OpenStack networking contributors community through 
>> almost 8 cycles of pedant comments and annoying "what if" questions, it is 
>> probably time for me to relieve neutron contributors from this burden.
>>
>> It has been a pleasure for me serving the Neutron community (or Quantum as 
>> it was called at the time), and now it feel right - and probably overdue - 
>> to relinquish my position as a core team member in a spirit of rotation and 
>> alternation between contributors.
>>
>> Note: Before you uncork your champagne bottles, please be aware that I will 
>> stay in the Neutron community as a contributors and I might still end up 
>> reviewing patches.
>>
>> Thanks for being so understanding with my pedant remarks,
>> Salvatore
>>
>
> If I could -1 this as a patch, I would.
>
> But seriously. Salvatore, thanks for all the years of work you've put into 
> Neutron. Please note that just because you've stepped down from the core 
> reviewer team doesn't mean we won't be relying on you to be a part of the 
> community.
>
> Thanks,
> Kyle

Kyle, I think you should -2 this one.  ;)  Maybe we should put the core team 
list in a repo just so you can.

All joking aside, @Salv, I have appreciated your feedback much more than you 
give yourself credit for, maybe more than I let on.  You don't need to be a 
core to give it, so keep it coming.

Carl
__
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?

[Dimitri Mazmanov]

Here’s one way:

heat_template_version: 2013-05-23
parameters:
  image:
type: string
default: TestVM
  flavor:
type: string
default: m1.micro
  network:
type: string
default: cirros_net2

resources:
  serv_1:
type: OS::Nova::Server
properties:
  image: { get_param: image }
  flavor: { get_param: flavor }
  networks:
- network: {get_param: network}
  scheduler_hints: {different_host: {get_resource: serv_2}}
   serv_2:
type: OS::Nova::Server
properties:
  image: { get_param: image }
  flavor: { get_param: flavor }
  networks:
- network: {get_param: network}
  scheduler_hints: {different_host: {get_resource: serv_1}}

Note: In order to the above mentioned scheduler hints to work, the following 
scheduler filter should be enabled for nova scheduler
  SameHostFilter and
  DifferentHostFilter

There’s another way of doing it using OS::Nova::ServerGroup, but it’s available 
only since Juno.

-
Dimitri

From: Daniel Comnea mailto:comnea.d...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Sunday 24 May 2015 12:24
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
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

[openstack-dev] [Fuel][HA][AMQP] RabbitMQ failover and downtime fixes

[Bogdan Dobrelya]

Folks,

JFYI: There were several major RabbitMQ HA failover related bugs fixed
for the Fuel 6.1 release scope. Short story:
1) the AMQP cluster failover time was dramatically shortened from ~350
to ~220 seconds in average.
2) there is *no more* a full cluster downtime expected while the
failover is in progress.

And these are about to be shortly backported for the 5.1.x/6.0.x
milestones as well.

Long story:
* RabbiMQ fence daemon startup bug [0]. W/o this daemon running, the
rabbit node failover time was *significantly* higher.
* Fix for the full RabbitMQ cluster downtime issue [1] for the master of
the multistate pacemaker resource failover. W/o this fix, all of the
rabbit nodes would have been kept down until the failover finished.
* Decreased mnesia_table_loading_timeout to 10 seconds [2]. This makes
the failover a bit faster.
* Incomplete mnesia files removal [3]. W/or this fix, the rabbit app may
sometimes fail to start.
* Some other fixes in the OCF logic for demote/stop/promote actions [4]
(ready for review, testing in progress). W/o these fixes, the failover
time was much longer than it should be and sometimes it could even fail
and require manual steps (restarting the RabbitMQ cluster resource in
pacemaker) to finish.

Also, there were several fixes related to the bug [5] merged: [6], [7]
but there is still an issue in the OCF script design persist. Which is,
a node might sometimes have missed its join event and the OCF action
monitor might not detect this as the RabbitMQ pacemaker resource agent
keeps the rabbit app stopped unless it is really safe to be started.
Hence, the monitor/start/promote actions must be drastically redesigned
in oder to get this done. This issue may happen not very often, for
example, for the long run failover test I've been running for a while,
it may appear at the 23rd iteration and looks completely random.

Note, there are no additional troubleshooting steps required to be
described in the ops documentation as related patch [8] covers this case
as well. Although, these changes require an update for the RabbitMQ
clustering flow charts [9] (in progress).

[0] https://launchpad.net/bugs/1456791
[1] https://bugs.launchpad.net/fuel/+bug/1436812
[2] https://review.openstack.org/184671
[3] https://bugs.launchpad.net/fuel/+bug/1457766
[4] https://review.openstack.org/185044
[5] https://bugs.launchpad.net/fuel/+bug/1455761
[6] https://review.openstack.org/184911
[7] https://review.openstack.org/184671
[8] https://review.openstack.org/184014
[9] http://goo.gl/PPNrw7

-- 
Best regards,
Bogdan Dobrelya,
Skype #bogdando_at_yahoo.com
Irc #bogdando



__
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

[Roman Vasilets]

Thanks for presentation Rally team at Summit. Nice T-shirt at fist video!
__
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] Integrating Cloudkitty-dashboard to Horizon

[Venkateswarlu P]

Hi,

Does anyone knows how to integrate Cloud-kitty dashboard  to Horizon.

Cloud-kitty - Rating as a service : module


Thanks
Venkatesh P
__
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] [zaqar]

[Li Tianqing]

Yes. I mean trove guest agent.
How can the vm send messages to rabbitmq in management network?



--

Best
Li Tianqing

At 2015-05-23 04:43:28, "Victoria Martínez de la Cruz" 
 wrote:

Hi,


So, what are you trying to do? With guest agent you are referring to Trove 
guest agent?



Thanks





El sáb., 16 may. 2015 a las 5:42, Li Tianqing () escribió:

Hello,
How can zaqar make guestagent in vm connect to server manager? Can someone 
give one example? 
Thanks.





--

Best
Li Tianqing





__
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] meeting with the zaqar team at summit; my notes

[Li Tianqing]

--

Best
Li Tianqing



At 2015-05-23 13:07:42, "Zane Bitter"  wrote:
>On 22/05/15 19:01, Fox, Kevin M wrote:
>> I believe that trove still needs the multi tenant isolation of a multi
>> tenant message queue due to the fact that the vm runs in the tenant, and
>> the tenant can then force a reboot, go to the console, root it, and
>> inject messages at queues destened for other tenants vm's. And there are
>> other routes too.
>
>So what I gathered is that according to the Trove folks you are Doing It 
>Wrong(TM), even though you installed it in the default configuration. 
>You should have modified the Trove code in undocumented ways to create 

>the VMs in a project that Trove itself owns, not the user's project.
Yes
>
>> This is a major problem, and I think our site is going to have to
>> strongly consider uninstalling trove until fixed.
>
>I think if you made that change the configuration it would be a lot less 
>dangerous. Arguably even then it would be better to use something 
>multi-tenant capable and authenticated (if it's so safe why not use the 
>same RabbitMQ as all the other services?), but it would be less of an 

>'immediate uninstall' case.
Can you explain how the vm send messages to rabbitmq in management network? 
>
>cheers,
>Zane.
>
>> Thanks,
>> Kevin *
>> *
>> 
>> *From:* Zane Bitter
>> *Sent:* Friday, May 22, 2015 12:34:01 PM
>> *To:* openstack-dev@lists.openstack.org
>> *Subject:* Re: [openstack-dev] meeting with the zaqar team at summit; my
>> notes
>>
>> On 22/05/15 11:48, Amrith Kumar wrote:
>>> I’m posting this to the mailing list to summarize my notes from a
>>> meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
>>> multi-tenant messaging and how it may be applicable to a number of projects.
>>>
>>> I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
>>> notes and observations after the meeting and how they relate
>>> specifically to Trove. I don’t claim to speak for Trove, other
>>> contributors to Trove, other projects who were at the meeting, for
>>> zaqar, etc., etc.,
>>>
>>> After the meeting I think I have a slightly better understanding of what
>>> Zaqar is but I am still not entirely sure. As best as I can tell, it is
>>> a lightweight, keystone authenticated, multi-tenant messaging system.
>>
>> I'm not sure what 'lightweight' means in this context. I'd describe it
>> as a keystone-authenticated multi-tenant reliable messaging system a la
>> Amazon SQS.
>>
>>> I
>>> am still a little troubled that of the many people in the room who were
>>> knowledgeable of zaqar, there appeared to be some disagreement on how
>>> best to describe or explain the project.
>>
>> I don't think there's any disagreement. It just seems to be hard to
>> explain to people, because everyone instinctively wants to compare it to
>> Rabbit, which is a completely different thing with completely different
>> use cases. IMHO part of the problem has been that folks have been
>> reluctant to name SQS specifically, and so we end up talking elliptically.
>>
>>> I learned that users of zaqar can authenticate with keystone and then
>>> interact with zaqar, and pass messages using it. I learned also that
>>> zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
>>> zaquar as I had thought it was.
>>>
>>> It became clear that the underlying transport in zaqar is not based on
>>> an existing AMQP service, rather zaqar is a “from the ground up”
>>> implementation. This scares me (a lot).
>>
>> Yes, literally every person who has ever heard of Zaqar complains about
>> this and it's getting a little boring. It's irrelevant because Zaqar is
>> not a replacement for AMQP, it's a replacement for SQS.
>>
>>> I gather there is currently no oslo.messaging integration with zaqar;
>>
>> Right, Zaqar has never been intended as a replacement for Rabbit in Oslo
>> messaging.
>>
>> (Although that could be an interesting idea, it's another discussion
>> altogether.)
>>
>>> for Trove to use zaqar we would have to either (a) abandon
>>> oslo.messaging and use zaqar, or (b) build in smarts within Trove to
>>> determine at run time whether we are using zaqar or o.m and implement
>>> code in Trove to handle the differences between them if any.
>>>
>>> It wasn’t clear to me after the meeting what differences there may be
>>> with Trove; one which was alluded to was the inability to do a
>>> synchronous (call()) style message and the statement was that this was
>>> something that “could be built into a driver”.
>>
>> Where Zaqar really provides the biggest benefit is sending the message
>> from the cloud to the user/application (since it can be authenticated by
>> Keystone). IMHO the ideal scenario would be that messages from Trove (or
>> whatever) to the VM would go over Zaqar, and for messages in the other
>> direction would just go straight to the Trove (or whatever) API. The
>> problem is that Keystone'

Re: [openstack-dev] [Neutron][DB] neutron DB migration scripts

[Henry Gessau]

On Mon, May 25, 2015, Zang, Rui  wrote:
> 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

Are you sure you needed to do this step? I have never needed to.

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

Yes, unfortunately the autogenerate currently generates commands to drop all
the FWaaS, LBaaS and VPNaaS tables since their models are not in the neutron
tree. You can and should delete all these commands that are not related to
your new models.

We have been meaning to fix the autogeneration so that it handles the *aaS
tables correctly, but it is a little tricky.

> So I replaced the upgrade() method with the DB table creation code.

If you import your models file in neutron/db/migration/models/head.py then
autogenerate should generate the commands for your schemas (in addition to the
drops for *aaS).

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

They are used by the start migration (havana_initial) and some corner cases.
You shouldn't need them.

> * Should I just keep the "ee78798e4af_my_plugin_init_ops.py" file?

Yes, after modifying it so that it contains only commands for your tables.

> Seems the metadata files are no longer usable.

What metadata files?

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

Yes.

> * Anything what I did wrong or missing?

You were not too far off. I hope my answers helped.

> 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

Re: [openstack-dev] meeting with the zaqar team at summit; my notes

[Flavio Percoco]

On 22/05/15 15:34 -0400, Zane Bitter wrote:

On 22/05/15 11:48, Amrith Kumar wrote:

I’m posting this to the mailing list to summarize my notes from a
meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
multi-tenant messaging and how it may be applicable to a number of projects.

I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
notes and observations after the meeting and how they relate
specifically to Trove. I don’t claim to speak for Trove, other
contributors to Trove, other projects who were at the meeting, for
zaqar, etc., etc.,

After the meeting I think I have a slightly better understanding of what
Zaqar is but I am still not entirely sure. As best as I can tell, it is
a lightweight, keystone authenticated, multi-tenant messaging system.


I'm not sure what 'lightweight' means in this context. I'd describe it 
as a keystone-authenticated multi-tenant reliable messaging system a 
la Amazon SQS.


This is the way we've been describing it.



I
am still a little troubled that of the many people in the room who were
knowledgeable of zaqar, there appeared to be some disagreement on how
best to describe or explain the project.


I don't think there's any disagreement. It just seems to be hard to 
explain to people, because everyone instinctively wants to compare it 
to Rabbit, which is a completely different thing with completely 
different use cases. IMHO part of the problem has been that folks have 
been reluctant to name SQS specifically, and so we end up talking 
elliptically.


+1




I learned that users of zaqar can authenticate with keystone and then
interact with zaqar, and pass messages using it. I learned also that
zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
zaquar as I had thought it was.

It became clear that the underlying transport in zaqar is not based on
an existing AMQP service, rather zaqar is a “from the ground up”
implementation. This scares me (a lot).


Yes, literally every person who has ever heard of Zaqar complains 
about this and it's getting a little boring. It's irrelevant because 
Zaqar is not a replacement for AMQP, it's a replacement for SQS.


Again +1




I gather there is currently no oslo.messaging integration with zaqar;


Right, Zaqar has never been intended as a replacement for Rabbit in 
Oslo messaging.


This is probably the main reason why there's no driver for Zaqar in
oslo.messaging. That is, to prevent people from actually using Zaqar
as a message bus in openstack.



(Although that could be an interesting idea, it's another discussion 
altogether.)



for Trove to use zaqar we would have to either (a) abandon
oslo.messaging and use zaqar, or (b) build in smarts within Trove to
determine at run time whether we are using zaqar or o.m and implement
code in Trove to handle the differences between them if any.

It wasn’t clear to me after the meeting what differences there may be
with Trove; one which was alluded to was the inability to do a
synchronous (call()) style message and the statement was that this was
something that “could be built into a driver”.


Where Zaqar really provides the biggest benefit is sending the message 
from the cloud to the user/application (since it can be authenticated 
by Keystone). IMHO the ideal scenario would be that messages from 
Trove (or whatever) to the VM would go over Zaqar, and for messages in 
the other direction would just go straight to the Trove (or whatever) 
API. The problem is that Keystone's authorisation capabilities are not 
sufficient to handle this at the moment. One thing that should be 
possible in a shorter time-frame is a pre-signed URL for a Zaqar queue 
as a return path.


++




It wasn’t clear to me what scale zaqar has been run at and whether
anyone has in fact deployed and run zaqar at scale, and whether it has
been battle hardened the way a service like RabbitMQ has. While I hear
from many that RabbitMQ is a nightmare to scale and manage, I realize
that it does in fact have a long history of deployments at scale.


I believe that Rackspace deployed it?


And Catalyst




We discussed some of the assumptions being made in the conversation
relative to the security of the various parties to the communication on
the existing rabbit message queue and at the conclusion of the meeting I
believe we left things as below.

(a)Zaqar would be more appealing if it had a simple oslo.messaging
driver and an easier path to integration by client projects like Trove.
The rip-and-replace option put a certain damper on the enthusiasm


So the key point here is that Trove regards the VM running the 
database and the Trove agent as within its own security perimeter. 
(Whether that's appropriate is another debate, but it's up to the 
Trove contributors to decide.) In this case, the ability to 
authenticate to the queue using Keystone provides no real value, so 
this isn't really a use case that requires Zaqar.


The same is not true for other projects, like H

[openstack-dev] [magnum] team irc meeting reminder @ 1600 UTC

[Steven Dake (stdake)]

Hey folks,

Just a quick reminder, we have a team meeting tomorrow at 1600 UTC on 
#openstack-meeting-alt.

Look forward to seeing the team there.

Regards
-steve
__
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

[Ronald Bradford]

To summarize. I believe we have 3 decisions from my original email but I
have also uncovered some more problems.

1. "replication controller" instead of "rc"

Adrian, regarding "rc" and "replication controller".  The OSC uses verbose
commands including multi words. This includes "availability zone", "volume
type" and "security group role".  As this precedent is set, "replication
controller" rather then "rc" is inline with current syntax.   While I
personally am not for verbose operations in general or multi word options,
given the breath of commands already available you may not intrinsically
know what "rc" was, e.g. a OSC user that does not work with containers.

I believe "replication controller" is the appropriate choice here.

2. "execute" or "exec"

This is clearly a new type of action that requires OSC to provide
recommended guidance on. I am 50/50 here.

3. "set" or "update"

While I consider the word "set" to be more an attribute specific term,
"update" implies a change of multiple attributes. If I just looked at the
usage I would say "update".  However, looking at the actual usage openstack
client set syntax uses named parameters to set multiple parameters.

$ openstack help quota set
usage: openstack quota set [-h] [--class] [--properties ]
   [--ram ] [--secgroup-rules ]
   [--instances ] [--key-pairs
]
   [--fixed-ips ] [--secgroups
]
   [--injected-file-size ]
   [--floating-ips ]
   [--injected-files ]
   [--cores ]
   [--injected-path-size ]
   [--gigabytes ] [--volumes ]
   [--snapshots ]
   [--volume-type ]
   


Looking into the help syntax of a Magnum "update" option, I find it
supports "add", "replace" and "remove" operations.  This complicates
matters.

$ magnum help bay-update
usage: magnum bay-update[ ...]

Update information about the given bay.

Positional arguments:
   UUID or name of bay
Operations: 'add', 'replace' or 'remove'
Attributes to add/replace or remove (only PATH is necessary
on
remove)

I see the name specific parameters as a lot of work, I would be a fan of
more general name=value attributes.

Does "update" really then become  "set" and "unset"? Opinions.

4. "service" is already used by Identity. See
http://docs.openstack.org/developer/python-openstackclient/command-objects/service.html

5. "container" is already used by Swift. See
http://docs.openstack.org/developer/python-openstackclient/command-objects/container.html


I have no suggestions on 4. and 5.
Given these last 2 entanglements the OSC will quickly become unusable as
more clients which it integrate.

Regards

Ronald

Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford 
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Mon, May 25, 2015 at 1:30 AM, Steve Martinelli 
wrote:

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

[openstack-dev] [oslo] No meeting today

[Davanum Srinivas]

Hi all,

Sorry for the late notice, since it is a US holiday and we all just
met last week at the summit. Let's skip today's meeting and talk next
week.

thanks,
dims

-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] meeting with the zaqar team at summit; my notes

[Amrith Kumar]

Flavio,

Thanks for your response. I was waiting for your response before replying 
further.

In parallel with the conversation with the Zaqar team, we started some other 
conversations (as you know) at the summit. Bruno (of Catalyst) is in the 
process of formalizing a blueprint for the Nova team that would provide some 
interfaces that would be useful for projects like Trove, Sahara, and if I'm not 
mistaken, Designate, and other projects that launch Nova VM's. Bruno has the 
action item to follow up on this and we'll be working with him on that.

There is one proposals about working with the keystone team (I have the action 
item on this and will be following up with them) to investigate whether the 
project already has, or could easily provide some additional capabilities that 
would similarly be useful for Trove, Sahara and other projects that launch VM's.

The lack of documentation around how to configure Trove is well taken, we will 
be resolving that and making available additional documentation and code to 
address this.

Thanks!

-amrith 

| -Original Message-
| From: Flavio Percoco [mailto:fla...@redhat.com]
| Sent: Monday, May 25, 2015 10:36 AM
| To: OpenStack Development Mailing List (not for usage questions)
| Subject: Re: [openstack-dev] meeting with the zaqar team at summit; my
| notes
| 
| On 22/05/15 15:34 -0400, Zane Bitter wrote:
| >On 22/05/15 11:48, Amrith Kumar wrote:
| >>I’m posting this to the mailing list to summarize my notes from a
| >>meeting at 5pm yesterday at Summit relative to Zaqar and lightweight
| >>multi-tenant messaging and how it may be applicable to a number of
| projects.
| >>
| >>I’ll begin by saying these are not ‘minutes’ of a meeting, merely my
| >>notes and observations after the meeting and how they relate
| >>specifically to Trove. I don’t claim to speak for Trove, other
| >>contributors to Trove, other projects who were at the meeting, for
| >>zaqar, etc., etc.,
| >>
| >>After the meeting I think I have a slightly better understanding of
| >>what Zaqar is but I am still not entirely sure. As best as I can tell,
| >>it is a lightweight, keystone authenticated, multi-tenant messaging
| system.
| >
| >I'm not sure what 'lightweight' means in this context. I'd describe it
| >as a keystone-authenticated multi-tenant reliable messaging system a la
| >Amazon SQS.
| 
| This is the way we've been describing it.
| >
| >>I
| >>am still a little troubled that of the many people in the room who
| >>were knowledgeable of zaqar, there appeared to be some disagreement on
| >>how best to describe or explain the project.
| >
| >I don't think there's any disagreement. It just seems to be hard to
| >explain to people, because everyone instinctively wants to compare it
| >to Rabbit, which is a completely different thing with completely
| >different use cases. IMHO part of the problem has been that folks have
| >been reluctant to name SQS specifically, and so we end up talking
| >elliptically.
| 
| +1
| 
| >
| >>I learned that users of zaqar can authenticate with keystone and then
| >>interact with zaqar, and pass messages using it. I learned also that
| >>zaqar is spelt with a ‘q’ that is not followed by a ‘u’. i.e. it isn’t
| >>zaquar as I had thought it was.
| >>
| >>It became clear that the underlying transport in zaqar is not based on
| >>an existing AMQP service, rather zaqar is a “from the ground up”
| >>implementation. This scares me (a lot).
| >
| >Yes, literally every person who has ever heard of Zaqar complains about
| >this and it's getting a little boring. It's irrelevant because Zaqar is
| >not a replacement for AMQP, it's a replacement for SQS.
| 
| Again +1
| 
| >
| >>I gather there is currently no oslo.messaging integration with zaqar;
| >
| >Right, Zaqar has never been intended as a replacement for Rabbit in
| >Oslo messaging.
| 
| This is probably the main reason why there's no driver for Zaqar in
| oslo.messaging. That is, to prevent people from actually using Zaqar as a
| message bus in openstack.
| 
| >
| >(Although that could be an interesting idea, it's another discussion
| >altogether.)
| >
| >>for Trove to use zaqar we would have to either (a) abandon
| >>oslo.messaging and use zaqar, or (b) build in smarts within Trove to
| >>determine at run time whether we are using zaqar or o.m and implement
| >>code in Trove to handle the differences between them if any.
| >>
| >>It wasn’t clear to me after the meeting what differences there may be
| >>with Trove; one which was alluded to was the inability to do a
| >>synchronous (call()) style message and the statement was that this was
| >>something that “could be built into a driver”.
| >
| >Where Zaqar really provides the biggest benefit is sending the message
| >from the cloud to the user/application (since it can be authenticated
| >by Keystone). IMHO the ideal scenario would be that messages from Trove
| >(or whatever) to the VM would go over Zaqar, and for messages in the
| >other direction would jus

Re: [openstack-dev] [Neutron][DB] neutron DB migration scripts

[Mike Bayer]

On 5/25/15 10:24 AM, Henry Gessau wrote:
Yes, unfortunately the autogenerate currently generates commands to 
drop all the FWaaS, LBaaS and VPNaaS tables since their models are not 
in the neutron tree. You can and should delete all these commands that 
are not related to your new models. We have been meaning to fix the 
autogeneration so that it handles the *aaS tables correctly, but it is 
a little tricky. 
I'm sure you know this already, but when you do this you should be using 
the Alembic include_object hook:


http://alembic.readthedocs.org/en/latest/api.html?highlight=include_object#alembic.environment.EnvironmentContext.configure.params.include_object

implementing this function will give you complete control over every 
object considered by autogenerate.I'm assuming the "tricky" part 
here has to do with some unpredictability on the part of the Neutron 
schema.  On the Alembic side it should be straightforward (e.g. there's 
no need to manipulate the MetaData or anything like that).


Feel free to point me to a review dealing with this.





__
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] I think nova behaves poorly when booting multiple instances

[Chris Friesen]

Hi all,

I've just opened a bug around booting multiple instances at once, and it was 
suggested on IRC that I mention it here to broaden the discussion around the 
ideal behaviour.


The bug is at:  https://bugs.launchpad.net/nova/+bug/1458122

Basically the problem is this:

When booting up instances, nova allows the user to specify a "min count" and a 
"max count".  So logically, this request should be considered successful if at 
least "min count" instances can be booted.


Currently, if the user has quota space for "max count" instances, then nova will 
try to create them all. If any of them can't be scheduled, then the creation of 
all of them will be aborted and they will all be put into an error state.


Arguably, if nova was able to schedule at least "min count" instances (which 
defaults to 1) then it should continue on with creating those instances that it 
was able to schedule. Only if nova cannot create at least "min count" instances 
should nova actually consider the request as failed.


Also, I think that if nova can't schedule "max count" instances, but can 
schedule at least "min count" instances, then it shouldn't put the unscheduled 
ones into an error state--it should just delete them.


Thoughts?

Chris

__
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] [oslo][service] oslo.service puplic repositiry review request

[Flavio Percoco]

On 22/05/15 11:08 -0700, Davanum Srinivas wrote:

Hi Elena,

This looks good to me.

thanks,
dims

On Thu, May 21, 2015 at 7:38 AM, Elena Ezhova  wrote:

Hi, all!

As the spec for the graduation of oslo.service [1] is about to merge I have
created a public repository on github [2] with oslo.service initial version,
which is the next step in graduation of a library according to [3].

I would like to ask everyone interested to review it so we can proceed with
the graduation process.

Thanks, Elena


[1] https://review.openstack.org/#/c/142659/9
[2] https://github.com/eezhova/oslo.service
[3] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary


The above looks good to me,
Flavio

--
@flaper87
Flavio Percoco


pgpCD76QSLG2j.pgp
Description: PGP signature
__
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][DB] neutron DB migration scripts

[Armando M.]

On 25 May 2015 at 08:23, Mike Bayer  wrote:

>
>
> On 5/25/15 10:24 AM, Henry Gessau wrote:
>
>> Yes, unfortunately the autogenerate currently generates commands to drop
>> all the FWaaS, LBaaS and VPNaaS tables since their models are not in the
>> neutron tree. You can and should delete all these commands that are not
>> related to your new models. We have been meaning to fix the autogeneration
>> so that it handles the *aaS tables correctly, but it is a little tricky.
>>
> I'm sure you know this already, but when you do this you should be using
> the Alembic include_object hook:
>
>
> http://alembic.readthedocs.org/en/latest/api.html?highlight=include_object#alembic.environment.EnvironmentContext.configure.params.include_object
>
> implementing this function will give you complete control over every
> object considered by autogenerate.I'm assuming the "tricky" part here
> has to do with some unpredictability on the part of the Neutron schema.  On
> the Alembic side it should be straightforward (e.g. there's no need to
> manipulate the MetaData or anything like that).
>
> Feel free to point me to a review dealing with this.
>
>
>
One thing I would like to point out is that in this cycle we'll be working
extensively in this area to make the very task you are working on easier to
deal with, and better documented. This will fall under the umbrella of the
blueprint [1].

HTH
Armando

[1] https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition


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

Re: [openstack-dev] [Neutron][DB] neutron DB migration scripts

[Mike Bayer]

On 5/25/15 12:34 PM, Armando M. wrote:




One thing I would like to point out is that in this cycle we'll be 
working extensively in this area to make the very task you are working 
on easier to deal with, and better documented. This will fall under 
the umbrella of the blueprint [1].


HTH
Armando

[1] 
https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition


took a look at https://review.openstack.org/#/c/134680/17, can I have 
some clarification on what "currently alembic requires extra work to 
support multiple db migration paths onto a single database"?   Want to 
make sure you're aware that Alembic supports this fully (and my job has 
been to try to get Openstack projects to notice); see 
http://alembic.readthedocs.org/en/latest/branches.html#working-with-multiple-bases.










__
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] [Ironic][oslo] Stepping down from oslo-ironic liaison

[Ghe Rivero]

My focus on the Ironic project has been decreasing in the last cycles, so
it's about time to relinquish my position as a oslo-ironic liaison so new
contributors can take over it and help ironic to be the vibrant project it
is.

So long, and thanks for all the fish,

Ghe Rivero
-- 
Pinky: "Gee, Brain, what do you want to do tonight?"
The Brain: "The same thing we do every night, Pinky—try to take over the
world!"

 .''`.  Pienso, Luego Incordio
: :' :
`. `'
  `-www.debian.orgwww.openstack.com

GPG Key: 26F020F7
GPG fingerprint: 4986 39DA D152 050B 4699  9A71 66DB 5A36 26F0 20F7
__
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]

Thank you!

I'll try it out and check whether it works there. Otherwise I think it 
would be good to get rid of it.


Best regards,

Geza

On 05/24/2015 11:10 PM, Fox, Kevin M wrote:
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


__
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] [glance] [kolla] [magnum] [nova] [neutron] Vancouver Summit Operations Containers Session

[Flavio Percoco]

On 22/05/15 12:35 -0700, Richard Raseley wrote:

Daniel Comnea wrote:

Since i couldn't attend the summit, are there any AIs which needs to
happen/ take place and which i can keep an eye on?


There weren't any action items, which aren't already (in whole or in 
part) in flight as part of their respective product discussions.


From my perspective, a couple of the key bits which came out of the 
discussion were:


* There needs to be a lot of consideration given to the use-case of 
containers as pets, not just as cattle. This is especially important 
from a service provider point of view. People want things like 
live-migration, non-ephemeral storage, etc.


* There is some confusion around what networking models play in what 
ways (e.g. Neutron integration).


* Interest in how Glance is going to solve the issue of 'hierarchical 
images' (for lack of a better term), which is important to some 
container models. This was as coupled with interest in making Glance a 
more generic artifact storage service.


There's work going on on something called Artifacts[0], which - in a
poorly worded definition - is an enhancement of the current image
model in Glance.

It'll take some time for the full migration to happen but that should
solve your requirement.

[0] 
http://specs.openstack.org/openstack/glance-specs/specs/kilo/artifact-repository.html



Again, as I understand it these are already known quantities. If 
anyone feels I've misrepresented parts of our discussion here, please 
let me know.


Regards,

Richard


__
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


--
@flaper87
Flavio Percoco


pgpsyzraTUm9A.pgp
Description: PGP signature
__
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] [Ironic][oslo] Stepping down from oslo-ironic liaison

[Mitsuhiro SHIGEMATSU]

> My focus on the Ironic project has been decreasing in the last cycles, so
> it's about time to relinquish my position as a oslo-ironic liaison so new
> contributors can take over it and help ironic to be the vibrant project it
> is.

Thanks for all your work and service.

-- pshige

2015-05-26 1:45 GMT+09:00 Ghe Rivero :
> My focus on the Ironic project has been decreasing in the last cycles, so
> it's about time to relinquish my position as a oslo-ironic liaison so new
> contributors can take over it and help ironic to be the vibrant project it
> is.
>
> So long, and thanks for all the fish,
>
> Ghe Rivero
> --
> Pinky: "Gee, Brain, what do you want to do tonight?"
> The Brain: "The same thing we do every night, Pinky—try to take over the
> world!"
>
>  .''`.  Pienso, Luego Incordio
> : :' :
> `. `'
>   `-www.debian.orgwww.openstack.com
>
> GPG Key: 26F020F7
> GPG fingerprint: 4986 39DA D152 050B 4699  9A71 66DB 5A36 26F0 20F7
>
> __
> 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 a bunch Gents!

Dani

On Mon, May 25, 2015 at 12:30 PM, Dimitri Mazmanov <
dimitri.mazma...@ericsson.com> wrote:

>  Here’s one way:
>
>  heat_template_version: 2013-05-23
> parameters:
>   image:
> type: string
> default: TestVM
>   flavor:
> type: string
> default: m1.micro
>   network:
> type: string
> default: cirros_net2
>
> resources:
>   serv_1:
> type: OS::Nova::Server
> properties:
>   image: { get_param: image }
>   flavor: { get_param: flavor }
>   networks:
> - network: {get_param: network}
>   scheduler_hints: {different_host: {get_resource: serv_2}}
>serv_2:
> type: OS::Nova::Server
> properties:
>   image: { get_param: image }
>   flavor: { get_param: flavor }
>   networks:
> - network: {get_param: network}
>   scheduler_hints: {different_host: {get_resource: serv_1}}
>
> Note: In order to the above mentioned scheduler hints to work, the
> following scheduler filter should be enabled for nova scheduler
>   SameHostFilter and
>   DifferentHostFilter
>
>  There’s another way of doing it using OS::Nova::ServerGroup, but it’s
> available only since Juno.
>
>  -
> Dimitri
>
>   From: Daniel Comnea 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Sunday 24 May 2015 12:24
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> 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  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
>
>
__
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] Weekly meeting cancelled today

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi All,

The Barbican weekly meeting is cancelled today because of the US
holiday.  Meetings will resume next week at the regularly scheduled time
.

Thanks,

- - Douglas Mendizábal
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVY16nAAoJEB7Z2EQgmLX7UMUP/0AEVdM+EVmWw8OKDPx3L5Vi
2cV4MOgfdnDv+y+yZAWG0HZwi4Bu/2UJTDzACC9DqcmSk3WJ71ULdoIqerWj0Emn
F/4ozEyb/NRoIJWrDgVPAmlnx8Wr8igcDt/tJD8jbjGvU2xGUPAW1FsB5NSsax7d
2CgSED0md1jJxdSBi6Y6+onPzGCMfjFH90eGie/Cz5Z1qn5mRfP9/TPBhQYvqsbO
isV+BADjLmJSvW2c9jkTpIhpnhUTbFauIk/bEZxlEQG1U70NHujs8+/yoVm6IHSt
bWdr1IunNiUt2RY7cU4Ys/Xpkk0KGc3dnEZkI/FJAVLR+8noGJUArrX9XBB9ffAz
4bbj5I9WWJnK4TXT1THMnUwUQ00XFtLSo4AFt+B5ZZm3JoiIxmfgnEJwIC804RNB
VtoULCPx0PaM1LZNE8ZfnZvM+tk6h0U1BP2c6B/7hdKD4vni4jKb2DoFMhzIyLEB
NLjL+eA9J5vkb9+Jx8kkAKMONT5W6JAitgq4Oopj3/Jo/LaKT0CoIpILT6BLTkNk
73AmvqRpEoZPSGUJKvPZ5YHycDamPkl/H8jQUzPTSRFsX+mApZsg04hrdKteMeYi
6wo6zyEyUa5EIJoeixTCTbJlDxNN+NYuclIH3rtXZ0KhAvt1cXO5Ns4hDAjfClU6
BSNFVfKfVIy0WTgrpPdb
=F9+H
-END PGP SIGNATURE-

__
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] Some Changes to Cinder Core

[Avishay Traeger]

On Sat, May 23, 2015 at 2:34 AM, Mike Perez  wrote:

> I would like to recognize Avishay Traeger for his
> contributions, and now
> unfortunately departure from the Cinder core team.
>

Unfortunately I have been unable to participate in fully due to additional
obligations and therefore it is time to step down.  It was a pleasure
serving on the Cinder core team.  I will still be "around", and am not
leaving the community.  I wish Mike and the Cinder team the best of luck.

Cheers,
Avishay
__
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] [Barbican] Nominating Chelsea Winfree for Barbican core

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since there are no objections, Chelsea Winfree is now part of
barbican-core.  Congratulations!

- - Douglas Mendizábal

On 5/21/15 6:58 PM, Nathan Reller wrote:
> +1
> 
> On Thu, May 21, 2015 at 4:53 PM, Juan Antonio Osorio 
>  wrote:
>> +1
>> 
>> On Thu, May 21, 2015 at 11:05 PM, John Wood
>>  wrote:
>>> 
>>> +1
>>> 
>>>  From: Chad Lung
>>>  Sent: Sunday, May 17, 2015 6:34 PM To:
>>> openstack-dev@lists.openstack.org Subject: [openstack-dev]
>>> [Barbican] Nominating Chelsea Winfree for Barbican core
>>> 
>>> Hi all,
>>> 
>>> I'd like to nominate Chelsea Winfree for the Barbican core
>>> review team.
>>> 
>>> Chelsea has been active in Barbican as a regular contributor of
>>> code and helping always needed documentation. 
>>> http://stackalytics.com/?user_id=chelsea-winfree&release=all
>>> 
>>> As a reminder to barbican-core members we use the voting
>>> process outlined in
>>> https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
>>> members to our team.
>>> 
>>> Thanks,
>>> 
>>> Chad Lung EMC Cloud Services
>>> 
>>> 
>>> 
>>> 
__
>>>
>>> 
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
>>>
>>
>>
>>
>>
>>> 
- --
>> Juan Antonio Osorio R. e-mail: jaosor...@gmail.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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVY2CyAAoJEB7Z2EQgmLX7a8wP+gJPQywz3hJwiE51kupcIi6W
z0Uy7QrC41CF91IyEMlGclp1oXPCGFdYb0XFNGGJbu9VoLxdUM5E48EbkjQHRcV/
WNSYiXapfzWx2P23zP33FPvsf2z+Lg8mSlbNeCrV9KCOgDb6vXR37wq1mho5vYyA
RS0mqi6CTQht2o24qhB0HnHqDXHTCfzpSTE3ljrtzLtjSJj1B/f7Dwof3Ek3cLnq
eA88WFiXftQSpKGw/XDvFn7jzHMuXkRWN8MhXV3/gqvNUOmtRaogeO2xg+vGIW1s
8E8iyUKwKjZhj03DTvSKzdLd7RSujXPblzIpulXA2kl9lXurmtRnBDOBqvO7wlyJ
7POB627vMs5ci/T8yYIaBMqxxaXgPNJuH/Kiz4MbcpqzmVtgnAHbNqZvTwCdNwMz
ArFJxvKwxMBL8rQdjEwSaXRrUACYKSwkTT08lcYQZ/g2+yi6oz5EkREztdwIZBkF
ZeSP2kKvpssEbZ0E4B8u16wo/xA1/MFdftzg8YfjK7/aZ/Zx6aFPkKSYxB2R7gNO
f2Ep0SEImswe+cACqoeFv8ba8pNIruBGv34amNsYyp6c91a/6FyvRy0hP0E73iXp
7MMoLoJN37lUM0/bAUaTT6PB1RNw6WOUsc/Bvc3HFW6aR4w+7XrrymuJnctJgny0
0uS/xOd3JdTfcmxVhQK1
=9U0h
-END PGP SIGNATURE-

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

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since there are no objections, Kaitlin Farr is now part of
barbican-core.  Congratulations!

- - Douglas Mendizábal

On 5/24/15 12:19 PM, Chad Lung wrote:
> 
> +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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVY2GYAAoJEB7Z2EQgmLX7ByQP/AvBG2GRW25gtyxL+MFY/AHz
hlZyqS3Hy+c++G/AjwAlVc8p2Ik7t50cqJ0kEaPva5E77JBhLT9yppD1W58gAvjj
jS8e0m+PhZU+3rHLl1UqHFLye1q/tHo4XAmibAAybgxMb42EcwjpPx8vQFXueBmg
7WJyU9tCFatB9fU7F+zHWn0PrAA28FCWMgPwv4dgBpx0z2Ud1xPYmYp/TN4kKAVs
T2jIqc0qYdG9/vBG81rQ+r68mAGrr2896fu1MQiztUYwixeih08VDdl/itAU3piD
kKAo9QGFjUnPWL53J+Bx9TEWZjxB98DcKl57eE9XA0BphG2JeaIvgbMO9A0BArvt
gi+ELScO/Ih5GQ6A9MzzxMltv2GFyxmcVi7yQtKDGkdsOSiD3AnArVPyC7bb+7FV
V9eVuXg0enU7qbSSIErKc5BQQwAYMwoeA5y5tplqE6xv3vpsc57pIgxcOxUbSrYd
FneGNxqqwBM6Si/1SoB7bAQQUs94tJkW+TAfjJ88wKdglDnmz/9DRvJBsL9/1vcH
RHWreMmC5VRobzInzRVL2EBaGluqQglHx88EdSlrlD4cgxkPoPUAEa8c07iWewXn
g6qLFPqUqduJ+Ga8k5u2HzvHKT2XYB/JAUaZ2vvY9aRbiFPCDuqm5frZwC4pkevy
i5GCV4iCcu0mc71R2VfG
=bO+O
-END PGP SIGNATURE-

__
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] Some Changes to Cinder Core

[vilobhmeshram . openstack]

Not a core but definately a +1 for Sean as a Core member. 


He has done enormous amount of reviews and we can definately trust on his +1. 
His stats itself speak for it.




Good work Sean!


—
Sent from Mailbox

On Fri, May 22, 2015 at 9:05 PM, Sheng Bo Hou  wrote:

> I am not a core, but I support with +1 from my heart.
> Best wishes,
> Vincent Hou (侯胜博)
> Staff Software Engineer, Open Standards and Open Source Team, Emerging 
> Technology Institute, IBM China Software Development Lab
> Tel: 86-10-82450778 Fax: 86-10-82453660
> Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com 
> Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang 
> West Road, Haidian District, Beijing, P.R.C.100193
> 地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193
> Jay Bryant  
> 05/23/2015 11:22 AM
> Please respond to
> jsbry...@electronicjungle.net; Please respond to
> "OpenStack Development Mailing List \(not for usage questions\)" 
> 
> To
> "OpenStack Development Mailing List (not for usage questions)" 
> 
> cc
> Subject
> Re: [openstack-dev] [cinder] Some Changes to Cinder Core
> +1 Well deserved.  Welcome to Core Sean! It is a pleasure to work with 
> you! 
> Thanks to Avishay for all his contributions!  Sorry to see you go. 
> Jay
> On May 22, 2015 4:36 PM, "Mike Perez"  wrote:
> This is long overdue, but it gives me great pleasure to nominate Sean
> McGinnis for
> Cinder core.
> Reviews:
> https://review.openstack.org/#/q/reviewer:+%22Sean+McGinnis%22,n,z
> Contributions:
> https://review.openstack.org/#/q/owner:+%22Sean+McGinnis%22,n,z
> 30/90 day review stats:
> http://stackalytics.com/report/contribution/cinder-group/30
> http://stackalytics.com/report/contribution/cinder-group/90
> As new contributors step up to help in the project, some move onto
> other things. I would like to recognize Avishay Traeger for his
> contributions, and now
> unfortunately departure from the Cinder core team.
> Cinder core, please reply with a +1 for approval. This will be left
> open until May 29th. Assuming there are no objections, this will go
> forward after voting is closed.
> --
> Mike Perez
> __
> 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] [Ironic][oslo] Stepping down from oslo-ironic liaison

[Devananda van der Veen]

Thanks for all your contributions, Ghe! You've done a lot to help keep this
project synced with the common libs -- of course, you're welcome back any
time.

Best
Deva

On Mon, May 25, 2015, 09:49 Ghe Rivero  wrote:

> My focus on the Ironic project has been decreasing in the last cycles, so
> it's about time to relinquish my position as a oslo-ironic liaison so new
> contributors can take over it and help ironic to be the vibrant project it
> is.
>
> So long, and thanks for all the fish,
>
> Ghe Rivero
> --
> Pinky: "Gee, Brain, what do you want to do tonight?"
> The Brain: "The same thing we do every night, Pinky—try to take over the
> world!"
>
>  .''`.  Pienso, Luego Incordio
> : :' :
> `. `'
>   `-www.debian.orgwww.openstack.com
>
> GPG Key: 26F020F7
> GPG fingerprint: 4986 39DA D152 050B 4699  9A71 66DB 5A36 26F0 20F7
>  __
> 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] [Ironic] no IRC meeting tonight

[Devananda van der Veen]

Some folks are still traveling (or recovering) from the summit, and today
is a holiday in the US, so I'm cancelling tonight's meeting.

There are many action items recorded in the etherpads - we'll have a lot to
talk about next week!

-Devananda
__
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-scheduler] Scheduler sub-group (gantt} meeting 5/26 - cancel

[Dugger, Donald D]

I would suggest we cancel the IRC meeting this week since we just had the 
summit (and I'm on vacation so it would be  5AM my time :)

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

__
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] [kolla] Functional gate expansion

[Steven Dake (stdake)]

Hey fellow Kolla devs,

With Sam’s recent change to add build from source as an option and build from 
Debuntian binaries as an option, we will end up in a situation where our gate 
will take 4+ hours to build all of the images and run the functional tests.  I 
would like to separate each major distro and source type with a separate 
functional gate, for example:

centos-rdo
fedora-rdo
ubuntu-binary
debian-bianry
centos-source
fedora-source
debian-source
ubuntu-source

I propose separating each of these as a separate non-voting check job.  What 
needs to happen in our image building scripts, our functional tests, and the 
project-config repo to make this happen?

I’d like to make our current functional gate voting asap, but don’t want to 
block build from source to make that happen.

Jeff & Sam, can you two sort this problem out?

Regards
-steve

__
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] [kolla] Add core approver Sam Yaple

[Steven Dake (stdake)]

Hi folks,

I propose Sam Yaple for core approver for the Kolla team.  Sam has a lot of 
great ideas and has done some really cool work lately.  Sam is active in IRC 
and is starting to pick up more reviews.  Of particular interest to me his his 
idea of merging the work he has done on YAODU into Kolla.  This would be 
fantastic for Kolla and allow us to deliver on our goals of providing high 
availability which depends on multi-node deployment in our container 
architecture.

Some really complex and nice improvements to the codebase:
https://review.openstack.org/#q,Ifc7bac0d827470f506c8b5c004a833da9ce13b90,n,z
https://review.openstack.org/#q,Ic0ff96bb8119ddfab15b99e9f1e21cfe8d321dab,n,z
https://review.openstack.org/#q,I95101136dad56e9331d8b92cd394495f7bd0576a,n,z

Sam's stats for Liberty and Kilo:
http://stackalytics.com/?project_type=all&user_id=s8m&module=kolla&release=all

Count my proposal as a +1.  Since our core team is only 5 people presently, I 
think it makes sense to only require one additional +1.  Typically projects 
require 3 +1 votes but have larger core teams, so we will use that in the 
future.  -1 = veto, so vote wisely.  Folks often abstain if they are not 
certain how their vote should go – so don’t feel compelled to vote.

I’ll keep the voting open until May 29th.  If the vote is unanimous or vetoed 
prior, I’ll close voting.

Regards
-steve

__
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] [Puppet] puppet-keystone federation module

[Richard Raseley]

> On May 25, 2015, at 11:35 AM, Iury Ferreira  wrote:
> 
> Hello everyone,
> 
> I'm new in the community and i'm starting to work with K2K Federation.
> I have created scripts in python to easily configure SP (Service Provider) 
> and IdP (Identity Provider) in a K2K environment.
> I am now working on making these scripts with puppet, it would make sense to 
> propose two federation modules (IdP and SP) or just one in puppet-keystone 
> repo?
> 
> Thanks 
> 
> -- 
> ~
> Att[]'s
> Iury Gregory Melo Ferreira 
> Master student in Computer Science at UFCG
> E-mail:  iurygreg...@gmail.com
> ~
> -- 
> 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-openstack+unsubscr...@puppetlabs.com.

The functionality should be integrated into the existing puppet-keystone 
module, if I am understanding your question.__
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] [Swift] Meeting time change

[John Dickinson]

Based on discussion over at the summit and over the last few weeks, the Swift 
team meeting time has changed.

The new meeting time is 2100UTC on Wednesdays in #openstack-meeting.

The meeting agenda is tracked at https://wiki.openstack.org/wiki/Meetings/Swift


--John






signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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] [Puppet] puppet-keystone federation module

[Richard Raseley]

Ah, since they are closely related, it seems plausible that a single blueprint 
would be sufficient.

Regards,

Richard 

> On May 25, 2015, at 12:44 PM, Iury Gregory  wrote:
> 
> Yes Richard, sorry for the misunderstanding.
> Since the configurations for SP and IdP are a little different, I need to 
> create two blueprints or just one?
> 
> 2015-05-25 16:30 GMT-03:00 Richard Raseley :
>> 
>>> On May 25, 2015, at 11:35 AM, Iury Ferreira  wrote:
>>> 
>>> Hello everyone,
>>> 
>>> I'm new in the community and i'm starting to work with K2K Federation.
>>> I have created scripts in python to easily configure SP (Service Provider) 
>>> and IdP (Identity Provider) in a K2K environment.
>>> I am now working on making these scripts with puppet, it would make sense 
>>> to propose two federation modules (IdP and SP) or just one in 
>>> puppet-keystone repo?
>>> 
>>> Thanks 
>>> 
>>> -- 
>>> ~
>>> Att[]'s
>>> Iury Gregory Melo Ferreira 
>>> Master student in Computer Science at UFCG
>>> E-mail:  iurygreg...@gmail.com
>>> ~
>>> -- 
>>> 
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to puppet-openstack+unsubscr...@puppetlabs.com.
>> 
>> The functionality should be integrated into the existing puppet-keystone 
>> module, if I am understanding your question.
>> -- 
>> 
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-openstack+unsubscr...@puppetlabs.com.
> 
> 
> 
> -- 
> ~
> Att[]'s
> Iury Gregory Melo Ferreira 
> Mestrando em Ciência da Computação - UFCG
> E-mail:  iurygreg...@gmail.com
>   iury.ferre...@ccc.ufcg.edu.br  
> ~
> -- 
> 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-openstack+unsubscr...@puppetlabs.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] Stepping down from Neutron core team

[Sukhdev Kapur]

Hey Salvatore,

Best of luck and thanks for all the hard work.


-Sukhdev




On Thu, May 21, 2015 at 8:58 AM, Salvatore Orlando 
wrote:

> After putting the whole OpenStack networking contributors community
> through almost 8 cycles of pedant comments and annoying "what if"
> questions, it is probably time for me to relieve neutron contributors from
> this burden.
>
> It has been a pleasure for me serving the Neutron community (or Quantum as
> it was called at the time), and now it feel right - and probably overdue -
> to relinquish my position as a core team member in a spirit of rotation and
> alternation between contributors.
>
> Note: Before you uncork your champagne bottles, please be aware that I
> will stay in the Neutron community as a contributors and I might still end
> up reviewing patches.
>
> Thanks for being so understanding with my pedant remarks,
> Salvatore
>
> __
> 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] [puppet] Weekly meeting #36

[Colleen Murphy]

Hi everyone,

Here's an initial agenda for our weekly meeting tomorrow at 1500 UTC in
#openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150526

Please add additional items you'd like to discuss.

Colleen
__
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][DB] neutron DB migration scripts

[Henry Gessau]

On Mon, May 25, 2015, Mike Bayer  wrote:
> On 5/25/15 10:24 AM, Henry Gessau wrote:
>> Yes, unfortunately the autogenerate currently generates commands to 
>> drop all the FWaaS, LBaaS and VPNaaS tables since their models are not 
>> in the neutron tree. You can and should delete all these commands that 
>> are not related to your new models. We have been meaning to fix the 
>> autogeneration so that it handles the *aaS tables correctly, but it is 
>> a little tricky. 
> I'm sure you know this already, but when you do this you should be using 
> the Alembic include_object hook:
> 
> http://alembic.readthedocs.org/en/latest/api.html?highlight=include_object#alembic.environment.EnvironmentContext.configure.params.include_object

I kind of knew about it, but I did not realize that I could hook it into the
env like that. Thanks!

> implementing this function will give you complete control over every 
> object considered by autogenerate.I'm assuming the "tricky" part 
> here has to do with some unpredictability on the part of the Neutron 
> schema.  On the Alembic side it should be straightforward (e.g. there's 
> no need to manipulate the MetaData or anything like that).
> 
> Feel free to point me to a review dealing with this.

https://review.openstack.org/185465


__
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] [Horizon] dashboard-app split in horizon

[Richard Jones]

As a follow-up to this [in the misguided hope that anyone will actually
read this conversation with myself ;-)] I've started looking at the
base.html split. At the summit last week, we agreed to:

1. move base.html over from the framework to the dashboard, and
2. move the _conf.html and _scripts.html over as well, since they configure
the application (dashboard).

Upon starting the work it occurs to me that all of the other files
referenced by base.html should also move. So, here's the complete list of
base.html components and whether they should move over in my opinion:

- horizon/_custom_meta.html
  Yep, is an empty file in horizon, intended as an extension point in
dashboard. The empty file (plus an added comment) should move.
  - horizon/_stylesheets.html
  Is just a dummy in horizon anyway, should move.
- horizon/_conf.html
  Yep, should move.
- horizon/client_side/_script_loader.html
  Looks to be a framework component not intended for override, so we should
leave it there.
- horizon/_custom_head_js.html
  Yep, is an empty file in horizon, intended as an extension point in
dashboard. Move, with a comment added.
- horizon/_header.html
  There is a basic implementation in framework but the real (used)
implementation is in dashboard, so should move.
- horizon/_messages.html
  This is a framework component, so I think should stay there. I'm not sure
whether anyone would ever wish to override this. Also the bulk of it is
probably going to be replaced by the  implementation anyway... hmm...
- horizon/common/_sidebar.html
  This is an overridable component that I think should move.
- horizon/common/_page_header.html
  This is an overridable component that I think should move.
- horizon/_scripts.html
  Yep, should move.

Thoughts, anyone who has read this far?


Richard


On Sat, 23 May 2015 at 11:46 Richard Jones  wrote:

> As part of the ongoing Horizon project code reorganisation, we today
> agreed to clean up the Horizon-the-Framework and OpenStack Dashboard
> separation issue by doing a couple of things:
>
> 1. nuke (the recently-created) horizon dashboard-app by moving the angular
> app over to dashboard and the other contents to appropriate places (mostly
> under the heading of "tech-debt" :)
> 2. move base.html, _conf.html and _scripts.html from horizon over to
> dashboard.
>
> Thanks to Cindy, Sean and Thai for the pair (er triple?) programming
> keeping me honest today.
>
> The first step is done and captured in several linked patches based off
> your leaf patch "ngReorg - Create dashboard-app" <
> https://review.openstack.org/#/c/184597/> (yes, I am nuking the thing
> created by your patch).
>
> I've not done the second step, but might find some time since I have 6
> hours to waste in LAX tomorrow.
>
>
>  Richard
>
>
__
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] [Ironic][oslo] Stepping down from oslo-ironic liaison

[Davanum Srinivas]

Thanks a lot for your work Ghe and best wishes and hope to see you back.

-- dims

On Mon, May 25, 2015 at 9:45 AM, Ghe Rivero  wrote:
> My focus on the Ironic project has been decreasing in the last cycles, so
> it's about time to relinquish my position as a oslo-ironic liaison so new
> contributors can take over it and help ironic to be the vibrant project it
> is.
>
> So long, and thanks for all the fish,
>
> Ghe Rivero
> --
> Pinky: "Gee, Brain, what do you want to do tonight?"
> The Brain: "The same thing we do every night, Pinky—try to take over the
> world!"
>
>  .''`.  Pienso, Luego Incordio
> : :' :
> `. `'
>   `-www.debian.orgwww.openstack.com
>
> GPG Key: 26F020F7
> GPG fingerprint: 4986 39DA D152 050B 4699  9A71 66DB 5A36 26F0 20F7
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

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

[Zang, Rui]

Hi Henry,

Your replies are very helpful! Thank you very much.
Some minor replies in line.

Thanks,
Rui Zang

> -Original Message-
> From: Henry Gessau [mailto:ges...@cisco.com]
> Sent: Monday, May 25, 2015 10:25 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][DB] neutron DB migration scripts
> 
> On Mon, May 25, 2015, Zang, Rui  wrote:
> > 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
> 
> Are you sure you needed to do this step? I have never needed to.
> 
[Zang, Rui]  I guess you meant that I did not need to *copy* this alembic.ini 
file.
But I still need this file for neutron-db-manage command, right?


> > - 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.
> 
> Yes, unfortunately the autogenerate currently generates commands to drop all
> the FWaaS, LBaaS and VPNaaS tables since their models are not in the neutron
> tree. You can and should delete all these commands that are not related to
> your new models.
> 
> We have been meaning to fix the autogeneration so that it handles the *aaS
> tables correctly, but it is a little tricky.
> 
> > So I replaced the upgrade() method with the DB table creation code.
> 
> If you import your models file in neutron/db/migration/models/head.py then
> autogenerate should generate the commands for your schemas (in addition to
> the drops for *aaS).
> 
> > - 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?
> 
> They are used by the start migration (havana_initial) and some corner cases.
> You shouldn't need them.
> 
> > * Should I just keep the "ee78798e4af_my_plugin_init_ops.py" file?
> 
> Yes, after modifying it so that it contains only commands for your tables.
> 
> > Seems the metadata files are no longer usable.
> 
> What metadata files?
> 
[Zang, Rui] I meant the "alembic.ini" file and the neutron.conf file

> > * 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?
> 
> Yes.
> 
> > * Anything what I did wrong or missing?
> 
> You were not too far off. I hope my answers helped.
> 
> > 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 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] [kolla] Add core approver Sam Yaple

[Andre Martin]

On May 26, 2015, at 03:59, Steven Dake (stdake) 
mailto:std...@cisco.com>> wrote:

Hi folks,

I propose Sam Yaple for core approver for the Kolla team.  Sam has a lot of 
great ideas and has done some really cool work lately.  Sam is active in IRC 
and is starting to pick up more reviews.  Of particular interest to me his his 
idea of merging the work he has done on YAODU into Kolla.  This would be 
fantastic for Kolla and allow us to deliver on our goals of providing high 
availability which depends on multi-node deployment in our container 
architecture.

Some really complex and nice improvements to the codebase:
https://review.openstack.org/#q,Ifc7bac0d827470f506c8b5c004a833da9ce13b90,n,z
https://review.openstack.org/#q,Ic0ff96bb8119ddfab15b99e9f1e21cfe8d321dab,n,z
https://review.openstack.org/#q,I95101136dad56e9331d8b92cd394495f7bd0576a,n,z

Sam's stats for Liberty and Kilo:
http://stackalytics.com/?project_type=all&user_id=s8m&module=kolla&release=all

Count my proposal as a +1.  Since our core team is only 5 people presently, I 
think it makes sense to only require one additional +1.  Typically projects 
require 3 +1 votes but have larger core teams, so we will use that in the 
future.  -1 = veto, so vote wisely.  Folks often abstain if they are not 
certain how their vote should go – so don’t feel compelled to vote.

I’ll keep the voting open until May 29th.  If the vote is unanimous or vetoed 
prior, I’ll close voting.

Huge +1 for me. Sam is an excellent engineer with lots of interesting ideas, he 
would be a great addition to the core team.

Martin

Regards
-steve

__
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


"PLEASE NOTE:  This email,  and  any  attachments  hereto,  are
intended only  for use  by the specified addressee(s)  and  may
contain legally privileged and/or confidential and/or proprietary
information of KVH Co., Ltd.  and/or its affiliates  (including
personal information).  If you are not the intended recipient of
this email, please immediately notify the sender by email,  and
please permanently  delete the original,  any print out and any
copies of the foregoing. "



__
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] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers

[Kevin Benton]

Hi,

A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused
DHCPNAK messages when multiple agents are scheduled to a network [2].

This was back-ported to Icehouse and Juno so we need a fix that is
compatible with both of them.

I have two fixes for this so far and a third alternative if we don't like
those.

The first is hacky, but it's only a few-line change.[3] It adds an iptables
rule that just stops the DHCPNAKs from making it to the client. This is
clean to back-port but it doesn't protect clients that have filtering
disabled (e.g. bare metal).

The second persists the DHCP leases to a database.[4] The downside to this
was always that being rescheduled to another agent would mean no entries in
the lease file. This approach adds a work-around to generate an initial
fake lease file based on all of the ports in the network.

A third approach that I don't have a patch pushed for yet is very similar
to the second. When dnsmasq is in the leasefile-ro mode, it will call the
script passed to --dhcp-script to get a list of leases to start with. This
script would be built with the same logic as the second one. The only
difference between the second approach is that dnsmasq wouldn't persist
leases to a database.


I'm looking for feedback on how we want to go forward with this in a
back-port friendly manner.

Cheers,
Kevin Benton


1.
https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z
2. https://bugs.launchpad.net/neutron/+bug/1457900
3. https://review.openstack.org/#/c/185332/
4. https://review.openstack.org/#/c/185486/

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

Re: [openstack-dev] [Neutron][DB] neutron DB migration scripts

[Armando M.]

On 25 May 2015 at 09:46, Mike Bayer  wrote:

>
>
> On 5/25/15 12:34 PM, Armando M. wrote:
>
>
>
>
>
> One thing I would like to point out is that in this cycle we'll be working
> extensively in this area to make the very task you are working on easier to
> deal with, and better documented. This will fall under the umbrella of the
> blueprint [1].
>
>  HTH
> Armando
>
>  [1]
> https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition
>
>
> took a look at https://review.openstack.org/#/c/134680/17, can I have
> some clarification on what "currently alembic requires extra work to
> support multiple db migration paths onto a single database"?   Want to make
> sure you're aware that Alembic supports this fully (and my job has been to
> try to get Openstack projects to notice); see
> http://alembic.readthedocs.org/en/latest/branches.html#working-with-multiple-bases
> .
>
>

The wording might be confusing, my bad.

What I intended there was that neutron's logic to handle alembic migrations
required some work in order to simplify the support of out-of-tree DB
migrations. Past experiences, like the one that triggered this thread, have
shown that we can improve neutron's tooling (neutron-db-manage), as well as
documentation.

Cheers,
Armando


>

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

Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers

[Doug Wiegley]

Option 4, turn off authoritative if we don’t want NAK’s?

doug

> On May 25, 2015, at 7:35 PM, Kevin Benton  wrote:
> 
> Hi,
> 
> A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused 
> DHCPNAK messages when multiple agents are scheduled to a network [2].
> 
> This was back-ported to Icehouse and Juno so we need a fix that is compatible 
> with both of them.
> 
> I have two fixes for this so far and a third alternative if we don't like 
> those.
> 
> The first is hacky, but it's only a few-line change.[3] It adds an iptables 
> rule that just stops the DHCPNAKs from making it to the client. This is clean 
> to back-port but it doesn't protect clients that have filtering disabled 
> (e.g. bare metal).
> 
> The second persists the DHCP leases to a database.[4] The downside to this 
> was always that being rescheduled to another agent would mean no entries in 
> the lease file. This approach adds a work-around to generate an initial fake 
> lease file based on all of the ports in the network.
> 
> A third approach that I don't have a patch pushed for yet is very similar to 
> the second. When dnsmasq is in the leasefile-ro mode, it will call the script 
> passed to --dhcp-script to get a list of leases to start with. This script 
> would be built with the same logic as the second one. The only difference 
> between the second approach is that dnsmasq wouldn't persist leases to a 
> database.
> 
> 
> I'm looking for feedback on how we want to go forward with this in a 
> back-port friendly manner.
> 
> Cheers,
> Kevin Benton
> 
> 
> 1. 
> https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z
>  
> 
> 2. https://bugs.launchpad.net/neutron/+bug/1457900 
> 
> 3. https://review.openstack.org/#/c/185332/ 
> 
> 4. https://review.openstack.org/#/c/185486/ 
> 
> 
> -- 
> Kevin Benton
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Barbican] Nominating Chelsea Winfree for Barbican core

[Chelsea Winfree]

Thanks to everyone for the votes of confidence! I appreciate it. Really missed 
seeing you all at OS Vancouver! 

Have a great week!

From: Douglas Mendizábal 
Sent: Monday, May 25, 2015 12:49 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Barbican] Nominating Chelsea Winfree for Barbican 
core

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since there are no objections, Chelsea Winfree is now part of
barbican-core.  Congratulations!

- - Douglas Mendizábal

On 5/21/15 6:58 PM, Nathan Reller wrote:
> +1
>
> On Thu, May 21, 2015 at 4:53 PM, Juan Antonio Osorio
>  wrote:
>> +1
>>
>> On Thu, May 21, 2015 at 11:05 PM, John Wood
>>  wrote:
>>>
>>> +1
>>>
>>>  From: Chad Lung
>>>  Sent: Sunday, May 17, 2015 6:34 PM To:
>>> openstack-dev@lists.openstack.org Subject: [openstack-dev]
>>> [Barbican] Nominating Chelsea Winfree for Barbican core
>>>
>>> Hi all,
>>>
>>> I'd like to nominate Chelsea Winfree for the Barbican core
>>> review team.
>>>
>>> Chelsea has been active in Barbican as a regular contributor of
>>> code and helping always needed documentation.
>>> http://stackalytics.com/?user_id=chelsea-winfree&release=all
>>>
>>> As a reminder to barbican-core members we use the voting
>>> process outlined in
>>> https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
>>> members to our team.
>>>
>>> Thanks,
>>>
>>> Chad Lung EMC Cloud Services
>>>
>>>
>>>
>>> 
__
>>>
>>>
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
>>>
>>
>>
>>
>>
>>>
- --
>> Juan Antonio Osorio R. e-mail: jaosor...@gmail.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
>
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVY2CyAAoJEB7Z2EQgmLX7a8wP+gJPQywz3hJwiE51kupcIi6W
z0Uy7QrC41CF91IyEMlGclp1oXPCGFdYb0XFNGGJbu9VoLxdUM5E48EbkjQHRcV/
WNSYiXapfzWx2P23zP33FPvsf2z+Lg8mSlbNeCrV9KCOgDb6vXR37wq1mho5vYyA
RS0mqi6CTQht2o24qhB0HnHqDXHTCfzpSTE3ljrtzLtjSJj1B/f7Dwof3Ek3cLnq
eA88WFiXftQSpKGw/XDvFn7jzHMuXkRWN8MhXV3/gqvNUOmtRaogeO2xg+vGIW1s
8E8iyUKwKjZhj03DTvSKzdLd7RSujXPblzIpulXA2kl9lXurmtRnBDOBqvO7wlyJ
7POB627vMs5ci/T8yYIaBMqxxaXgPNJuH/Kiz4MbcpqzmVtgnAHbNqZvTwCdNwMz
ArFJxvKwxMBL8rQdjEwSaXRrUACYKSwkTT08lcYQZ/g2+yi6oz5EkREztdwIZBkF
ZeSP2kKvpssEbZ0E4B8u16wo/xA1/MFdftzg8YfjK7/aZ/Zx6aFPkKSYxB2R7gNO
f2Ep0SEImswe+cACqoeFv8ba8pNIruBGv34amNsYyp6c91a/6FyvRy0hP0E73iXp
7MMoLoJN37lUM0/bAUaTT6PB1RNw6WOUsc/Bvc3HFW6aR4w+7XrrymuJnctJgny0
0uS/xOd3JdTfcmxVhQK1
=9U0h
-END PGP SIGNATURE-

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

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

Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers

[Kevin Benton]

Here is the description of the behavior for --dhcp-authoritative from the
dnsmasq page. [1]

>Should be set when dnsmasq is definitely the only DHCP server on a
network. For DHCPv4, it changes the behaviour from strict RFC compliance so
that DHCP requests on unknown leases from unknown hosts are not ignored.
This allows new hosts to get a lease without a tedious timeout under all
circumstances. It also allows dnsmasq to rebuild its lease database without
each client needing to reacquire a lease, if the database is lost. For
DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0
(the minimum).

As far as I understand it, the original intent of the patch that caused the
issue was to fix that refusal to answer lease renewals after a restart. So
it wasn't added to get NAKs, it was added to make it respond to renewals
before they timeout.


1. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html


On Mon, May 25, 2015 at 7:44 PM, Doug Wiegley 
wrote:

> Option 4, turn off authoritative if we don’t want NAK’s?
>
> doug
>
> On May 25, 2015, at 7:35 PM, Kevin Benton  wrote:
>
> Hi,
>
> A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused
> DHCPNAK messages when multiple agents are scheduled to a network [2].
>
> This was back-ported to Icehouse and Juno so we need a fix that is
> compatible with both of them.
>
> I have two fixes for this so far and a third alternative if we don't like
> those.
>
> The first is hacky, but it's only a few-line change.[3] It adds an
> iptables rule that just stops the DHCPNAKs from making it to the client.
> This is clean to back-port but it doesn't protect clients that have
> filtering disabled (e.g. bare metal).
>
> The second persists the DHCP leases to a database.[4] The downside to this
> was always that being rescheduled to another agent would mean no entries in
> the lease file. This approach adds a work-around to generate an initial
> fake lease file based on all of the ports in the network.
>
> A third approach that I don't have a patch pushed for yet is very similar
> to the second. When dnsmasq is in the leasefile-ro mode, it will call the
> script passed to --dhcp-script to get a list of leases to start with. This
> script would be built with the same logic as the second one. The only
> difference between the second approach is that dnsmasq wouldn't persist
> leases to a database.
>
>
> I'm looking for feedback on how we want to go forward with this in a
> back-port friendly manner.
>
> Cheers,
> Kevin Benton
>
>
> 1.
> https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z
> 2. https://bugs.launchpad.net/neutron/+bug/1457900
> 3. https://review.openstack.org/#/c/185332/
> 4. https://review.openstack.org/#/c/185486/
>
> --
> Kevin Benton
>  __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers

[Doug Wiegley]

After a brief IRC conversation with Kevin, he pointed out that we already don’t 
allow any other ports on the subnet to send DHCP replies, so NAKs are 
completely unnecessary. I’d be fine just filtering them out for now.

Thanks,
doug

> On May 25, 2015, at 7:54 PM, Kevin Benton  wrote:
> 
> Here is the description of the behavior for --dhcp-authoritative from the 
> dnsmasq page. [1]
> 
> >Should be set when dnsmasq is definitely the only DHCP server on a network. 
> >For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP 
> >requests on unknown leases from unknown hosts are not ignored. This allows 
> >new hosts to get a lease without a tedious timeout under all circumstances. 
> >It also allows dnsmasq to rebuild its lease database without each client 
> >needing to reacquire a lease, if the database is lost. For DHCPv6 it sets 
> >the priority in replies to 255 (the maximum) instead of 0 (the minimum).
> 
> As far as I understand it, the original intent of the patch that caused the 
> issue was to fix that refusal to answer lease renewals after a restart. So it 
> wasn't added to get NAKs, it was added to make it respond to renewals before 
> they timeout.
> 
> 
> 1. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html 
> 
> 
> 
> On Mon, May 25, 2015 at 7:44 PM, Doug Wiegley  > wrote:
> Option 4, turn off authoritative if we don’t want NAK’s?
> 
> doug
> 
>> On May 25, 2015, at 7:35 PM, Kevin Benton > > wrote:
>> 
>> Hi,
>> 
>> A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has caused 
>> DHCPNAK messages when multiple agents are scheduled to a network [2].
>> 
>> This was back-ported to Icehouse and Juno so we need a fix that is 
>> compatible with both of them.
>> 
>> I have two fixes for this so far and a third alternative if we don't like 
>> those.
>> 
>> The first is hacky, but it's only a few-line change.[3] It adds an iptables 
>> rule that just stops the DHCPNAKs from making it to the client. This is 
>> clean to back-port but it doesn't protect clients that have filtering 
>> disabled (e.g. bare metal).
>> 
>> The second persists the DHCP leases to a database.[4] The downside to this 
>> was always that being rescheduled to another agent would mean no entries in 
>> the lease file. This approach adds a work-around to generate an initial fake 
>> lease file based on all of the ports in the network.
>> 
>> A third approach that I don't have a patch pushed for yet is very similar to 
>> the second. When dnsmasq is in the leasefile-ro mode, it will call the 
>> script passed to --dhcp-script to get a list of leases to start with. This 
>> script would be built with the same logic as the second one. The only 
>> difference between the second approach is that dnsmasq wouldn't persist 
>> leases to a database.
>> 
>> 
>> I'm looking for feedback on how we want to go forward with this in a 
>> back-port friendly manner.
>> 
>> Cheers,
>> Kevin Benton
>> 
>> 
>> 1. 
>> https://review.openstack.org/#/q/Ieff0236670c1403b5d79ad8e50d7574c1b694e34,n,z
>>  
>> 
>> 2. https://bugs.launchpad.net/neutron/+bug/1457900 
>> 
>> 3. https://review.openstack.org/#/c/185332/ 
>> 
>> 4. https://review.openstack.org/#/c/185486/ 
>> 
>> 
>> -- 
>> Kevin Benton
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
>> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> 
> 
> -- 
> Kevin Benton
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [puppet] Weekly meeting #36

[Matt Fischer]

Emilien, sbadia, and spredzy are out. Given that agenda, should we cancel
since its right after the summit and a holiday? My update (the only other
thing on the agenda) is that the clean-up is done.

On Mon, May 25, 2015 at 4:14 PM, Colleen Murphy  wrote:

> Hi everyone,
>
> Here's an initial agenda for our weekly meeting tomorrow at 1500 UTC in
> #openstack-meeting-4:
>
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150526
>
> Please add additional items you'd like to discuss.
>
> Colleen
>
> --
>
>  To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-openstack+unsubscr...@puppetlabs.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-dev] Stepping Down from Trove Core

[Vipul Sabhaya]

Having not been very active in Trove for the past few months, it’s time to
step down from the core team.

I’ll be focusing primarily on Cue going forward, getting it included into
the Big Tent, and making it production worthy.

>From RedDwarf to Trove to Onwards and Upwards!

-Vipul
__
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] [puppet] Weekly meeting #36

[Colleen Murphy]

On Mon, May 25, 2015 at 8:17 PM, Matt Fischer  wrote:

> Emilien, sbadia, and spredzy are out. Given that agenda, should we cancel
> since its right after the summit and a holiday? My update (the only other
> thing on the agenda) is that the clean-up is done.
>
Let's go ahead and cancel, as there's nothing time critical on the agenda.

Colleen
__
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] [Ironic][oslo] Stepping down from oslo-ironic liaison

[Tan, Lin]

Thank you for your effort and wish you luck, Ghe

B.R

Tan

From: Ghe Rivero [mailto:g...@debian.org]
Sent: Tuesday, May 26, 2015 12:46 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison

My focus on the Ironic project has been decreasing in the last cycles, so it's 
about time to relinquish my position as a oslo-ironic liaison so new 
contributors can take over it and help ironic to be the vibrant project it is.

So long, and thanks for all the fish,

Ghe Rivero
--
Pinky: "Gee, Brain, what do you want to do tonight?"
The Brain: "The same thing we do every night, Pinky—try to take over the world!"

 .''`.  Pienso, Luego Incordio
: :' :
`. `'
  `-www.debian.org
www.openstack.com

GPG Key: 26F020F7
GPG fingerprint: 4986 39DA D152 050B 4699  9A71 66DB 5A36 26F0 20F7
__
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