[openstack-dev] [Murano] Nominating Kirill Zaitsev for murano-core

[Serg Melikyan]

I'd like to propose Kirill Zaitsev to core members of Murano team.

Kirill Zaitsev is active member of our community, he implemented
 several blueprint in
Kilo and fixed number of bugs, he maintains a really good score as
contributor:
http://stackalytics.com/report/users/kzaitsev

Existing Murano cores, please vote +1/-1 for the addition of Kirill to the
murano-core.
-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.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] [Murano] Nominating Filip Blaha for murano-core

[Serg Melikyan]

Folks, I'd like to propose Filip Blaha to core members of Murano team.

Filip is active member of our community and he maintains a good score
as contributor:
http://stackalytics.com/report/users/filip-blaha

Existing Murano cores, please vote +1/-1 for the addition of Filip to
the murano-core.
-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.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] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

[Adrian Otto]

-1. I disagree.

I am not convinced that requiring names is a good idea. I've asked several 
times why there is a desire to require names, and I'm not seeing any persuasive 
arguments that are not already addressed by UUIDs. We have UUID values to allow 
for acting upon an individual resource. Names are there as a convenience. 
Requiring names, especially unique names, would make Magnum harder to use for 
API users driving Magnum from other systems. I want to keep the friction as low 
as possible.

I'm fine with replacing "None" with an empty string.

Consistency with Nova would be a valid argument if we were being more 
restrictive, but that's not the case. We are more permissive. You can use 
Magnum in the same way you use Nova if you want, by adding names to all 
resources. I don't see the wisdom in forcing that style of use without a 
technical reason for it.

Thanks,

Adrian

On May 31, 2015, at 4:43 PM, Jay Lau 
mailto:jay.lau@gmail.com>> wrote:


Just want to use ML to trigger more discussion here. There are now bugs/patches 
tracing this, but seems more discussions are needed before we come to a 
conclusion.

https://bugs.launchpad.net/magnum/+bug/1453732
https://review.openstack.org/#/c/181839/
https://review.openstack.org/#/c/181837/
https://review.openstack.org/#/c/181847/
https://review.openstack.org/#/c/181843/

IMHO, making the Bay/Baymodel name as a MUST will bring more flexibility to end 
user as Magnum also support operating Bay/Baymodel via names and the name might 
be more meaningful to end users.

Perhaps we can borrow some iead from nova, the concept in magnum can be mapped 
to nova as following:

1) instance => bay
2) flavor => baymodel

So I think that a solution might be as following:
1) Make name as a MUST for both bay/baymodel
2) Update magnum client to use following style for bay-create and 
baymodel-create: DO NOT add "--name" option

root@devstack007:/tmp# nova boot
usage: nova boot [--flavor ] [--image ]
 [--image-with ] [--boot-volume ]
 [--snapshot ] [--min-count ]
 [--max-count ] [--meta ]
 [--file ] [--key-name ]
 [--user-data ]
 [--availability-zone ]
 [--security-groups ]
 [--block-device-mapping ]
 [--block-device key1=value1[,key2=value2...]]
 [--swap ]
 [--ephemeral size=[,format=]]
 [--hint ]
 [--nic 
]
 [--config-drive ] [--poll]
 
error: too few arguments
Try 'nova help boot' for more information.
root@devstack007:/tmp# nova flavor-create
usage: nova flavor-create [--ephemeral ] [--swap ]
  [--rxtx-factor ] [--is-public ]
  

Please show your comments if any.

--
Thanks,

Jay Lau (Guangya Liu)
__
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] virtual machine can not get DHCP lease due packet has no checksum

[Kevin Benton]

I would propose a back-port of it and then continue the discussion on the
patch. I don't see any major blockers for back-porting it.

On Mon, Jun 1, 2015 at 7:01 PM, Tidwell, Ryan  wrote:

> Not seeing this on Kilo, we're seeing this on Juno builds (that's
> expected).  I'm interested in a Juno backport, but mainly wanted to be see
> if others had confidence in the fix.  The discussion in the bug report also
> seemed to indicate there were other alternative solutions others might be
> looking into that didn't involve an iptables rule.
>
> -Ryan
>
> -Original Message-
> From: Mark McClain [mailto:m...@mcclain.xyz]
> Sent: Monday, June 01, 2015 6:47 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] virtual machine can not get DHCP
> lease due packet has no checksum
>
>
> > On Jun 1, 2015, at 7:26 PM, Tidwell, Ryan  wrote:
> >
> > I see a fix for https://bugs.launchpad.net/neutron/+bug/1244589 merged
> during Kilo.  I'm wondering if we think we have identified a root cause and
> have merged an appropriate long-term fix, or if
> https://review.openstack.org/148718 was merged just so there's at least a
> fix available while we investigate other alternatives.  Does anyone have an
> update to provide?
> >
> > -Ryan
>
> The fix works in environments we’ve tested in.  Are you still seeing
> problems?
>
> mark
> __
> 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-dev] [Fuel] Hard Code Freeze status update - Just 1st 8PM PDT

[Eugene Bogdanov]

Hello everyone,

We keep fixing bugs with a decent pace, but we received 2 critical and 
10+ high new bugs from QA today. All manageable, but we need 1 more day 
to close them out and do smoke testing. So, ETA for HardCodeFreeze is 
June 3rd.


Today's stats:

Bugs left:  7 bugs + 17 incomplete.
Automated tests pass rate: 72% for CentoOS, 70% for Ubuntu.

--
EugeneB

__
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] [murano] oslo namespace changes and murano-dashboard

[Serg Melikyan]

Hi Doug,

sorry for the late response, I was traveling a little bit after the
summit. I've released python-muranoclient 0.6.0 with requirements
changes made by you.

We use new release policy for libraries, so versions >=0.5.6,<0.6.0
correspond to Kilo release, and >=0.6 correspond to the Liberty:
https://launchpad.net/python-muranoclient/+series

Do we need to make changes in Kilo branch?

On Fri, May 29, 2015 at 10:00 PM, Georgy Okrokvertskhov
 wrote:
> Hi,
>
> We do monitor both IRC and openstack-dev. #murano is our IRC channel. Most
> of the time there are someone who can respond quickly.  Mirantis and
> Telefonica guys are located in Europe so they will respond during US morning
> but not during US day time. HP guys are US based so they can respond more
> quickly in US timezones.
>
> As for the releases, murano-dashboard is installed from master on the gates,
> so it should already be compatible with oslo changes, but python-muranoagent
> is release based and we need to release a new version and upload it to pip
> repository as it is installed via pip.
>
> Thanks
> Gosha
>
> On Fri, May 29, 2015 at 9:34 AM, Jeremy Stanley  wrote:
>>
>> On 2015-05-29 12:28:37 -0400 (-0400), Doug Hellmann wrote:
>> > First, where do you hang out on IRC? I couldn’t find a channel
>> > that looked like it had any population, and there’s nothing
>> > mentioned on https://wiki.openstack.org/wiki/Murano
>> [...]
>>
>>
>> https://wiki.openstack.org/wiki/IRC says it's #murano (though I
>> haven't /joined to see if anyone actually uses it, I would assume
>> they do).
>> --
>> Jeremy Stanley
>>
>> __
>> 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
>
>
>
>
> --
> Georgy Okrokvertskhov
> Architect,
> OpenStack Platform Products,
> Mirantis
> http://www.mirantis.com
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
>
> __
> 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
>



-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.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] Scheduler sub-group (gantt) meeting 6/2

[Dugger, Donald D]

Meeting on #openstack-meeting at 1500 UTC (9:00AM MDT)

1) Liberty summit recap - 
https://etherpad.openstack.org/p/YVR-nova-scheduler-in-liberty
2) Updating concept of resource - Ed Leafe's email thread
3) Opens

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

Re: [openstack-dev] [all] upcoming oslo releases

[Davanum Srinivas]

Doug,

Here's the updated tip of the trees that i have tested by hand against
at least Nova.

0.5.0  8f4100a debtcollector
1.10.0 9a963a9 oslo.concurrency
1.12.0 cc9940f oslo.config
0.4.0  23f81ea oslo.context
1.10.0 42dc936 oslo.db
1.7.0  7935c3f oslo.i18n
1.3.0  1d64c91 oslo.log
1.12.0 5181361 oslo.messaging
0.5.0  08215c5 oslo.policy
1.8.0  563291f oslo.rootwrap
1.6.0  15c82cc oslo.serialization
1.6.0  e5349b9 oslo.utils
0.3.0  a03c635 oslo.versionedobjects

Let's please release these tomorrow. Here's the paste of the unreleased changes:
http://paste.openstack.org/show/254643/

thanks,
dims

On Mon, Jun 1, 2015 at 6:00 PM, Davanum Srinivas  wrote:
> Matt,
>
> we are reverting that change -
> https://review.openstack.org/#/c/187306/ - so no need for any caps.
> that change will go to a feature branch for later. We can decide
> version numbers etc later and add caps if needed at that time.
>
> -- dims
>
> On Mon, Jun 1, 2015 at 5:38 PM, Matt Riedemann
>  wrote:
>>
>>
>> On 6/1/2015 12:04 PM, Doug Hellmann wrote:
>>>
>>> We have a bunch of Oslo libraries ready for releases tomorrow, Tuesday 2
>>> June.
>>>
>>> I will be releasing:
>>>
>>> 0.5.0 8685171 debtcollector
>>> 1.10.0 9a963a9 oslo.concurrency
>>> 1.12.0 02a86d2 oslo.config
>>> 0.4.0 4c9b37d oslo.context
>>> 1.10.0 42dc936 oslo.db
>>> 1.7.0 a02d901 oslo.i18n
>>> 1.3.0 6754d13 oslo.log
>>> 1.12.0 27efb36 oslo.messaging
>>> 0.5.0 757857b oslo.policy
>>> 1.8.0 2335e63 oslo.rootwrap
>>> 1.6.0 74b3f97 oslo.utils
>>> 0.3.0 a03c635 oslo.versionedobjects
>>>
>>> If you are interested in more detail, the full set of changes to be
>>> included is available in http://paste.openstack.org/show/253257/
>>>
>>> Doug
>>>
>>>
>>> __
>>> 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
>>>
>>
>> Was there agreement on capping oslo.serialization < 2.0 in
>> global-requirements on master so that nova doesn't pick up the latest and
>> breaks with the new iso time format stuff?
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> __
>> 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



-- 
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] virtual machine can not get DHCP lease due packet has no checksum

[Tidwell, Ryan]

Not seeing this on Kilo, we're seeing this on Juno builds (that's expected).  
I'm interested in a Juno backport, but mainly wanted to be see if others had 
confidence in the fix.  The discussion in the bug report also seemed to 
indicate there were other alternative solutions others might be looking into 
that didn't involve an iptables rule.

-Ryan

-Original Message-
From: Mark McClain [mailto:m...@mcclain.xyz] 
Sent: Monday, June 01, 2015 6:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] virtual machine can not get DHCP lease 
due packet has no checksum


> On Jun 1, 2015, at 7:26 PM, Tidwell, Ryan  wrote:
> 
> I see a fix for https://bugs.launchpad.net/neutron/+bug/1244589 merged during 
> Kilo.  I'm wondering if we think we have identified a root cause and have 
> merged an appropriate long-term fix, or if 
> https://review.openstack.org/148718 was merged just so there's at least a fix 
> available while we investigate other alternatives.  Does anyone have an 
> update to provide?
> 
> -Ryan

The fix works in environments we’ve tested in.  Are you still seeing problems?

mark
__
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] [cinder] Consider using Explicit type casts on filters

[Huang Zhiteng]

Not a DB expert but looks like a valid bug.  Do you mind file a bug on this?

On Mon, Jun 1, 2015 at 5:43 PM, Vasco Rodrigues  wrote:

> Running Cinder on postgresql, i get the following error:
>
> 2015-06-02 01:21:27.471 32698 DEBUG cinder.api.v2.volumes
> [req-a0a15e07-2a86-4f98-a371-2f7203706b9f
> e8bd9bfef65c4def9d3977993c56b9b0 9dbebc529a0a469cb4574c3f9c0d86f7 - - -]
> Could not evaluate value 1, assuming string _get_volumes
> /usr/lib/python2.7/dist-packages/cinder/api/v2/volumes.py:238
> 2015-06-02 01:21:27.471 32698 DEBUG cinder.volume.api
> [req-a0a15e07-2a86-4f98-a371-2f7203706b9f
> e8bd9bfef65c4def9d3977993c56b9b0 9dbebc529a0a469cb4574c3f9c0d86f7 - - -]
> Searching by: MultiDict([(u'status', u'available'), (u'bootable', 1)]).
> get_all /usr/lib/python2.7/dist-packages/cinder/volume/api.py:421
> 2015-06-02 01:21:27.486 32698 ERROR oslo_db.sqlalchemy.exc_filters
> [req-a0a15e07-2a86-4f98-a371-2f7203706b9f
> e8bd9bfef65c4def9d3977993c56b9b0 9dbebc529a0a469cb4574c3f9c0d86f7 - - -]
> DBAPIError exception wrapped from (psycopg2.ProgrammingError) operator
> does not exist: boolean = integer
> LINE 3: ...volumes.status = 'available' AND volumes.bootable = 1 AND vo...
>  ^
> HINT:  No operator matches the given name and argument type(s). You
> might need to add explicit type casts.
>
>
> I think it's because postgresql doesn't allow comparing integer to boolean.
>
> Which I fixed by adding:
>
> if 'bootable' in filters:
>filters['bootable'] = bool(filters['bootable'])
>
>
> to VolumeController._get_volumes
>
>
> Regards,
> Vasco Rodrigues
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards
Huang Zhiteng
__
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][LBaaS] No LBaaS agent?

[Gandhi, Kunal]

Hi Wanjing

We at PayPal/eBay have integrated with a multi-vendor solution. One of the 
vendor solution is agent less and off loads all the business logic to a vendor 
controller that manages the devices.

Regards
Kunal


> On Jun 1, 2015, at 4:52 PM, Wanjing Xu  wrote:
> 
> Is there a way to add an LBaaS service without having to use neutron 
> plugin/agent framework?
> 
> I want to add a LBaaS service without  an LBaaS agent running and still want 
> to have lb cli and horizon.  When the user configure loadbalance via cli or 
> horizon, neutron will send the events(pool, member, vip create/delete 
> event)in the notification info queue and our application will listen to the 
> queue and program  the LBaaS box.  So far, I have tried to enable the 
> built-in HAProxy LBaaS(enable the service_plugin to be LoadBalancerPlugin and 
> service provider to be haproxy).  By doing that , horizon and cli are all 
> enabled and our application can successfully program LBaaS box using the 
> notification events.  The problem with that is that there is a haproxy agent 
> running in the background although we are not using its function.  But if I 
> don't enable the agent, we can not use horizon.  Currently we don't want to 
> write a LBaaS agent of our own.  Is there a way to not to use LBaaS agent and 
> still  be able to use horizon/cli to configure loadbalance?  During openstack 
> summit at vancouver, I saw paypal loadbalance presentation, they use two 
> providers, one is agent , the other is agentless controller, not sure how 
> that controller works, could not find it through googling.
> 
> Regards
> Wanjing Xu
> 
> 
> __
> 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][LBaaS] No LBaaS agent?

[Doug Wiegley]

I missed the part about wanting to do your own event handling.  Brandon is 
right, the right thing to do is to make yourself a driver. You can start with 
the noop_driver in this review, though some of the import paths will need 
fixing up: https://review.openstack.org/#/c/56187/ 


Feel free to stop into #openstack-lbaas and we can help you out.

Thanks,
doug

> On Jun 1, 2015, at 7:02 PM, Brandon Logan  wrote:
> 
> For v2 there is the logging noop driver that does not use an agent and just 
> logs.  v1 sits not have this though.  I do wonder why you don't just build a 
> simple driver to do what you are currently doing when acting upon events in 
> the notification queue.
> On Jun 1, 2015 7:09 PM, "Fox, Kevin M"  wrote:
> Have a look here:
> http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/neutron_lbaas/drivers
>  
> 
> 
> Thanks,
> Kevin
> From: Wanjing Xu [wanjing...@hotmail.com]
> Sent: Monday, June 01, 2015 4:52 PM
> To: OpenStack Development Mailing List not for usage questions
> Subject: [openstack-dev] [Neutron][LBaaS] No LBaaS agent?
> 
> Is there a way to add an LBaaS service without having to use neutron 
> plugin/agent framework?
> 
> I want to add a LBaaS service without  an LBaaS agent running and still want 
> to have lb cli and horizon.  When the user configure loadbalance via cli or 
> horizon, neutron will send the events(pool, member, vip create/delete 
> event)in the notification info queue and our application will listen to the 
> queue and program  the LBaaS box.  So far, I have tried to enable the 
> built-in HAProxy LBaaS(enable the service_plugin to be LoadBalancerPlugin and 
> service provider to be haproxy).  By doing that , horizon and cli are all 
> enabled and our application can successfully program LBaaS box using the 
> notification events.  The problem with that is that there is a haproxy agent 
> running in the background although we are not using its function.  But if I 
> don't enable the agent, we can not use horizon.  Currently we don't want to 
> write a LBaaS agent of our own.  Is there a way to not to use LBaaS agent and 
> still  be able to use horizon/cli to configure loadbalance?  During openstack 
> summit at vancouver, I saw paypal loadbalance presentation, they use two 
> providers, one is agent , the other is agentless controller, not sure how 
> that controller works, could not find it through googling.
> 
> Regards
> Wanjing Xu
> 
> 
> __
> 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] virtual machine can not get DHCP lease due packet has no checksum

[Mark McClain]

> On Jun 1, 2015, at 7:26 PM, Tidwell, Ryan  wrote:
> 
> I see a fix for https://bugs.launchpad.net/neutron/+bug/1244589 merged during 
> Kilo.  I'm wondering if we think we have identified a root cause and have 
> merged an appropriate long-term fix, or if 
> https://review.openstack.org/148718 was merged just so there's at least a fix 
> available while we investigate other alternatives.  Does anyone have an 
> update to provide?
> 
> -Ryan

The fix works in environments we’ve tested in.  Are you still seeing problems?

mark
__
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] [all] error codes design conclusion?

[Gareth]

Hey guys,

I remember there was a session in design summit talking about openstack
error codes. What's the current status? or is there any conclusion yet?

Kun
__
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] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

[Kai Qiang Wu]

+1 about Jay option.

BTW, as nova and glance all allow same name for instance or image, So name
seems not need to be unique, it is OK I think.



Thanks

Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   Jay Lau 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   06/01/2015 11:17 PM
Subject:Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a
required option when creating a Bay/Baymodel





2015-06-01 21:54 GMT+08:00 Jay Pipes :
  On 05/31/2015 05:38 PM, Jay Lau wrote:
   Just want to use ML to trigger more discussion here. There are now
   bugs/patches tracing this, but seems more discussions are needed before
   we come to a conclusion.

   https://bugs.launchpad.net/magnum/+bug/1453732
   https://review.openstack.org/#/c/181839/
   https://review.openstack.org/#/c/181837/
   https://review.openstack.org/#/c/181847/
   https://review.openstack.org/#/c/181843/

   IMHO, making the Bay/Baymodel name as a MUST will bring more flexibility
   to end user as Magnum also support operating Bay/Baymodel via names and
   the name might be more meaningful to end users.

   Perhaps we can borrow some iead from nova, the concept in magnum can be
   mapped to nova as following:

   1) instance => bay
   2) flavor => baymodel

   So I think that a solution might be as following:
   1) Make name as a MUST for both bay/baymodel
   2) Update magnum client to use following style for bay-create and
   baymodel-create: DO NOT add "--name" option

  You should decide whether name would be unique -- either globally or
  within a tenant.

  Note that Nova's instance names (the display_name model field) are *not*
  unique, neither globally nor within a tenant. I personally believe this
  was a mistake.

  The decision affects your data model and constraints.
Yes, my thinking is to enable Magnum has same behavior with nova. The name
can be managed by the end user and the end user can specify the name as
they want, it is end user's responsibility to make sure there are no
duplicate names. Actually, I think that the name do not need to be unique
but UUID.

  Best,
  -jay


  __

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



--
Thanks,

Jay Lau (Guangya Liu)
__
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][LBaaS] No LBaaS agent?

[Brandon Logan]

For v2 there is the logging noop driver that does not use an agent and just 
logs.  v1 sits not have this though.  I do wonder why you don't just build a 
simple driver to do what you are currently doing when acting upon events in the 
notification queue.

On Jun 1, 2015 7:09 PM, "Fox, Kevin M"  wrote:
Have a look here:
http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/neutron_lbaas/drivers

Thanks,
Kevin

From: Wanjing Xu [wanjing...@hotmail.com]
Sent: Monday, June 01, 2015 4:52 PM
To: OpenStack Development Mailing List not for usage questions
Subject: [openstack-dev] [Neutron][LBaaS] No LBaaS agent?

Is there a way to add an LBaaS service without having to use neutron 
plugin/agent framework?

I want to add a LBaaS service without  an LBaaS agent running and still want to 
have lb cli and horizon.  When the user configure loadbalance via cli or 
horizon, neutron will send the events(pool, member, vip create/delete event)in 
the notification info queue and our application will listen to the queue and 
program  the LBaaS box.  So far, I have tried to enable the built-in HAProxy 
LBaaS(enable the service_plugin to be LoadBalancerPlugin and service provider 
to be haproxy).  By doing that , horizon and cli are all enabled and our 
application can successfully program LBaaS box using the notification events.  
The problem with that is that there is a haproxy agent running in the 
background although we are not using its function.  But if I don't enable the 
agent, we can not use horizon.  Currently we don't want to write a LBaaS agent 
of our own.  Is there a way to not to use LBaaS agent and still  be able to use 
horizon/cli to configure loadbalance?  During openstack summit at vancouver, I 
saw paypal loadbalance presentation, they use two providers, one is agent , the 
other is agentless controller, not sure how that controller works, could not 
find it through googling.

Regards
Wanjing Xu


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

Re: [openstack-dev] [DevStack][Neutron] PHYSICAL_NETWORK vs. PUBLIC_PHYSICAL_NETWORK - rant

[Hirofumi Ichihara]

> Thanks for the clarification. Do you think that there are cases where
> the value for PHYSICAL_NETWORK and PUBLIC_PHYSICAL_NETWORK will be different? 
No, I cannot find the cases. I think it’s traditional something.

> Perhaps we can change the default value for PUBLIC_PHYSICAL_NETWORK from
> "public" to just pulling in what PHYSICAL_NETWORK is set to, if it is
> set?

Do you expect anything like the following?

PUBLIC_PHYSICAL_NETWORK=${PUBLIC_PHYSICAL_NETWORK:-$PHYSICAL_NETWORK}
PUBLIC_PHYSICAL_NETWORK=${PUBLIC_PHYSICAL_NETWORK:-public}

I guess it’s a simple solution even though it’s not essential.
The issue probably is caused by two points.
1) PHYSICAL_NETWORK and PUBLIC_PHYSICAL_NETWORK confuse users.
2) Devstack lacks the condition for avoiding the issue in 
https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/openvswitch_agent#L58

If I solve the issue, I would unify the two parameters.
I would leave the following for backward compatibility.
PUBLIC_PHYSICAL_NETWORK=${PUBLIC_PHYSICAL_NETWORK:-$PHYSICAL_NETWORK}
and
change PHYSICAL_NETWORK into PUBLIC_PHYSICAL_NETWORK in all the code.

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

[openstack-dev] [cinder] Consider using Explicit type casts on filters

[Vasco Rodrigues]

Running Cinder on postgresql, i get the following error:

2015-06-02 01:21:27.471 32698 DEBUG cinder.api.v2.volumes
[req-a0a15e07-2a86-4f98-a371-2f7203706b9f
e8bd9bfef65c4def9d3977993c56b9b0 9dbebc529a0a469cb4574c3f9c0d86f7 - - -]
Could not evaluate value 1, assuming string _get_volumes
/usr/lib/python2.7/dist-packages/cinder/api/v2/volumes.py:238
2015-06-02 01:21:27.471 32698 DEBUG cinder.volume.api
[req-a0a15e07-2a86-4f98-a371-2f7203706b9f
e8bd9bfef65c4def9d3977993c56b9b0 9dbebc529a0a469cb4574c3f9c0d86f7 - - -]
Searching by: MultiDict([(u'status', u'available'), (u'bootable', 1)]).
get_all /usr/lib/python2.7/dist-packages/cinder/volume/api.py:421
2015-06-02 01:21:27.486 32698 ERROR oslo_db.sqlalchemy.exc_filters
[req-a0a15e07-2a86-4f98-a371-2f7203706b9f
e8bd9bfef65c4def9d3977993c56b9b0 9dbebc529a0a469cb4574c3f9c0d86f7 - - -]
DBAPIError exception wrapped from (psycopg2.ProgrammingError) operator
does not exist: boolean = integer
LINE 3: ...volumes.status = 'available' AND volumes.bootable = 1 AND vo...
 ^
HINT:  No operator matches the given name and argument type(s). You
might need to add explicit type casts.


I think it's because postgresql doesn't allow comparing integer to boolean.

Which I fixed by adding:

if 'bootable' in filters:
   filters['bootable'] = bool(filters['bootable'])


to VolumeController._get_volumes


Regards,
Vasco Rodrigues

__
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] Spec for volume migration improvement

[Mitsuhiro Tanino]

Hi Vincent,

>>@Mitsuhiro Tanino, I believe you can submit another spec for the efficient 
>>migration as well.

Yup, I posted a SPEC and got some positive feedbacks.
https://review.openstack.org/#/c/186209/

Also I posted some comments for your spec. Waiting your next update
for the spec. Thanks,

Regards,
Mitsuhiro Tanino 
HITACHI DATA SYSTEMS

From: Sheng Bo Hou [mailto:sb...@cn.ibm.com]
Sent: Monday, June 01, 2015 2:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [cinder] Spec for volume migration improvement

Hi all folks from Cinder,

According to our agreement in the Vancouver summit, I submitted a cinder-spec 
to do the volume migration improvement. The spec is here for review: 
https://review.openstack.org/#/c/186327/.
 Please feel free to give your comments.
@Mitsuhiro Tanino, I believe you can submit another spec for the efficient 
migration as well.

Thanks, folks.

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

Re: [openstack-dev] [Neutron][LBaaS] No LBaaS agent?

[Fox, Kevin M]

Have a look here:
http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/neutron_lbaas/drivers

Thanks,
Kevin

From: Wanjing Xu [wanjing...@hotmail.com]
Sent: Monday, June 01, 2015 4:52 PM
To: OpenStack Development Mailing List not for usage questions
Subject: [openstack-dev] [Neutron][LBaaS] No LBaaS agent?

Is there a way to add an LBaaS service without having to use neutron 
plugin/agent framework?

I want to add a LBaaS service without  an LBaaS agent running and still want to 
have lb cli and horizon.  When the user configure loadbalance via cli or 
horizon, neutron will send the events(pool, member, vip create/delete event)in 
the notification info queue and our application will listen to the queue and 
program  the LBaaS box.  So far, I have tried to enable the built-in HAProxy 
LBaaS(enable the service_plugin to be LoadBalancerPlugin and service provider 
to be haproxy).  By doing that , horizon and cli are all enabled and our 
application can successfully program LBaaS box using the notification events.  
The problem with that is that there is a haproxy agent running in the 
background although we are not using its function.  But if I don't enable the 
agent, we can not use horizon.  Currently we don't want to write a LBaaS agent 
of our own.  Is there a way to not to use LBaaS agent and still  be able to use 
horizon/cli to configure loadbalance?  During openstack summit at vancouver, I 
saw paypal loadbalance presentation, they use two providers, one is agent , the 
other is agentless controller, not sure how that controller works, could not 
find it through googling.

Regards
Wanjing Xu


__
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.messaging][zeromq] Next step

[Davanum Srinivas]

fyi, the spec for zeromq driver in oslo.messaging is here:
https://review.openstack.org/#/c/187338/1/specs/liberty/zmq-patterns-usage.rst,unified

-- dims

On Thu, May 28, 2015 at 1:07 PM, Alec Hothan (ahothan)
 wrote:
> Hi Oleksii,
>
> Thanks for putting together the slides, they are well done and extremely
> useful!
>
> I find this 0MQ driver redesign proposal a much needed improvement over the
> current design.
> However it is worth debating the need to keep the proxy server and I would
> be interested to hear from others as well if they feel like this is
> something we should pursue.
> Also do we know the level of interest we have in the community to contribute
> to, use or support a production grade 0MQ driver in the future?
>
> Comments inline...
>
>
> From: ozamiatin 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, May 27, 2015 at 3:52 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: Re: [openstack-dev] [oslo.messaging][zeromq] Next step
>
> Hi,
>
> I'll try to address the question about Proxy process.
>
> AFAIK there is no way yet in zmq to bind more than once to a specific port
> (e.g. tcp://*:9501).
>
> Apparently we can:
>
> socket1.bind('tcp://node1:9501')
> socket2.bind('tcp://node2:9501')
>
> but we can not:
>
> socket1.bind('tcp://*:9501')
> socket2.bind('tcp://*:9501')
>
> So if we would like to have a definite port assigned with the driver we need
> to use a proxy which receives on a single socket and redirects to a number
> of sockets.
>
>
> Right you can only bind once on a given ip/port.
>
>
>
> It is a normal practice in zmq to do so. There are even some helpers
> implemented in the library so-called 'devices'.
>
> Here the performance question is relevant. According to ZeroMQ documentation
> [1] The basic heuristic is to allocate 1 I/O thread in the context for every
> gigabit per second of data that will be sent and received (aggregated).
>
> The other way is to 'bind_to_random_port', but here we need some mechanism
> to notify the client about the port we are listening to. So it is more
> complicated solution.
>
>
> It is all relative and I actually find it simpler overall than using a proxy
> ;-)
> Dynamic port binding has some benefits as well, is widely used and is a well
> known/understood pattern.
> In the current implementation, messaging end points register their topic to
> Redis with the host address (and implicitly on the well known port 5901), it
> would have been possible to register the host+port instead if we were to
> consider bypassing the proxy.
>
>
> Why to run in a separate process? For zmq api it doesn't matter to
> communicate between threads (INPROC), between processes (IPC) or between
> nodes (TCP, PGM and others). Because we need to run proxy once on a node
> it's easier to do it in a separate process. How to track the proxy is
> running already if we put it in a thread of some service?
>
>
> There would not be any proxy at all. Each end point (nova compute, ovs
> agent, neutron server...) would simply listen on its unique IP+port (that's
> real peer to peer)
>
>
>
>
> In spite of having a broker-like instance locally we still stay brokerless
> because we have no central broker node with a queue we need to replicate and
> keep alive. Each node is acutally a peer. The broker is not a standalone
> node so we can not say that it is a 'single point of failure' .
>
>
> You are correct in that regard (i.e. "node" level), but there is also
> process level HA (meaning if the proxy process goes down for whatever
> reason, all end points in that node become unreachable). One complication to
> keep in mind is that some production deployment schemes (those that use a
> container or a VM to deploy openstack services) would have to accommodate
> that extra proxy process (in the same way that they do today with rabbitMQ
> clusters) by adding one extra service "container" just for the proxy which
> is pretty heavy handed since you can't bundle that proxy process with any
> other container. For example a typical compute node would have 2 "packages"
> (nova-compute and ovs agent for example), with that proxy there will be a
> need to have a third package.
>
>
>
> We can consider the local broker as a part of a server. It is worth noting
> that IPC communication is much more reliable than real network
> communication.
>
> One more benefit is that the proxy is stateless so we don't have to bother
> about managing the state (syncing it or having enough memory to keep it)
>
>
> I agree the proxy server is not very complex and likely solid, but there are
> also downsides to it as well.
> Talking about TCP sockets vs. IPC sockets (which are probably based on unix
> domain sockets), you'll have to note that you won't be able to use IPC if
> the proxy server will have to run inside a VM by itself (as would be the
> case for certain deployment schemes), and you'd have to use TCP sockets in
> that case 

Re: [openstack-dev] [Neutron][LBaaS] No LBaaS agent?

[Doug Wiegley]

The reference implemenation for lbaas (using haproxy with namespaces) requires 
the agent. There are vendor implementations that are agent-less, but not the 
reference.

There is a non-agent ref driver for lbaas v2, but there is no horizon support 
for v2, and that driver is unsupported beyond dev use.

If I may ask, why do you not want to run the agent?

Thanks,
doug


> On Jun 1, 2015, at 5:52 PM, Wanjing Xu  wrote:
> 
> Is there a way to add an LBaaS service without having to use neutron 
> plugin/agent framework?
> 
> I want to add a LBaaS service without  an LBaaS agent running and still want 
> to have lb cli and horizon.  When the user configure loadbalance via cli or 
> horizon, neutron will send the events(pool, member, vip create/delete 
> event)in the notification info queue and our application will listen to the 
> queue and program  the LBaaS box.  So far, I have tried to enable the 
> built-in HAProxy LBaaS(enable the service_plugin to be LoadBalancerPlugin and 
> service provider to be haproxy).  By doing that , horizon and cli are all 
> enabled and our application can successfully program LBaaS box using the 
> notification events.  The problem with that is that there is a haproxy agent 
> running in the background although we are not using its function.  But if I 
> don't enable the agent, we can not use horizon.  Currently we don't want to 
> write a LBaaS agent of our own.  Is there a way to not to use LBaaS agent and 
> still  be able to use horizon/cli to configure loadbalance?  During openstack 
> summit at vancouver, I saw paypal loadbalance presentation, they use two 
> providers, one is agent , the other is agentless controller, not sure how 
> that controller works, could not find it through googling.
> 
> Regards
> Wanjing Xu
> 
> 
> __
> 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] [Neutron][LBaaS] No LBaaS agent?

[Wanjing Xu]

Is there a way to add an LBaaS service without having to use neutron 
plugin/agent framework?
I want to add a LBaaS service without  an LBaaS agent running and still want to 
have lb cli and horizon.  When the user configure loadbalance via cli or 
horizon, neutron will send the events(pool, member, vip create/delete event)in 
the notification info queue and our application will listen to the queue and 
program  the LBaaS box.  So far, I have tried to enable the built-in HAProxy 
LBaaS(enable the service_plugin to be LoadBalancerPlugin and service provider 
to be haproxy).  By doing that , horizon and cli are all enabled and our 
application can successfully program LBaaS box using the notification events.  
The problem with that is that there is a haproxy agent running in the 
background although we are not using its function.  But if I don't enable the 
agent, we can not use horizon.  Currently we don't want to write a LBaaS agent 
of our own.  Is there a way to not to use LBaaS agent and still  be able to use 
horizon/cli to configure loadbalance?  During openstack summit at vancouver, I 
saw paypal loadbalance presentation, they use two providers, one is agent , the 
other is agentless controller, not sure how that controller works, could not 
find it through googling.
RegardsWanjing Xu

  __
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] virtual machine can not get DHCP lease due packet has no checksum

[Tidwell, Ryan]

I see a fix for https://bugs.launchpad.net/neutron/+bug/1244589 merged during 
Kilo.  I'm wondering if we think we have identified a root cause and have 
merged an appropriate long-term fix, or if https://review.openstack.org/148718 
was merged just so there's at least a fix available while we investigate other 
alternatives.  Does anyone have an update to provide?

-Ryan
__
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] [TC] Discussion: changing Ironic's release model

[Ruby Loo]

On 28 May 2015 at 15:55, Jim Rollenhagen  wrote:

> ...
>
I also put an informational spec about this change up in the
> ironic-specs repo: https://review.openstack.org/#/c/185171/. My goal was
> to discuss this in the spec, but the mailing list is fine too. There are
> some unanswered questions in that review that we should make sure we
> cover.
>
> I'm really excited about this, and hope it can lead to good outcomes for
> the rest of OpenStack in the future. :)
>
> // jim
>
>
Hi Jim, thanks for the spec! It'll be good to incorporate the feedback from
this thread, into the spec. To be honest, I'm apprehensive and worried
about this. As Devananda mentioned, the devil is in the details. I hope we
get enough of the details right, so that we aren't spending time wondering
about the process instead of doing coding and reviewing.

My main concern is that with my reviewer's hat on, I don't feel like it
will help me much. We are proposing more (smaller) releases, and as long as
people know that there is an upcoming release planned, they will try to get
their patches merged. So I think we're just spreading out the 'please
review my patch' requests, but at least I won't feel so bad now when I say
no, because they won't have to wait 6+ months to land their feature :)

Anyway, I'm open to this (or am I, maybe I'm just resigned to it cause the
train seems to be leaving), and hope to be pleasantly surprised ;)

--ruby
__
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] [Magnum] Discuss mesos-bay-type Blueprint

[Hongbin Lu]

Hi Jay,

For your question “what is the mesos object that we want to manage”, the short 
answer is it depends. There are two options I can think of:

1.   Don’t manage any object from Marathon directly. Instead, we can focus 
on the existing Magnum objects (i.e. container), and implements them by using 
Marathon APIs if it is possible. Use the abstraction ‘container’ as an example. 
For a swarm bay, container will be implemented by calling docker APIs. For a 
mesos bay, container could be implemented by using Marathon APIs (it looks the 
Marathon’s object ‘app’ can be leveraged to operate a docker container). The 
effect is that Magnum will have a set of common abstractions that is 
implemented differently by different bay type.

2.   Do manage a few Marathon objects (i.e. app). The effect is that Magnum 
will have additional API object(s) that is from Marathon (like what we have for 
existing k8s objects: pod/service/rc).
Thoughts?

Thanks
Hongbin

From: Jay Lau [mailto:jay.lau@gmail.com]
Sent: May-29-15 1:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] Discuss mesos-bay-type Blueprint

I want to mention that there is another mesos framework named as chronos: 
https://github.com/mesos/chronos , it is used for job orchestration.

For others, please refer to my comments in line.

2015-05-29 7:45 GMT+08:00 Adrian Otto 
mailto:adrian.o...@rackspace.com>>:
I’m moving this whiteboard to the ML so we can have some discussion to refine 
it, and then go back and update the whiteboard.

Source: https://blueprints.launchpad.net/magnum/+spec/mesos-bay-type

My comments in-line below.


Begin forwarded message:

From: hongbin mailto:hongbin...@huawei.com>>
Subject: COMMERCIAL:[Blueprint mesos-bay-type] Add support for mesos bay type
Date: May 28, 2015 at 2:11:29 PM PDT
To: mailto:adrian.o...@rackspace.com>>
Reply-To: hongbin mailto:hongbin...@huawei.com>>

Blueprint changed by hongbin:

Whiteboard set to:

I did a preliminary research on possible implementations. I think this BP can 
be implemented in two steps.
1. Develop a heat template for provisioning mesos cluster.
2. Implement a magnum conductor for managing the mesos cluster.

Agreed, thanks for filing this blueprint!
For 2, the conductor is mainly used to manage objects for CoE, k8s has pod, 
service, rc, what is the mesos object that we want to manage? IMHO, mesos is a 
resource manager and it needs to be worked with some frameworks to provide 
services.


First, I want to emphasis that mesos is not a service (It looks like a
library). Therefore, mesos doesn't have web API, and most users don't
use mesos directly. Instead, they use a mesos framework that is on top
of mesos. Therefore, a mesos bay needs to have a mesos framework pre-
configured so that magnum can talk to the framework to manage the bay.
There are several framework choices. Below is a list of frameworks that
look like a fit (in my opinion). A exhaustive list of framework can be
found here [1].

1. Marathon [2]
This is a framework controlled by a company (mesosphere [3]). It is open source 
through. It supports running app on clusters of docker containers. It is 
probably the most widely-used mesos framework for long-running application.

Marathon offers a REST API, whereas Aroura does not (unless one has 
materialized in the last month). This was the one we discussed in our Vancouver 
design summit, and we agreed that those wanting to use Apache Mesos are 
probably expecting this framework.


2. Aurora [4]
This is a framework governed by Apache Software Foundation. It looks very 
similar to Marathon, but maybe more advanced in nature. It has been used by 
Twitter at scale. Here [5] is a detailed comparison between Marathon and Aurora.

We should have an alternate bay template for Aroura in our contrib directory. 
If users like Aroura better than Marathon, we can discuss making it the default 
template, and put the Marathon template in the contrib directory.


3. Kubernetes/Docker swarm
It looks the swarm-mesos is not ready yet. I cannot find any thing about that 
(besides several videos on Youtube). The kubernetes-mesos is there [6]. In 
theory, magnum should be able to deploy a mesos bay and talk to the bay through 
kubernetes API. An advantage is that we can reuse the kubernetes conductor. A 
disadvantage is that it is not a 'mesos' way to manage containers. Users from 
mesos community are probably more comfortable to manage containers through 
Marathon/Aurora.

If you want Kubernetes, you should use the Kubernetes bay type. If you want 
Kubernetes controlling Mesos, make a custom Heat template for that, and we can 
put it into contrib.
Agree, even using Mesos as resource manager, end user can still use magnum API 
to create pod, service, and rc.

If you want Swarm controlling Mesos, then you want BOTH a Swarm bay *and* a 
Mesos bay, with the Swarm bay configured to use the Mesos bay using the 
(currently developing) int

Re: [openstack-dev] [all] upcoming oslo releases

[Davanum Srinivas]

Matt,

we are reverting that change -
https://review.openstack.org/#/c/187306/ - so no need for any caps.
that change will go to a feature branch for later. We can decide
version numbers etc later and add caps if needed at that time.

-- dims

On Mon, Jun 1, 2015 at 5:38 PM, Matt Riedemann
 wrote:
>
>
> On 6/1/2015 12:04 PM, Doug Hellmann wrote:
>>
>> We have a bunch of Oslo libraries ready for releases tomorrow, Tuesday 2
>> June.
>>
>> I will be releasing:
>>
>> 0.5.0 8685171 debtcollector
>> 1.10.0 9a963a9 oslo.concurrency
>> 1.12.0 02a86d2 oslo.config
>> 0.4.0 4c9b37d oslo.context
>> 1.10.0 42dc936 oslo.db
>> 1.7.0 a02d901 oslo.i18n
>> 1.3.0 6754d13 oslo.log
>> 1.12.0 27efb36 oslo.messaging
>> 0.5.0 757857b oslo.policy
>> 1.8.0 2335e63 oslo.rootwrap
>> 1.6.0 74b3f97 oslo.utils
>> 0.3.0 a03c635 oslo.versionedobjects
>>
>> If you are interested in more detail, the full set of changes to be
>> included is available in http://paste.openstack.org/show/253257/
>>
>> Doug
>>
>>
>> __
>> 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
>>
>
> Was there agreement on capping oslo.serialization < 2.0 in
> global-requirements on master so that nova doesn't pick up the latest and
> breaks with the new iso time format stuff?
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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] [release][manila] python-manilaclient 1.2.0

[Ben Swartzlander]

On 06/01/2015 10:47 AM, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2015-06-01 10:27:38 -0400:

We are thrilled to announce the release of:

python-manilaclient 1.2.0: Client library for OpenStack Manila API.

With source available at:

 http://git.openstack.org/cgit/openstack/python-manilaclient

For more details, please see the git log history below and:

 http://launchpad.net/python-manilaclient/+milestone/1.2.0

The launchpad project for manila is not configured to allow the release
management team to create milestones, so this doesn't actually exist
yet. If someone from the team contacts me on IRC, I can work with you to
set it up properly and re-run the script to create the series and
milestone.


I believe I have fixed this. Please try and let me know if you run into 
any problems


-Ben


Doug


__
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] [all] upcoming oslo releases

[Matt Riedemann]

On 6/1/2015 12:04 PM, Doug Hellmann wrote:

We have a bunch of Oslo libraries ready for releases tomorrow, Tuesday 2 June.

I will be releasing:

0.5.0 8685171 debtcollector
1.10.0 9a963a9 oslo.concurrency
1.12.0 02a86d2 oslo.config
0.4.0 4c9b37d oslo.context
1.10.0 42dc936 oslo.db
1.7.0 a02d901 oslo.i18n
1.3.0 6754d13 oslo.log
1.12.0 27efb36 oslo.messaging
0.5.0 757857b oslo.policy
1.8.0 2335e63 oslo.rootwrap
1.6.0 74b3f97 oslo.utils
0.3.0 a03c635 oslo.versionedobjects

If you are interested in more detail, the full set of changes to be included is 
available in http://paste.openstack.org/show/253257/

Doug


__
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



Was there agreement on capping oslo.serialization < 2.0 in 
global-requirements on master so that nova doesn't pick up the latest 
and breaks with the new iso time format stuff?


--

Thanks,

Matt Riedemann


__
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] service chaining feature development meeting at 1800 UTC June 4th

[Cathy Zhang]

Hello everyone,

I have set up the weekly IRC meeting for the OpenStack service chain feature 
development. Following is the meeting info:

Weekly on Thursday at 1800 
UTC 
in #openstack-meeting-4

You can also find the meeting info at 
http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting and
http://git.openstack.org/cgit/openstack-infra/irc-meetings/tree/meetings]

Agenda:

1. Usage scenario

2. Feature scope: functional module breakdown and their architecture 
relationship as well as their relationship to OpenStack Neutron, the types of 
service functions that will be chained in this feature development

3. Module ownership sign-up

4. Deep dive into technical questions on etherpad if there is time.


Anyone who would like to contribute to this feature development is welcome to 
join the meeting. Hope the time is good for most people.





Thanks,

Cathy



__
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] Progressing/tracking work on libvirt / vif drivers

[Moshe Levi]

Hi Neil,

First of all thank for organizing this.

Both  Infiniband SR-IOV VIF type and Removal of mlnx_direct VIF type are ready 
for core review.



-Original Message-
From: Neil Jerram [mailto:neil.jer...@metaswitch.com] 
Sent: Monday, June 01, 2015 8:38 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif 
drivers

On 01/06/15 17:45, Neil Jerram wrote:

> Many thanks, John & Dan.  I'll start by drafting a summary of the work 
> that I'm aware of in this area, at 
> https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work.

OK, my first draft of this is now there at [1].  Please could folk with 
VIF-related work pending check that I haven't missed or misrepresented them?  
Especially, please could owners of the 'Infiniband SR-IOV' and 'mlnx_direct 
removal' changes confirm that those are really ready for core review?  It would 
be bad to ask for core review that wasn't in fact wanted.

Thanks,
Neil


[1] https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work

__
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] [cognitive] any meeting details yet?

[RJ Nowling]

I was interested in the announcement of Cognitive.  Are there any details on 
the upcoming meetings?  Will details be announced on this mailing list?  Thanks!

__
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] Updates from the Summit

[Ruby Loo]

Thanks for the summary Devananda. Lots of juicy features to sink our teeth
into :-)

There was a session with Nova, to discuss HA of nova compute nodes (and
Nova's resource model) as it pertains to Ironic. What does a potential
future look like?

--ruby
__
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] Mellanox CI Issues

[Lenny Verkhovsky]

Hi Dan,
I disabled Mellanox Nova CI from commenting and will check this issue first 
thing tomorrow morning.
Thanks and my deepest apologies.

Lenny Verkhovsky


-Original Message-
From: Dan Smith [mailto:d...@danplanet.com] 
Sent: Monday, June 01, 2015 7:41 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Moshe Levi; Lenny Verkhovsky
Subject: [nova] Mellanox CI Issues

Hi,

Mellanox CI has been broken for a while now. Test runs are reported as 
"successful" after an impossibly short less-than-a-minute run. Could the owners 
of this please take a look and address the problem? At least disabling 
commenting while working on the issue would be helpful.

Also, on success, the bot doesn't post the log files, which is (a) inconsistent 
with other test bots and (b) not very helpful for validating that success is 
real. This is especially relevant right now, given that we know the success 
reports are erroneous at the moment.

This is the second time (in recent memory) that Mellanox CI has gone off the 
rails for a decent amount of time without being noticed by the owners. If this 
continues, I'll be in favor of removing commenting privileges for this account 
and will be hesitant to throw in my support for re-enabling it. Running CI 
against gerrit comes with serious responsibility for monitoring!

Thanks!

--Dan

__
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] [Plugins] modification disk configuration

[Andrew Woodward]

Samuel,

I cases like glance, and nova, you will likely want the volumes still
because they are still used in some cases as cache(glance), operational
files(nova-compute), or even interim storage(nova-compute) of snapshots. We
keep them around even when we use Ceph.

In the case of cinder, I'm assuming you mean the cinder vg created from the
cinder storage role. You should not need to deploy this role as it's only
necessary for lvm/iSCSI which it sounds like you are replacing.

Finally, if you truly don't want the allocations you would have to remove
them from the base releases data [1], As Evgeniy noted the role api won't
do this for you, you would have to update this using the release API or by
replacing the base data that is loaded from [1] as fuel initalizes.

[1]
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L243-355

On Wed, May 27, 2015 at 1:27 AM Evgeniy L  wrote:

> Hi Samuel,
>
> Currently it's not possible to change partitioning schema of Fuel roles,
> but you can change partitioning in post_deployment tasks of your plugin.
>
> Thanks,
>
> On Wed, May 27, 2015 at 9:38 AM, Samuel Bartel <
> samuel.bartel@gmail.com> wrote:
>
>> Hi folks
>>
>> In some plugin  such as the nfs for glance or nova and the netapp for
>> cinder, we have replaced the lvm by nfs mount point. However we still have
>> partition setup for glance, cinder, nova which are not used anymore.
>> we can still int the disk configure allocate the minimum space to these
>> partitions. but is it possible in the plugin to chache the disk
>> configuration in order to reallocate thiese partition to a different used?
>>
>> regards
>>
>> Samuel
>>
>> __
>> 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] [neutron] Reminder: meeting tomorrow

[Kyle Mestery]

We've had a few weeks off, but tomorrow we'll re-start the Neutron meeting
[1]. It's at 1400 UTC in #openstack-meeting. See you all there!

Thanks,
Kyle

[1] https://wiki.openstack.org/wiki/Network/Meetings
__
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-20150602

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] [nova] Add new VIF Type

[Jay Pipes]

On 06/01/2015 11:13 AM, Andreas Scheuring wrote:

Hi,
what are the prereqs to get a spec for a new nova VIF type approved?

In my case I'm planning for a new neutron ml2 driver and agent (on
stackforge) that adds general support for macvtap to neutron. I've not
yet published anything regarding the neutron part so far - but this will
happen in the next days...

For the nova part I already createad a blueprint + spec and a first
draft of the code changes required [1]. Howewer, this is still WIP, but
I wanted to get clarification about the process to get it approved



- Is it sufficient to have a spec with the plans for the neutron code in
the stackforge repo to get my nova changes approved?

- Or does it require that the thirdparty code is already up on
stackforge, and the integration points already merged into neutron?


It looks like like a chicken egg problem to me: Probably nova only wants
to add support, if there's already full functional support in neutron,
but on the other hand, to get the neutron code developed and tested, the
nova support is required..


No, I think Nova would be fine if the Nova spec pointed to a Neutron 
spec that described the new ML2 plugin.


Best,
-jay


Thanks

[1] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif


__
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] [release][neutron] python-neutronclient 2.6.0

[Doug Hellmann]

Excerpts from Ihar Hrachyshka's message of 2015-06-01 16:43:36 +0200:
> I have a suggestion... Since it's not obvious now which stable branch
> a release corresponds to, can we add that info into release note email
> body somewhere for the sake of those who may closely track stable
> updates but not so much those in-development, e.g. most packagers?
> 
> For server projects, (most) versions clearly map to cycles, but not
> for oslo or client libraries.

I have been doing that for releases on stable branches. This was a
release from master, so I didn't include that detail, but I can go ahead
and include the release in all messages for clarity.

Doug

> 
> Thanks
> Ihar
> 
> On 06/01/2015 04:27 PM, Doug Hellmann wrote:
> > We are thrilled to announce the release of:
> > 
> > python-neutronclient 2.6.0: CLI and Client Library for OpenStack 
> > Networking
> > 
> > With source available at:
> > 
> > http://git.openstack.org/cgit/openstack/python-neutronclient
> > 
> > For more details, please see the git log history below and:
> > 
> > http://launchpad.net/python-neutronclient/+milestone/2.6.0
> > 
> > Please report issues through launchpad:
> > 
> > http://bugs.launchpad.net/python-neutronclient
> > 
> > Changes in python-neutronclient 2.5.0..2.6.0 
> > 
> > 
> > f62492b Updated from global requirements 9e6977d Allow setting
> > router's external ip(s) d9113f1 Drop use of 'oslo' namespace
> > package 06a6e4d Updated from global requirements 6190a72 Add
> > functional test for subnet create 5eb292c Fix Python client library
> > for Neutron d830767 Update README to work with release tools 
> > d75689a Add --binding-profile to port-create 7bc65cb Fix invalid
> > error message in neutron-cli ae09deb Add basic functional tests for
> > client library
> > 
> > Diffstat (except docs and test files) 
> > -
> > 
> > README.rst | 15 +++- 
> > neutronclient/common/serializer.py |  2 +- 
> > neutronclient/common/utils.py  | 13 +++- 
> > neutronclient/i18n.py  |  2 +- 
> > neutronclient/neutron/v2_0/__init__.py |  6 +- 
> > neutronclient/neutron/v2_0/port.py | 11 ++- 
> > neutronclient/neutron/v2_0/quota.py|  2 +- 
> > neutronclient/neutron/v2_0/router.py   | 18 - 
> > neutronclient/neutron/v2_0/subnet.py   |  2 +- 
> > .../neutron/v2_0/vpn/ipsec_site_connection.py  |  2 +- 
> > neutronclient/shell.py | 17 - 
> > requirements.txt   |  6 +- 
> > test-requirements.txt  |  2 +- 24 files
> > changed, 282 insertions(+), 21 deletions(-)
> > 
> > 
> > Requirements updates 
> > 
> > diff --git a/requirements.txt b/requirements.txt index
> > b7a9ee1..28e9652 100644 --- a/requirements.txt +++
> > b/requirements.txt @@ -4 +4 @@ -pbr>=0.6,!=0.7,<1.0 
> > +pbr>=0.11,<2.0 @@ -12,2 +12,2 @@ oslo.utils>=1.4.0
> > # Apache-2.0 -requests>=2.2.0,!=2.4.0 
> > -python-keystoneclient>=1.1.0 +requests>=2.5.2 
> > +python-keystoneclient>=1.3.0 diff --git a/test-requirements.txt
> > b/test-requirements.txt index 1c395de..24c84a1 100644 ---
> > a/test-requirements.txt +++ b/test-requirements.txt @@ -19 +19 @@
> > testtools>=0.9.36,!=1.2.0 -tempest-lib>=0.4.0 +tempest-lib>=0.5.0
> > 
> > __
> 
> >
> > 
> 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-
> 

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

Re: [openstack-dev] [DevStack][Neutron] PHYSICAL_NETWORK vs. PUBLIC_PHYSICAL_NETWORK - rant

[Sean M. Collins]

On Thu, May 28, 2015 at 09:40:12PM EDT, Hirofumi Ichihara wrote:
> Hi Sean,
> 
> > We have a *lot* of configuration knobs in DevStack for Neutron. I am not
> > a smart man, so I think we may need to wrap our arms around this and
> > simplify.
> I agree with you. I want to fix the confused configure too.
> 
> PHYSICAL_NETWORK is a option in order to setup L2 public network only without 
> L3 and private network.
> PUBLIC_PHYSICAL_NETWORK is a option in order to setup public L2 network with 
> L3 and private network.
> 
> You can look at simple document in neutron-legacy[1].
> 
> According with the comment, therefore, you should fix your local.conf as the 
> following.
> PHYSICAL_NETWORK=default -> PUBLIC_PHYSICAL_NETWORK=public
> and add

Hirofumi,

Thanks for the clarification. Do you think that there are cases where
the value for PHYSICAL_NETWORK and PUBLIC_PHYSICAL_NETWORK will be different? 

Perhaps we can change the default value for PUBLIC_PHYSICAL_NETWORK from
"public" to just pulling in what PHYSICAL_NETWORK is set to, if it is
set?



-- 
Sean M. Collins

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

Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers

[Neil Jerram]

On 01/06/15 17:45, Neil Jerram wrote:


Many thanks, John & Dan.  I'll start by drafting a summary of the work
that I'm aware of in this area, at
https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work.


OK, my first draft of this is now there at [1].  Please could folk with 
VIF-related work pending check that I haven't missed or misrepresented 
them?  Especially, please could owners of the 'Infiniband SR-IOV' and 
'mlnx_direct removal' changes confirm that those are really ready for 
core review?  It would be bad to ask for core review that wasn't in fact 
wanted.


Thanks,
Neil


[1] https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work

__
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] [chef] OpenStack-Chef client-cookbook hacking

[JJ Asghar]

Hey everyone!

Per our meeting today[1] I’ve put together a doodle[2] for some time slots for 
us to come together and hack on the client-cookbook[3]. 

Please answer select the best time for you asap, and tomorrow at 1600UTC i’ll 
send out the time that has been decided.

Thanks!
-JJ

[1]: https://etherpad.openstack.org/p/openstack-chef-meeting-20150601 
<https://etherpad.openstack.org/p/openstack-chef-meeting-20150601>
[2]: http://doodle.com/gvn3v2t76czewwg6
[3]: https://github.com/stackforge/cookbook-openstack-client 
<https://github.com/stackforge/cookbook-openstack-client>__
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] [Manila] Midcycle meetup dates

[Sturdevant, Mark]

Week of July 27-31 works better for me.

I'd vote for Wed-Thu, but other days should work.



From: Ben Swartzlander [b...@swartzlander.org]
Sent: Saturday, May 30, 2015 7:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Manila] Midcycle meetup dates

We are going to have a Manila midcycle meetup this summer before the L-2
milestone. NetApp is volunteering their RTP office to host the meetup.
We will have a google hangout again this time to include those who can't
join in person, but I would encourage everyone to participate locally if
you can, because it's a lot more productive to have face to face
discussions.

What remains to be decided:

Week of July 20-24 or week of July 27-31?

Which days of the week?

I know that there are conflicts with both of the above weeks, so we may
not be able to accommodate everyone. Please let me know (either by IRC
or mail) if you want to attend the meetup but one of those above times
doesn't work for you.

I think 2 days is a good amount of time for the meetup. Last time we did
1.5 days, and it worked out pretty well. We have more to talk about this
time around (IMO) so I'm willing to dedicate 2 whole days (experience
has shown that 3 days tends to lead to burnout). I would lean towards
Tuesday-Wednesday or Wednesday-Thursday, but if someone has a good
argument for other days I'm open to ideas.

-Ben Swartzlander


__
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] [packaging] Adding packaging as an OpenStack project

[Jeremy Stanley]

On 2015-06-01 14:55:06 +0200 (+0200), Thomas Goirand wrote:
[...]
> So, should I start writing a script to build an image for package
> building (ie: an image with sbuild, git-buildpackage, and so on...)?
[...]

Probably what we'd want to do is something like debootstrap/rpmstrap
a chroot for each platform we want to build, then in each of them
iterate through the packaging git repos and --download-only the
build-deps listed therein. That will prime a local cache in each
chroot and then it will get baked into that image. Later when a
worker is booted from that image, the package build job just chroots
into the appropriate filesystem subtree and has a warm cache
available to it so it only needs to hopefully update at most the
package list and maybe a handful of packages before starting to
build whatever new package was requested.

The good thing about this approach is that it can be added later, it
doesn't need to be implemented on day one. If we design the jobs
correctly they'll download whatever they need, and then we can just
iterate on improving our caches to improve performance.

> How would a job get the latest version of a Git repository then? This
> still needs network, right?
[...]

The way our jobs work right now is that the workers start with a
recent (generally no more than a day old) clone of all the Git
repositories we maintain. It still has to hit the network to
retrieve more recent Git refs, but this at least minimizes network
interaction and significantly reduces the failure rate.
-- 
Jeremy Stanley

__
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] [all][release] summit session summary: Release Versioning for Server Applications

[Donald Stufft]

On June 1, 2015 at 1:03:08 PM, Jeremy Stanley (fu...@yuggoth.org) wrote:
>  
> Since pip treats .postN in strange ways, it's not entirely safe to
> rely on the old PBR behavior which would have made this
> 2.25.0.post8. In particular, if we were to ever upload that to PyPI
> (terrible idea I know, bear with me anyway), anyone asking pip to
> install python-novaclient==2.25.0 would get the latest 2.25.0.postN
> package rather than the actual 2.25.0 package.

That’s not exactly accurate, the only real special handling is that even
though 2.25.0.post8 is “greater than” 2.25.0, it won’t match if you do
>2.25.0 because it’s recommended that you only use post releases for non
code changes (packaging issues, documentation fixes, etc).

I wouldn’t recommend using post releases for code change releases though,
I think you’d be better off just adding a 4th digit to the release number
and being 2.25.0.8 or so. That’s mostly just a semantic thing (except for
>) not any functional reason.

---  
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



__
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] [all] upcoming oslo releases

[Doug Hellmann]

We have a bunch of Oslo libraries ready for releases tomorrow, Tuesday 2 June.

I will be releasing:

0.5.0 8685171 debtcollector
1.10.0 9a963a9 oslo.concurrency
1.12.0 02a86d2 oslo.config
0.4.0 4c9b37d oslo.context
1.10.0 42dc936 oslo.db
1.7.0 a02d901 oslo.i18n
1.3.0 6754d13 oslo.log
1.12.0 27efb36 oslo.messaging
0.5.0 757857b oslo.policy
1.8.0 2335e63 oslo.rootwrap
1.6.0 74b3f97 oslo.utils
0.3.0 a03c635 oslo.versionedobjects

If you are interested in more detail, the full set of changes to be included is 
available in http://paste.openstack.org/show/253257/

Doug


__
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] [all][release] summit session summary: Release Versioning for Server Applications

[Jeremy Stanley]

On 2015-06-01 08:53:41 -0400 (-0400), Doug Hellmann wrote:
[...]
> pbr generates versions like x.y.z.postN on each commit now, indicating N
> commits since the x.y.z tag. So I think we're OK with version numbers
> without having to do any tagging explicitly.
[...]

Well, technically x.y.(z+1).devN instead. For example, the latest
tag on python-novaclient is 2.25.0 and there have been 8 commits on
master since then, so latest PBR is versioning the tip of master as
2.25.1.dev8.

Since pip treats .postN in strange ways, it's not entirely safe to
rely on the old PBR behavior which would have made this
2.25.0.post8. In particular, if we were to ever upload that to PyPI
(terrible idea I know, bear with me anyway), anyone asking pip to
install python-novaclient==2.25.0 would get the latest 2.25.0.postN
package rather than the actual 2.25.0 package.
-- 
Jeremy Stanley

__
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] Progressing/tracking work on libvirt / vif drivers

[Neil Jerram]

On 01/06/15 14:23, Daniel P. Berrange wrote:

On Mon, Jun 01, 2015 at 09:44:24AM +0100, John Garbutt wrote:

On 29 May 2015 at 18:32, Neil Jerram  wrote:

Hi all,

Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work is
being somewhat driven by the etherpad at [2].  But this etherpad doesn't
have a section for libvirt / vif driver changes.  The log at [1] briefly
touched on this, but moved on after noting that Dan PB had disbanded a
libvirt subteam for lack of interest.


Apologies, I am not nearly half way through writing up all that came
out of the summit. A few nasty bugs in production kept me occupied
last week, but I have got out of that now / fixed them, I hope.

In the design summit session we said any group of people can
self-organise and start proposing patches as "ready to merge" by that
sub team, in here:
https://etherpad.openstack.org/p/liberty-nova-priorities-tracking

We agreed that if there were too many sub teams, we would ask the
teams to join together. And I hope some subteams find each other on
that etherpad, and organically decide its best to join forces.

While we have established patterns of successful sub team
collaborations (IRC meetings, bug tags, etc), feel free to do whatever
works, assuming its aligned with the Open nature of our community
(i.e. I expect code reviews to be done in gerrit, not using some
internal communication channel. Even if you review face to face, I
would appreciate you writing up the outcome in gerrit).


So, what should folk interested in libvirt / vif work (including me) now do?
I think the answer is that we should self-organize, then report to the next
IRC on how we've done that, and I'm happy to lead that if no one else wants
to - but is there someone else who should or wants to own this?


In summary, yes please, sounds good.

I would reach out to Dan, and the other folks who were active in those
meetings, to see how it best makes sense to collaborate. Let me know
if I can help connect you folks, but IRC usually works.


I'm mostly just lurking on IRC but keep an eye out on this mailing list
for anything tagged with [nova]. So if there's any times my input is
needed I should catch the mails as long as they're on the list.


Many thanks, John & Dan.  I'll start by drafting a summary of the work 
that I'm aware of in this area, at 
https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work.


Thanks,
Neil


__
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 : Regarding the API support for Order and Consumer Resource

[Asha Seshagiri]

Thanks a lot John for your response :)

On Mon, Jun 1, 2015 at 3:02 AM, John Vrbanac 
wrote:

>  Asha,
>
> We haven't removed anything. Unfortunately, no one has had the chance to
> port those resources over from the old github wiki page and into the new
> sphinx format yet. Also, yes they are still supported.
>
>
> John Vrbanac
>  --
> *From:* Asha Seshagiri 
> *Sent:* Monday, June 1, 2015 2:38 AM
> *To:* openstack-dev
> *Subject:* Re: [openstack-dev] Barbican : Regarding the API support for
> Order and Consumer Resource
>
>  Editing the subject
>
> On Mon, Jun 1, 2015 at 2:35 AM, Asha Seshagiri 
> wrote:
>
>> Hi All ,
>>
>>  Would like to know why have we removed the API details for Order and
>> Consumer Resource in the following update link for API Documentation of
>> Barbican
>>
>>  http://docs.openstack.org/developer/barbican/api/index.html
>>
>>
>>  Does the Barbican support order and consumer resource  now ?
>>
>>  Any help would be highly appreciated.
>> Thanks in Advance
>> --
>>  *Thanks and Regards,*
>> *Asha Seshagiri*
>>
>
>
>
>  --
>  *Thanks and Regards,*
> *Asha Seshagiri*
>
> __
> 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
>
>


-- 
*Thanks and Regards,*
*Asha Seshagiri*
__
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] [all] Liberty summit: Updates in Glance

[Steve Lewis]

On Monday, June 1, 2015 05:30, John Garbutt   wrote:
On 1 June 2015 at 13:10, Flavio Percoco  wrote:
>> AFAIK, the biggest issue right now is "changed-since" which is
>> something Glance doesn't have in v2 but it's exposed throught Nova's
>> image API.
>
> Thats the big unanswered question that needs fixing in any spec we
> would approve around this effort.
>
We're working on a plan for that, too. 


__
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] Mellanox CI Issues

[Dan Smith]

Hi,

Mellanox CI has been broken for a while now. Test runs are reported as
"successful" after an impossibly short less-than-a-minute run. Could the
owners of this please take a look and address the problem? At least
disabling commenting while working on the issue would be helpful.

Also, on success, the bot doesn't post the log files, which is (a)
inconsistent with other test bots and (b) not very helpful for
validating that success is real. This is especially relevant right now,
given that we know the success reports are erroneous at the moment.

This is the second time (in recent memory) that Mellanox CI has gone off
the rails for a decent amount of time without being noticed by the
owners. If this continues, I'll be in favor of removing commenting
privileges for this account and will be hesitant to throw in my support
for re-enabling it. Running CI against gerrit comes with serious
responsibility for monitoring!

Thanks!

--Dan



signature.asc
Description: OpenPGP digital 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] [akanda] meeting time change

[sean roberts]

Note that the 11am PDT meeting has moved to the #openstack-meeting channel

On Sun, May 31, 2015 at 2:20 PM, sean roberts 
wrote:

> Starting tomorrow, the akanda project will be meeting on
> #openstack-meeting at 11:00 PDT. Agenda is in the usual place
> https://wiki.openstack.org/wiki/Meetings/akanda
> See you there
>
> ~ sean
>



-- 

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

[openstack-dev] [neutron][vnaas] IRC Meeting scheduled for June 2nd...

[Paul Michali]

Since we had a bunch of interest at the Summit in VPN, we'll hold a meeting
at our time-slot, Tuesday, 1600 UTC, openstack-meeting-3, tomorrow on June
2nd.

I updated the agenda. If you have other updates, please add them to the
wiki page:

https://wiki.openstack.org/wiki/Meetings/VPNaaS

Regards,

Paul Michali (pc_m)
__
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] [all][release] summit session summary: Release Versioning for Server Applications

[Thierry Carrez]

Doug Hellmann wrote:
> Excerpts from Thierry Carrez's message of 2015-06-01 10:30:33 +0200:
>> Doug Hellmann wrote:
>>> Please let me know if you think I missed any details, or misunderstood 
>>> something as agreed to. Or, of course, if you weren’t there and see 
>>> something wrong with the plan after looking at it now.
>>
>> We'd also provide a tool to easily translate the series name with the
>> current associated version for every repository, to facilitate
>> navigation in a world without common versioning.
>>
> 
> Yes, that's right we did talk about that. Do you have a workflow in mind
> already?

It's probably just about finding the "last" tag in a stable/$SERIES or
master set of branches, given a repo name... querying git.o.o ?

Would be also nice if by default it could list all the versions for
"server" projects, if we can find a way to have a list of them.

Something like:

$ openstackversion kilo openstack/nova
2015.1.0

$ openstackversion kilo
openstack/nova 2015.1.0
openstack/swift 2.3.0
openstack/keystone 2015.1.0
...


-- 
Thierry Carrez (ttx)

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

[openstack-dev] [Infra] Meeting Tuesday June 2nd at 19:00 UTC

[Elizabeth K. Joseph]

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday June 2nd, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

In case you missed them or would like a refresher, meeting logs and
minutes from our last meeting couple of meetings are available.

May 12:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-05-12-19.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-05-12-19.01.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-05-12-19.01.log.html

May 26:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-05-26-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-05-26-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-05-26-19.02.log.html

Additionally, etherpads that resulted from our sessions at the
OpenStack Design Summit a couple weeks ago (May 19-22) are linked
here:

https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Infrastructure

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

__
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] [all] [stable] No longer doing stable point releases

[Jeremy Stanley]

On 2015-06-01 15:57:17 + (+), Jeremy Stanley wrote:
[...]
> The biggest hurdle is that we'd need a separate upload job name
> for those since the current version of Zuul lacks a way to run a
> particular job for different branches in different pipelines (we'd
> want to do versioned uploads for all pre-release and release
> pipeline refs, but also for post pipeline refs only when the
> branch name is like stable/.*).

Actually, scratch that. It's a bit more complicated since the post
pipeline isn't actually branch-relevant. We'd need to tweak the
tarball and wheel creation scripts to check the containing branch,
like we do for some proposal jobs. Still, I think it wouldn't be too
hard.
-- 
Jeremy Stanley

__
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] [all] [stable] No longer doing stable point releases

[Jeremy Stanley]

On 2015-06-01 12:20:22 +0100 (+0100), Dimitri John Ledkov wrote:
[...]
> If the stable tarball snapshots had stable, ever increasing names, I
> would switch to using those straight away. (Out of which $ git
> describe --tags satisfies said requirement)

Current PBR releases already create monotonically-increasing
SemVer-like PEP-440-compliant versions for any commit, and name the
resulting sdist tarballs and wheels accordingly. It would be fairly
easy right now to switch stable branch tarball uploads on
tarballs.openstack.org to do that rather than constantly replace a
branch tip tarball. The biggest hurdle is that we'd need a separate
upload job name for those since the current version of Zuul lacks a
way to run a particular job for different branches in different
pipelines (we'd want to do versioned uploads for all pre-release and
release pipeline refs, but also for post pipeline refs only when the
branch name is like stable/.*).
-- 
Jeremy Stanley

__
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] [all] [stable] No longer doing stable point releases

[Jeremy Stanley]

On 2015-06-01 17:32:03 +0200 (+0200), Alan Pevec wrote:
[...]
> and *Plan D* would be to start doing automatic per-project
> micro-versions on each commit: e.g. 2015.1.N where N is increased on
> each commit. There's just TBD item how to provide source tarballs for
> this.
[...]

That would happen automatically (they're already generated and
uploaded to tarballs.openstack.org each time a tag is pushed).
-- 
Jeremy Stanley

__
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] [all] [stable] No longer doing stable point releases

[Jeremy Stanley]

On 2015-06-01 12:04:34 +0200 (+0200), Thierry Carrez wrote:
> Thierry Carrez wrote:
[...]
> > 2. it would be difficult to get proper release notes
> > 
> > If we don't have point releases anymore, we don't have release notes
> > anymore. Release notes contain various types of information: the list of
> > security fixes, the occasional upgrade warning, and the list of bugfixes.
> 
> We'd probably have to find a way to provide the same information in the
> tarball itself, so that if you picked any of them you could still get a
> list of the fixes in there.
[...]

PBR has the ability to generate a ChangeLog as part of the sdist
tarball generation. If the ChangeLog itself isn't suitable, we could
do something akin to what Doug described about scraping commit
messages for particular specially-formatted header lines and then
maybe have a separate release notes sdist hook in PBR. Or we could
just expect projects to update a release notes file in that repo on
any stable branch change which implies some action on the part of
the downstream consumers.

As to the separate concern raised by a couple of respondents for a
lack of signatures on stable branch tarballs (be they per-commit or
arbitrarily tagged by their respective project teams), I've been
itching to implement some mechanical generation of detached
signatures to publish along with artifacts uploaded to
tarballs.openstack.org and PyPI anyway. We could presumably leverage
that. It wouldn't be a human signature, just a signature made by a
trusted host in the infrastructure build chain whose key was signed
by some of the infrastructure root admins, but would at least attest
to the integrity of the file once uploaded to the point of
publication.
-- 
Jeremy Stanley


signature.asc
Description: Digital 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] [all] [stable] No longer doing stable point releases

[Haïkel]

2015-06-01 17:32 GMT+02:00 Alan Pevec :
>> *Plan C* would be to just let projects tag stable point releases from
>> time to time. That would solve all the original stated problems. And
>> that would solve objections 2 and 3, which I think are the most valid ones.
>
> and *Plan D* would be to start doing automatic per-project
> micro-versions on each commit: e.g. 2015.1.N where N is increased on
> each commit. There's just TBD item how to provide source tarballs for
> this.

+1 for micro-versions rather than raw git checksums.

> This would solve 3. reference points for OSSAs and relnotes.
> Solution for 2. could be to add doc/source/release-notes.rst for each
> project wishing to maintain it, docs are already published for each
> branch e.g. http://docs.openstack.org/developer/keystone/kilo/
>
> Cheers,
> Alan
>
> __
> 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] [all] [stable] No longer doing stable point releases

[Ian Cordasco]

On 6/1/15, 06:20, "Dimitri John Ledkov"  wrote:

>On 29 May 2015 at 14:41, Thierry Carrez  wrote:
>> Hi everyone,
>>
>> TL;DR:
>> - We propose to stop tagging coordinated point releases (like 2015.1.1)
>> - We continue maintaining stable branches as a trusted source of stable
>> updates for all projects though
>>
>
>Ideally I would still want to see tarballs published, even if they are
>generated with a $ git describe --tags name in it.
>
>E.g. keystone-2015.1.0-3-g1373bfa.tar.gz
>
>keystone-stable-kilo.tar.gz -> is really bad name imho, as it's ever
>changing tarball. It would be nice if that was e.g. a symlink to a
>keystone-2015.1.0-3-g1373bfa.tar.gz if said snapshot is latest.
>
>If the stable tarball snapshots had stable, ever increasing names, I
>would switch to using those straight away. (Out of which $ git
>describe --tags satisfies said requirement)

Except this won't help anyone deploying with pip (which I know people
don't believe actually happens). That's not a valid pip version number
(neither 2015.1.0-3-g1373bfa nor stable-kilo are valid). If someone were
to use this archive with something like

pip install 'keystone>=2015.1.0' --find-links
https://stable-archive.openstack.org/kilo/

Then they wouldn't find anything new. If the releases are to be
auto-versioned, they should be done in a different way.

__
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] [qa] Need volunteers for tempest bug triage

[David Kranz]

On 05/30/2015 09:15 AM, Kashyap Chamarthy wrote:

On Sat, May 30, 2015 at 03:52:02PM +0300, Yaroslav Lobankov wrote:

Hi everyone,

Is it possible for other people (not only core reviewers) to
participate in bug triage? I would like to help in doing this.

Absolutely. There's no such silly rule that only core reviwers can do
bug triage.
Of course it is helpful for any one to help with bug triage. Beware that 
confirming new bugs is a bit trickier
for tempest than other projects because it has such a high rate of 
Invalid bug reports. This is because bugs in other projects will often cause
tempest to fail and many people just file tempest bugs with a stacktrace 
from the console. You often have to dig further to find the real issue.


For that reason we like to always have a core reviewer watching bug 
traffic and being the "bug supervisor" in the below referenced wiki.

That was the point of this message.

 -David


While not mandatory, it can make your life a bit more easier while
troubleshooting if you have spent some time test/debugging OpenStack
environments.

Take a look here:

 https://wiki.openstack.org/wiki/BugTriage

Also, you might want to refer this useful notes from Sean Dague about
what to consider while triaging bugs (though, the example below is from
the Nova bug tracker, it's generally applicable across components):

 
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html




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

Re: [openstack-dev] [Neutron][bgpvpn] IRC meetings on BGP VPN interconnection API

[thomas.morin]

Hi,

We confirm this meeting for tomorrow Tuesday 2nd @15:00 UTC on 
#openstack-meeting-alt .


We'll discuss tomorrow what we want to do for future IRC meetings
(day, time, periodicity, etc.).

(Everyone is encouraged to also follow the VPNaaS meeting that will follow)

Best,

-Thomas


2015-05-29, Thomas Morin:

Hi everyone,

As a follow-up to discussions last week on a BGP VPN interconnection API
and the work started with the people already involved, we are going to
hold IRC meetings to discuss how to progress the different pieces of
work, in particular on the API itself [1] and its implementation+drivers
[2].

The slot we propose is ** Tuesday 15:00 UTC ** with the first meeting
next Tuesday (June 2nd).

Note that, based on last week feedback, we submitted the existing
stackforge project for inclusion in the Neutron "big tent" earlier this
week [3].

We will do a proper meeting registration (patch to openstack-infra
irc-meeting) and send meeting info with wiki and meeting room before
next Tuesday.

Looking forward to discussing with everyone interested!

-Thomas & Mathieu

[1] currently being discussed at https://review.openstack.org/#/c/177740
[2] https://github.com/stackforge/networking-bgpvpn
[3] https://review.openstack.org/#/c/186041





_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.


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

Re: [openstack-dev] [Neutron][bgpvpn] IRC meetings on BGP VPN interconnection API

[thomas.morin]

Hi Paul, all,

Yes, it's good to have a discussion on BGP VPN and edge VPN proposals 
during the VPNaaS meeting.

At least Mathieu and I will participate to see how we can help.

To avoid confusion we think it's good to keep separate the discussion on 
the details of the work around the networking-bgpvpn stackforge project, 
so we'll use the 15:00 UTC slot on #openstack-alt for this purpose (free 
AFAICT). And, we will encourage all participants to attend the VPNaaS 
meeting right after, on #openstack-meeting-3.


Thank you,

-Thomas


Le 01/06/2015 13:06, Paul Michali a écrit :

FYI, the channel is openstack-meeting-3.

On Sun, May 31, 2015 at 10:41 PM Mohammad Hanif > wrote:


Hi Thomas,

The time reserved for the weekly IRC is 1600 UTC on Tuesdays
(http://eavesdrop.openstack.org/#Neutron_VPNaaS_Meeting). The IRC
channel might not be available on any other time (1500 UTC is
taken by the libvirt team meeting).

Thanks,
—Hanif.



On 5/29/15, 12:57 PM, "Vikram Choudhary" mailto:viks...@gmail.com>> wrote:

>Hi Thomas/Mathieu,
>
>Thanks for starting this mail thread. Let's discuss over the IRC as
>suggested by Paul.
>
>Thanks
>Vikram
>
>On 5/29/15, Paul Michali mailto:p...@michali.net>>
wrote:
>> You can use the VPNaaS IRC channel/time... we don't have much
on the agenda
>> right now, other than discussion VPN flavors for Liberty, in
which it would
>> be good to discuss BGP VPN and Edge VPN.
>>
>> Regards,
>>
>> Paul Michali (pc_m)
>>
>> On Fri, May 29, 2015 at 11:08 AM mailto:thomas.mo...@orange.com>> wrote:
>>
>>> Hi everyone,
>>>
>>> As a follow-up to discussions last week on a BGP VPN
interconnection API
>>> and the work started with the people already involved, we are
going to
>>> hold IRC meetings to discuss how to progress the different
pieces of
>>> work, in particular on the API itself [1] and its
implementation+drivers
>>> [2].
>>>
>>> The slot we propose is ** Tuesday 15:00 UTC ** with the first
meeting
>>> next Tuesday (June 2nd).
>>>
>>> Note that, based on last week feedback, we submitted the existing
>>> stackforge project for inclusion in the Neutron "big tent"
earlier this
>>> week [3].
>>>
>>> We will do a proper meeting registration (patch to openstack-infra
>>> irc-meeting) and send meeting info with wiki and meeting room
before
>>> next Tuesday.
>>>
>>> Looking forward to discussing with everyone interested!
>>>
>>> -Thomas & Mathieu
>>>
>>> [1] currently being discussed at
https://review.openstack.org/#/c/177740
>>> [2] https://github.com/stackforge/networking-bgpvpn
>>> [3] https://review.openstack.org/#/c/186041
>>>
>>>
>>>
>>>
>>>

_
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si
vous avez
>>> recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes.
Les messages
>>> electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete
altere, deforme
>>> ou
>>> falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or
privileged
>>> information that may be protected by law;
>>> they should not be distributed, used or copied without
authorisation.
>>> If you have received this email in error, please notify the
sender and
>>> delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages
that have
>>> been
>>> modified, changed or falsified.
>>> Thank you.
>>>
>>>
>>>
__
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>
>__
>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 Ma

Re: [openstack-dev] [nova] I think nova behaves poorly when booting multiple instances

[Ed Leafe]

On Jun 1, 2015, at 8:26 AM, Andrew Laski  wrote:

>> In any case, even if we wanted to deprecate it (and I think an argument 
>> could be made for that) we still have to decide what the "correct" behaviour 
>> should be for the API as it exists today.  In my view the current behaviour 
>> doesn't match what a reasonable person would expect given the description of 
>> the "min count" and "max count" parameters.
> 
> I'm +1 on fixing the behavior here.  As many instances as can be booted 
> should be, despite part of the initial block failing.  The only reason I can 
> think of for failing all of them is if you want to consider the request as a 
> single operation that can either fail or succeed.

Even in that case, "succeed" would mean that you were able to create min_count 
instances. If that isn't what was wanted, then the min_count should be the same 
as the max_count.


-- Ed Leafe







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] [all] [stable] No longer doing stable point releases

[Alan Pevec]

> *Plan C* would be to just let projects tag stable point releases from
> time to time. That would solve all the original stated problems. And
> that would solve objections 2 and 3, which I think are the most valid ones.

and *Plan D* would be to start doing automatic per-project
micro-versions on each commit: e.g. 2015.1.N where N is increased on
each commit. There's just TBD item how to provide source tarballs for
this.
This would solve 3. reference points for OSSAs and relnotes.
Solution for 2. could be to add doc/source/release-notes.rst for each
project wishing to maintain it, docs are already published for each
branch e.g. http://docs.openstack.org/developer/keystone/kilo/

Cheers,
Alan

__
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] [release] WSME 0.7.0

[Stéphane Bisinger]

Thank you!!

Hopefully this release will be the starting point for a small rebirth of
the WSME project. Many bugs still need fixes, the code needs improvements
and probably some standardisation towards the OpenStack guidelines.

It would be very useful to receive some feedback from the projects who are
actually using this library so that there can be a plan for what the future
of this library should be, if we want to avoid it to be cast into
deprecation. I think that with some care it can grow to be a better
library, but that cannot be done without some discussion about it...


On Mon, Jun 1, 2015 at 3:22 PM, Doug Hellmann  wrote:

> We are jubilant to announce the release of:
>
> wsme 0.7.0: Simplify the writing of REST APIs, and extend them with
> additional protocols.
>
> With source available at:
>
> http://git.openstack.org/cgit/stackforge/wsme
>
> For more details, please see the git log history below and:
>
> https://launchpad.net/wsme/+bugs/+milestone/0.7.0
>
> Please report issues through launchpad:
>
> https://bugs.launchpad.net/wsme/+bugs
>
> Changes in WSME 0.6.4..0.7.0
> 
>
> 9b3e71e Add instructions to configure cornice with WSME
> 002473c Move ipaddr to netaddr
> d60de97 Add pytz as a dependency.
> a88c830 Fix wrong reference to status argument in the docs
> 3ea152c Added timezone support to parse_isodatetime
> 32456d3 Replace deprecated assertEquals with assertEqual
> 7379a3a Update changes doc
> d2f8f8f Ensure UserType objects are converted to basetype
> 9a0d3c1 Convert built-in types when passed as strings
> 78d6b89 Enable real testing of python 3.4
> e31045e Multiple protocol accept or content-type matching
> f66cf4c Raise an InvalidInput if you get a ValueError from JSON data.
> 8d9f82d Return a 400 status code on invalid JSON input
> b4e918b Remove unsupported python versions from setup.cfg
> 34f325a Clean up setup.py and add requirements.txt
> 5874aa6 Remove tab character from setup.cfg
> f6602e7 Add full MIT license
> 81afe37 Fix i18n when formatting exception
> c4d3986 Converts prints to logging.debug calls
> 94cd175 Change client-side error logging to debug
> de877d2 Pecan: Make it possible to use the Response to return a
> non-default return type
> 80e0c2a Fixing spelling error on MIME Type Errors and PEP8
> 8710dab Improve Accept and Content-Type handling
> bad1c3e Fix pep8 w503 errors
> da67a34 Correct pep8 errors from imports in weird places.
> b4ef065 several fixes for SOAP protocol
> 1ecf647 [doc] Update changes list
> d34eb82 Fix validation of IPv{4,6}AddressType
> 5de10ea Fix printing object reference on StringType
>
> Diffstat (except docs and test files)
> -
>
> LICENSE  |  20 +-
> requirements-py3.txt |   5 +
> requirements.txt |   5 +
> setup.cfg|   6 +-
> setup.py |  27 +-
> tox-tmpl.ini | 111 +---
> tox.ini  | 736
> +--
> wsme/api.py  |  25 +-
> wsme/protocol.py |  34 ++
> wsme/rest/args.py|   2 +-
> wsme/rest/json.py|  53 +-
> wsme/rest/protocol.py|   9 +-
> wsme/root.py |  42 +-
> wsme/types.py|  26 +-
> wsme/utils.py|  24 +-
> wsmeext/pecan.py |  17 +-
> wsmeext/soap/protocol.py |  12 +-
> wsmeext/soap/wsdl.py |   6 +-
> wsmeext/sphinxext.py |  10 +-
> wsmeext/tg1.py   |   6 +-
> 38 files changed, 1021 insertions(+), 934 deletions(-)
>
>
> Requirements updates
> 
>
> diff --git a/requirements-py3.txt b/requirements-py3.txt
> new file mode 100644
> index 000..d15bd16
> --- /dev/null
> +++ b/requirements-py3.txt
> @@ -0,0 +1,5 @@
> +six>=1.9.0
> +WebOb>=1.2.3
> +simplegeneric
> +pytz
> +netaddr>=0.7.12
> diff --git a/requirements.txt b/requirements.txt
> new file mode 100644
> index 000..d15bd16
> --- /dev/null
> +++ b/requirements.txt
> @@ -0,0 +1,5 @@
> +six>=1.9.0
> +WebOb>=1.2.3
> +simplegeneric
> +pytz
> +netaddr>=0.7.12
> __
> 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
>



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

[openstack-dev] [nova] Add new VIF Type

[Andreas Scheuring]

Hi, 
what are the prereqs to get a spec for a new nova VIF type approved?

In my case I'm planning for a new neutron ml2 driver and agent (on
stackforge) that adds general support for macvtap to neutron. I've not
yet published anything regarding the neutron part so far - but this will
happen in the next days...

For the nova part I already createad a blueprint + spec and a first
draft of the code changes required [1]. Howewer, this is still WIP, but
I wanted to get clarification about the process to get it approved



- Is it sufficient to have a spec with the plans for the neutron code in
the stackforge repo to get my nova changes approved?

- Or does it require that the thirdparty code is already up on
stackforge, and the integration points already merged into neutron?


It looks like like a chicken egg problem to me: Probably nova only wants
to add support, if there's already full functional support in neutron,
but on the other hand, to get the neutron code developed and tested, the
nova support is required..

Thanks


[1] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif

-- 
Andreas 
(irc: scheuran)




__
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] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

[Jay Lau]

2015-06-01 21:54 GMT+08:00 Jay Pipes :

> On 05/31/2015 05:38 PM, Jay Lau wrote:
>
>> Just want to use ML to trigger more discussion here. There are now
>> bugs/patches tracing this, but seems more discussions are needed before
>> we come to a conclusion.
>>
>> https://bugs.launchpad.net/magnum/+bug/1453732
>> https://review.openstack.org/#/c/181839/
>> https://review.openstack.org/#/c/181837/
>> https://review.openstack.org/#/c/181847/
>> https://review.openstack.org/#/c/181843/
>>
>> IMHO, making the Bay/Baymodel name as a MUST will bring more flexibility
>> to end user as Magnum also support operating Bay/Baymodel via names and
>> the name might be more meaningful to end users.
>>
>> Perhaps we can borrow some iead from nova, the concept in magnum can be
>> mapped to nova as following:
>>
>> 1) instance => bay
>> 2) flavor => baymodel
>>
>> So I think that a solution might be as following:
>> 1) Make name as a MUST for both bay/baymodel
>> 2) Update magnum client to use following style for bay-create and
>> baymodel-create: DO NOT add "--name" option
>>
>
> You should decide whether name would be unique -- either globally or
> within a tenant.
>
> Note that Nova's instance names (the display_name model field) are *not*
> unique, neither globally nor within a tenant. I personally believe this was
> a mistake.
>
> The decision affects your data model and constraints.
>
Yes, my thinking is to enable Magnum has same behavior with nova. The name
can be managed by the end user and the end user can specify the name as
they want, it is end user's responsibility to make sure there are no
duplicate names. Actually, I think that the name do not need to be unique
but UUID.

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



-- 
Thanks,

Jay Lau (Guangya Liu)
__
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] [release][cinder] os-brick 0.2.0

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2015-06-01 10:29:32 -0400:
> We are jubilant to announce the release of:
> 
> os-brick 0.2.0: OpenStack Cinder brick library for managing local
> volume attaches
> 
> With source available at:
> 
> http://git.openstack.org/cgit/openstack/os-brick
> 
> For more details, please see the git log history below and:
> 
> http://launchpad.net/os-brick/+milestone/0.2.0

The launchpad project for os-brick is not configured to allow the
release management team to create milestones, so this doesn't
actually exist yet. If someone from the team contacts me on IRC, I
can work with you to set it up properly and re-run the script to
create the series and milestone.

Doug

__
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] [release][tripleo] os-collect-config 0.1.35

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2015-06-01 10:31:36 -0400:
> We are excited to announce the release of:
> 
> os-collect-config 0.1.35: Collect and cache metadata, run hooks on
> changes.
> 
> For more details, please see the git log history below.
> 
> 
> Changes in os-collect-config 0.1.34..0.1.35
> ---
> 
> 4a41f0b Drop use of 'oslo' namespace package
> 
> Diffstat (except docs and test files)

The launchpad project for os-collect-config is not configured to
allow the release management team to create milestones, so the
milestone tracking isn't working.  If someone from the team contacts
me on IRC, I can work with you to set it up properly and re-run the
script to create the series and milestone.

Doug

__
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] [release][neutron] python-neutronclient 2.6.0

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2015-06-01 10:27:41 -0400:
> We are thrilled to announce the release of:
> 
> python-neutronclient 2.6.0: CLI and Client Library for OpenStack
> Networking
> 
> With source available at:
> 
> http://git.openstack.org/cgit/openstack/python-neutronclient
> 
> For more details, please see the git log history below and:
> 
> http://launchpad.net/python-neutronclient/+milestone/2.6.0

The launchpad project for python-neutronclient is not configured
to allow the release management team to create milestones, so this
doesn't actually exist yet. If someone from the team contacts me
on IRC, I can work with you to set it up properly and re-run the
script to create the series and milestone.

Doug

__
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][all] Zaqar will stay... Lots of work ahead

[Ildikó Váncsa]

Hi Ryan and Flavio,

Thanks for the quick response and the pointers, I will check out the reviews to 
catch up.

Best Regards,
Ildikó

> -Original Message-
> From: Ryan Brown [mailto:rybr...@redhat.com]
> Sent: June 01, 2015 16:34
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work 
> ahead
> 
> On 06/01/2015 04:34 AM, Flavio Percoco wrote:
> > On 31/05/15 18:12 +, Ildikó Váncsa wrote:
> >> Hi All,
> >>
> >> I would like to ask about the user-facing notifications part of the
> >> list. Do you have a roadmap for this? Is this driven by the Zaqar
> >> team? What are the next steps?
> >
> > Hey,
> >
> > This will require cross-project efforts and we (the Zaqar team) would
> > love to get some help here. If anyone is willing to drive the spec and
> > sync, the Zaqar team would be happy to help with other tasks.
> >
> > I think it'd be really beneficial to start doing it in one of the
> > services (Heat?) as a PoC, while we discuss the cross-project spec and
> > feed it with the things we'll learn from the PoC.
> >
> > Would you like to help with this?
> 
> Indeed it will require tons of cross-project work. Heat is going to try to get
> Zaqar notifications to our users in Liberty, and I've posted specs for the
> message format side of the problem[1][2]. There is also a cross-project spec
> for user notifications[3].
> 
> Heat plans on adopting this format after sufficient review, and we welcome
> other projects to look over the format and provide feedback to help it work
> for their use case as well.
> 
> [1]: https://review.openstack.org/#/c/186436/
> [2]: https://review.openstack.org/#/c/186555/
> [3]: https://review.openstack.org/#/c/185822/
> 
> > ...[snip]...
> 
> --
> Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
> 
> __
> 
> 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] [release][oslo] oslo.middleware 1.3.0

[Doug Hellmann]

We are delighted to announce the release of:

oslo.middleware 1.3.0: Oslo Middleware library

With source available at:

http://git.openstack.org/cgit/openstack/oslo.middleware

For more details, please see the git log history below and:

http://launchpad.net/oslo.middleware/+milestone/1.3.0

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.middleware

Changes in oslo.middleware 1.2.0..1.3.0
---

cab38ce Added CORS wildcard handling
4586979 Drop use of 'oslo' namespace package
44a7b7d Updated from global requirements
ce1acb4 Advertise support for Python3.4 / Remove support for Python 3.3
48e64af Remove run_cross_tests.sh
7b9709c Update response body when healthcheck is available

Diffstat (except docs and test files)
-

openstack-common.conf  |   1 -
oslo_middleware/cors.py|  11 +-
oslo_middleware/healthcheck/disable_by_file.py |   4 +-
requirements.txt   |   2 +-
setup.cfg  |   2 +-
tox.ini|   2 +-
10 files changed, 268 insertions(+), 159 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 4547208..81a2693 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +5 @@
-pbr>=0.6,!=0.7,<1.0
+pbr>=0.11,<2.0

__
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] [release][manila] python-manilaclient 1.2.0

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2015-06-01 10:27:38 -0400:
> We are thrilled to announce the release of:
> 
> python-manilaclient 1.2.0: Client library for OpenStack Manila API.
> 
> With source available at:
> 
> http://git.openstack.org/cgit/openstack/python-manilaclient
> 
> For more details, please see the git log history below and:
> 
> http://launchpad.net/python-manilaclient/+milestone/1.2.0

The launchpad project for manila is not configured to allow the release
management team to create milestones, so this doesn't actually exist
yet. If someone from the team contacts me on IRC, I can work with you to
set it up properly and re-run the script to create the series and
milestone.

Doug


__
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] [release][neutron] python-neutronclient 2.6.0

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have a suggestion... Since it's not obvious now which stable branch
a release corresponds to, can we add that info into release note email
body somewhere for the sake of those who may closely track stable
updates but not so much those in-development, e.g. most packagers?

For server projects, (most) versions clearly map to cycles, but not
for oslo or client libraries.

Thanks
Ihar

On 06/01/2015 04:27 PM, Doug Hellmann wrote:
> We are thrilled to announce the release of:
> 
> python-neutronclient 2.6.0: CLI and Client Library for OpenStack 
> Networking
> 
> With source available at:
> 
> http://git.openstack.org/cgit/openstack/python-neutronclient
> 
> For more details, please see the git log history below and:
> 
> http://launchpad.net/python-neutronclient/+milestone/2.6.0
> 
> Please report issues through launchpad:
> 
> http://bugs.launchpad.net/python-neutronclient
> 
> Changes in python-neutronclient 2.5.0..2.6.0 
> 
> 
> f62492b Updated from global requirements 9e6977d Allow setting
> router's external ip(s) d9113f1 Drop use of 'oslo' namespace
> package 06a6e4d Updated from global requirements 6190a72 Add
> functional test for subnet create 5eb292c Fix Python client library
> for Neutron d830767 Update README to work with release tools 
> d75689a Add --binding-profile to port-create 7bc65cb Fix invalid
> error message in neutron-cli ae09deb Add basic functional tests for
> client library
> 
> Diffstat (except docs and test files) 
> -
> 
> README.rst | 15 +++- 
> neutronclient/common/serializer.py |  2 +- 
> neutronclient/common/utils.py  | 13 +++- 
> neutronclient/i18n.py  |  2 +- 
> neutronclient/neutron/v2_0/__init__.py |  6 +- 
> neutronclient/neutron/v2_0/port.py | 11 ++- 
> neutronclient/neutron/v2_0/quota.py|  2 +- 
> neutronclient/neutron/v2_0/router.py   | 18 - 
> neutronclient/neutron/v2_0/subnet.py   |  2 +- 
> .../neutron/v2_0/vpn/ipsec_site_connection.py  |  2 +- 
> neutronclient/shell.py | 17 - 
> requirements.txt   |  6 +- 
> test-requirements.txt  |  2 +- 24 files
> changed, 282 insertions(+), 21 deletions(-)
> 
> 
> Requirements updates 
> 
> diff --git a/requirements.txt b/requirements.txt index
> b7a9ee1..28e9652 100644 --- a/requirements.txt +++
> b/requirements.txt @@ -4 +4 @@ -pbr>=0.6,!=0.7,<1.0 
> +pbr>=0.11,<2.0 @@ -12,2 +12,2 @@ oslo.utils>=1.4.0
> # Apache-2.0 -requests>=2.2.0,!=2.4.0 
> -python-keystoneclient>=1.1.0 +requests>=2.5.2 
> +python-keystoneclient>=1.3.0 diff --git a/test-requirements.txt
> b/test-requirements.txt index 1c395de..24c84a1 100644 ---
> a/test-requirements.txt +++ b/test-requirements.txt @@ -19 +19 @@
> testtools>=0.9.36,!=1.2.0 -tempest-lib>=0.4.0 +tempest-lib>=0.5.0
> 
> __

>
> 
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-
Version: GnuPG v2

iQEcBAEBCAAGBQJVbG+YAAoJEC5aWaUY1u57k0MIAOLIqhWa1pfK1jtHe0F4cbNu
pjAXs25suHy+GK6U5z5LRr7ZgNXviQFDJyGmYjaKJdPVrnVRtS59G6Hrz4vw8epH
qKmaCHqBad1TivurViPM7c567c8Jd6p4jKQfriEKOz1lPCrT2ciZLTrIZU0ZKLUP
D4YKfp4Jlw0g8CCCAxNPsef7EOjcTmDQwJiR7axAiu8jQNMwCM6U5dfxnbPCwoC8
IcGkdgWEZk+g5YmmaBjj6PLtX1qwBWkB7wqFzuCfVUO1Es8EvnfaKlTmFs7GD2e3
KSU1o8NMznt+hmUj066X3juQUX39FE4NWcGmN+IrinZ6PSFsmT+4/wqE8Tw1GQg=
=djGk
-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] [kolla] gate failing sporadically

[Jeff Peeler]

On Sat, May 30, 2015 at 03:00:04AM +, Steven Dake (stdake) wrote:

Hey Folks,

I noticed the Kolla functional gate is failing sporadically.

It seems that sometimes an image doesn’t build.

http://logs.openstack.org/75/186475/1/check/check-kolla-functional-f21/8f23913/console.html


(For the record, due to the compressing of the logs it's best to post 
the link to the directory of the logs.)


One thing that looks off there is barbican is not building a —release 
image (I.e. Tag =atest).  Shouldn’t it?


The other failures I’ve noticed follow the same pattern.  Is there a 
problem in our build scripts?


All the images are handled the same. I didn't see the atest tag you 
mentioned, but I see that the latest build did succeed. It appears that 
a yum mirror failure was to blame and affected other reviews as well.  
Hopefully mirror reliability doesn't become a frequent problem.


I imagine all of this has been figured out, but mailing list posts 
without a reply are less useful for the archives.


__
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] [release][tripleo] os-collect-config 0.1.35

[Doug Hellmann]

We are excited to announce the release of:

os-collect-config 0.1.35: Collect and cache metadata, run hooks on
changes.

For more details, please see the git log history below.


Changes in os-collect-config 0.1.34..0.1.35
---

4a41f0b Drop use of 'oslo' namespace package

Diffstat (except docs and test files)
-

os_collect_config/cache.py | 2 +-
os_collect_config/cfn.py   | 2 +-
os_collect_config/collect.py   | 2 +-
os_collect_config/ec2.py   | 2 +-
os_collect_config/heat.py  | 2 +-
os_collect_config/heat_local.py| 2 +-
os_collect_config/keystone.py  | 2 +-
os_collect_config/local.py | 2 +-
os_collect_config/openstack/common/log.py  | 2 +-
os_collect_config/request.py   | 2 +-
17 files changed, 17 insertions(+), 17 deletions(-)

__
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] [release][trove] python-troveclient 1.2.0

[Doug Hellmann]

We are delighted to announce the release of:

python-troveclient 1.2.0: Client library for OpenStack DBaaS API

With source available at:

http://git.openstack.org/cgit/openstack/python-troveclient

For more details, please see the git log history below and:

http://launchpad.net/python-troveclient/+milestone/1.2.0

Please report issues through launchpad:

http://bugs.launchpad.net/python-troveclient

Changes in python-troveclient 1.1.0..1.2.0
--

025191a Fixes new hacking rules
d688936 Updated coverage related options to project
b355471 Updated from global requirements
8612fd0 Drop use of 'oslo' namespace package
f996f5e Updated from global requirements
8b1e3c3 Corrects order of parameters to assertEqual
622f9bc Update README to work with release tools

Diffstat (except docs and test files)
-

.coveragerc| 29 ++
README.rst |  6 +
requirements.txt   |  6 ++---
test-requirements.txt  |  2 +-
tox.ini|  8 --
troveclient/client.py  |  2 +-
troveclient/compat/utils.py|  2 +-
troveclient/i18n.py|  4 +--
troveclient/openstack/common/apiclient/base.py |  2 +-
.../openstack/common/apiclient/fake_client.py  |  2 +-
troveclient/shell.py   | 10 
troveclient/utils.py   |  4 +--
troveclient/v1/flavors.py  |  2 +-
16 files changed, 64 insertions(+), 25 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index a87acea..8d5e780 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -4 +4 @@
-pbr>=0.6,!=0.7,<1.0
+pbr>=0.11,<2.0
@@ -7 +7 @@ PrettyTable>=0.7,<0.8
-requests>=2.2.0,!=2.4.0
+requests>=2.5.2
@@ -10 +10 @@ oslo.utils>=1.4.0   # Apache-2.0
-python-keystoneclient>=1.1.0
+python-keystoneclient>=1.3.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 6c5f39f..d0ea1de 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -4 +4 @@
-hacking>=0.8.0,<0.9
+hacking>=0.10.0,<0.11
__
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] [release][manila] python-manilaclient 1.2.0

[Doug Hellmann]

We are thrilled to announce the release of:

python-manilaclient 1.2.0: Client library for OpenStack Manila API.

With source available at:

http://git.openstack.org/cgit/openstack/python-manilaclient

For more details, please see the git log history below and:

http://launchpad.net/python-manilaclient/+milestone/1.2.0

Please report issues through launchpad:

http://bugs.launchpad.net/python-manilaclient

Changes in python-manilaclient 1.1.0..1.2.0
---

281795e Drop incubating theme from docs
916ae8c Add share extend API
095c81e Fix configuration for tox 2.0.x
1c94a59 Rename functional test module from shares to shares_listing
b6c24ef Increase quota for share networks in manila installation
f88f356 Updated from global requirements
a920805 Updated from global requirements
25d9af1 Drop use of 'oslo' namespace package
17f76ed Add rw functional tests for share networks
c6eace1 Add rw functional tests for share type extra specs
0a4ccec Add rw functional tests for private share types
4243d87 Add rw functional tests for public share types
b442181 Implement wrapper for ascii table parser from tempest_lib.cli
c51f80b Update README to work with release tools

Diffstat (except docs and test files)
-

README.rst |   5 +
contrib/ci/post_test_hook.sh   |   4 +
contrib/ci/pre_test_hook.sh|   5 +
manilaclient/client.py |   2 +-
manilaclient/config.py |  13 +-
manilaclient/httpclient.py |   2 +-
manilaclient/openstack/common/_i18n.py |   4 +-
manilaclient/openstack/common/apiclient/base.py|   2 +-
manilaclient/openstack/common/apiclient/client.py  |   2 +-
manilaclient/openstack/common/apiclient/utils.py   |   2 +-
manilaclient/openstack/common/cliutils.py  |   4 +-
manilaclient/shell.py  |   2 +-
manilaclient/v1/shares.py  |  12 +
manilaclient/v1/shell.py   |  13 +
requirements.txt   |  10 +-
test-requirements.txt  |   2 +-
tox.ini|  10 +-
30 files changed, 1337 insertions(+), 140 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 64a94ff..a6bb4e0 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -6 +6 @@
-pbr>=0.6,!=0.7,<1.0
+pbr>=0.11,<2.0
@@ -10 +10,2 @@ iso8601>=0.1.9
-oslo.config>=1.9.3  # Apache-2.0
+oslo.config>=1.11.0  # Apache-2.0
+oslo.log>=1.0.0  # Apache-2.0
@@ -15 +16 @@ pycrypto>=2.6
-requests>=2.2.0,!=2.4.0
+requests>=2.5.2
@@ -19 +20,2 @@ six>=1.9.0
-python-keystoneclient>=1.1.0
+python-keystoneclient>=1.3.0
+python-openstackclient>=1.0.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 5935882..4c779ed 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -16 +16 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-tempest-lib>=0.4.0
+tempest-lib>=0.5.0

__
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][all] Zaqar will stay... Lots of work ahead

[Ryan Brown]

On 06/01/2015 04:34 AM, Flavio Percoco wrote:
> On 31/05/15 18:12 +, Ildikó Váncsa wrote:
>> Hi All,
>>
>> I would like to ask about the user-facing notifications part of the
>> list. Do you have a roadmap for this? Is this driven by the Zaqar
>> team? What are the next steps?
> 
> Hey,
> 
> This will require cross-project efforts and we (the Zaqar team) would
> love to get some help here. If anyone is willing to drive the spec and
> sync, the Zaqar team would be happy to help with other tasks.
> 
> I think it'd be really beneficial to start doing it in one of the
> services (Heat?) as a PoC, while we discuss the cross-project spec and
> feed it with the things we'll learn from the PoC.
> 
> Would you like to help with this?

Indeed it will require tons of cross-project work. Heat is going to try
to get Zaqar notifications to our users in Liberty, and I've posted
specs for the message format side of the problem[1][2]. There is also a
cross-project spec for user notifications[3].

Heat plans on adopting this format after sufficient review, and we
welcome other projects to look over the format and provide feedback to
help it work for their use case as well.

[1]: https://review.openstack.org/#/c/186436/
[2]: https://review.openstack.org/#/c/186555/
[3]: https://review.openstack.org/#/c/185822/

> ...[snip]...

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

__
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] [release][neutron] python-neutronclient 2.6.0

[Doug Hellmann]

We are thrilled to announce the release of:

python-neutronclient 2.6.0: CLI and Client Library for OpenStack
Networking

With source available at:

http://git.openstack.org/cgit/openstack/python-neutronclient

For more details, please see the git log history below and:

http://launchpad.net/python-neutronclient/+milestone/2.6.0

Please report issues through launchpad:

http://bugs.launchpad.net/python-neutronclient

Changes in python-neutronclient 2.5.0..2.6.0


f62492b Updated from global requirements
9e6977d Allow setting router's external ip(s)
d9113f1 Drop use of 'oslo' namespace package
06a6e4d Updated from global requirements
6190a72 Add functional test for subnet create
5eb292c Fix Python client library for Neutron
d830767 Update README to work with release tools
d75689a Add --binding-profile to port-create
7bc65cb Fix invalid error message in neutron-cli
ae09deb Add basic functional tests for client library

Diffstat (except docs and test files)
-

README.rst | 15 +++-
neutronclient/common/serializer.py |  2 +-
neutronclient/common/utils.py  | 13 +++-
neutronclient/i18n.py  |  2 +-
neutronclient/neutron/v2_0/__init__.py |  6 +-
neutronclient/neutron/v2_0/port.py | 11 ++-
neutronclient/neutron/v2_0/quota.py|  2 +-
neutronclient/neutron/v2_0/router.py   | 18 -
neutronclient/neutron/v2_0/subnet.py   |  2 +-
.../neutron/v2_0/vpn/ipsec_site_connection.py  |  2 +-
neutronclient/shell.py | 17 -
requirements.txt   |  6 +-
test-requirements.txt  |  2 +-
24 files changed, 282 insertions(+), 21 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b7a9ee1..28e9652 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -4 +4 @@
-pbr>=0.6,!=0.7,<1.0
+pbr>=0.11,<2.0
@@ -12,2 +12,2 @@ oslo.utils>=1.4.0   # Apache-2.0
-requests>=2.2.0,!=2.4.0
-python-keystoneclient>=1.1.0
+requests>=2.5.2
+python-keystoneclient>=1.3.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 1c395de..24c84a1 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -19 +19 @@ testtools>=0.9.36,!=1.2.0
-tempest-lib>=0.4.0
+tempest-lib>=0.5.0

__
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] [release][cinder] os-brick 0.2.0

[Doug Hellmann]

We are jubilant to announce the release of:

os-brick 0.2.0: OpenStack Cinder brick library for managing local
volume attaches

With source available at:

http://git.openstack.org/cgit/openstack/os-brick

For more details, please see the git log history below and:

http://launchpad.net/os-brick/+milestone/0.2.0

Please report issues through launchpad:

http://bugs.launchpad.net/os-brick

Changes in os-brick 0.1.0..0.2.0


3433f5d Allow overriding the host field
49c2bdf Assign the platform after declaration
20b9a0e Added a unit test for masking iscsiadm passwords
28f3d09 Preparing for the 0.1.1 release
8e6e07e ISCSI be careful parsing iscsiadm output
418a965 Updated from global requirements
9247aa4 Drop use of 'oslo' namespace package

Diffstat (except docs and test files)
-

os_brick/i18n.py   |  2 +-
os_brick/initiator/connector.py| 23 +--
requirements.txt   | 16 
setup.py   |  8 
test-requirements.txt  |  4 +-
8 files changed, 103 insertions(+), 22 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index 267a4f5..195e6cd 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -5 +5 @@
-pbr>=0.6,!=0.7,<1.0
+pbr>=0.11,<2.0
@@ -7,7 +7,7 @@ Babel>=1.3
-eventlet>=0.16.1,!=0.17.0
-oslo.concurrency>=1.8.0,<1.9.0
-oslo.log>=1.0.0,<1.1.0
-oslo.serialization>=1.4.0,<1.5.0
-oslo.i18n>=1.5.0,<1.6.0
-oslo.utils>=1.4.0,<1.5.0
-retrying>=1.2.3,!=1.3.0
+eventlet>=0.17.3
+oslo.concurrency>=1.8.0 # Apache-2.0
+oslo.log>=1.0.0  # Apache-2.0
+oslo.serialization>=1.4.0   # Apache-2.0
+oslo.i18n>=1.5.0  # Apache-2.0
+oslo.utils>=1.4.0   # Apache-2.0
+retrying>=1.2.3,!=1.3.0 # Apache-2.0
diff --git a/test-requirements.txt b/test-requirements.txt
index ca6ca9a..fd41824 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -10,2 +10,2 @@ sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
-oslosphinx>=2.5.0,<2.6.0
-oslotest>=1.5.1,<1.6.0
+oslosphinx>=2.5.0  # Apache-2.0
+oslotest>=1.5.1  # Apache-2.0

__
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] [release][ironic] python-ironicclient 0.7.0

[Doug Hellmann]

We are thrilled to announce the release of:

python-ironicclient 0.7.0: OpenStack Bare Metal Provisioning API
Client Library

With source available at:

http://git.openstack.org/cgit/openstack/python-ironicclient

For more details, please see the git log history below and:

http://launchpad.net/python-ironicclient/+milestone/0.7.0

Please report issues through launchpad:

http://bugs.launchpad.net/python-ironicclient

Changes in python-ironicclient 0.6.0..0.7.0
---

6e8d761 Disable meaningless sort keys in list command
530baca httpretty can fail in Python 3.4 with wrong LC_ALL
3d66fa1 Add node-show-states command
720effd Updated from global requirements
7bc4afb Revert fix that issues Unauthorized exception
9db3fbf Sync oslo.incubator
8fd2ac3 Consistent and more valid strings for Booleans
d0987b3 Drop use of 'oslo' namespace package
b776e47 Disable invalid sort key in list command
9efabe4 Updated from global requirements
0bb42e9 Add in support for a tox pypy target
cec37d5 Ensure *-show input uuid is not empty
2df670c Remove unneeded 'utf-8' coding lines
26d90b2 Update README to work with release tools

Diffstat (except docs and test files)
-

README.rst |   7 +-
ironicclient/__init__.py   |   2 -
ironicclient/client.py |   2 -
ironicclient/common/base.py|   2 -
ironicclient/common/http.py|   2 -
ironicclient/common/utils.py   |  36 +-
ironicclient/exc.py|  12 -
ironicclient/openstack/common/_i18n.py |  49 +--
ironicclient/openstack/common/apiclient/auth.py|  13 +
ironicclient/openstack/common/apiclient/base.py|  18 +-
ironicclient/openstack/common/apiclient/client.py  |   6 +-
.../openstack/common/apiclient/exceptions.py   |  37 +-
.../openstack/common/apiclient/fake_client.py  |  13 +
ironicclient/openstack/common/apiclient/utils.py   |  17 +-
ironicclient/openstack/common/cliutils.py  | 100 ++---
ironicclient/openstack/common/gettextutils.py  | 413 -
ironicclient/openstack/common/importutils.py   |  67 
ironicclient/openstack/common/strutils.py  | 224 ---
ironicclient/openstack/common/uuidutils.py |  39 --
ironicclient/shell.py  |   8 +-
ironicclient/v1/chassis_shell.py   |  10 +-
ironicclient/v1/client.py  |   2 -
ironicclient/v1/driver.py  |   2 -
ironicclient/v1/driver_shell.py|   2 -
ironicclient/v1/node.py|  50 ++-
ironicclient/v1/node_shell.py  |  44 ++-
ironicclient/v1/port_shell.py  |  12 +-
ironicclient/v1/resource_fields.py |  25 +-
ironicclient/v1/shell.py   |   2 -
openstack-common.conf  |   1 -
requirements.txt   |   4 +-
test-requirements.txt  |   2 +-
tools/install_venv_common.py   |   2 -
tox.ini|   7 +-
51 files changed, 671 insertions(+), 982 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index b837718..2dee54d 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -9 +9 @@ oslo.utils>=1.4.0   # Apache-2.0
-pbr>=0.6,!=0.7,<1.0
+pbr>=0.11,<2.0
@@ -11 +11 @@ PrettyTable>=0.7,<0.8
-python-keystoneclient>=1.1.0
+python-keystoneclient>=1.3.0
diff --git a/test-requirements.txt b/test-requirements.txt
index 57e162e..cacf765 100644
--- a/test-requirements.txt
+++ b/test-requirements.txt
@@ -9 +9 @@ hacking>=0.10.0,<0.11
-httpretty>=0.8.4,!=0.8.7,!=0.8.8
+httpretty>=0.8.4,<0.8.7
__
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] Pre-5.1 and master builds ISO are available for download

[Sergii Golovatiuk]

Hi,

Are we going to add this feature to 7.0? There are some customers who tried
Fuel from nightly or technical previews builds. However, they don't want to
install fuel master node once again. There are several reasons for that. As
a sample it's dev environment, though production environment should be done
with GA code and packages. Though, the customers want to upgrade Fuel
master node to GA. That will allow them to create new environments with GA
code and package base. Also, they will be able to reset environment to
install GA code. How are we going to support such clients?

Thanks,

On Wed, Sep 3, 2014 at 5:37 PM Dmitry Pyzhov  wrote:

> Dmitry,
>
> I totally agree that we should support nightly builds in upgrades. I've
> created a blueprint for this:
> https://blueprints.launchpad.net/fuel/+spec/upgrade-nightly
>
>
> On Tue, Sep 2, 2014 at 3:24 AM, Dmitry Borodaenko <
> dborodae...@mirantis.com> wrote:
>
>> We should not confuse beta and rc builds, normally betas predate RCs and
>> serve a different purpose. In that sense, the nightlies we currently
>> publish are closest to what beta builds should be.
>>
>> As discussed earlier in the thread, we already have full versioning and
>> provenance information in each build, so there is not a lot of value in
>> inventing a parallel versioning scheme just for the time period when our
>> builds are feature complete but not yet stable enough to declare an RC. The
>> only benefit is to explicitly indicate the beta status of these builds, and
>> we can achieve that without messing with versions. For example, by
>> generating a summary table of all community builds that have passed the
>> tests (using same build numbers we already have).
>>
>> Not supporting upgrades from/to intermediate builds is a limitation that
>> we should not discard as inevitable, overcoming it should be in our
>> backlog. Image based provisioning should make it much easier to support.
>>
>> My 2c,
>> -Dmitry
>> I would not use "beta" word anywhere at all. These are nightly builds,
>> pre-5.1. So it will become 5.1 eventually, but for the moment - it is just
>> master branch. We've not even reached HCF.
>>
>> After we reach HCF, we will start calling builds as Release Candidates
>> (RC1, RC2, etc.)  - and QA team runs acceptance testing against them. This
>> can be considered as another name instead of "beta-1", etc.
>>
>> Anyone can go to :8000/api/version to get sha commits of
>> git repos a particular build was created of. Yes, these are development
>> builds, and there will be no upgrade path provided from development build
>> to 5.1 release or any other release. We might want to think about it
>> though, if we could do it in theory, but I confirm what Evgeny says - we do
>> not support it now.
>>
>>
>>
>> On Wed, Aug 27, 2014 at 1:11 PM, Evgeniy L  wrote:
>>
>>> Hi guys, I have to say something about beta releases.
>>>
>>> As far as I know our beta release has the same version
>>> 5.1 as our final release.
>>>
>>> I think this versions should be different, because in case
>>> of some problem it will be much easier to identify what
>>> version we are trying to debug.
>>>
>>> Also from the irc channel I've heard that somebody wanted
>>> to upgrade his system to stable version, right now it's impossible
>>> because upgrade system uses this version for names of
>>> containers/images/temporary directories and we have
>>> validation which prevents the user to run upgrade to the
>>> same version.
>>>
>>> In upgrade script we use python module [1] to compare versions
>>> for validation.
>>> Let me give an example how development versions can look like
>>>
>>> 5.1a1 # alpha
>>> 5.1b1 # beta 1
>>> 5.1b1 # beta 2
>>> 5.1b1 # beta 3
>>> 5.1# final release
>>>
>>> [1]
>>> http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html
>>>
>>> Thanks,
>>>
>>>
>>> On Tue, Aug 26, 2014 at 11:15 AM, Mike Scherbakov <
>>> mscherba...@mirantis.com> wrote:
>>>
 Igor,
 thanks a lot for improving UX over it - this table allows me to see
 which ISO passed verification tests.


 On Mon, Aug 25, 2014 at 7:54 PM, Vladimir Kuklin 
 wrote:

> I would also like to add that you can use our library called devops
> along with system tests we use for QA and CI. These tests use libvirt and
> kvm so that you can easily fire up an environment with specific
> configuration (Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the
> documentation how to use this library is here:
> http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs
> or gaps in documentation, please feel free to file bugs to
> https://launchpad.net/fuel.
>
>
> On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin  > wrote:
>
>> Hi all,
>> along with building your own ISO following instructions [1], you can
>> always download nightly build [2] and run it, by using virtualbox scripts
>> [3], for example.
>

[openstack-dev] [release][barbican] python-barbicanclient 3.2.0

[Doug Hellmann]

We are happy to announce the release of:

python-barbicanclient 3.2.0: Client Library for OpenStack Barbican Key
Management API

With source available at:

http://git.openstack.org/cgit/openstack/python-barbicanclient

For more details, please see the git log history below and:

http://launchpad.net/python-barbicanclient/+milestone/3.2.0

Please report issues through launchpad:

http://bugs.launchpad.net/python-barbicanclient

Changes in python-barbicanclient 3.1.1..3.2.0
-

9f9b326 Drop incubating theme from docs
3d4caaf Remove tempest config dependency in functional tests
240c581 Add capability of specifying Barbican version to client
4c4b8e8 Remove instances of _base_url
2b5bd9e Re-merge CLI test update for auth URL and version
8f1e12e Add CLI smoke functional tests for containers
82daee2 Create behaviors for secrets
70da0d0 Pass in keystone version and correct v2 URL to CLI
b5ef798 Add support for certificate order
b97ea92 Updated from global requirements
282a1e3 Adding new tests to cover failure scenarios
b6d37a2 Drop use of 'oslo' namespace package

Diffstat (except docs and test files)
-

.coveragerc|   2 +-
barbicanclient/barbican.py |   5 +-
barbicanclient/barbican_cli/orders.py  |  40 +-
barbicanclient/base.py |   3 +-
barbicanclient/client.py   |  10 +-
barbicanclient/containers.py   |   8 +-
barbicanclient/orders.py   |  99 +-
.../cli/v1/behaviors/container_behaviors.py|  94 ++
.../cli/v1/behaviors/secret_behaviors.py   | 122 ++
.../client/v1/behaviors/base_behaviors.py  |   2 +-
.../client/v1/functional/test_containers.py|   2 +-
requirements.txt   |   2 +-
30 files changed, 834 insertions(+), 326 deletions(-)


Requirements updates


diff --git a/requirements.txt b/requirements.txt
index cb3a4a5..462fed3 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -4 +4 @@
-pbr>=0.6,!=0.7,<1.0
+pbr>=0.11,<2.0

__
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] [all] Project Team Guide workgroup planning a virtual sprint Jun 18-19

[Thierry Carrez]

Hi everyone,

In an attempt to document shared understandings and "the OpenStack way",
the Technical Committee created a workgroup around the idea of a
"Project Team Guide". This group is however open to anyone who would
like to contribute. The current outline for the guide lives here:

https://etherpad.openstack.org/p/project-team-guide

In order to make fast progress, we plan to hold a virtual sprint on IRC
on June 18-19 where we would focus on writing and reviewing guide
chapters (in the spirit of the infra guide). Let me know if you're
interested to join us then (by adding your name to that etherpad).

Cheers,

-- 
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] [Zaqar][all] Zaqar will stay... Lots of work ahead

[Alex Meade]

There is a spec to get this work started. It's currently a Heat spec:
https://review.openstack.org/#/c/186436/

That spec is for defining a basic schema to start with.

-Alex

On Mon, Jun 1, 2015 at 4:48 AM, Flavio Percoco  wrote:

> On 28/05/15 16:48 +0100, Gordon Sim wrote:
>
>> On 05/27/2015 05:08 PM, Hayes, Graham wrote:
>>
>>> It was agreed that Zaqar would look at a oslo_messaging driver for the
>>> services that did not agree with the 3 options presented.
>>>
>>
>> Another option there would be to add amqp 1.0 support to zaqar, and then
>> you could use the amqp 1.0 driver with zaqar as the back-end.
>>
>> (Support for an existing protocol would be beneficial for the general
>> messaging as a service use case also.)
>>
>
> FWIW, this is still in the long-term roadmap for Zaqar. This is
> something we looked into a couple of cycles ago that we'd love to get
> done.
>
> I do think an AMQP *1.0* would help with some use cases.
>
> Cheers,
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

[Jay Pipes]

On 05/31/2015 05:38 PM, Jay Lau wrote:

Just want to use ML to trigger more discussion here. There are now
bugs/patches tracing this, but seems more discussions are needed before
we come to a conclusion.

https://bugs.launchpad.net/magnum/+bug/1453732
https://review.openstack.org/#/c/181839/
https://review.openstack.org/#/c/181837/
https://review.openstack.org/#/c/181847/
https://review.openstack.org/#/c/181843/

IMHO, making the Bay/Baymodel name as a MUST will bring more flexibility
to end user as Magnum also support operating Bay/Baymodel via names and
the name might be more meaningful to end users.

Perhaps we can borrow some iead from nova, the concept in magnum can be
mapped to nova as following:

1) instance => bay
2) flavor => baymodel

So I think that a solution might be as following:
1) Make name as a MUST for both bay/baymodel
2) Update magnum client to use following style for bay-create and
baymodel-create: DO NOT add "--name" option


You should decide whether name would be unique -- either globally or 
within a tenant.


Note that Nova's instance names (the display_name model field) are *not* 
unique, neither globally nor within a tenant. I personally believe this 
was a mistake.


The decision affects your data model and constraints.

Best,
-jay

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

Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance

[Jay Pipes]

On 06/01/2015 08:30 AM, John Garbutt wrote:

On 1 June 2015 at 13:10, Flavio Percoco  wrote:

On 01/06/15 11:57 +0100, John Garbutt wrote:

On 26/05/15 13:54 -0400, Nikhil Komawar wrote:

FWIW, moving Nova from glance v1 to glance v2, without breaking Nova's
public API, will require someone getting a big chunk of glance v1 on
top of glance v2.


AFAIK, the biggest issue right now is "changed-since" which is
something Glance doesn't have in v2 but it's exposed throught Nova's
image API.


Thats the big unanswered question that needs fixing in any spec we
would approve around this effort.


I'm happy you brought this up. What are Nova's plans to adopt Glance's
v2 ? I heard there was a discussion and something along the lines of
creating a library that wraps both APIs came up.


We don't have anyone who has stepped up to work on it at his point.

I think the push you made around this effort in kilo is the latest
updated on this:
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/remove-glanceclient-wrapper.html

It would be great if we could find a glance/nova CPL to drive this effort.


I am happy to take the lead on this from the Nova side. I'm familiar 
with the code in Nova.



I really think nova should put some more effort on helping this
happen. The work I did[0] - all red now, I swear it wasn't - during
Kilo didn't get enough attention even before we decided to push it
back. Not a complain, really. However, I'd love to see some
cross-project efforts on making this happen.
[0] https://review.openstack.org/#/c/144875/


As there is no one to work on the effort, we haven't made it a
priority for liberty.


It's not a huge amount of work. I can do it.


If someone is able to step up to help complete the work, I can do my
best to help get that effort reviewed, by raising its priority, just
as we did in Kilo.

I suspect looking at how to slowly move towards v2, rather than going
for a "big bang" approach, will make this easier to land. That and
solving how we implement "changed-since", if thats not available in
the newer glance APIs. Honestly, part of me wonders about skipping v2,
and going straight to v3.


We actually already support Glance V2 in some things. It shouldn't be 
too difficult to complete the work to fully support V2.


Please assign me as the CPL for Glance from Nova.

Best,
-jay

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

Re: [openstack-dev] [cinder] Some Changes to Cinder Core

[Tom Barron]

Well deserved, and hope you had a nice break.


__
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

[Sean McGinnis]

Finally back after a few days offline. Thanks everyone. Just glad to be 
part of this great group. Thank you for all the positive comments from 
cores and non-cores alike.


Sean

On 05/26/2015 04:42 PM, Ivan Kolodyazhny wrote:

+1,

Welcome to the team, Sean.

Regards,
Ivan Kolodyazhny


On Wed, May 27, 2015 at 12:07 AM, John Griffith 
mailto:john.griffi...@gmail.com>> wrote:




On Fri, May 22, 2015 at 5:34 PM, Mike Perez mailto:thin...@gmail.com>> 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

​
+1​


__
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] [nova] Progressing/tracking work on libvirt / vif drivers

[Daniel P. Berrange]

On Mon, Jun 01, 2015 at 09:44:24AM +0100, John Garbutt wrote:
> On 29 May 2015 at 18:32, Neil Jerram  wrote:
> > Hi all,
> >
> > Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work is
> > being somewhat driven by the etherpad at [2].  But this etherpad doesn't
> > have a section for libvirt / vif driver changes.  The log at [1] briefly
> > touched on this, but moved on after noting that Dan PB had disbanded a
> > libvirt subteam for lack of interest.
> 
> Apologies, I am not nearly half way through writing up all that came
> out of the summit. A few nasty bugs in production kept me occupied
> last week, but I have got out of that now / fixed them, I hope.
> 
> In the design summit session we said any group of people can
> self-organise and start proposing patches as "ready to merge" by that
> sub team, in here:
> https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
> 
> We agreed that if there were too many sub teams, we would ask the
> teams to join together. And I hope some subteams find each other on
> that etherpad, and organically decide its best to join forces.
> 
> While we have established patterns of successful sub team
> collaborations (IRC meetings, bug tags, etc), feel free to do whatever
> works, assuming its aligned with the Open nature of our community
> (i.e. I expect code reviews to be done in gerrit, not using some
> internal communication channel. Even if you review face to face, I
> would appreciate you writing up the outcome in gerrit).
> 
> > So, what should folk interested in libvirt / vif work (including me) now do?
> > I think the answer is that we should self-organize, then report to the next
> > IRC on how we've done that, and I'm happy to lead that if no one else wants
> > to - but is there someone else who should or wants to own this?
> 
> In summary, yes please, sounds good.
> 
> I would reach out to Dan, and the other folks who were active in those
> meetings, to see how it best makes sense to collaborate. Let me know
> if I can help connect you folks, but IRC usually works.

I'm mostly just lurking on IRC but keep an eye out on this mailing list
for anything tagged with [nova]. So if there's any times my input is
needed I should catch the mails as long as they're on the list.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] [release] WSME 0.7.0

[Doug Hellmann]

We are jubilant to announce the release of:

wsme 0.7.0: Simplify the writing of REST APIs, and extend them with
additional protocols.

With source available at:

http://git.openstack.org/cgit/stackforge/wsme

For more details, please see the git log history below and:

https://launchpad.net/wsme/+bugs/+milestone/0.7.0

Please report issues through launchpad:

https://bugs.launchpad.net/wsme/+bugs

Changes in WSME 0.6.4..0.7.0


9b3e71e Add instructions to configure cornice with WSME
002473c Move ipaddr to netaddr
d60de97 Add pytz as a dependency.
a88c830 Fix wrong reference to status argument in the docs
3ea152c Added timezone support to parse_isodatetime
32456d3 Replace deprecated assertEquals with assertEqual
7379a3a Update changes doc
d2f8f8f Ensure UserType objects are converted to basetype
9a0d3c1 Convert built-in types when passed as strings
78d6b89 Enable real testing of python 3.4
e31045e Multiple protocol accept or content-type matching
f66cf4c Raise an InvalidInput if you get a ValueError from JSON data.
8d9f82d Return a 400 status code on invalid JSON input
b4e918b Remove unsupported python versions from setup.cfg
34f325a Clean up setup.py and add requirements.txt
5874aa6 Remove tab character from setup.cfg
f6602e7 Add full MIT license
81afe37 Fix i18n when formatting exception
c4d3986 Converts prints to logging.debug calls
94cd175 Change client-side error logging to debug
de877d2 Pecan: Make it possible to use the Response to return a non-default 
return type
80e0c2a Fixing spelling error on MIME Type Errors and PEP8
8710dab Improve Accept and Content-Type handling
bad1c3e Fix pep8 w503 errors
da67a34 Correct pep8 errors from imports in weird places.
b4ef065 several fixes for SOAP protocol
1ecf647 [doc] Update changes list
d34eb82 Fix validation of IPv{4,6}AddressType
5de10ea Fix printing object reference on StringType

Diffstat (except docs and test files)
-

LICENSE  |  20 +-
requirements-py3.txt |   5 +
requirements.txt |   5 +
setup.cfg|   6 +-
setup.py |  27 +-
tox-tmpl.ini | 111 +---
tox.ini  | 736 +--
wsme/api.py  |  25 +-
wsme/protocol.py |  34 ++
wsme/rest/args.py|   2 +-
wsme/rest/json.py|  53 +-
wsme/rest/protocol.py|   9 +-
wsme/root.py |  42 +-
wsme/types.py|  26 +-
wsme/utils.py|  24 +-
wsmeext/pecan.py |  17 +-
wsmeext/soap/protocol.py |  12 +-
wsmeext/soap/wsdl.py |   6 +-
wsmeext/sphinxext.py |  10 +-
wsmeext/tg1.py   |   6 +-
38 files changed, 1021 insertions(+), 934 deletions(-)


Requirements updates


diff --git a/requirements-py3.txt b/requirements-py3.txt
new file mode 100644
index 000..d15bd16
--- /dev/null
+++ b/requirements-py3.txt
@@ -0,0 +1,5 @@
+six>=1.9.0
+WebOb>=1.2.3
+simplegeneric
+pytz
+netaddr>=0.7.12
diff --git a/requirements.txt b/requirements.txt
new file mode 100644
index 000..d15bd16
--- /dev/null
+++ b/requirements.txt
@@ -0,0 +1,5 @@
+six>=1.9.0
+WebOb>=1.2.3
+simplegeneric
+pytz
+netaddr>=0.7.12
__
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] I think nova behaves poorly when booting multiple instances

[Andrew Laski]

On 05/27/15 at 07:38pm, Chris Friesen wrote:

On 05/27/2015 05:09 PM, Fox, Kevin M wrote:

If the current behavior is broken, and the behavior is causing problems with
things like fixing quota's, should it just be deprecated and pushed off to
orchestration rather then change it?


Is this causing problems with quotas?  The problem I brought up isn't 
with quotas but rather with all the instances being set to an error 
state when we could have actually booted up a bunch of them.


In any case, even if we wanted to deprecate it (and I think an 
argument could be made for that) we still have to decide what the 
"correct" behaviour should be for the API as it exists today.  In my 
view the current behaviour doesn't match what a reasonable person 
would expect given the description of the "min count" and "max count" 
parameters.


I'm +1 on fixing the behavior here.  As many instances as can be booted 
should be, despite part of the initial block failing.  The only reason I 
can think of for failing all of them is if you want to consider the 
request as a single operation that can either fail or succeed.  But that 
would be better handled outside of Nova with some orchestration IMO.  
But we should get some feedback from the EC2 API folks as to what kind 
of contract it needs to provide and ways for them to achieve that.


I'm also in favor of deprecating these parameters, or moving this 
functionality into a separate API if it must be kept for EC2.  However 
what these parameters give users, versus orchestrating outside of Nova, 
is the ability to have the instances all scheduled as a single block.  
Outside of it being a performance optimization I think there's minimal 
value in this, but it's there and should be kept in mind since removing 
it may affect certain use cases.




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


__
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

[Damon Wang]

Thanks! I'll reconsider about this.

2015-06-01 16:54 GMT+08:00 Kevin Benton :

> >But I don't know that does NAK matters?
>
> Yes, some clients will honor it and re-request, so they end up in a loop.
> I believe the dhcp client in the Cirros image does this.
>
> >"dhcp-authoritative" is really a simple way to solve the problem of that
> dnsmasq will lose lease if restarted
>
> Yes, unfortunately it made dnsmasq behave authoritatively though. :-) The
> patch that merged should fix the NAK issue and the lease lost on restart
> issue.
>
> On Mon, Jun 1, 2015 at 1:47 AM, Damon Wang  wrote:
>
>> Hi Benton,
>>
>> I'm sorry that seems I missed your discuss. I just seen your patch's
>> merge yesterday.
>>
>> But I don't know that does NAK matters? A client will get a ACK and a NAK
>> if there are two agents, it's ok because client will assign IP address
>> successfully according to the ACK.
>>
>> "dhcp-authoritative" is really a simple way to solve the problem of that
>> dnsmasq will lose lease if restarted, and we have put this patch to our
>> production (public cloud), it works well.
>>
>> Thanks!
>> Wei
>>
>> 2015-05-28 6:39 GMT+08:00 Kevin Benton :
>>
>>> >Looking at [1], I don't see that it generates a script at all. What it does
>>> is it prepopulates a lease file for dnsmasq consumption (so there is no
>>> external shell involved). Do we talk about the same patch?
>>>
>>> Not that patch. In the first email, I mentioned 3 approaches: iptables,
>>> lease db generation, and script generation. I didn't put something up for
>>> script generation because it was basically the same thing is the lease db
>>> generation with an echo statement at the top.
>>>
>>> I was just pointing out that the script approach I was using was
>>> suggesting was quite different from the other one up for review. But it
>>> doesn't really matter because the lease DB is the easy way to go.
>>>
>>>
>>> On Wed, May 27, 2015 at 4:57 AM, Ihar Hrachyshka 
>>> wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 05/26/2015 11:53 PM, Kevin Benton wrote:
 >> Actually, that approach was initially taken for bug 1345947, but
 > then the patch was abandoned to be replaced with a simpler -
 > --dhcp-authoritative approach that ended up with unexpected NAKs
 > for multi agent setup.
 >
 >> See: https://review.openstack.org/#/c/108272/12
 >
 > So I had seen that patch but it's quite different from the approach
 > I was taking. That one requires a new script in the 'bin'
 > directory, a new entry in setup.cfg, an a new dhcp filter entry for
 > rootwrap. Is that something you would be comfortable back-porting
 > all of the way back to Icehouse?

 I agree that a patch without a new script and, more importantly,
 without a rootwrap filter modification, is a lot better than the one I
 cited above.

 >
 > The approach I was using was to generate the script at runtime in
 > the data directory for each instance to just return the addresses
 > directly. That way there are no setup changes or new entries in
 > bin. Personally, I felt it was easier to understand since it simply
 > generated a big echo statement, but I might be biased because I
 > wrote it. :)
 >

 Looking at [1], I don't see that it generates a script at all. What it
 does is it prepopulates a lease file for dnsmasq consumption (so there
 is no external shell involved). Do we talk about the same patch?

 I've checked [1], and it seems like the best approach, both from code
 complexity and "backportability" perspective. I've left some comments
 there.

 [1]: https://review.openstack.org/#/c/185486/

 Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBCAAGBQJVZbE8AAoJEC5aWaUY1u57ufkH/RfsQJy+Ddz3f+L37mNY28uj
 h+gLaiJIcZ1iMKKMo1tpg881u/aKpy3LlScoKHLnwWXub/IPxrxN2+/IMfCoF9iV
 ZbgtmggVRh/TjHOMbMpQVqJ+J8qe4TN29kW5x1RcUEecYy/hbyyKeBYoLlEXoZhn
 GzWcWyx9yp2qSOqe9010K+nmXdAzD+jg8/YJlBtP/ggO0qoWB7Is/D2bHkoeCPsd
 uqJzhAAZg4w2hhPgKpb1aUhyQU9uE5gzj5Yh5PE+kvINDRwLTLoqWQ7sxpR1hiqH
 rZ8t8FE1wmdQKEWrsRVy6/2pLOziKVNGPinBLYwwBUGY+S7kb2Jc6AgAHrAx/iY=
 =Wnx+
 -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

>>>
>>>
>>>
>>> --
>>> 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] [nova] Progressing/tracking work on libvirt / vif drivers

[Daniel P. Berrange]

On Fri, May 29, 2015 at 06:32:18PM +0100, Neil Jerram wrote:
> Hi all,
> 
> Per yesterday's IRC meeting [1], and discussion in Vancouver, Nova work is
> being somewhat driven by the etherpad at [2].  But this etherpad doesn't
> have a section for libvirt / vif driver changes.  The log at [1] briefly
> touched on this, but moved on after noting that Dan PB had disbanded a
> libvirt subteam for lack of interest.
> 
> So, what should folk interested in libvirt / vif work (including me) now do?
> I think the answer is that we should self-organize, then report to the next
> IRC on how we've done that, and I'm happy to lead that if no one else wants
> to - but is there someone else who should or wants to own this?

I'm of a mindset that aims to avoid creating rules & bureaucracy, so don't
feel you need to get permission to form a special interest group to work on
the libvirt VIF drivers. Any group of interested devs should just collaborate
and divide work up between themselves. I just strongly suggest that you
work to keep any design / technical discussions in public forums. ie have
your email discussions on this openstack-dev mailing list or #nova IRC, and
not in private CC'd email threads between the special interest team. This
ensures that anyone with interest can watch what's going on, without having
to formally join any team.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] [mistral] Team meeting - 2015/06/01

[Renat Akhmerov]

Hi Mistral team,

This is just a reminder that we’ll have a team meeting today at 
#openstack-meeting at 16.00 UTC (not 16.20 like it was during a couple of 
months!)

Agenda:
Review action items
Current status (progress, issues, roadblocks, further plans)
Liberty Roadmap
Add seconds granularity in cron-trigger execute 

Open discussion

If you have topics to discuss please add them at the meeting agenda page at 
https://wiki.openstack.org/wiki/Meetings/MistralAgenda#Agenda 
.

Renat Akhmerov
@ Mirantis Inc.



__
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] [all] Liberty summit: Updates in Glance

[Flavio Percoco]

On 01/06/15 13:30 +0100, John Garbutt wrote:

On 1 June 2015 at 13:10, Flavio Percoco  wrote:

On 01/06/15 11:57 +0100, John Garbutt wrote:


On 26/05/15 13:54 -0400, Nikhil Komawar wrote:


On 5/26/15 12:57 PM, Jesse Cook wrote:
   We also had some hallway talk about putting the v1 and v2 APIs on top
of
   the v3 API. This forces faster adoption, verifies supportability via
v1
and
   v2 tests, increases supportability of v1 and v2 APIs, and pushes out
the
   need to kill v1 API.

Let's discuss more as time and development progresses on that
possibility.
v3
API should stay EXPERIMENTAL for now as that would help us understand
use-cases
across programs as it gets adopted by various code-bases. Putting v1/v2
on
top
of v3 would be tricky for now as we may have breaking changes with code
being
relatively-less stable due to narrow review domain.




I actually think we'd benefit more from having V2 on top of V3 than
not doing it. I'd probably advocate to make this M material rather
than L but I think it'd be good.

I think regardless of what we do, I'd like to kill v1 as it has a
sharing model that is not secure.



Given v1 has lots of users, killing it will be hard.

If you maintained v1 support as v1 on top of v3 (or v2 I guess), could
you not do something like permanently disable the "bad bits" of the
API?


I agree it'll be hard but, at least for v1, I believe it should
happen. It has some security issues (mostly related to image sharing)
that are not going to be fixed there.


OK, I guess you mean this one:
https://wiki.openstack.org/wiki/OSSN/1226078


The idea being, users listing their images, and updating image
metadata via v1, don't get broken during the evolution?


The feedback we got at the summit (even from OPs) was that we could go
ahead, mark it as deprecated, give a deprecation period and then turn
it off.


I am surprised by that reply, but OK.


FWIW, moving Nova from glance v1 to glance v2, without breaking Nova's
public API, will require someone getting a big chunk of glance v1 on
top of glance v2.


AFAIK, the biggest issue right now is "changed-since" which is
something Glance doesn't have in v2 but it's exposed throught Nova's
image API.


Thats the big unanswered question that needs fixing in any spec we
would approve around this effort.


I don't have an answer myself right now.




I'm happy you brought this up. What are Nova's plans to adopt Glance's
v2 ? I heard there was a discussion and something along the lines of
creating a library that wraps both APIs came up.


We don't have anyone who has stepped up to work on it at his point.

I think the push you made around this effort in kilo is the latest
updated on this:
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/remove-glanceclient-wrapper.html

It would be great if we could find a glance/nova CPL to drive this effort.


So, unless the library is proposed and some magic happens, is it safe
to assume that the above spec is still valid and that folks can work
on it?




Where can I find more info about this?


I suspect it will be included on our liberty priority TODO list, that
I am yet to write, but I expect to appear here:
http://specs.openstack.org/openstack/nova-specs/


I really think nova should put some more effort on helping this
happen. The work I did[0] - all red now, I swear it wasn't - during
Kilo didn't get enough attention even before we decided to push it
back. Not a complain, really. However, I'd love to see some
cross-project efforts on making this happen.
[0] https://review.openstack.org/#/c/144875/


As there is no one to work on the effort, we haven't made it a
priority for liberty.

If someone is able to step up to help complete the work, I can do my
best to help get that effort reviewed, by raising its priority, just
as we did in Kilo.


IIRC, the patch wasn't far from being ready. The latest patch-sets
relied on the gate to run some tests and the biggest issue I had -
still have - is that this script[0] didn't even use glanceclient but
direct http calls. The issue, to be precises, is that I didn't have
ways to test it locally, which made the work painful.

If there's a way to do it - something that has already being asked -
it'd be great.

This said, I'm not sure how much time I'll have for this but I'm
trying to find someone that could help out.

https://review.openstack.org/#/c/144875/30/plugins/xenserver/xenapi/etc/xapi.d/plugins/glance,cm



I suspect looking at how to slowly move towards v2, rather than going
for a "big bang" approach, will make this easier to land. That and
solving how we implement "changed-since", if thats not available in
the newer glance APIs. Honestly, part of me wonders about skipping v2,
and going straight to v3.


Regardless, I think we should enable people to run on a v2 only
deployment. Not a crazy thought, I think. We'll have to think this
through a bit more.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


pgpskjVyn6vqX.pgp
Description: PGP signature
_

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

[Ed Leafe]

On Jun 1, 2015, at 7:49 AM, Sylvain Bauza  wrote:

> Long story short :
> https://blueprints.launchpad.net/nova/+spec/resource-objects
> 
> Until we get this, it's difficult to discuss on different resources within 
> Nova. Let's work by small steps and provide a versioned resource system 
> before discussing on how other projects could add more resources to Nova.

Yes, this is important in making it possible to transition to a different model 
in an organized way. I just wanted to start the discussion on what that new 
model might look like.


-- Ed Leafe







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