Re: [openstack-dev] [nova] is it possible to microversion a static class method?

[Chris Friesen]

On 03/12/2015 12:13 PM, Sean Dague wrote:

On 03/12/2015 02:03 PM, Chris Friesen wrote:

Hi,

I'm having an issue with microversions.

The api_version() code has a comment saying "This decorator MUST appear
first (the outermost decorator) on an API method for it to work correctly"

I tried making a microversioned static class method like this:

 @wsgi.Controller.api_version("2.4")  # noqa
 @staticmethod
 def _my_func(req, foo):

and pycharm highlighted the api_version decorator and complained that
"This decorator will not receive a callable it may expect; the built-in
decorator returns a special object."

Is this a spurious warning from pycharm?  The pep8 checks don't complain.

If I don't make it static, then pycharm suggests that the method could
be static.


*API method*

This is not intended for use by methods below the top controller level.
If you want conditionals lower down in your call stack pull the request
version out yourself and use that.


Both the original spec and doc/source/devref/api_microversions.rst contain text 
talking about decorating a private method.  The latter gives this example:


@api_version("2.1", "2.4")
def _version_specific_func(self, req, arg1):
pass

@api_version(min_version="2.5") #noqa
def _version_specific_func(self, req, arg1):
pass

def show(self, req, id):
 common stuff 
self._version_specific_func(req, "foo")
 common stuff 

It's entirely possible that such a private method might not need to reference 
"self", and could therefore be static, so I think it's a valid question.


Chris

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

Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

[Zhi Yan Liu]

I'd prefer 1400UTC.

zhiyan

On Mon, Mar 9, 2015 at 4:07 AM, Nikhil Komawar
 wrote:
>
> Hi all,
>
>
> Currently, we've alternating time for Glance meetings. Now, with the
> Daylight savings being implemented in some parts of the world, we're
> thinking of moving the meeting time to just one slot i.e. earlier in the
> day(night). This solves the original conflicting times issue that a subset
> of the individuals had; to add to that the schedule is less confusing and
> unified.
>
>
> So, the new proposal is:
>
> Glance meetings [1] to be conducted weekly on Thursdays at 1400UTC [2] on
> #openstack-meeting-4
>
>
> This would be implemented on Mar 19th, given there are no major objections.
>
>
> Please vote with +1/-1 here.
>
>
> [1] https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting
>
> [2] http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0
>
>
> Thanks,
> -Nikhil
>
> __
> OpenStack Development Mailing 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] A question on static routes on Neutron router

[Maria Napierala]

> 
> 
> 
> Yes, the extra routes extension allows IP addresses from any of the 
networks connected to the router.
> I see in the code that send_redirects is set to 0 so it will not generate 
ICMP redirect messages in the case you mentioned. I don't see anything 
obviously preventing the forwarding to a next hop on the same subnet, but 
you would have to try it out to be 100% sure.
> 
> 
> On Thu, Mar 12, 2015 at 5:25 PM, NAPIERALA, MARIA H  wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> Can a static/extra route on Neutron router point to an internal/tenant 
subnet interface as the next-hop?  
> If yes, can Neutron router forward packets received from a host on an 
attached subnet and matching on a configured static route back to the same 
subnet (to a different host)?
>  
> Appreciate the help answering the questions.
> 
>  
> Maria 
>  
>  
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request-
ZwoEplunGu0gQVYkTtqAhA@public.gmane.orgorg?
subject:unsubscribehttp://lists.openstack.org/cgi-
bin/mailman/listinfo/openstack-dev
> 
> 
> -- Kevin Benton
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request@...?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
Thanks much for the reply. I have looked at the code for the extra route 
extension and there was nothing preventing the static route next-hop to be 
on an internal subnet. However, all the discussion or expamples I found 
were about the external subnets. So, I wanted to make sure.. I guess this 
is probably where it is pimarily being used.

Regarding the second question, at least the router should not send ICMP 
redirect (thanks for pointing it out). I will try it.

Maria



__
OpenStack Development Mailing 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] Generic question about synchronizing neutron agent on compute node with DB

[Kevin Benton]

Yeah, I was making a bad assumption for the l2 and l3. Sorry about that. It
sounds like we don't have any protection against servers failing to send
notifications.
On Mar 12, 2015 7:41 PM, "Assaf Muller"  wrote:

>
>
> - Original Message -
> > > However, I briefly looked through the L2 agent code and didn't see a
> > > periodic task to resync the port information to protect from a neutron
> > > server that failed to send a notification because it crashed or lost
> its
> > > amqp connection. The L3 agent has a period sync routers task that
> helps in
> > > this regard.
>
> The L3 agent periodic sync is only if the full_sync flag was turned on,
> which
> is a result of an error.
>
> > > Maybe another neutron developer more familiar with the L2
> > > agent can chime in here if I'm missing anything.
> >
> > i don't think you are missing anything.
> > periodic sync would be a good improvement.
> >
> > YAMAMAOTO Takashi
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing 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] Generic question about synchronizing neutron agent on compute node with DB

[Assaf Muller]

- Original Message -
> > However, I briefly looked through the L2 agent code and didn't see a
> > periodic task to resync the port information to protect from a neutron
> > server that failed to send a notification because it crashed or lost its
> > amqp connection. The L3 agent has a period sync routers task that helps in
> > this regard.

The L3 agent periodic sync is only if the full_sync flag was turned on, which
is a result of an error.

> > Maybe another neutron developer more familiar with the L2
> > agent can chime in here if I'm missing anything.
> 
> i don't think you are missing anything.
> periodic sync would be a good improvement.
> 
> YAMAMAOTO Takashi
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing 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] Generic question about synchronizing neutron agent on compute node with DB

[YAMAMOTO Takashi]

> However, I briefly looked through the L2 agent code and didn't see a
> periodic task to resync the port information to protect from a neutron
> server that failed to send a notification because it crashed or lost its
> amqp connection. The L3 agent has a period sync routers task that helps in
> this regard. Maybe another neutron developer more familiar with the L2
> agent can chime in here if I'm missing anything.

i don't think you are missing anything.
periodic sync would be a good improvement.

YAMAMAOTO Takashi

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

Re: [openstack-dev] A question on static routes on Neutron router

[Kevin Benton]

Yes, the extra routes extension allows IP addresses from any of the
networks connected to the router.

I see in the code that send_redirects is set to 0 so it will not generate
ICMP redirect messages in the case you mentioned. I don't see anything
obviously preventing the forwarding to a next hop on the same subnet, but
you would have to try it out to be 100% sure.

On Thu, Mar 12, 2015 at 5:25 PM, NAPIERALA, MARIA H  wrote:

>  Can a static/extra route on Neutron router point to an internal/tenant
> subnet interface as the next-hop?
> If yes, can Neutron router forward packets received from a host on an
> attached subnet and matching on a configured static route back to the same
> subnet (to a different host)?
>
> Appreciate the help answering the questions.
>
> Maria
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB

[Kevin Benton]

If there are any errors on the agent connecting to the message bus or
retrieving messages, an exception will be thrown in the main rpc_loop,
which will be caught and a sync flag will be set to true, which will
trigger the sync on the next loop.

However, I briefly looked through the L2 agent code and didn't see a
periodic task to resync the port information to protect from a neutron
server that failed to send a notification because it crashed or lost its
amqp connection. The L3 agent has a period sync routers task that helps in
this regard. Maybe another neutron developer more familiar with the L2
agent can chime in here if I'm missing anything.

On Thu, Mar 12, 2015 at 6:19 AM, Leo Y  wrote:

> What does it mean under "if that notification is lost, the agent will
> eventually resynchronize"? Is it proven/guaranteed? By what means?
> Can you, please the process with more details? Or point me to resources
> that describe it.
>
> Thank you
>
>
> On Mon, Mar 9, 2015 at 2:11 AM, Kevin Benton  wrote:
>
>> Port changes will result in an update message being sent on the AMQP
>> message bus. When the agent receives it, it will affect the communications
>> then. If that notification is lost, the agent will eventually resynchronize.
>>
>> So during normal operations, the change should take effect within a few
>> seconds.
>>
>> On Sat, Mar 7, 2015 at 4:10 AM, Leo Y  wrote:
>>
>>> Hello,
>>>
>>> What happens when neutron DB is updated to change network settings (e.g.
>>> via Dashboard or manually) when there are communication sessions opened in
>>> compute nodes. Does it influence those sessions? When the update is
>>> propagated to compute nodes?
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>> 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
>>
>>
>
>
> --
> Regards,
> Leo
> -
> I enjoy the massacre of ads. This sentence will slaughter ads without a
> messy bloodbath
>
> __
> OpenStack Development Mailing 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] is it possible to microversion a static class method?

[Alex Xu]

2015-03-13 2:13 GMT+08:00 Sean Dague :

> On 03/12/2015 02:03 PM, Chris Friesen wrote:
> > Hi,
> >
> > I'm having an issue with microversions.
> >
> > The api_version() code has a comment saying "This decorator MUST appear
> > first (the outermost decorator) on an API method for it to work
> correctly"
> >
> > I tried making a microversioned static class method like this:
> >
> > @wsgi.Controller.api_version("2.4")  # noqa
> > @staticmethod
> > def _my_func(req, foo):
> >
> > and pycharm highlighted the api_version decorator and complained that
> > "This decorator will not receive a callable it may expect; the built-in
> > decorator returns a special object."
> >
> > Is this a spurious warning from pycharm?  The pep8 checks don't complain.
> >
> > If I don't make it static, then pycharm suggests that the method could
> > be static.
>
> *API method*
>
> This is not intended for use by methods below the top controller level.
> If you want conditionals lower down in your call stack pull the request
> version out yourself and use that.
>

++


>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing 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] [openstack-operators][rally] What's new in Rally v0.0.2

[Yingjun Li]

Nice!

> On Mar 13, 2015, at 1:03 AM, Boris Pavlovic  wrote:
> 
> Hi stackers, 
> 
> For those who doesn't know Rally team started making releases. 
> 
> There are 3 major reasons why we started doing releases: 
> 
>  * A lot of people started using Rally in their CI/CD. 
> 
> Usually they don't like to depend on something that is from master.
> And would like to have smooth testable upgrades between versions 
> 
>  * Rally is used in gates of many projects. 
> 
> As far as you know in Rally everything is plugable. These plugins can be
> put  in project tree. This is nice flexibility for all projects. But it 
> blocks a lot
>development of Rally. To resolve this issue we are going to allow projects 
> t
>specify which version of Rally to run in their trees. This resolves 2 
> issues:
>1) projects gates won't depend on Rally master 
>2) projects have smooth, no downtime, testable way to switch to newer
>version of Rally 
> 
>  * Release notes - as a simple way to track project changes. 
> 
> 
> 
> Release stats: 
> +--+-+
> | Commits  | **100** |
> +--+-+
> | Bug fixes| **18**  |
> +--+-+
> | Dev cycle|   **45 days**   |
> +--+-+
> | Release date | **12/Mar/2015** |
> +--+-+
> 
> 
> Release notes: 
> 
> https://rally.readthedocs.org/en/latest/release_notes/v0.0.2.html 
> 
> 
> 
> Pypi:
> 
> https://pypi.python.org/pypi/rally/0.0.2 
> 
> 
> 
> Future goals: 
> 
> Our goal is to cut releases ever 2 weeks.  As far as project is quite bugless 
> and stable we don't need feature freeze at all, so I don't think that it will 
> be hard to achieve this goal.  
> 
> 
> Best regards,
> Boris Pavlovic 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] proposing rameshg87 to ironic-core

[Tan, Lin]

Congratulations Ramesh

B.R

Tan

From: Devananda van der Veen [mailto:devananda@gmail.com]
Sent: Friday, March 13, 2015 12:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ironic] proposing rameshg87 to ironic-core

Without further ado, and since everyone (even though some haven't replied here) 
has +1'd this, and since we could really use ramesh's +2's in the run up to 
Kilo-3 and feature freeze, even without the customary waiting/voting period 
being completely satisfied (after all, when we all agree, why wait a week?), 
I'd like to officially welcome him to the core team.

-Devananda

On Tue, Mar 10, 2015 at 10:03 AM David Shrewsbury 
mailto:shrewsbury.d...@gmail.com>> wrote:
+1

On Mar 9, 2015, at 6:03 PM, Devananda van der Veen 
mailto:devananda@gmail.com>> wrote:

Hi all,

I'd like to propose adding Ramakrishnan (rameshg87) to ironic-core.

He's been consistently providing good code reviews, and been in the top five 
active reviewers for the last 90 days and top 10 for the last 180 days. Two 
cores have recently approached me to let me know that they, too, find his 
reviews valuable.

Furthermore, Ramakrishnan has made significant code contributions to Ironic 
over the last year. While working primarily on the iLO driver, he has also done 
a lot of refactoring of the core code, touched on several other drivers, and 
maintains the proliantutils library on stackforge. All in all, I feel this 
demonstrates a good and growing knowledge of the codebase and architecture of 
our project, and feel he'd be a valuable member of the core team.

Stats, for those that want them, are below the break.

Best Regards,
Devananda



http://stackalytics.com/?release=all&module=ironic-group&user_id=rameshg87

http://russellbryant.net/openstack-stats/ironic-reviewers-90.txt
http://russellbryant.net/openstack-stats/ironic-reviewers-180.txt
__
OpenStack Development Mailing 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] Deprecation warnings considered harmful?

[Nikhil Manchanda]

Looking back at the meeting eavesdrop, the primary reasons why we
deferred this work to Liberty was twofold:

- It wasn't a set plan based on information available to us at the time.
This being the case, we decided to wait until we had more information
regarding the requirements around this from oslo.

- We wanted to ensure that we had a corresponding hacking rule in
place to prevent future patch-sets from using the deprecated module
names.

We specifically didn't consider the impact of logging statements with
deprecation warnings at the meeting.

We now have a better picture of the actual status -- with the oslo
decision that these namespace packages are definitely going away.
I've added an agenda item to bring this up again at the next Trove
weekly meeting [1] so that we can address this.

[1] https://wiki.openstack.org/wiki/Meetings/TroveMeeting

Thanks,
Nikhil



On Thu, Mar 12, 2015 at 4:05 PM, Robert Collins 
wrote:

> On 13 March 2015 at 09:43, Ihar Hrachyshka  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 03/12/2015 09:35 PM, Robert Collins wrote:
> >> On 13 March 2015 at 08:09, Ihar Hrachyshka 
> >> wrote:
> >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> >>>
> >>> On 03/12/2015 11:38 AM, Boris Bobrov wrote:
>  On Thursday 12 March 2015 12:59:10 Duncan Thomas wrote:
> > So, assuming that all of the oslo depreciations aren't going
> > to be fixed before release
> 
>  What makes you think that?
> 
>  In my opinion it's just one component's problem. These
>  particular deprecation warnings are a result of still on-going
>  migration from oslo. to oslo_. Ironically,
>  all components except oslo have already moved to the new naming
>  scheme.
> >>>
> >>> It's actually wrong. For example, Trove decided to stay on using
> >>> the old namespace for Kilo.
> >>
> >> Why?
> >>
> >> -Rob
> >>
> >
> >
> http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2015-02-11.log
> >
> > starting from "2015-02-11T18:03:11". I guess the assumption was that
> > there is immediate benefit, and they can just wait. Though I don't
> > think the fact that it means deprecation warnings in their logs was
> > appreciated at the time of decision.
>
> Thanks, reading that it looks like the actual status (oslo decided
> most definitely that namespace packages are going away, its just a
> matter of when) wasn't understood in that meeting.
>
> Is it possible to put it back on the agenda for the next Trove meeting?
>
> Cheers,
> Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
>
> __
> OpenStack Development Mailing 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] A question on static routes on Neutron router

[NAPIERALA, MARIA H]

Can a static/extra route on Neutron router point to an internal/tenant subnet 
interface as the next-hop?
If yes, can Neutron router forward packets received from a host on an attached 
subnet and matching on a configured static route back to the same subnet (to a 
different host)?

Appreciate the help answering the questions.

Maria


__
OpenStack Development Mailing 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] Proposal to change Glance meeting time.

[Tripp, Travis S]

I can do either.  Small preference for 1500.

On 3/12/15, 9:45 AM, "Okuma, Wayne"  wrote:

>My vote is for 1500.
>
>-Original Message-
>From: Hemanth Makkapati [mailto:hemanth.makkap...@rackspace.com]
>Sent: Thursday, March 12, 2015 8:32 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting
>time.
>
>+1 to consistent time.
>Both 1400 and 1500 work me.
>
>-Hemanth
>
>From: Ian Cordasco 
>Sent: Wednesday, March 11, 2015 10:25 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting
>time.
>
>I have no opinions on the matter. Either 1400 or 1500 work for me. I
>think there are a lot of people asking for it to be at 1500 instead
>though.
>Would anyone object to changing it to 1500 instead (as long as it is one
>consistent time for the meeting)?
>
>On 3/11/15, 01:53, "Inessa Vasilevskaya" 
>wrote:
>
>>+1
>>
>>
>>On Mon, Mar 9, 2015 at 2:43 AM, Alexander Tivelkov
>> wrote:
>>
>>Works for me, but the previous one worked as well. So, consider my vote
>>as +1 unless the majority is against this :)
>>
>>
>>--
>>Regards,
>>Alexander Tivelkov
>>
>>
>>
>>
>>On Mon, Mar 9, 2015 at 12:36 AM, Fei Long Wang
>> wrote:
>>
>>Oh, it means 3:00AM for me :-(
>>
>>
>>On 09/03/15 09:07, Nikhil Komawar wrote:
>>
>>
>>
>>
>>
>>
>>Hi all,
>>
>>
>>Currently, we've alternating time for Glance meetings. Now, with the
>>Daylight savings being implemented in some parts of the world, we're
>>thinking of moving the meeting time to just one slot i.e. earlier in
>>the day(night). This solves the original conflicting  times issue that
>>a subset of the individuals had; to add to that the schedule is less
>>confusing and unified.
>>
>>
>>
>>So, the new proposal is:
>>Glance meetings [1] to be conducted
>>weekly on
>>Thursdays at 1400UTC [2] on
>>#openstack-meeting-4
>>
>>
>>
>>This would be implemented on Mar 19th, given there are no major
>>objections.
>>
>>
>>Please vote with +1/-1 here.
>>
>>
>>
>>[1]
>>https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting
>>
>>[2]
>>http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=
>>0 
>>>=0>
>>
>>
>>Thanks,
>>-Nikhil
>>
>>
>>
>>
>>
>>
>>___
>>___ OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe:
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists
>>.
>>openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>--
>>Cheers & Best regards,
>>Fei Long Wang (王飞龙)
>>---
>>---
>>Senior Cloud Software Engineer
>>Tel: +64-48032246 
>>Email: flw...@catalyst.net.nz
>>Catalyst IT Limited
>>Level 6, Catalyst House, 150 Willis Street, Wellington
>>---
>>---
>>
>>
>>___
>>___ OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe:
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>___
>>___ OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe:
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>>
>>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] Deprecation warnings considered harmful?

[Flavio Percoco]

On 13/03/15 12:05 +1300, Robert Collins wrote:

On 13 March 2015 at 09:43, Ihar Hrachyshka  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/12/2015 09:35 PM, Robert Collins wrote:

On 13 March 2015 at 08:09, Ihar Hrachyshka 
wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1

On 03/12/2015 11:38 AM, Boris Bobrov wrote:

On Thursday 12 March 2015 12:59:10 Duncan Thomas wrote:

So, assuming that all of the oslo depreciations aren't going
to be fixed before release


What makes you think that?

In my opinion it's just one component's problem. These
particular deprecation warnings are a result of still on-going
migration from oslo. to oslo_. Ironically,
all components except oslo have already moved to the new naming
scheme.


It's actually wrong. For example, Trove decided to stay on using
the old namespace for Kilo.


Why?

-Rob



http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2015-02-11.log

starting from "2015-02-11T18:03:11". I guess the assumption was that
there is immediate benefit, and they can just wait. Though I don't
think the fact that it means deprecation warnings in their logs was
appreciated at the time of decision.


Thanks, reading that it looks like the actual status (oslo decided
most definitely that namespace packages are going away, its just a
matter of when) wasn't understood in that meeting.

Is it possible to put it back on the agenda for the next Trove meeting?


I had the same feeling after reading the log of the meeting and I'd
appreciate if the Trove team could dedicate another meeting space to
discuss this better.

It's important to have projects as aligned as possible to reduce the
impact of this deprecation.

Flavio



Cheers,
Rob

--
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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


--
@flaper87
Flavio Percoco


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

[openstack-dev] [nova] if by "archived" you mean, "wipes out your tables completely", then sure, it works fine

[Mike Bayer]

Hello Nova -

Not sure if I’m just staring at this for too long, or if
archive_deleted_rows_for_table() is just not something we ever use.  
Because it looks like it’s really, really broken very disastrously, and I’m 
wondering if I’m just missing something in front of me.

Let’s look at what it does!

First, archive_deleted_rows() calls it with a table name. These names are
taken by collecting every single table name from nova.db.sqlalchemy.models.

Then, the function uses table reflection (that is, doesn’t look in the model
at all, just goes right to the database) to load the table definitions:

table = Table(tablename, metadata, autoload=True)
shadow_tablename = _SHADOW_TABLE_PREFIX + tablename
rows_archived = 0
try:
shadow_table = Table(shadow_tablename, metadata, autoload=True)
except NoSuchTableError:
# No corresponding shadow table; skip it.
return rows_archived

this is pretty heavy handed and wasteful from an efficiency point of view,
and I’d like to fix this too, but let’s go with it. Now we have the two
tables.

Then we do this:

deleted_column = table.c.deleted
query_insert = sql.select([table],
  deleted_column != deleted_column.default).\
  order_by(column).limit(max_rows)
query_delete = sql.select([column],
  deleted_column != deleted_column.default).\
  order_by(column).limit(max_rows)

We make some SELECT statements that we’re going to use to find “soft
deleted” rows, and these will be embedded into an INSERT 
and a DELETE. It is trying to make a statement like “SELECT .. FROM
table WHERE deleted != ”, so that it finds rows where
“deleted” has been changed to something, e.g. the row was 
soft deleted.

But what’s the value of “deleted_default” ?   Remember, all this
table knows is what the database just told us about it, because it only
uses reflection.  Let’s see what the “deleted” column in a table like 
instance_types looks like:

MariaDB [nova]> show create table instance_types;
| instance_types | CREATE TABLE `instance_types` (
  `created_at` datetime DEFAULT NULL,

  …  [omitted] ...

  `deleted` int(11) DEFAULT NULL,
)

The default that we get for this column is NULL. That is very interesting!
Because, if we look at the *Python-side value of deleted*, we see something
that is quite the opposite of NULL, e.g. a thing that is most certainly not
null:

class SoftDeleteMixin(object):
deleted_at = Column(DateTime)
deleted = Column(Integer, default=0)

See that zero there? That’s a ***Python-side default***. It is **not the
server default**!! You will **not** get it from reflection, the database has
no clue about it (oddly enough, this entire subject matter is fully
documented in SQLAlchemy’s documentation, and guess what, the docs are free!
Read them all you like, I won’t ask for a dime, no questions asked!).

So, all of our INSERTS **will** put a zero, not NULL, into that column.
Let’s look in instance_types and see:

MariaDB [nova]> select id, name, deleted from instance_types;
++---+-+
| id | name  | deleted |
++---+-+
|  3 | m1.large  |   0 |
|  1 | m1.medium |   0 |
|  7 | m1.micro  |   0 |
|  6 | m1.nano   |   0 |
|  5 | m1.small  |   0 |
|  2 | m1.tiny   |   0 |
|  4 | m1.xlarge |   0 |
++---+-+
7 rows in set (0.00 sec)

No NULLs.  The value of non-deleted rows is zero.

What does this all mean?

It means, when this archival routine runs, it runs queries like this:

INSERT INTO shadow_quota_usages SELECT quota_usages.created_at, 
quota_usages.updated_at, quota_usages.deleted_at, quota_usages.id, 
quota_usages.project_id, quota_usages.resource, quota_usages.in_use, 
quota_usages.reserved, quota_usages.until_refresh, quota_usages.deleted, 
quota_usages.user_id
FROM quota_usages
WHERE quota_usages.deleted IS NOT NULL ORDER BY quota_usages.id
 LIMIT ? OFFSET ?
2015-03-12 17:01:01,218 INFO [sqlalchemy.engine.base.Engine] (7, 0)
2015-03-12 17:01:01,219 INFO [sqlalchemy.engine.base.Engine] DELETE FROM 
quota_usages WHERE quota_usages.id in (SELECT T1.id FROM (SELECT quota_usages.id
FROM quota_usages
WHERE quota_usages.deleted IS NOT NULL ORDER BY quota_usages.id
 LIMIT ? OFFSET ?) as T1)

The second query is to DELETE rows from a table like quota_usages based on
looking at rows where the “deleted” column is “NOT NULL”. Which means, all
of them! They are all zeros, not NULL!

If we assume that all of our tables are filled up with zeroes for those
deleted columns, because that’s the default, this **wipes the whole table
clean**.

How do the tests pass? Well the tests are in test_db_api->ArchiveTestCase,
and actually, they don’t. But they don’t fail every time, because the test
suite here runs with a database that is almost completely empty anyway, so
the broken archival routine doesn’t find too many rows to blow away except
for the rows in “i

Re: [openstack-dev] [all] Do we need release announcements for all the things?

[Robert Collins]

On 13 March 2015 at 12:22, Clint Byrum  wrote:
> Excerpts from Jeremy Stanley's message of 2015-03-12 13:58:20 -0700:
>> On 2015-03-12 13:22:04 -0700 (-0700), Clint Byrum wrote:
>> [...]
>> > So I'm wondering what people are getting from these announcements
>> > being on the discussion list.
>> [...]
>>
>> The main thing I get from them is that they're being recorded to a
>> (theoretically) immutable archive indexed by a lot of other systems.
>> Some day I'd love for them to include checksums of the release
>> artifacts and be OpenPGP-signed by a release delegate for whatever
>> project is releasing, and for those people to also try to get their
>> keys signed by one another and members of the community at large.
>>
>
> I had not considered the value of that, but it seems like a good thing.
>
>> Sure, we could divert them to a different list (openstack-announce
>> was suggested in another reply), but I suspect that most people
>> subscribed to -dev are also subscribed to -announce and so it
>> wouldn't effectively decrease their E-mail volume. On the other
>> hand, a lot more people should be subscribed to -announce so that's
>> probably a good idea anyway?
>
> openstack-announce would be the opposite of less impact on the signal
> to noise ratio for anyone who does want to see them. I prioritize
> openstack-announce since I would assume announcements would mostly be
> important things reserved for a low-traffic list.
>
> So I think a tag seems like a reasonable way to keep them on the list,
> but allow for automated de-prioritization of them by those who don't
> want to see them.
>
> Could we maybe have a [release] tag mandated for these?

Rather than adding process, how about we setup automation in zuul for
this. Then email tags etc don't require human thought, training etc.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Do we need release announcements for all the things?

[Clint Byrum]

Excerpts from Jeremy Stanley's message of 2015-03-12 13:58:20 -0700:
> On 2015-03-12 13:22:04 -0700 (-0700), Clint Byrum wrote:
> [...]
> > So I'm wondering what people are getting from these announcements
> > being on the discussion list.
> [...]
> 
> The main thing I get from them is that they're being recorded to a
> (theoretically) immutable archive indexed by a lot of other systems.
> Some day I'd love for them to include checksums of the release
> artifacts and be OpenPGP-signed by a release delegate for whatever
> project is releasing, and for those people to also try to get their
> keys signed by one another and members of the community at large.
> 

I had not considered the value of that, but it seems like a good thing.

> Sure, we could divert them to a different list (openstack-announce
> was suggested in another reply), but I suspect that most people
> subscribed to -dev are also subscribed to -announce and so it
> wouldn't effectively decrease their E-mail volume. On the other
> hand, a lot more people should be subscribed to -announce so that's
> probably a good idea anyway?

openstack-announce would be the opposite of less impact on the signal
to noise ratio for anyone who does want to see them. I prioritize
openstack-announce since I would assume announcements would mostly be
important things reserved for a low-traffic list.

So I think a tag seems like a reasonable way to keep them on the list,
but allow for automated de-prioritization of them by those who don't
want to see them.

Could we maybe have a [release] tag mandated for these?

__
OpenStack Development Mailing 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] Deprecation warnings considered harmful?

[Robert Collins]

On 13 March 2015 at 09:43, Ihar Hrachyshka  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/12/2015 09:35 PM, Robert Collins wrote:
>> On 13 March 2015 at 08:09, Ihar Hrachyshka 
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>>
>>> On 03/12/2015 11:38 AM, Boris Bobrov wrote:
 On Thursday 12 March 2015 12:59:10 Duncan Thomas wrote:
> So, assuming that all of the oslo depreciations aren't going
> to be fixed before release

 What makes you think that?

 In my opinion it's just one component's problem. These
 particular deprecation warnings are a result of still on-going
 migration from oslo. to oslo_. Ironically,
 all components except oslo have already moved to the new naming
 scheme.
>>>
>>> It's actually wrong. For example, Trove decided to stay on using
>>> the old namespace for Kilo.
>>
>> Why?
>>
>> -Rob
>>
>
> http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2015-02-11.log
>
> starting from "2015-02-11T18:03:11". I guess the assumption was that
> there is immediate benefit, and they can just wait. Though I don't
> think the fact that it means deprecation warnings in their logs was
> appreciated at the time of decision.

Thanks, reading that it looks like the actual status (oslo decided
most definitely that namespace packages are going away, its just a
matter of when) wasn't understood in that meeting.

Is it possible to put it back on the agenda for the next Trove meeting?

Cheers,
Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Do we need release announcements for all the things?

[Flavio Percoco]

On 12/03/15 23:31 +0300, Boris Pavlovic wrote:

Clint, 

Personally I am quite interested in new releases of python clients and oslo
stuff, but I believe 
that oslo releases announcement should be merged to single email with rate
limit 1 email per week. 
It will be much simpler at least for me to track stuff. 


I think this would make more sense than not sending them. I guess
there's something we can workout to make it happen.

Flavio




Best regards,
Boris Pavlovic 

On Thu, Mar 12, 2015 at 11:22 PM, Clint Byrum  wrote:

   I spend a not-insignificant amount of time deciding which threads to
   read and which to fully ignore each day, so extra threads mean extra
   work, even with a streamlined workflow of single-key-press-per-thread.

   So I'm wondering what people are getting from these announcements being
   on the discussion list. I feel like they'd be better off in a weekly
   digest, on a web page somewhere, or perhaps with a tag that could be
   filtered out for those that don't benefit from them.

   __
   OpenStack Development Mailing 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



--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [Glance] Experimental API

[Everett Toews]

On Mar 12, 2015, at 1:42 PM, Brian Rosmaita  
wrote:

> I don't know how elaborate we want to get here, but Everett Toews had an
> interesting suggestion in the openstack-api channel. It would go something
> like this: 
> 
> (1) User gets "/x1/search" endpoint from service catalog
> (2) User does some request against /x1/search

My apologies, I should have been a bit more specific. I actually meant put a 
version in some header *instead* of putting any version info in the URL. But I 
realize that Glance already uses the /vN/ style in its URLs.

Given the info on header’s below, an /xN/ style would not be necessary.

> (3) User receives 400 with an error message like:
> This is an experimental API.
> You must include the following header with your request:
>x-openstack-api-status: acknowledged
> By using this header, you acknowledge that while we think this API is
> pretty solid, we reserve the right to make breaking changes as we analyze
> usage patterns and API consumer comments during the experimental period.
> Please send comments to the OpenStack Future Development Mailing List with
> the subject "[Glance] x1 API".
> To subscribe to the mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> (4) User makes all subsequent requests including the
> x-openstack-api-status header

I don’t think you’d necessarily need to invent a new header. You could reuse 
something semantically similar to Nova’s X-OpenStack-Nova-API-Version [1], 
which can include an "experimental" tag.

The experimental nature of the API would need to be documented thoroughly 
somewhere. And how to work with it by including the “experimental” tag in the 
X-OpenStack-Glance-API-Version header. It would be best if the error message 
just linked to that documentation.

Everett

[1] 
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html#client-interaction


__
OpenStack Development Mailing 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] is it possible to microversion a static class method?

[Chen CH Ji]

Know it's a little bit tricky but from
doc/source/devref/api_microversions.rst,
can we make _version_specific_func static function thought it's not
required or we can explicitly suggest not to do so...


 91 @api_version("2.1", "2.4")
 92 def _version_specific_func(self, req, arg1):
 93 pass
 94
 95 @api_version(min_version="2.5") #noqa
 96 def _version_specific_func(self, req, arg1):
 97 pass
 98
 99 def show(self, req, id):
100  common stuff 
101 self._version_specific_func(req, "foo")
102  common stuff 

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Sean Dague 
To: openstack-dev@lists.openstack.org
Date:   03/12/2015 07:16 PM
Subject:Re: [openstack-dev] [nova] is it possible to microversion a
static class method?



On 03/12/2015 02:03 PM, Chris Friesen wrote:
> Hi,
>
> I'm having an issue with microversions.
>
> The api_version() code has a comment saying "This decorator MUST appear
> first (the outermost decorator) on an API method for it to work
correctly"
>
> I tried making a microversioned static class method like this:
>
> @wsgi.Controller.api_version("2.4")  # noqa
> @staticmethod
> def _my_func(req, foo):
>
> and pycharm highlighted the api_version decorator and complained that
> "This decorator will not receive a callable it may expect; the built-in
> decorator returns a special object."
>
> Is this a spurious warning from pycharm?  The pep8 checks don't complain.
>
> If I don't make it static, then pycharm suggests that the method could
> be static.

*API method*

This is not intended for use by methods below the top controller level.
If you want conditionals lower down in your call stack pull the request
version out yourself and use that.

 -Sean

--
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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] [Horizon] [swift] dependency on non-standardized, private APIs

[Jay Pipes]

On 03/12/2015 05:09 PM, John Dickinson wrote:

On Mar 12, 2015, at 12:48 PM, Jay Pipes  wrote:

On 03/12/2015 03:08 PM, John Dickinson wrote:

I'd like a little more info here.

Is Horizon relying on the X-Timestamp header for reads (GET/HEAD)? If so, I 
think that's somewhat odd, but not hugely problematic. Swift has been returning 
an X-Timestamp header since patch b20264c9d3196 (which landed 3 years ago -- 
April 2012).


OK, so there is a documentation bug here that X-Timestamp should be part of the 
Swift REST API. It currently is not documented that X-Timestamp is a 
non-optional HTTP Header, and therefore the RadosGW folks did not send 
X-Timestamp headers back in the container response.


The X-Timestamp header is certainly part of the Swift API. It is required for 
container-sync functionality (implemented in early 2011) so that two clusters 
can communicate about the proper timestamp of the objects.


OK. Sounds like an implementation detail leaking out of the API to me. In other 
words, RadosGW (which is attempting to expose a Swift API in front of Ceph 
backend storage) needs to expose this X-Timestamp header even if it implements 
container-sync using an entirely difference mechanism...


I'm not sure if this actually matters for Horizon in this specific case. But 
it's certainly true that Swift requires and used the X-Timestamp header for 
implementing core functionality. Anyone talking to a Swift endpoint can assume 
that there is an X-Timestamp header in the response and use it as they see fit.


Anyone talking to an upstream Swift *implementation* can assume that header 
will be there :) But, the header is not actually documented in the Swift *API* 
and therefore one cannot make this assumption.

Thus the confusion. :)



I don't particularly agree with the characterization of the API and implementation as 
separate, but that's a "discussion" that's as old as openstack itself. (and we 
don't need to belabor it here.)

:-)


:) Understood.


But yes, in my opinion, x-timestamp needs to be added to docs.


K, thx for the verification. I've added a doc bug:

https://bugs.launchpad.net/openstack-manuals/+bug/1431568


Anyway, sounds like X-Timestamp should be documented as part of the official 
Swift API. What about the X-Object-Meta-Mtime header in the related bug? That, 
too, is problematic for a similar reason. Is that header part of the Swift API 
as well?



Anything prefixed by "X-Object-Meta-" is user metadata, ie completely arbitrary 
and set by an end user (same with x-container-meta-* and x-account-meta-*). From the 
context of Swift, I have zero semantic understanding of any key or value in that 
namespace.


Excellent, thanks for the clarification.

All the best,
-jay


--John



Best,
-jay



--John





On Mar 9, 2015, at 12:53 PM, Anne Gentle  wrote:



On Mon, Mar 9, 2015 at 2:32 PM, Matthew Farina  wrote:
David,

FYI, the last time I chatted with John Dickinson I learned there are numerous 
API elements not documented. Not meant to be private but the docs have not kept 
up. How should we handle that?


I've read through this thread and the bug comments and searched through the 
docs and I'd like more specifics: which docs have not kept up? Private API docs 
for swift internal workings? Or is this a header that could be in _some_ swift 
(not ceph) deployments?

Thanks,
Anne


Thanks,
Matt Farina

On Sat, Mar 7, 2015 at 5:25 PM, David Lyle  wrote:
I agree that Horizon should not be requiring optional headers. Changing status 
of bug.

On Tue, Mar 3, 2015 at 5:51 PM, Jay Pipes  wrote:
Added [swift] to topic.

On 03/03/2015 07:41 AM, Matthew Farina wrote:
Radoslaw,

Unfortunately the documentation for OpenStack has some holes. What you
are calling a private API may be something missed in the documentation.
Is there a documentation bug on the issue? If not one should be created.

There is no indication that the X-Timestamp or X-Object-Meta-Mtime HTTP headers 
are part of the public Swift API:

http://developer.openstack.org/api-ref-objectstorage-v1.html

I don't believe this is a bug in the Swift API documentation, either. John 
Dickinson (cc'd) mentioned that the X-Timestamp HTTP header is required for the 
Swift implementation of container replication (John, please do correct me if 
wrong on that).

But that is the private implementation and not part of the public API.

In practice OpenStack isn't a specification and implementation. The
documentation has enough missing information you can't treat it this
way. If you want to contribute to improving the documentation I'm sure
the documentation team would appreciate it. The last time I looked there
were a number of undocumented public swift API details.

The bug here is not in the documentation. The bug is that Horizon is coded to rely on HTTP 
headers that are not in the Swift API. Horizon should be fixed to use 
.get('X-Timestamp') instead of doing ['X-Timestamp'] in its view 
pages for container details. There are already patche

Re: [openstack-dev] [Horizon] [swift] dependency on non-standardized, private APIs

[John Dickinson]

> On Mar 12, 2015, at 12:48 PM, Jay Pipes  wrote:
> 
> On 03/12/2015 03:08 PM, John Dickinson wrote:
>> I'd like a little more info here.
>> 
>> Is Horizon relying on the X-Timestamp header for reads (GET/HEAD)? If so, I 
>> think that's somewhat odd, but not hugely problematic. Swift has been 
>> returning an X-Timestamp header since patch b20264c9d3196 (which landed 3 
>> years ago -- April 2012).
> 
> OK, so there is a documentation bug here that X-Timestamp should be part of 
> the Swift REST API. It currently is not documented that X-Timestamp is a 
> non-optional HTTP Header, and therefore the RadosGW folks did not send 
> X-Timestamp headers back in the container response.
> 
>> The X-Timestamp header is certainly part of the Swift API. It is required 
>> for container-sync functionality (implemented in early 2011) so that two 
>> clusters can communicate about the proper timestamp of the objects.
> 
> OK. Sounds like an implementation detail leaking out of the API to me. In 
> other words, RadosGW (which is attempting to expose a Swift API in front of 
> Ceph backend storage) needs to expose this X-Timestamp header even if it 
> implements container-sync using an entirely difference mechanism...
> 
>> I'm not sure if this actually matters for Horizon in this specific case. But 
>> it's certainly true that Swift requires and used the X-Timestamp header for 
>> implementing core functionality. Anyone talking to a Swift endpoint can 
>> assume that there is an X-Timestamp header in the response and use it as 
>> they see fit.
> 
> Anyone talking to an upstream Swift *implementation* can assume that header 
> will be there :) But, the header is not actually documented in the Swift 
> *API* and therefore one cannot make this assumption.
> 
> Thus the confusion. :)


I don't particularly agree with the characterization of the API and 
implementation as separate, but that's a "discussion" that's as old as 
openstack itself. (and we don't need to belabor it here.)

:-)


But yes, in my opinion, x-timestamp needs to be added to docs.


> 
> Anyway, sounds like X-Timestamp should be documented as part of the official 
> Swift API. What about the X-Object-Meta-Mtime header in the related bug? 
> That, too, is problematic for a similar reason. Is that header part of the 
> Swift API as well?


Anything prefixed by "X-Object-Meta-" is user metadata, ie completely arbitrary 
and set by an end user (same with x-container-meta-* and x-account-meta-*). 
From the context of Swift, I have zero semantic understanding of any key or 
value in that namespace.


--John

> 
> Best,
> -jay
> 
>> 
>> --John
>> 
>> 
>> 
>> 
>>> On Mar 9, 2015, at 12:53 PM, Anne Gentle  
>>> wrote:
>>> 
>>> 
>>> 
>>> On Mon, Mar 9, 2015 at 2:32 PM, Matthew Farina  wrote:
>>> David,
>>> 
>>> FYI, the last time I chatted with John Dickinson I learned there are 
>>> numerous API elements not documented. Not meant to be private but the docs 
>>> have not kept up. How should we handle that?
>>> 
>>> 
>>> I've read through this thread and the bug comments and searched through the 
>>> docs and I'd like more specifics: which docs have not kept up? Private API 
>>> docs for swift internal workings? Or is this a header that could be in 
>>> _some_ swift (not ceph) deployments?
>>> 
>>> Thanks,
>>> Anne
>>> 
>>> 
>>> Thanks,
>>> Matt Farina
>>> 
>>> On Sat, Mar 7, 2015 at 5:25 PM, David Lyle  wrote:
>>> I agree that Horizon should not be requiring optional headers. Changing 
>>> status of bug.
>>> 
>>> On Tue, Mar 3, 2015 at 5:51 PM, Jay Pipes  wrote:
>>> Added [swift] to topic.
>>> 
>>> On 03/03/2015 07:41 AM, Matthew Farina wrote:
>>> Radoslaw,
>>> 
>>> Unfortunately the documentation for OpenStack has some holes. What you
>>> are calling a private API may be something missed in the documentation.
>>> Is there a documentation bug on the issue? If not one should be created.
>>> 
>>> There is no indication that the X-Timestamp or X-Object-Meta-Mtime HTTP 
>>> headers are part of the public Swift API:
>>> 
>>> http://developer.openstack.org/api-ref-objectstorage-v1.html
>>> 
>>> I don't believe this is a bug in the Swift API documentation, either. John 
>>> Dickinson (cc'd) mentioned that the X-Timestamp HTTP header is required for 
>>> the Swift implementation of container replication (John, please do correct 
>>> me if wrong on that).
>>> 
>>> But that is the private implementation and not part of the public API.
>>> 
>>> In practice OpenStack isn't a specification and implementation. The
>>> documentation has enough missing information you can't treat it this
>>> way. If you want to contribute to improving the documentation I'm sure
>>> the documentation team would appreciate it. The last time I looked there
>>> were a number of undocumented public swift API details.
>>> 
>>> The bug here is not in the documentation. The bug is that Horizon is coded 
>>> to rely on HTTP headers that are not in the Swift API. Horizon should be 
>>> fixed to use .get('

Re: [openstack-dev] [all] Do we need release announcements for all the things?

[Jeremy Stanley]

On 2015-03-12 13:22:04 -0700 (-0700), Clint Byrum wrote:
[...]
> So I'm wondering what people are getting from these announcements
> being on the discussion list.
[...]

The main thing I get from them is that they're being recorded to a
(theoretically) immutable archive indexed by a lot of other systems.
Some day I'd love for them to include checksums of the release
artifacts and be OpenPGP-signed by a release delegate for whatever
project is releasing, and for those people to also try to get their
keys signed by one another and members of the community at large.

Sure, we could divert them to a different list (openstack-announce
was suggested in another reply), but I suspect that most people
subscribed to -dev are also subscribed to -announce and so it
wouldn't effectively decrease their E-mail volume. On the other
hand, a lot more people should be subscribed to -announce so that's
probably a good idea anyway?
-- 
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] Deprecation warnings considered harmful?

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/12/2015 09:35 PM, Robert Collins wrote:
> On 13 March 2015 at 08:09, Ihar Hrachyshka 
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> On 03/12/2015 11:38 AM, Boris Bobrov wrote:
>>> On Thursday 12 March 2015 12:59:10 Duncan Thomas wrote:
 So, assuming that all of the oslo depreciations aren't going
 to be fixed before release
>>> 
>>> What makes you think that?
>>> 
>>> In my opinion it's just one component's problem. These
>>> particular deprecation warnings are a result of still on-going
>>> migration from oslo. to oslo_. Ironically,
>>> all components except oslo have already moved to the new naming
>>> scheme.
>> 
>> It's actually wrong. For example, Trove decided to stay on using
>> the old namespace for Kilo.
> 
> Why?
> 
> -Rob
> 

http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2015-02-11.log

starting from "2015-02-11T18:03:11". I guess the assumption was that
there is immediate benefit, and they can just wait. Though I don't
think the fact that it means deprecation warnings in their logs was
appreciated at the time of decision.

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVAfplAAoJEC5aWaUY1u579TgIAMfCaH3SEHNXg5D0gHSyA6xd
ScQEcD9L7pL7C70ZW8ZVH4sneVEoFZAxu1hGx8Vzi3YoPXrnoQbtjWgpiscIwHC9
wrj4b1kjDmnI0z5fu+S0doq8Rzp0VarIRe4gIpzqfkZilmsPgKD8My3Fewf9ee5N
Or5ulSvP5URut+9fSClUmk0jjHUgHsRz4n0dBvhKrpbBAM/kEIlvQ9hcbg+jYgM7
JOKwTJRRMq7boqPpMAq+OhYXenZ9gDTvSJAovGveUw6G4i6wdz/99M595mnQ7bIJ
/Fj0iizZU0jo8NW/6dr6+aUgKHPw8MMpqt/DcinTp+0oYSHhU8Yvb/vo5DvFL28=
=Oqbc
-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] Deprecation warnings considered harmful?

[Robert Collins]

On 13 March 2015 at 08:09, Ihar Hrachyshka  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/12/2015 11:38 AM, Boris Bobrov wrote:
>> On Thursday 12 March 2015 12:59:10 Duncan Thomas wrote:
>>> So, assuming that all of the oslo depreciations aren't going to
>>> be fixed before release
>>
>> What makes you think that?
>>
>> In my opinion it's just one component's problem. These particular
>> deprecation warnings are a result of still on-going migration from
>> oslo. to oslo_. Ironically, all components except
>> oslo have already moved to the new naming scheme.
>
> It's actually wrong. For example, Trove decided to stay on using the
> old namespace for Kilo.

Why?

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Do we need release announcements for all the things?

[Gregory Haynes]

Excerpts from Clint Byrum's message of 2015-03-12 20:22:04 +:
> I spend a not-insignificant amount of time deciding which threads to
> read and which to fully ignore each day, so extra threads mean extra
> work, even with a streamlined workflow of single-key-press-per-thread.
> 
> So I'm wondering what people are getting from these announcements being
> on the discussion list. I feel like they'd be better off in a weekly
> digest, on a web page somewhere, or perhaps with a tag that could be
> filtered out for those that don't benefit from them.
> 

++

Or maybe even just send them to the already existing openstack-anounce
list?

__
OpenStack Development Mailing 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] Do we need release announcements for all the things?

[Boris Pavlovic]

Clint,

Personally I am quite interested in new releases of python clients and oslo
stuff, but I believe
that oslo releases announcement should be merged to single email with rate
limit 1 email per week.
It will be much simpler at least for me to track stuff.


Best regards,
Boris Pavlovic

On Thu, Mar 12, 2015 at 11:22 PM, Clint Byrum  wrote:

> I spend a not-insignificant amount of time deciding which threads to
> read and which to fully ignore each day, so extra threads mean extra
> work, even with a streamlined workflow of single-key-press-per-thread.
>
> So I'm wondering what people are getting from these announcements being
> on the discussion list. I feel like they'd be better off in a weekly
> digest, on a web page somewhere, or perhaps with a tag that could be
> filtered out for those that don't benefit from them.
>
> __
> OpenStack Development Mailing 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] [all] Do we need release announcements for all the things?

[Clint Byrum]

I spend a not-insignificant amount of time deciding which threads to
read and which to fully ignore each day, so extra threads mean extra
work, even with a streamlined workflow of single-key-press-per-thread.

So I'm wondering what people are getting from these announcements being
on the discussion list. I feel like they'd be better off in a weekly
digest, on a web page somewhere, or perhaps with a tag that could be
filtered out for those that don't benefit from them.

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

Re: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

[Doug Fish]

I'm sure additional feedback on those patches would be welcome and helpful 
toward getting them merged in Kilo

> On Mar 12, 2015, at 9:14 AM, Lei Zhang  wrote:
> 
> Hi Lin,
> 
> This two PS is what I wanted. Thx a lot.
> 
> btw, is it possible that these PS finished in Kilo?
> 
>> On Thu, Mar 12, 2015 at 5:41 PM, Lin Hua Cheng  wrote:
>> Hi,
>> 
>> The 'cloud_admin' policy file requires domain-scoped to work to work.
>> 
>> Horizon does not currently support domain scope token yet. So yes, it is a 
>> gap in horizon at the moment.
>> 
>> There are on-going patches to address this in horizon: 
>> - https://review.openstack.org/#/c/141153/
>> - https://review.openstack.org/#/c/148082/
>> 
>> Dan (esp) prepared a nicely written document on this should eventually work.
>> 
>> -Lin
>> 
>>> On Wed, Mar 11, 2015 at 7:33 PM, Lei Zhang  wrote:
>>> is there anyone tryed this and successfully?
>>> 
 On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang  wrote:
 Hi guys,
 
 I am setting up the keytone v3 api. Now I meet a issue about the 
 `cloud_admin` policy.
 
 Base on the 
 http://www.florentflament.com/blog/setting-keystone-v3-domains.html 
 article, I modify the cloud_admin policy to 
 
 ```
 "cloud_admin": "rule:admin_required and 
 domain_id:ef0d30167f744401a0cbfcc938ea7d63",
 ```
 
 But the cloud_admin don't work as expected. I failed to open all the 
 identity panel ( like http:///horizon/identity/domains/)
 Horizon tell me" Error: Unable to retrieve project list."
 And keystone log warning:  
 
 ```
 2015-03-09 16:00:06.423 9415 DEBUG keystone.policy.backends.rules [-] 
 enforce identity:list_user_projects: {'is_delegated_auth': False, 
 'access_token_id': None, 'user_id': u'6433222efd78459bb70ad9adbcfac418', 
 'roles': [u'_member_', u'admin'], 'trustee_id': None, 'trustor_id': None, 
 'consumer_id': None, 'token': >>> (audit_id=DWsSa6yYSWi0ht9E7q4uhw, audit_chain_id=w_zLBBeFQ82KevtJrdKIJw) 
 at 0x7f4503fab3c8>, 'project_id': u'4d170baaa89b4e46b239249eb5ec6b00', 
 'trust_id': None}, enforce 
 /usr/lib/python2.7/dist-packages/keystone/policy/backends/rules.py:100
 2015-03-09 16:00:06.061 9410 WARNING keystone.common.wsgi [-] You are not 
 authorized to perform the requested action: identity:list_projects 
 (Disable debug mode to suppress these details.) 
 ```
 
 ​I make some debug and found that, the root cause is that the `context` 
 variable in keystone has no `domain_id` field( like the above keystone 
 log). So the `cloud_admin` rule failed.​ if i change the `cloud_admin` to 
 following. It works as expected. 
 
 ```
 "cloud_admin": "rule:admin_required and 
 user_id:6433222efd78459bb70ad9adbcfac418",
 ```
 
 I found that in the keystone code[0], the domain_id only exist when it is 
 a domain scope. But i believe that the horizon login token is a project 
 one( I am not very sure this)
 
 ```
 if token.project_scoped:
 auth_context['project_id'] = token.project_id
 elif token.domain_scoped:
 auth_context['domain_id'] = token.domain_id
 else:
 LOG.debug('RBAC: Proceeding without project or domain scope')
 
 ```
 
 Is it a bug? or some wrong configuration? 
 
 
 Following is my configuration.
 
 
 ```
 # /etc/keystone/keystone.conf
 [DEFAULT]
 debug=true
 verbose=true
 log_dir=/var/log/keystone
 [assignment]
 driver = keystone.assignment.backends.sql.Assignment 
 [database]
 connection=mysql://:@controller/keystone
 [identity]
 driver=keystone.identity.backends.sql.Identity
 [memcache]
 servers=controller1:11211,controller2:11211,controller3:1121
 [token]
 provider=keystone.token.providers.uuid.Provider
 ```
 
 ```
 # /etc/openstack-dashboard/local_settings.py ( partly )
 POLICY_FILES_PATH = "/etc/openstack-dashboard/"
 POLICY_FILES = {
 'identity': 'keystone_policy.json',
 }
 OPENSTACK_HOST = "127.0.0.1"
 OPENSTACK_KEYSTONE_URL = "http://%s:5000/v3"; % OPENSTACK_HOST
 OPENSTACK_KEYSTONE_DEFAULT_ROLE = "_member_"
 OPENSTACK_API_VERSIONS = {
  "data_processing": 1.1,
  "identity": 3,
  "volume": 2
 }
 OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
 OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'admin'
 ``` 
 
 ​[0] 
 https://github.com/openstack/keystone/blob/master/keystone/common/authorization.py#L58​
 
 -- 
 Lei Zhang
 Blog: http://xcodest.me
 twitter/weibo: @jeffrey4l
>>> 
>>> 
>>> 
>>> -- 
>>> Lei Zhang
>>> Blog: http://xcodest.me
>>> twitter/weibo: @jeffrey4l
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@

Re: [openstack-dev] [Glance] Experimental API

[McLellan, Steven]

This would require some changes to how python-glanceclient parses
versions. Even if the keystone catalog has a version string in it (which
typically is not the case for glance) the version parsing in common/utils
only recognizes version strings beginning with 'v'.

Would it be sensible to add clients/x1 (that might largely inherit from
clients/v2 code)? Or alter glanceclient/client to treat an 'x' version as
the same as 'v' (in which case maybe 'use /x2')?

Steve

On 3/12/15, 1:42 PM, "Brian Rosmaita"  wrote:

>I don't know how elaborate we want to get here, but Everett Toews had an
>interesting suggestion in the openstack-api channel. It would go something
>like this: 
>
>(1) User gets "/x1/search" endpoint from service catalog
>(2) User does some request against /x1/search
>(3) User receives 400 with an error message like:
>This is an experimental API.
>You must include the following header with your request:
>x-openstack-api-status: acknowledged
>By using this header, you acknowledge that while we think this API is
>pretty solid, we reserve the right to make breaking changes as we analyze
>usage patterns and API consumer comments during the experimental period.
>Please send comments to the OpenStack Future Development Mailing List with
>the subject "[Glance] x1 API".
>To subscribe to the mailing list:
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>(4) User makes all subsequent requests including the
>x-openstack-api-status header
>
>If we did something like that, my conscience would be completely clean if
>we wound up introducing a breaking change.
>
>
>On 3/12/15, 1:19 PM, "Sampath, Lakshmi"  wrote:
>
>>We had a discussion with API WG today about what it means to be an
>>"EXPERIMENTAL API" and here's the takeway from that discussion.
>>
>>- API's can be experimental, but mark it clearly in the docs as such
>>- Experimental means a breaking change may be introduced
>>- Use /x1/ instead of /v1/  in the endpoint.
>>
>>Thoughts/Suggestions?
>>
>>
>>Thanks
>>Lakshmi.
>
>
>__
>OpenStack Development Mailing 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] [Horizon] [swift] dependency on non-standardized, private APIs

[Jay Pipes]

On 03/12/2015 03:08 PM, John Dickinson wrote:

I'd like a little more info here.

Is Horizon relying on the X-Timestamp header for reads (GET/HEAD)? If so, I 
think that's somewhat odd, but not hugely problematic. Swift has been returning 
an X-Timestamp header since patch b20264c9d3196 (which landed 3 years ago -- 
April 2012).


OK, so there is a documentation bug here that X-Timestamp should be part 
of the Swift REST API. It currently is not documented that X-Timestamp 
is a non-optional HTTP Header, and therefore the RadosGW folks did not 
send X-Timestamp headers back in the container response.



The X-Timestamp header is certainly part of the Swift API. It is required for 
container-sync functionality (implemented in early 2011) so that two clusters 
can communicate about the proper timestamp of the objects.


OK. Sounds like an implementation detail leaking out of the API to me. 
In other words, RadosGW (which is attempting to expose a Swift API in 
front of Ceph backend storage) needs to expose this X-Timestamp header 
even if it implements container-sync using an entirely difference 
mechanism...



I'm not sure if this actually matters for Horizon in this specific case. But 
it's certainly true that Swift requires and used the X-Timestamp header for 
implementing core functionality. Anyone talking to a Swift endpoint can assume 
that there is an X-Timestamp header in the response and use it as they see fit.


Anyone talking to an upstream Swift *implementation* can assume that 
header will be there :) But, the header is not actually documented in 
the Swift *API* and therefore one cannot make this assumption.


Thus the confusion. :)

Anyway, sounds like X-Timestamp should be documented as part of the 
official Swift API. What about the X-Object-Meta-Mtime header in the 
related bug? That, too, is problematic for a similar reason. Is that 
header part of the Swift API as well?


Best,
-jay



--John





On Mar 9, 2015, at 12:53 PM, Anne Gentle  wrote:



On Mon, Mar 9, 2015 at 2:32 PM, Matthew Farina  wrote:
David,

FYI, the last time I chatted with John Dickinson I learned there are numerous 
API elements not documented. Not meant to be private but the docs have not kept 
up. How should we handle that?


I've read through this thread and the bug comments and searched through the 
docs and I'd like more specifics: which docs have not kept up? Private API docs 
for swift internal workings? Or is this a header that could be in _some_ swift 
(not ceph) deployments?

Thanks,
Anne


Thanks,
Matt Farina

On Sat, Mar 7, 2015 at 5:25 PM, David Lyle  wrote:
I agree that Horizon should not be requiring optional headers. Changing status 
of bug.

On Tue, Mar 3, 2015 at 5:51 PM, Jay Pipes  wrote:
Added [swift] to topic.

On 03/03/2015 07:41 AM, Matthew Farina wrote:
Radoslaw,

Unfortunately the documentation for OpenStack has some holes. What you
are calling a private API may be something missed in the documentation.
Is there a documentation bug on the issue? If not one should be created.

There is no indication that the X-Timestamp or X-Object-Meta-Mtime HTTP headers 
are part of the public Swift API:

http://developer.openstack.org/api-ref-objectstorage-v1.html

I don't believe this is a bug in the Swift API documentation, either. John 
Dickinson (cc'd) mentioned that the X-Timestamp HTTP header is required for the 
Swift implementation of container replication (John, please do correct me if 
wrong on that).

But that is the private implementation and not part of the public API.

In practice OpenStack isn't a specification and implementation. The
documentation has enough missing information you can't treat it this
way. If you want to contribute to improving the documentation I'm sure
the documentation team would appreciate it. The last time I looked there
were a number of undocumented public swift API details.

The bug here is not in the documentation. The bug is that Horizon is coded to rely on HTTP 
headers that are not in the Swift API. Horizon should be fixed to use 
.get('X-Timestamp') instead of doing ['X-Timestamp'] in its view 
pages for container details. There are already patches up that the Horizon developers have, 
IMO erroneously, rejected stating this is a problem in Ceph RadosGW for not properly 
following the Swift API).

Best,
-jay

Best of luck,
Matt Farina

On Tue, Mar 3, 2015 at 9:59 AM, Radoslaw Zarzynski
mailto:rzarzyn...@mirantis.com>> wrote:

 Guys,

 I would like discuss a problem which can be seen in Horizon: breaking
 the boundaries of public, well-specified Object Storage API in favour
 of utilizing a Swift-specific extensions. Ticket #1297173 [1] may serve
 as a good example of such violation. It is about relying on
 non-standard (in the terms of OpenStack Object Storage API v1) and
 undocumented HTTP header provided by Swift. In order to make
 Ceph RADOS Gateway work correctly with Horizon, developers had to
 inspect sources of Swift and

[openstack-dev] [puppet] Re-schedule Puppet OpenStack meeting

[Emilien Macchi]

Hi everyone,

Since OPS midcycle discussions, it seems we need to reschedule the
meeting again.

Here is the poll to do it: https://doodle.com/wuhsuafq5tibzugg

Next meeting stays on Monday and we'll close this on Thursday of next week.

Thanks,
-- 
Emilien Macchi



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] [oslo] oslo.concurrency runtime dependency on fixtures/testtools

[Robert Collins]

On 13 March 2015 at 05:06, Ben Nemec  wrote:
> On 03/12/2015 09:18 AM, Brant Knudson wrote:
>> On Thu, Mar 12, 2015 at 7:20 AM, Davanum Srinivas  wrote:
>>
>>> Alan,
>>>
>>> We are debating this on:
>>> https://review.openstack.org/#/c/157135/
>>>
>>> Please hop on :)
>>> -- dims
>>>
>>> On Thu, Mar 12, 2015 at 5:28 AM, Alan Pevec  wrote:
 Hi,

 hijacking this thread to point out something that feels wrong in the
 dependency chain which jumped out:

> Colecting testtools>=0.9.22 (from
>>> fixtures>=0.3.14->oslo.concurrency>=1.4.1->keystone==2015.1.dev395)

 fixtures is imported in oslo_concurrency/fixture/lockutils.py but
 that's not really used at _runtime_


 Cheers,
 Alan

>>>
>>
>> And it's also being discussed in keystone for deps for non-default
>> features: https://review.openstack.org/#/c/162360/
>>
>> -- Brant
>
> We actually have a spec open to discuss this for the Oslo libs.  Would
> love to get more input on it: https://review.openstack.org/#/c/153966/
>
> It's possible that will need to become a cross-project spec if we
> determine that more projects need an optional deps policy (which is
> sounding like the case).

Nit picking just a little, I think this is by definition
cross-project: pbr affects every project, and all the proposals around
this casually propose modifying pbr :). That said I've commented on
both reviews.

tl;dr I'm proposing:
 - a single new file extras.txt
 - ini sections one per extras
 - glue in pbr to make this automatic

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Experimental API

[Dean Troyer]

On Thu, Mar 12, 2015 at 1:42 PM, Brian Rosmaita <
brian.rosma...@rackspace.com> wrote:

> I don't know how elaborate we want to get here, but Everett Toews had an
> interesting suggestion in the openstack-api channel. It would go something
> like this:
>
> (1) User gets "/x1/search" endpoint from service catalog
> (2) User does some request against /x1/search
> (3) User receives 400 with an error message like:
> This is an experimental API.
> You must include the following header with your request:
> x-openstack-api-status: acknowledged
> By using this header, you acknowledge that while we think this API is
> pretty solid, we reserve the right to make breaking changes as we analyze
> usage patterns and API consumer comments during the experimental period.
> Please send comments to the OpenStack Future Development Mailing List with
> the subject "[Glance] x1 API".
> To subscribe to the mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> (4) User makes all subsequent requests including the
> x-openstack-api-status header
>

What keeps me, as a shady client, from just including
x-openstack-api-status  from the start?  and how is that different from
intentionally selecting an EXPERIEMNTAL endpoint form the service catalog?


> If we did something like that, my conscience would be completely clean if
> we wound up introducing a breaking change.


You also could do proper versioning even though it is experimental.
That'll help prove the version handling is working properly too.  As a dev
trying to get early use on an experimental API, I still need to be able to
detect when changes occur.

dt

-- 

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

Re: [openstack-dev] [Glance] Experimental API

[Jay Pipes]

On 03/12/2015 01:19 PM, Sampath, Lakshmi wrote:

We had a discussion with API WG today about what it means to be an "EXPERIMENTAL 
API" and here's the takeway from that discussion.


All experimental means with regards to an API is "we reserve the right 
to completely abandon this or change it in backwards compatible ways".



- API's can be experimental, but mark it clearly in the docs as such


Sure.


- Experimental means a breaking change may be introduced
- Use /x1/ instead of /v1/  in the endpoint.


-1 on using "x1". I don't see the point, honestly. Code (in clients) 
doesn't know or care whether there is a difference in compatibility 
guarantee between "x1" and "v1". Humans do. Leave it up to the 
documentation to mark some API as experimental and just use /v1


Best,
-jay


Thoughts/Suggestions?


Thanks
Lakshmi.

__
OpenStack Development Mailing 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] Deprecation warnings considered harmful?

[Jay S. Bryant]

Duncan,

If you see any of these coming out of Cinder (not oslo) please get a bug 
to me.


I think I have them all removed but need to know if I have missed anything.

Thanks!
Jay

On 03/12/2015 04:24 AM, Duncan Thomas wrote:

ubuntu@devstack-multiattach:~/devstack$ cinder-manage db sync
/usr/local/lib/python2.7/dist-packages/oslo_db/_i18n.py:19: 
DeprecationWarning: The oslo namespace package is deprecated. Please 
use oslo_i18n instead.

  from oslo import i18n
/opt/stack/cinder/cinder/openstack/common/policy.py:98: 
DeprecationWarning: The oslo namespace package is deprecated. Please 
use oslo_config instead.

  from oslo.config import cfg
/opt/stack/cinder/cinder/openstack/common/policy.py:99: 
DeprecationWarning: The oslo namespace package is deprecated. Please 
use oslo_serialization instead.

  from oslo.serialization import jsonutils
/opt/stack/cinder/cinder/objects/base.py:25: DeprecationWarning: The 
oslo namespace package is deprecated. Please use oslo_messaging instead.

  from oslo import messaging
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/openstack/common/fileutils.py:22: 
DeprecationWarning: The oslo namespace package is deprecated. Please 
use oslo_utils instead.

  from oslo.utils import excutils


What are normal, none developer users supposed to do with such 
warnings, other than:

a) panic or b) Assume openstack is beta quality and then panic

--
Duncan Thomas


__
OpenStack Development Mailing 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] [Horizon] [swift] dependency on non-standardized, private APIs

[John Dickinson]

I'd like a little more info here.

Is Horizon relying on the X-Timestamp header for reads (GET/HEAD)? If so, I 
think that's somewhat odd, but not hugely problematic. Swift has been returning 
an X-Timestamp header since patch b20264c9d3196 (which landed 3 years ago -- 
April 2012).

The X-Timestamp header is certainly part of the Swift API. It is required for 
container-sync functionality (implemented in early 2011) so that two clusters 
can communicate about the proper timestamp of the objects.

I'm not sure if this actually matters for Horizon in this specific case. But 
it's certainly true that Swift requires and used the X-Timestamp header for 
implementing core functionality. Anyone talking to a Swift endpoint can assume 
that there is an X-Timestamp header in the response and use it as they see fit.


--John




> On Mar 9, 2015, at 12:53 PM, Anne Gentle  
> wrote:
> 
> 
> 
> On Mon, Mar 9, 2015 at 2:32 PM, Matthew Farina  wrote:
> David,
> 
> FYI, the last time I chatted with John Dickinson I learned there are numerous 
> API elements not documented. Not meant to be private but the docs have not 
> kept up. How should we handle that?
> 
> 
> I've read through this thread and the bug comments and searched through the 
> docs and I'd like more specifics: which docs have not kept up? Private API 
> docs for swift internal workings? Or is this a header that could be in _some_ 
> swift (not ceph) deployments?
> 
> Thanks,
> Anne
> 
> 
> Thanks,
> Matt Farina
> 
> On Sat, Mar 7, 2015 at 5:25 PM, David Lyle  wrote:
> I agree that Horizon should not be requiring optional headers. Changing 
> status of bug.
> 
> On Tue, Mar 3, 2015 at 5:51 PM, Jay Pipes  wrote:
> Added [swift] to topic.
> 
> On 03/03/2015 07:41 AM, Matthew Farina wrote:
> Radoslaw,
> 
> Unfortunately the documentation for OpenStack has some holes. What you
> are calling a private API may be something missed in the documentation.
> Is there a documentation bug on the issue? If not one should be created.
> 
> There is no indication that the X-Timestamp or X-Object-Meta-Mtime HTTP 
> headers are part of the public Swift API:
> 
> http://developer.openstack.org/api-ref-objectstorage-v1.html
> 
> I don't believe this is a bug in the Swift API documentation, either. John 
> Dickinson (cc'd) mentioned that the X-Timestamp HTTP header is required for 
> the Swift implementation of container replication (John, please do correct me 
> if wrong on that).
> 
> But that is the private implementation and not part of the public API.
> 
> In practice OpenStack isn't a specification and implementation. The
> documentation has enough missing information you can't treat it this
> way. If you want to contribute to improving the documentation I'm sure
> the documentation team would appreciate it. The last time I looked there
> were a number of undocumented public swift API details.
> 
> The bug here is not in the documentation. The bug is that Horizon is coded to 
> rely on HTTP headers that are not in the Swift API. Horizon should be fixed 
> to use .get('X-Timestamp') instead of doing ['X-Timestamp'] in 
> its view pages for container details. There are already patches up that the 
> Horizon developers have, IMO erroneously, rejected stating this is a problem 
> in Ceph RadosGW for not properly following the Swift API).
> 
> Best,
> -jay
> 
> Best of luck,
> Matt Farina
> 
> On Tue, Mar 3, 2015 at 9:59 AM, Radoslaw Zarzynski
> mailto:rzarzyn...@mirantis.com>> wrote:
> 
> Guys,
> 
> I would like discuss a problem which can be seen in Horizon: breaking
> the boundaries of public, well-specified Object Storage API in favour
> of utilizing a Swift-specific extensions. Ticket #1297173 [1] may serve
> as a good example of such violation. It is about relying on
> non-standard (in the terms of OpenStack Object Storage API v1) and
> undocumented HTTP header provided by Swift. In order to make
> Ceph RADOS Gateway work correctly with Horizon, developers had to
> inspect sources of Swift and implement the same behaviour.
> 
>  From my perspective, that practise breaks the the mission of OpenStack
> which is much more than delivering yet another IaaS/PaaS implementation.
> I think its main goal is to provide a universal set of APIs covering all
> functional areas relevant for cloud computing, and to place that set
> of APIs in front as many implementations as possible. Having an open
> source reference implementation of a particular API is required to prove
> its viability, but is secondary to having an open and documented API.
> 
> I have full understanding that situations where the public OpenStack
> interfaces are insufficient to get the work done might exist.
> However, introduction of dependency on implementation-specific feature
> (especially without giving the users a choice via e.g. some
> configuration option) is not the proper way to deal with the problem.
>  From my point o

Re: [openstack-dev] Deprecation warnings considered harmful?

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/12/2015 11:38 AM, Boris Bobrov wrote:
> On Thursday 12 March 2015 12:59:10 Duncan Thomas wrote:
>> So, assuming that all of the oslo depreciations aren't going to
>> be fixed before release
> 
> What makes you think that?
> 
> In my opinion it's just one component's problem. These particular
> deprecation warnings are a result of still on-going migration from
> oslo. to oslo_. Ironically, all components except
> oslo have already moved to the new naming scheme.

It's actually wrong. For example, Trove decided to stay on using the
old namespace for Kilo.

> 
> I think that these warnings are just a single, not systemic
> problem.
> 
>> for something we know about at release time?
> 
> For bugs we know about at release time we have bugreports. Filing a
> bug is pretty easy ;)
> https://bugs.launchpad.net/oslo.db/+bug/1431268
> 
>> On 12 March 2015 at 11:41, Boris Bobrov 
>> wrote:
>>> On Thursday 12 March 2015 12:24:57 Duncan Thomas wrote:
 ubuntu@devstack-multiattach:~/devstack$ cinder-manage db
 sync 
 /usr/local/lib/python2.7/dist-packages/oslo_db/_i18n.py:19: 
 DeprecationWarning: The oslo namespace package is deprecated.
 Please use oslo_i18n instead.
 
 from oslo import i18n
 
 /opt/stack/cinder/cinder/openstack/common/policy.py:98:
>>> DeprecationWarning:
 The oslo namespace package is deprecated. Please use
 oslo_config instead.
 
 from oslo.config import cfg
 
 /opt/stack/cinder/cinder/openstack/common/policy.py:99:
>>> DeprecationWarning:
 The oslo namespace package is deprecated. Please use
 oslo_serialization instead.
 
 from oslo.serialization import jsonutils
 
 /opt/stack/cinder/cinder/objects/base.py:25:
 DeprecationWarning: The oslo namespace package is deprecated.
 Please use oslo_messaging instead.
 
 from oslo import messaging
>>> 
>>> /usr/local/lib/python2.7/dist-packages/oslo_concurrency/openstack/common/
>>>
>>> 
fi
>>> 
 leutils.py:22: DeprecationWarning: The oslo namespace package
 is deprecated. Please use oslo_utils instead.
 
 from oslo.utils import excutils
 
 What are normal, none developer users supposed to do with
 such warnings, other than: a) panic or b) Assume openstack is
 beta quality and then panic
>>> 
>>> Non developer users are supposed to file a bug, leave
>>> installation and usage to professional devops who know how to
>>> handle logs or and stop using non- stable branch.
>>> 
>>> -- С наилучшими пожеланиями, Boris
>>> 
>>> _
>>>
>>> 
_ OpenStack Development Mailing 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 v1

iQEcBAEBAgAGBQJVAeRiAAoJEC5aWaUY1u57aysH/0Ho+FQDuFmjrA/5bgESgJST
O71arqvVJN54OoQBIgY3wpFSi8GRLfYxYilZK8/6PJzOzJ+0FvEsz8wyT3Chh2/p
x8g7GNBXhtVnDTCY86BctvgMyYdvSAkbrn7PZNz4b9sEJ3ocHCzq4okz5YkRyztt
fzm4c6Nwva5tifRxXtZa1Ag581Pvzpp+UYQpllZ1If1hJaV7wsFrb7THzi42r3pR
4rwvuWoQJRunrgLRFGEeUElWYtIZjdlxqA2YlqyXyokw3pHaI8ctIFSudG8Pmkon
C4H8Lc81AmNvWVHmHe0xcjS7zWivPg3jJumCrVKaMbb2fcOG87zg3R3AzF09kQA=
=gwZa
-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] Deprecation warnings considered harmful?

[Doug Hellmann]

On Thu, Mar 12, 2015, at 01:13 PM, John Griffith wrote:
> On Thu, Mar 12, 2015 at 10:48 AM, Doug Hellmann 
> wrote:
> 
> >
> >
> > On Thu, Mar 12, 2015, at 05:24 AM, Duncan Thomas wrote:
> > > ubuntu@devstack-multiattach:~/devstack$ cinder-manage db sync
> > > /usr/local/lib/python2.7/dist-packages/oslo_db/_i18n.py:19:
> > > DeprecationWarning: The oslo namespace package is deprecated. Please use
> > > oslo_i18n instead.
> > >   from oslo import i18n
> > > /opt/stack/cinder/cinder/openstack/common/policy.py:98:
> > > DeprecationWarning:
> > > The oslo namespace package is deprecated. Please use oslo_config instead.
> > >   from oslo.config import cfg
> > > /opt/stack/cinder/cinder/openstack/common/policy.py:99:
> > > DeprecationWarning:
> > > The oslo namespace package is deprecated. Please use oslo_serialization
> > > instead.
> > >   from oslo.serialization import jsonutils
> > > /opt/stack/cinder/cinder/objects/base.py:25: DeprecationWarning: The oslo
> > > namespace package is deprecated. Please use oslo_messaging instead.
> > >   from oslo import messaging
> > >
> > /usr/local/lib/python2.7/dist-packages/oslo_concurrency/openstack/common/fileutils.py:22:
> > > DeprecationWarning: The oslo namespace package is deprecated. Please use
> > > oslo_utils instead.
> > >   from oslo.utils import excutils
> > >
> >
> > Yay, the system is working as designed!
> >
> > Oslo "froze" early to prepare releases to integrate with the downstream
> > projects. You found an issue and reported it. Dims and others worked on
> > patches, and we're releasing new versions. All before your feature
> > freeze, so you can adopt them.
> >
> > >
> > > What are normal, none developer users supposed to do with such warnings,
> > > other than:
> > > a) panic or b) Assume openstack is beta quality and then panic
> >
> > Next time, please try to be less snide. It makes it difficult to take
> > you seriously.
> >
> > Doug
> >
> > >
> > > --
> > > Duncan Thomas
> > >
> > __
> > > OpenStack Development Mailing 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
> >
> 
> ​Very cool!!  I think there may have been some misunderstanding here on
> how
> this would all shake out, but yes as Doug and Dims pointed out this
> worked
> great.  Thanks everyone!!​

Yep, I realize not everyone remembers the way we did it for Juno, but
this is standard operating procedure for Oslo now.

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

[openstack-dev] [all] oslo.vmware 0.11.1 release

[Doug Hellmann]

The Oslo team is eager to announce the release of:

oslo.vmware 0.11.1: Oslo VMware library for OpenStack projects

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

   http://launchpad.net/oslo.vmware/+milestone/0.11.1

Please report issues through launchpad:

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

Notable changes


We hope to make this the last release of the library for the Kilo cycle.

Changes in oslo.vmware 0.11.0..0.11.1
-

5de2c31 Switch to non-namespaced module imports
9196695 Imported Translations from Transifex
fa594ff Move missing tests to new oslo_vmware location

Diffstat (except docs and test files)
-

.../fr/LC_MESSAGES/oslo.vmware-log-warning.po  |   10 +-
oslo_vmware/_i18n.py   |4 +-
oslo_vmware/api.py |2 +-
oslo_vmware/common/loopingcall.py  |2 +-
oslo_vmware/rw_handles.py  |4 +-
oslo_vmware/service.py |2 +-
.../network/nsx/nsxv/test_nsxv_loadbalancer.py |   98 ++
oslo_vmware/vim_util.py|2 +-
25 files changed, 1500 insertions(+), 1500 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] [all] tooz 0.13.1 release

[Doug Hellmann]

The Oslo team is content to announce the release of:

tooz 0.13.1: Coordination library for distributed systems.

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

   http://launchpad.net/python-tooz/+milestone/0.13.1

Please report issues through launchpad:

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

Notable changes


We hope to make this the last release of the library for the Kilo cycle.

Changes in tooz 0.13.0..0.13.1
--

20033a7 Switch to non-namespaced module imports
bb00a5b Add a driver feature compatibility matrix
eb95e7f Remove support for 3.3

Diffstat (except docs and test files)
-

setup.cfg|   2 +-
tools/compat-matrix.py   | 142 +++
tooz/coordination.py |   2 +-
tooz/drivers/redis.py|   2 +-
tox.ini  |   6 ++
8 files changed, 226 insertions(+), 3 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

Re: [openstack-dev] [nova] need input on possible API change for bug #1420848

[Chris Friesen]

So I've been playing with microversions and noticed that the information about
req.ver_obj.matches(start_version, end_version) in the spec doesn't actually 
match what's in the codebase.


1) The code has req.api_version_request instead of req.ver_obj

2) The spec says that "end_version is optional in which case it will match any
version greater than or equal to start_version."  The code requires both but 
allows either to be None.


If we're going to refer people to the spec, do we maybe want to update the spec 
to match the code?


Chris

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

Re: [openstack-dev] [Glance] Experimental API

[Brian Rosmaita]

I don't know how elaborate we want to get here, but Everett Toews had an
interesting suggestion in the openstack-api channel. It would go something
like this: 

(1) User gets "/x1/search" endpoint from service catalog
(2) User does some request against /x1/search
(3) User receives 400 with an error message like:
This is an experimental API.
You must include the following header with your request:
x-openstack-api-status: acknowledged
By using this header, you acknowledge that while we think this API is
pretty solid, we reserve the right to make breaking changes as we analyze
usage patterns and API consumer comments during the experimental period.
Please send comments to the OpenStack Future Development Mailing List with
the subject "[Glance] x1 API".
To subscribe to the mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
(4) User makes all subsequent requests including the
x-openstack-api-status header

If we did something like that, my conscience would be completely clean if
we wound up introducing a breaking change.


On 3/12/15, 1:19 PM, "Sampath, Lakshmi"  wrote:

>We had a discussion with API WG today about what it means to be an
>"EXPERIMENTAL API" and here's the takeway from that discussion.
>
>- API's can be experimental, but mark it clearly in the docs as such
>- Experimental means a breaking change may be introduced
>- Use /x1/ instead of /v1/  in the endpoint.
>
>Thoughts/Suggestions?
>
>
>Thanks
>Lakshmi.


__
OpenStack Development Mailing 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] [stable] Icehouse 2014.1.4 freeze exceptions

[Paul McMillan]

> Can Paul (in CC) please have a look at the last patch set, as you are the one
> who found the main drawback in the firsts iterations...

The latest patchset (as currently merged) looks good to me.

-Paul

__
OpenStack Development Mailing 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] Experimental API

[Alexander Tivelkov]

Thanks Lakshmi, that's useful.

So, we want to release Artifacts API in Kilo as experimental. We do need
some early adopters to begin working with it (the initial interest was from
Heat and Murano projects, and the OVA/OVF initiative for Images as well) in
the next cycle and provide some feedback on the API and its usefulness, so
we may take this feedback into account before releasing the stable version
of API with L.
I've talked to Murano folks, they are ok with that plan, some feedback from
Heat and OVA teams would be great as well.

Anyways, we will not break the compatibility without serious reasons for
that, and we will collaborate with any early adopters about any such
breaking changes.

--
Regards,
Alexander Tivelkov

On Thu, Mar 12, 2015 at 8:19 PM, Sampath, Lakshmi 
wrote:

> We had a discussion with API WG today about what it means to be an
> "EXPERIMENTAL API" and here's the takeway from that discussion.
>
> - API's can be experimental, but mark it clearly in the docs as such
> - Experimental means a breaking change may be introduced
> - Use /x1/ instead of /v1/  in the endpoint.
>
> Thoughts/Suggestions?
>
>
> Thanks
> Lakshmi.
>
> __
> OpenStack Development Mailing 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] [Glance] Reviews.

[Nikhil Komawar]

Hi all (and specifically Glance cores reviewers),


We are approaching a Feature Freeze and there are reviews pending on multiple 
features [1]. I think as Good Samaritans and members of Glance community, we'd 
focus our reviews on the code that is expecting our attention in due time. So, 
let's try to avoid reviewing anything that can wait until after the freeze and 
focus our energy on the reviews related to these features still in "Needs Code 
Review" status.


[1] https://launchpad.net/glance/+milestone/kilo-3


Thanks,
-Nikhil
__
OpenStack Development Mailing 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] is it possible to microversion a static class method?

[Sean Dague]

On 03/12/2015 02:03 PM, Chris Friesen wrote:
> Hi,
> 
> I'm having an issue with microversions.
> 
> The api_version() code has a comment saying "This decorator MUST appear
> first (the outermost decorator) on an API method for it to work correctly"
> 
> I tried making a microversioned static class method like this:
> 
> @wsgi.Controller.api_version("2.4")  # noqa
> @staticmethod
> def _my_func(req, foo):
> 
> and pycharm highlighted the api_version decorator and complained that
> "This decorator will not receive a callable it may expect; the built-in
> decorator returns a special object."
> 
> Is this a spurious warning from pycharm?  The pep8 checks don't complain.
> 
> If I don't make it static, then pycharm suggests that the method could
> be static.

*API method*

This is not intended for use by methods below the top controller level.
If you want conditionals lower down in your call stack pull the request
version out yourself and use that.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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] is it possible to microversion a static class method?

[Chris Friesen]

Hi,

I'm having an issue with microversions.

The api_version() code has a comment saying "This decorator MUST appear first 
(the outermost decorator) on an API method for it to work correctly"


I tried making a microversioned static class method like this:

@wsgi.Controller.api_version("2.4")  # noqa
@staticmethod
def _my_func(req, foo):

and pycharm highlighted the api_version decorator and complained that "This 
decorator will not receive a callable it may expect; the built-in decorator 
returns a special object."


Is this a spurious warning from pycharm?  The pep8 checks don't complain.

If I don't make it static, then pycharm suggests that the method could be 
static.

Chris

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

Re: [openstack-dev] [Magnum][Heat][Solum] Expression of Bay Status

[Devdatta Kulkarni]

Hey Magnum team,

Just thought of sharing here that in Solum we have a similar requirement. We 
want to know when a Heat stack corresponding to an 'app' is ready so that we 
can mark that app as ready in Solum's database. 
We periodically query Heat to get this information (so essentially a 
polling-based approach).
So far it has been working fine for us.

Also, thanks for sharing insights on issues that may arise when using 
SoftwareDeployments.

Thanks,
- Devdatta


From: Adrian Otto 
Sent: Wednesday, March 11, 2015 7:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum][Heat] Expression of Bay Status

In summary, we have decided to use the usage notification events emitted by 
heat (http://tinyurl.com/oultjm5). This should allow us to detect stack action 
completions, and errors (with reasons) which should be enough for a Bay 
implementation that does not need to poll. Stack timeouts can be passed to heat 
as parameters. This is not as elegant as what Angus and Zane suggested because 
it requires Magnum to access all RPC messages. With their proposed approach we 
could use a Zaqar queue that only emits the stack events relevant to that 
user/tenant. This conforms better to the principle of least privilege. Our 
preference for the decided approach is that it allows us tight integration with 
Heat using functionality that exists today. We admit that this implementation 
will be harder to debug than other options.

More remarks in-line.

On Mar 11, 2015, at 2:27 AM, Jay Lau  wrote:

>
>
> 2015-03-10 23:21 GMT+08:00 Hongbin Lu :
> Hi Adrian,
>
> On Mon, Mar 9, 2015 at 6:53 PM, Adrian Otto  wrote:
> Magnum Team,
>
> In the following review, we have the start of a discussion about how to 
> tackle bay status:
>
> https://review.openstack.org/159546
>
> I think a key issue here is that we are not subscribing to an event feed from 
> Heat to tell us about each state transition, so we have a low degree of 
> confidence that our state will match the actual state of the stack in 
> real-time. At best, we have an eventually consistent state for Bay following 
> a bay creation.
>
> Here are some options for us to consider to solve this:
>
> 1) Propose enhancements to Heat (or learn about existing features) to emit a 
> set of notifications upon state changes to stack resources so the state can 
> be mirrored in the Bay resource.
>
> A drawback of this option is that it increases the difficulty of 
> trouble-shooting. In my experience of using Heat (SoftwareDeployments in 
> particular), Ironic and Trove, one of the most frequent errors I encountered 
> is that the provisioning resources stayed in deploying state (never went to 
> completed). The reason is that they were waiting a callback signal from the 
> provisioning resource to indicate its completion, but the callback signal was 
> blocked due to various reasons (e.g. incorrect firewall rules, incorrect 
> configs, etc.). Troubling-shooting such problem is generally harder.
> I think that the "heat convergence" is working on the issues for your 
> concern: https://wiki.openstack.org/wiki/Heat/Blueprints/Convergence

Yes, that wold address part of the concern, but not all of it. Depending on the 
implementation of state exchange, and the configuration of the network, it may 
be possible to create an installation of the system that does not function at 
all due to network ACLs, and almost no clue to the implementer about why it 
does not work. To mitigate this concern, we would want an implementation that 
does not require a bi-directional network trust relationship between Heat and 
Magnum. Instead, implement it in a way that connections are only made from 
Magnum to Heat, so if the stack creation call succeeds, so can the status 
updates. Perhaps we can revisit this design discussion in a future iteration of 
our Bay status code.

Adrian

>
> 2) Spawn a task to poll the Heat stack resource for state changes, and 
> express them in the Bay status, and allow that task to exit once the stack 
> reaches its terminal (completed) state.
>
> 3) Don’t store any state in the Bay object, and simply query the heat stack 
> for status as needed.
>
> Are each of these options viable? Are there other options to consider? What 
> are the pro/con arguments for each?
>
> Thanks,
>
> Adrian
>
>
>
> __
> OpenStack Development Mailing 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
>
>
>
>
> --
> Thanks,
>
>

Re: [openstack-dev] [Glance] Nitpicking in code reviews

[Jim Rollenhagen]

On Thu, Mar 12, 2015 at 09:07:30AM -0500, Flavio Percoco wrote:
> On 11/03/15 15:06 -1000, John Bresnahan wrote:
> >FWIW I agree with #3 and #4 but not #1 and #2.  Spelling is an easy enough
> >thing to get right and speaks to the quality standard to which the product
> >is held even in commit messages and comments (consider the 'broken window
> >theory').  Of course everyone makes mistakes (I am a terrible speller) but
> >correcting a spelling error should be a trivial matter.  If a reviewer
> >notices a spelling error I would expect them to point it.
> 
> I'd agree depending on the status of the patch. If the patch has
> already 2 +2s and someone blocks it because of a spelling error, then
> the cost of fixing it, running the CI jobs and getting the reviews
> again is higher than living with a simple typo.
> 
> Process and rules are good but we must evaluate them in a case by case
> basis to make sure we're not blocking important work on things that
> are not that relevant after all.
> 

In Ironic, we've set up rough guidelines for situations like these.

1) Reviewers should not -1 a patch solely for spelling/grammar errors.
2) If a reviewer finds one of these errors and feels strongly that it
   should be corrected, they should do one of the following:
   2a) If it won't slow down the patch (i.e. no +2's on it), fix it
   themselves and submit a new patchset. This is even easier for
   commit messages; they can be edited directly in Gerrit.
   2b) Make a note on the review and push a follow-up patch to fix it.
   2c) Ask the submitter for a follow-up patch that fixes it.

This has dramatically reduced our nitpicking on patches and has even
seemed to improve our general velocity.

// jim

> >
> >On 3/11/15 2:22 PM, Kuvaja, Erno wrote:
> >>Hi all,
> >>
> >>Following the code reviews lately I’ve noticed that we (the fan club
> >>seems to be growing on weekly basis) have been growing culture of
> >>nitpicking [1] and bikeshedding [2][3] over almost every single change.
> >>
> >>Seriously my dear friends, following things are not worth of “-1” vote
> >>if even a comment:
> >>
> >>1)Minor spelling errors on commit messages (as long as the message comes
> >>through and flags are not misspelled).
> >>
> >>2)Minor spelling errors on comments (docstrings and documentation is
> >>there and there, but comments, come-on).
> >>
> >>3)Used syntax that is functional, readable and does not break
> >>consistency but does not please your poem bowel.
> >>
> >>4)Other things you “just did not realize to check if they were there”.
> >>After you have gone through the whole change go and look your comments
> >>again and think twice if your concern/question/whatsoever was addressed
> >>somewhere else than where your first intuition would have dropped it.
> >>
> >>We have relatively high volume for glance at the moment and this
> >>nitpicking and bikeshedding does not help anyone. At best it just
> >>tightens nerves and breaks our group. Obviously if there is “you had ONE
> >>job” kind of situations or there is relatively high amount of errors
> >>combined with something serious it’s reasonable to ask fix the typos on
> >>the way as well. The reason being need to increase your statistics,
> >>personal perfectionist nature or actually I do not care what; just stop
> >>or go and do it somewhere else.
> 
> 
> Thanks for bringing all this up, Erno. I've been seeing the same
> pattern for all the points you've mentioned above. It's a good
> reminder for people to treat each patch individually so we avoid
> making our process and rules a pain for everyone.
> 
> Flavio
> 
> >>
> >>Love and pink ponies,
> >>
> >>-Erno
> >>
> >>[1] www.urbandictionary.com/define.php?term=nitpicking
> >>
> >>
> >>[2] http://bikeshed.com
> >>
> >>[3] http://en.wiktionary.org/wiki/bikeshedding
> >>
> >>
> >>
> >>__
> >>OpenStack Development Mailing 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
> 
> -- 
> @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.openstac

Re: [openstack-dev] FW: [nova] readout from Philly Operators Meetup

[Sajeesh Cimson Sasi]

Hi Salvatore,
   We had a short discussion on Hierarchical quota management 
in nova  somewhere in December. The spec was approved ,but the code couldn't 
make it to Kilo. I am trying to get it merged in Liberty. Implementation is 
over. Only test cases are pending.
   I have resubmitted the specs for L release.
   https://review.openstack.org/160605
   Kindly have a look at it.
  You had told about quota management via oslo and storing 
quota values in keystone.Whether any progress has happened towards that 
direction ?
best regards
   sajeesh

From: Tim Bell [tim.b...@cern.ch]
Sent: 12 March 2015 21:51:42
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] FW:  [nova] readout from Philly Operators Meetup

> I completely agree with you - Sean and Joe.
>
> Since the argument was brought up I just wanted to point out that this "quota 
> service" thing is a bit of a unicorn at the moment, and it should not 
> distract from fixing and improving quota maangement & enforcement logic in 
> the various openstack projects.
>
> I wan't be able to introduce hierarchical quotas in neutron by the end of 
> Kilo, but I'll keep it on the roadmap for Liberty.
>
> Salvatore
>

Given the hierarchical quotas make the quota handling more complex (to ensure 
parent quotas are consistent as well), this would seem a good candidate for an 
oslo library. During the Nova quota discussions, there was much consideration 
for how things would work and it would be a great cause of confusion if each 
project has its own approach/semantics.

A central quota service would then be a later decision which would have less 
impact if the code for quotas is shared.

Tim

> On 12 March 2015 at 11:59, Sean Dague  wrote:
> On 03/11/2015 08:31 PM, Joe Gordon wrote:
> >
> >
> > On Wed, Mar 11, 2015 at 4:07 PM, Ihar Hrachyshka  > > wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 03/11/2015 07:48 PM, Joe Gordon wrote:
> > > Out of sync Quotas --
> > >
> > > https://etherpad.openstack.org/p/PHL-ops-nova-feedback L63
> > >
> > > The quotas code is quite racey (this is kind of a known if you look
> > > at the bug tracker). It was actually marked as a top soft spot
> > > during last fall's bug triage -
> > > 
> > http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html
> > >
> > >  There is an operator proposed spec for an approach here -
> > > https://review.openstack.org/#/c/161782/
> > >
> > > Action: we should make a solution here a top priority for enhanced
> > > testing and fixing in Liberty. Addressing this would remove a lot
> > > of pain from ops.
> > >
> > >
> > > To help us better track quota bugs I created a quotas tag:
> > >
> > > https://bugs.launchpad.net/nova/+bugs?field.tag=quotas
> > >
> > > Next step is re-triage those bugs: mark fixed bugs as fixed,
> > > deduplicate bugs etc.
> >
> > (Being quite far from nova code, so ignore if not applicable)
> >
> > I would like to note that other services experience races in quota
> > management too. Neutron has a spec approved to land in Kilo-3 that is
> > designed to introduce a new quota enforcement mechanism that is
> > expected to avoid (some of those) races:
> >
> > 
> > https://github.com/openstack/neutron-specs/blob/master/specs/kilo/better-quotas.rst
> >
> > I thought you may be interested in looking into it to apply similar
> > ideas to nova.
> >
> >
> > Working on a library for this hasn't been ruled out yet. But right now I
> > am simply trying to figure out how to reproduce the issue, and nothing else.
> Right, I think assuming an architecture change will magically fix this
> without scenarios that expose the existing bugs seems overly optimistic.
>
> I think there is a short / medium term test / reproduce question here,
> then a longer term question about different architecture.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
> __
> OpenStack Development Mailing 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] [metadata] metadata service when NOT using name space

[Wanjing Xu]

Assaf
Thanks for replying.  I have been playing around metadata service to make sure 
our product is not breaking it.  If namespace is really needed if we want 
metadata service, then we need to know about it and document it in our product.
Thanks and Regards! Wanjing

> Date: Wed, 11 Mar 2015 22:38:09 -0400
> From: amul...@redhat.com
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron] [metadata] metadata service when NOT 
> using name space
> 
> Can you explain why are you not using namespaces? (I'm really curious).
> 
> I've been thinking of proposing to deprecate that option only for the simple
> truth that it's not tested and we have no idea if it works anymore, or if 
> anyone
> actually uses it.
> 
> - Original Message -
> > When use_namespaces is True, there will be a namespace metadata proxy
> > launched for either dhcp or router namespace, this proxy will accept metada
> > service request , and then proxy the request to metadata server via metadata
> > agent. But when use_namespaces is False, there is no namespace metadata
> > proxy running, how is the request from vm going to get to matadata server
> > then? I also checked that there is no NAT rule in the iptables. So do we
> > support metadata service with no namespace? If we do , how is it supposed to
> > work? This is Juno.
> > 
> > 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 Development Mailing 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] readout from Philly Operators Meetup

[Clint Byrum]

Excerpts from Sean Dague's message of 2015-03-12 09:59:35 -0700:
> On 03/12/2015 12:47 PM, Clint Byrum wrote:
> > Excerpts from Sean Dague's message of 2015-03-11 05:59:10 -0700:
> >> =
> >>  Additional Interesting Bits
> >> =
> >>
> >> Rabbit
> >> --
> >>
> >> There was a whole session on Rabbit -
> >> https://etherpad.openstack.org/p/PHL-ops-rabbit-queue
> >>
> >> Rabbit is a top operational concern for most large sites. Almost all
> >> sites have a "restart everything that talks to rabbit" script because
> >> during rabbit ha opperations queues tend to blackhole.
> >>
> >> All other queue systems OpenStack supports are worse than Rabbit (from
> >> experience in that room).
> >>
> >> oslo.messaging < 1.6.0 was a significant regression in dependability
> >> from the incubator code. It now seems to be getting better but still a
> >> lot of issues. (L112)
> >>
> >> Operators *really* want the concept in
> >> https://review.openstack.org/#/c/146047/ landed. (I asked them to
> >> provide such feedback in gerrit).
> >>
> > 
> > This reminded me that there are other options that need investigation.
> > 
> > A few of us have been looking at what it might take to use something
> > in between RabbitMQ and ZeroMQ for RPC and notifications. Some initial
> > forays into inspecting Gearman (which infra has successfully used for
> > quite some time as the backend of Zuul) look promising. A few notes:
> > 
> > * The Gearman protocol is crazy simple. There are currently 4 known gearman
> >   server implementations: Perl, Java, C, and Python (written and
> >   maintained by our own infra team). http://gearman.org/download/ for
> >   the others, and https://pypi.python.org/pypi/gear for the python one.
> > 
> > * Gearman has no pub/sub capability built in for 1:N comms. However, it
> >   is fairly straight forward to write workers that will rebroadcast
> >   messages to subscribers.
> > 
> > * Gearman's security model is not very rich. Mostly, if you have been
> >   authenticated to the gearman server (only the C server actually even
> >   supports any type of authentication, via SSL client certs), you can
> >   do whatever you want including consuming all the messages in a queue
> >   or filling up a queue with nonsense. This has been raised as a concern
> >   in the past and might warrant extra work to add support to the python
> >   server and/or add ACL support.
> > 
> > Part of our motivation for this is that some of us are going to be
> > deploying a cloud soon and none of us are excited about deploying and
> > supporting RabbitMQ. So we may be proposing specs to add Gearman as a
> > deployment option soon.
> 
> I think experimentation of other models is good. There was some
> conversation that maybe Kafka was a better model as well. However,
> realize that services are quite chatty at this point and push pretty
> large payloads through that bus. The HA story is also quite important,
> because the underlying message architecture assumes reliable delivery
> for some of the messages, and if they fall on the floor, you'll get
> either leaked resources, or broken resources. It's actually the HA
> recovery piece of Rabbit (and when it doesn't HA recover correctly)
> that's seemingly the sharp edge most people are hitting.

Kafka is definitely another one I'd like to keep an eye on, but have
zero experience using.

Chatty is good for gearman, I don't see a problem with that. It's
particulary good at the sort of "send, wait for response, act" model
that I see used often in RPC. Large payloads can be a little expensive
as Gearman will keep them all in memory, but I wonder what you mean by
large. 1MB/message is meh if the rate of sending is 50/s.

Reliable delivery is handled several ways:

* Synchronous senders that can hang around and wait for a reply will
  work well as gearman will simply retry those messages if receivers
  have problems. If the gearmand itself dies in this case, client
  libraries should re-send to the next one in the list of servers.

* Async messages can be stored and forwarded. This scales out really
  nicely, but does complicate things in similar ways to ZeroMQ by
  needing a store-and-forward worker on each box.

* Enable persistence in the C server. This one is really darn slow IMO,
  and gives back a lot of Gearman's advantage at being mostly in-memory
  and scaling out. It works a lot like RabbitMQ's shovel HA method where
  you recover from a down node by loading all of the jobs into another
  node's memory. There are multiple options for the store, including
  sqlite, redis, tokyocabinet, and good old fashioned MySQL. My personal
  experience was with tokyocabinet (which I co-wrote the driver for)
  on top of DRBD. We hit delivery rates in the thousands / second with
  small messages, and that was with 2006 CPU's and hard disks. I imagine
  modern hardware with battery backed write cache and  SSD's can deliver
  quite a bit more.

> 
>

Re: [openstack-dev] Deprecation warnings considered harmful?

[Joshua Harlow]

Also note that the following is supposed to be true (or should be?):

From: https://docs.python.org/2/library/warnings.html#warning-categories

>>> DeprecationWarning: Base category for warnings about deprecated
>>> features (ignored by default).
>>> Changed in version 2.7: DeprecationWarning is ignored by default.

So by default these should be off/ignored:

Now projects can change that as they wish (and maybe we should have it 
be set to 'once' during development, and 'ignore' at release?), where 
these levels are at:


https://docs.python.org/2/library/warnings.html#the-warnings-filter

I believe I put the 'once' into cinder code:

https://github.com/openstack/cinder/blob/master/cinder/cmd/all.py#L34

But feel free to change it (this seems like it should be something 
consistent across projects)...


-Josh

John Griffith wrote:



On Thu, Mar 12, 2015 at 10:48 AM, Doug Hellmann mailto:d...@doughellmann.com>> wrote:



On Thu, Mar 12, 2015, at 05:24 AM, Duncan Thomas wrote:
>  ubuntu@devstack-multiattach:~/devstack$ cinder-manage db sync
>  /usr/local/lib/python2.7/dist-packages/oslo_db/_i18n.py:19:
>  DeprecationWarning: The oslo namespace package is deprecated.
Please use
>  oslo_i18n instead.
>from oslo import i18n
>  /opt/stack/cinder/cinder/openstack/common/policy.py:98:
>  DeprecationWarning:
>  The oslo namespace package is deprecated. Please use oslo_config
instead.
>from oslo.config import cfg
>  /opt/stack/cinder/cinder/openstack/common/policy.py:99:
>  DeprecationWarning:
>  The oslo namespace package is deprecated. Please use
oslo_serialization
>  instead.
>from oslo.serialization import jsonutils
>  /opt/stack/cinder/cinder/objects/base.py:25: DeprecationWarning:
The oslo
>  namespace package is deprecated. Please use oslo_messaging instead.
>from oslo import messaging
>

/usr/local/lib/python2.7/dist-packages/oslo_concurrency/openstack/common/fileutils.py:22:
>  DeprecationWarning: The oslo namespace package is deprecated.
Please use
>  oslo_utils instead.
>from oslo.utils import excutils
>

Yay, the system is working as designed!

Oslo "froze" early to prepare releases to integrate with the downstream
projects. You found an issue and reported it. Dims and others worked on
patches, and we're releasing new versions. All before your feature
freeze, so you can adopt them.

>
>  What are normal, none developer users supposed to do with such
warnings,
>  other than:
>  a) panic or b) Assume openstack is beta quality and then panic

Next time, please try to be less snide. It makes it difficult to take
you seriously.

Doug

>
>  --
>  Duncan Thomas
 >
__
 > OpenStack Development Mailing 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


​Very cool!!  I think there may have been some misunderstanding here on
how this would all shake out, but yes as Doug and Dims pointed out this
worked great.  Thanks everyone!!​

__
OpenStack Development Mailing 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] readout from Philly Operators Meetup

[Clint Byrum]

Excerpts from Doug Hellmann's message of 2015-03-12 10:04:57 -0700:
> 
> On Thu, Mar 12, 2015, at 12:47 PM, Clint Byrum wrote:
> > Excerpts from Sean Dague's message of 2015-03-11 05:59:10 -0700:
> > > =
> > >  Additional Interesting Bits
> > > =
> > > 
> > > Rabbit
> > > --
> > > 
> > > There was a whole session on Rabbit -
> > > https://etherpad.openstack.org/p/PHL-ops-rabbit-queue
> > > 
> > > Rabbit is a top operational concern for most large sites. Almost all
> > > sites have a "restart everything that talks to rabbit" script because
> > > during rabbit ha opperations queues tend to blackhole.
> > > 
> > > All other queue systems OpenStack supports are worse than Rabbit (from
> > > experience in that room).
> > > 
> > > oslo.messaging < 1.6.0 was a significant regression in dependability
> > > from the incubator code. It now seems to be getting better but still a
> > > lot of issues. (L112)
> > > 
> > > Operators *really* want the concept in
> > > https://review.openstack.org/#/c/146047/ landed. (I asked them to
> > > provide such feedback in gerrit).
> > > 
> > 
> > This reminded me that there are other options that need investigation.
> > 
> > A few of us have been looking at what it might take to use something
> > in between RabbitMQ and ZeroMQ for RPC and notifications. Some initial
> > forays into inspecting Gearman (which infra has successfully used for
> > quite some time as the backend of Zuul) look promising. A few notes:
> > 
> > * The Gearman protocol is crazy simple. There are currently 4 known
> > gearman
> >   server implementations: Perl, Java, C, and Python (written and
> >   maintained by our own infra team). http://gearman.org/download/ for
> >   the others, and https://pypi.python.org/pypi/gear for the python one.
> > 
> > * Gearman has no pub/sub capability built in for 1:N comms. However, it
> >   is fairly straight forward to write workers that will rebroadcast
> >   messages to subscribers.
> > 
> > * Gearman's security model is not very rich. Mostly, if you have been
> >   authenticated to the gearman server (only the C server actually even
> >   supports any type of authentication, via SSL client certs), you can
> >   do whatever you want including consuming all the messages in a queue
> >   or filling up a queue with nonsense. This has been raised as a concern
> >   in the past and might warrant extra work to add support to the python
> >   server and/or add ACL support.
> > 
> > Part of our motivation for this is that some of us are going to be
> > deploying a cloud soon and none of us are excited about deploying and
> > supporting RabbitMQ. So we may be proposing specs to add Gearman as a
> > deployment option soon.
> 
> That sounds really intriguing, and I look forward to reading it and
> learning more about gearman.
> 
> Be forewarned that oslo.messaging is pretty badly understaffed right
> now. Most of the original contributors have moved on, either to other
> parts of OpenStack or out of the community entirely. We can use more
> messaging experts to help with reviews and improvements. 
> 

Noted, and subscribed in gertty. :)

__
OpenStack Development Mailing 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] [Glance] Experimental API

[Sampath, Lakshmi]

We had a discussion with API WG today about what it means to be an 
"EXPERIMENTAL API" and here's the takeway from that discussion.

- API's can be experimental, but mark it clearly in the docs as such
- Experimental means a breaking change may be introduced
- Use /x1/ instead of /v1/  in the endpoint.

Thoughts/Suggestions?


Thanks
Lakshmi.

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

Re: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

[Ali, Haneef]

Horizon needs to support domain scoped token for this to work. I don’t think it 
is yet there.

https://review.openstack.org/#/c/148082/39
https://review.openstack.org/#/c/141153/

Thanks
Haneef

From: Lei Zhang [mailto:zhang.lei@gmail.com]
Sent: Wednesday, March 11, 2015 7:33 PM
To: openstack; OpenStack Development Mailing List
Subject: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api 
for horizon

is there anyone tryed this and successfully?

On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang 
mailto:zhang.lei@gmail.com>> wrote:
Hi guys,

I am setting up the keytone v3 api. Now I meet a issue about the `cloud_admin` 
policy.

Base on the http://www.florentflament.com/blog/setting-keystone-v3-domains.html 
article, I modify the cloud_admin policy to

```
"cloud_admin": "rule:admin_required and 
domain_id:ef0d30167f744401a0cbfcc938ea7d63",
```

But the cloud_admin don't work as expected. I failed to open all the identity 
panel ( like 
http:///horizon/identity/domains/)
Horizon tell me" Error: Unable to retrieve project list."
And keystone log warning:

```
2015-03-09 16:00:06.423 9415 DEBUG keystone.policy.backends.rules [-] enforce 
identity:list_user_projects: {'is_delegated_auth': False, 'access_token_id': 
None, 'user_id': u'6433222efd78459bb70ad9adbcfac418', 'roles': [u'_member_', 
u'admin'], 'trustee_id': None, 'trustor_id': None, 'consumer_id': None, 
'token': , 'project_id': 
u'4d170baaa89b4e46b239249eb5ec6b00', 'trust_id': None}, enforce 
/usr/lib/python2.7/dist-packages/keystone/policy/backends/rules.py:100
2015-03-09 16:00:06.061 9410 WARNING keystone.common.wsgi [-] You are not 
authorized to perform the requested action: identity:list_projects (Disable 
debug mode to suppress these details.)
```

​I make some debug and found that, the root cause is that the `context` 
variable in keystone has no `domain_id` field( like the above keystone log). So 
the `cloud_admin` rule failed.​ if i change the `cloud_admin` to following. It 
works as expected.

```
"cloud_admin": "rule:admin_required and 
user_id:6433222efd78459bb70ad9adbcfac418",
```

I found that in the keystone code[0], the domain_id only exist when it is a 
domain scope. But i believe that the horizon login token is a project one( I am 
not very sure this)

```
if token.project_scoped:
auth_context['project_id'] = token.project_id
elif token.domain_scoped:
auth_context['domain_id'] = token.domain_id
else:
LOG.debug('RBAC: Proceeding without project or domain scope')

```

Is it a bug? or some wrong configuration?


Following is my configuration.


```
# /etc/keystone/keystone.conf
[DEFAULT]
debug=true
verbose=true
log_dir=/var/log/keystone
[assignment]
driver = keystone.assignment.backends.sql.Assignment
[database]
connection=mysql://:@controller/keystone
[identity]
driver=keystone.identity.backends.sql.Identity
[memcache]
servers=controller1:11211,controller2:11211,controller3:1121
[token]
provider=keystone.token.providers.uuid.Provider
```

```
# /etc/openstack-dashboard/local_settings.py ( partly )
POLICY_FILES_PATH = "/etc/openstack-dashboard/"
POLICY_FILES = {
'identity': 'keystone_policy.json',
}
OPENSTACK_HOST = "127.0.0.1"
OPENSTACK_KEYSTONE_URL = "http://%s:5000/v3" % 
OPENSTACK_HOST
OPENSTACK_KEYSTONE_DEFAULT_ROLE = "_member_"
OPENSTACK_API_VERSIONS = {
 "data_processing": 1.1,
 "identity": 3,
 "volume": 2
}
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'admin'
```

​[0] 
https://github.com/openstack/keystone/blob/master/keystone/common/authorization.py#L58​

--
Lei Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l



--
Lei Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l
__
OpenStack Development Mailing 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] Deprecation warnings considered harmful?

[John Griffith]

On Thu, Mar 12, 2015 at 10:48 AM, Doug Hellmann 
wrote:

>
>
> On Thu, Mar 12, 2015, at 05:24 AM, Duncan Thomas wrote:
> > ubuntu@devstack-multiattach:~/devstack$ cinder-manage db sync
> > /usr/local/lib/python2.7/dist-packages/oslo_db/_i18n.py:19:
> > DeprecationWarning: The oslo namespace package is deprecated. Please use
> > oslo_i18n instead.
> >   from oslo import i18n
> > /opt/stack/cinder/cinder/openstack/common/policy.py:98:
> > DeprecationWarning:
> > The oslo namespace package is deprecated. Please use oslo_config instead.
> >   from oslo.config import cfg
> > /opt/stack/cinder/cinder/openstack/common/policy.py:99:
> > DeprecationWarning:
> > The oslo namespace package is deprecated. Please use oslo_serialization
> > instead.
> >   from oslo.serialization import jsonutils
> > /opt/stack/cinder/cinder/objects/base.py:25: DeprecationWarning: The oslo
> > namespace package is deprecated. Please use oslo_messaging instead.
> >   from oslo import messaging
> >
> /usr/local/lib/python2.7/dist-packages/oslo_concurrency/openstack/common/fileutils.py:22:
> > DeprecationWarning: The oslo namespace package is deprecated. Please use
> > oslo_utils instead.
> >   from oslo.utils import excutils
> >
>
> Yay, the system is working as designed!
>
> Oslo "froze" early to prepare releases to integrate with the downstream
> projects. You found an issue and reported it. Dims and others worked on
> patches, and we're releasing new versions. All before your feature
> freeze, so you can adopt them.
>
> >
> > What are normal, none developer users supposed to do with such warnings,
> > other than:
> > a) panic or b) Assume openstack is beta quality and then panic
>
> Next time, please try to be less snide. It makes it difficult to take
> you seriously.
>
> Doug
>
> >
> > --
> > Duncan Thomas
> >
> __
> > OpenStack Development Mailing 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
>

​Very cool!!  I think there may have been some misunderstanding here on how
this would all shake out, but yes as Doug and Dims pointed out this worked
great.  Thanks everyone!!​
__
OpenStack Development Mailing 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] readout from Philly Operators Meetup

[Doug Hellmann]

On Thu, Mar 12, 2015, at 12:47 PM, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2015-03-11 05:59:10 -0700:
> > =
> >  Additional Interesting Bits
> > =
> > 
> > Rabbit
> > --
> > 
> > There was a whole session on Rabbit -
> > https://etherpad.openstack.org/p/PHL-ops-rabbit-queue
> > 
> > Rabbit is a top operational concern for most large sites. Almost all
> > sites have a "restart everything that talks to rabbit" script because
> > during rabbit ha opperations queues tend to blackhole.
> > 
> > All other queue systems OpenStack supports are worse than Rabbit (from
> > experience in that room).
> > 
> > oslo.messaging < 1.6.0 was a significant regression in dependability
> > from the incubator code. It now seems to be getting better but still a
> > lot of issues. (L112)
> > 
> > Operators *really* want the concept in
> > https://review.openstack.org/#/c/146047/ landed. (I asked them to
> > provide such feedback in gerrit).
> > 
> 
> This reminded me that there are other options that need investigation.
> 
> A few of us have been looking at what it might take to use something
> in between RabbitMQ and ZeroMQ for RPC and notifications. Some initial
> forays into inspecting Gearman (which infra has successfully used for
> quite some time as the backend of Zuul) look promising. A few notes:
> 
> * The Gearman protocol is crazy simple. There are currently 4 known
> gearman
>   server implementations: Perl, Java, C, and Python (written and
>   maintained by our own infra team). http://gearman.org/download/ for
>   the others, and https://pypi.python.org/pypi/gear for the python one.
> 
> * Gearman has no pub/sub capability built in for 1:N comms. However, it
>   is fairly straight forward to write workers that will rebroadcast
>   messages to subscribers.
> 
> * Gearman's security model is not very rich. Mostly, if you have been
>   authenticated to the gearman server (only the C server actually even
>   supports any type of authentication, via SSL client certs), you can
>   do whatever you want including consuming all the messages in a queue
>   or filling up a queue with nonsense. This has been raised as a concern
>   in the past and might warrant extra work to add support to the python
>   server and/or add ACL support.
> 
> Part of our motivation for this is that some of us are going to be
> deploying a cloud soon and none of us are excited about deploying and
> supporting RabbitMQ. So we may be proposing specs to add Gearman as a
> deployment option soon.

That sounds really intriguing, and I look forward to reading it and
learning more about gearman.

Be forewarned that oslo.messaging is pretty badly understaffed right
now. Most of the original contributors have moved on, either to other
parts of OpenStack or out of the community entirely. We can use more
messaging experts to help with reviews and improvements. 

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

[openstack-dev] [openstack-operators][rally] What's new in Rally v0.0.2

[Boris Pavlovic]

Hi stackers,

For those who doesn't know Rally team started making releases.

There are 3 major reasons why we started doing releases:

 * A lot of people started using Rally in their CI/CD.

Usually they don't like to depend on something that is from master.
And would like to have smooth testable upgrades between versions

 * Rally is used in gates of many projects.

As far as you know in Rally everything is plugable. These plugins can be
put  in project tree. This is nice flexibility for all projects. But it
blocks a lot
   development of Rally. To resolve this issue we are going to allow
projects t
   specify which version of Rally to run in their trees. This resolves 2
issues:
   1) projects gates won't depend on Rally master
   2) projects have smooth, no downtime, testable way to switch to newer
   version of Rally

 * Release notes - as a simple way to track project changes.



Release stats:
+--+-+
| Commits  | **100** |
+--+-+
| Bug fixes| **18**  |
+--+-+
| Dev cycle|   **45 days**   |
+--+-+
| Release date | **12/Mar/2015** |
+--+-+


Release notes:

https://rally.readthedocs.org/en/latest/release_notes/v0.0.2.html


Pypi:

https://pypi.python.org/pypi/rally/0.0.2


Future goals:

Our goal is to cut releases ever 2 weeks.  As far as project is quite
bugless and stable we don't need feature freeze at all, so I don't think
that it will be hard to achieve this goal.


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

Re: [openstack-dev] [nova] readout from Philly Operators Meetup

[Sean Dague]

On 03/12/2015 12:47 PM, Clint Byrum wrote:
> Excerpts from Sean Dague's message of 2015-03-11 05:59:10 -0700:
>> =
>>  Additional Interesting Bits
>> =
>>
>> Rabbit
>> --
>>
>> There was a whole session on Rabbit -
>> https://etherpad.openstack.org/p/PHL-ops-rabbit-queue
>>
>> Rabbit is a top operational concern for most large sites. Almost all
>> sites have a "restart everything that talks to rabbit" script because
>> during rabbit ha opperations queues tend to blackhole.
>>
>> All other queue systems OpenStack supports are worse than Rabbit (from
>> experience in that room).
>>
>> oslo.messaging < 1.6.0 was a significant regression in dependability
>> from the incubator code. It now seems to be getting better but still a
>> lot of issues. (L112)
>>
>> Operators *really* want the concept in
>> https://review.openstack.org/#/c/146047/ landed. (I asked them to
>> provide such feedback in gerrit).
>>
> 
> This reminded me that there are other options that need investigation.
> 
> A few of us have been looking at what it might take to use something
> in between RabbitMQ and ZeroMQ for RPC and notifications. Some initial
> forays into inspecting Gearman (which infra has successfully used for
> quite some time as the backend of Zuul) look promising. A few notes:
> 
> * The Gearman protocol is crazy simple. There are currently 4 known gearman
>   server implementations: Perl, Java, C, and Python (written and
>   maintained by our own infra team). http://gearman.org/download/ for
>   the others, and https://pypi.python.org/pypi/gear for the python one.
> 
> * Gearman has no pub/sub capability built in for 1:N comms. However, it
>   is fairly straight forward to write workers that will rebroadcast
>   messages to subscribers.
> 
> * Gearman's security model is not very rich. Mostly, if you have been
>   authenticated to the gearman server (only the C server actually even
>   supports any type of authentication, via SSL client certs), you can
>   do whatever you want including consuming all the messages in a queue
>   or filling up a queue with nonsense. This has been raised as a concern
>   in the past and might warrant extra work to add support to the python
>   server and/or add ACL support.
> 
> Part of our motivation for this is that some of us are going to be
> deploying a cloud soon and none of us are excited about deploying and
> supporting RabbitMQ. So we may be proposing specs to add Gearman as a
> deployment option soon.

I think experimentation of other models is good. There was some
conversation that maybe Kafka was a better model as well. However,
realize that services are quite chatty at this point and push pretty
large payloads through that bus. The HA story is also quite important,
because the underlying message architecture assumes reliable delivery
for some of the messages, and if they fall on the floor, you'll get
either leaked resources, or broken resources. It's actually the HA
recovery piece of Rabbit (and when it doesn't HA recover correctly)
that's seemingly the sharp edge most people are hitting.

So... experimentation is good, but also important to realize how much is
provided for by the infrastructure that's there.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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] readout from Philly Operators Meetup

[Clint Byrum]

Excerpts from Sean Dague's message of 2015-03-11 05:59:10 -0700:
> =
>  Additional Interesting Bits
> =
> 
> Rabbit
> --
> 
> There was a whole session on Rabbit -
> https://etherpad.openstack.org/p/PHL-ops-rabbit-queue
> 
> Rabbit is a top operational concern for most large sites. Almost all
> sites have a "restart everything that talks to rabbit" script because
> during rabbit ha opperations queues tend to blackhole.
> 
> All other queue systems OpenStack supports are worse than Rabbit (from
> experience in that room).
> 
> oslo.messaging < 1.6.0 was a significant regression in dependability
> from the incubator code. It now seems to be getting better but still a
> lot of issues. (L112)
> 
> Operators *really* want the concept in
> https://review.openstack.org/#/c/146047/ landed. (I asked them to
> provide such feedback in gerrit).
> 

This reminded me that there are other options that need investigation.

A few of us have been looking at what it might take to use something
in between RabbitMQ and ZeroMQ for RPC and notifications. Some initial
forays into inspecting Gearman (which infra has successfully used for
quite some time as the backend of Zuul) look promising. A few notes:

* The Gearman protocol is crazy simple. There are currently 4 known gearman
  server implementations: Perl, Java, C, and Python (written and
  maintained by our own infra team). http://gearman.org/download/ for
  the others, and https://pypi.python.org/pypi/gear for the python one.

* Gearman has no pub/sub capability built in for 1:N comms. However, it
  is fairly straight forward to write workers that will rebroadcast
  messages to subscribers.

* Gearman's security model is not very rich. Mostly, if you have been
  authenticated to the gearman server (only the C server actually even
  supports any type of authentication, via SSL client certs), you can
  do whatever you want including consuming all the messages in a queue
  or filling up a queue with nonsense. This has been raised as a concern
  in the past and might warrant extra work to add support to the python
  server and/or add ACL support.

Part of our motivation for this is that some of us are going to be
deploying a cloud soon and none of us are excited about deploying and
supporting RabbitMQ. So we may be proposing specs to add Gearman as a
deployment option soon.

__
OpenStack Development Mailing 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] Deprecation warnings considered harmful?

[Doug Hellmann]

On Thu, Mar 12, 2015, at 05:24 AM, Duncan Thomas wrote:
> ubuntu@devstack-multiattach:~/devstack$ cinder-manage db sync
> /usr/local/lib/python2.7/dist-packages/oslo_db/_i18n.py:19:
> DeprecationWarning: The oslo namespace package is deprecated. Please use
> oslo_i18n instead.
>   from oslo import i18n
> /opt/stack/cinder/cinder/openstack/common/policy.py:98:
> DeprecationWarning:
> The oslo namespace package is deprecated. Please use oslo_config instead.
>   from oslo.config import cfg
> /opt/stack/cinder/cinder/openstack/common/policy.py:99:
> DeprecationWarning:
> The oslo namespace package is deprecated. Please use oslo_serialization
> instead.
>   from oslo.serialization import jsonutils
> /opt/stack/cinder/cinder/objects/base.py:25: DeprecationWarning: The oslo
> namespace package is deprecated. Please use oslo_messaging instead.
>   from oslo import messaging
> /usr/local/lib/python2.7/dist-packages/oslo_concurrency/openstack/common/fileutils.py:22:
> DeprecationWarning: The oslo namespace package is deprecated. Please use
> oslo_utils instead.
>   from oslo.utils import excutils
>

Yay, the system is working as designed!

Oslo "froze" early to prepare releases to integrate with the downstream
projects. You found an issue and reported it. Dims and others worked on
patches, and we're releasing new versions. All before your feature
freeze, so you can adopt them.
 
> 
> What are normal, none developer users supposed to do with such warnings,
> other than:
> a) panic or b) Assume openstack is beta quality and then panic

Next time, please try to be less snide. It makes it difficult to take
you seriously.

Doug

> 
> -- 
> Duncan Thomas
> __
> OpenStack Development Mailing 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] proper way to extend index() and add a new property?

[Chris Friesen]

On 03/12/2015 08:47 AM, Chris Friesen wrote:


I'm looking for some technical advice on API extensions.

I want to add a new field to the output of the "nova service-list" command,
which currently maps to ServiceController.index().

For the v2 API this seems straightforward, I can add a new extension and in the
existing function I can call self.ext_mgr.is_loaded() to see if my extension is
loaded, similar to the existing code that checks for 
'os-extended-services-delete'.

For v2.1 (ie the plugins in the v3 directory) the extension management seems to
be different though.  As far as I can tell I can only extend the controller and
create a new index() that takes as arguments the request and the output of the
existing index() function.


Never mind, I've since learned about microversions and the fact that the v2 API 
is frozen. I think I'm good.


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-dev] [all] oslo.db 1.7.0 release

[Doug Hellmann]

The Oslo team is content to announce the release of:

oslo.db 1.7.0: oslo.db library

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

http://launchpad.net/oslo.db/+milestone/1.7.0

Please report issues through launchpad:

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

Notable changes


We hope to make this the last release of the library for the Kilo cycle.

Changes in oslo.db 1.6.0..1.7.0
---

464a3d0 Switch to non-namespaced module import - oslo_i18n
95d4543 Fix documented env variable for test connection
d0a0fdf Updated from global requirements

Diffstat (except docs and test files)
-

oslo_db/_i18n.py| 4 ++--
oslo_db/sqlalchemy/test_base.py | 2 +-
test-requirements-py2.txt   | 2 +-
test-requirements-py3.txt   | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)


Requirements updates


diff --git a/test-requirements-py2.txt b/test-requirements-py2.txt
index 34e18db..6ff3a1b 100644
--- a/test-requirements-py2.txt
+++ b/test-requirements-py2.txt
@@ -19 +19 @@ testtools>=0.9.36,!=1.2.0
-tempest-lib>=0.2.0
+tempest-lib>=0.3.0
diff --git a/test-requirements-py3.txt b/test-requirements-py3.txt
index 03670e8..4290cc6 100644
--- a/test-requirements-py3.txt
+++ b/test-requirements-py3.txt
@@ -19 +19 @@ testtools>=0.9.36,!=1.2.0
-tempest-lib>=0.2.0
+tempest-lib>=0.3.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] oslo.policy 0.3.1 release

[Doug Hellmann]

The Oslo team is content to announce the release of:

oslo.policy 0.3.1: RBAC policy enforcement library for OpenStack

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

http://launchpad.net/oslo.policy/+milestone/0.3.1

Please report issues through launchpad:

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

Notable changes


We hope to make this the last release of the library for the Kilo cycle.

Changes in oslo.policy 0.3.0..0.3.1
---

f9aaf11 Switch to non-namespaced module imports

Diffstat (except docs and test files)
-

oslo_policy/openstack/common/fileutils.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

__
OpenStack Development Mailing 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] FW: [nova] readout from Philly Operators Meetup

[Tim Bell]

> I completely agree with you - Sean and Joe.
>
> Since the argument was brought up I just wanted to point out that this "quota 
> service" thing is a bit of a unicorn at the moment, and it should not 
> distract from fixing and improving quota maangement & enforcement logic in 
> the various openstack projects.
>
> I wan't be able to introduce hierarchical quotas in neutron by the end of 
> Kilo, but I'll keep it on the roadmap for Liberty.
>
> Salvatore
>

Given the hierarchical quotas make the quota handling more complex (to ensure 
parent quotas are consistent as well), this would seem a good candidate for an 
oslo library. During the Nova quota discussions, there was much consideration 
for how things would work and it would be a great cause of confusion if each 
project has its own approach/semantics.

A central quota service would then be a later decision which would have less 
impact if the code for quotas is shared.

Tim

> On 12 March 2015 at 11:59, Sean Dague  wrote:
> On 03/11/2015 08:31 PM, Joe Gordon wrote:
> >
> >
> > On Wed, Mar 11, 2015 at 4:07 PM, Ihar Hrachyshka  > > wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 03/11/2015 07:48 PM, Joe Gordon wrote:
> > > Out of sync Quotas --
> > >
> > > https://etherpad.openstack.org/p/PHL-ops-nova-feedback L63
> > >
> > > The quotas code is quite racey (this is kind of a known if you look
> > > at the bug tracker). It was actually marked as a top soft spot
> > > during last fall's bug triage -
> > > 
> > http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html
> > >
> > >  There is an operator proposed spec for an approach here -
> > > https://review.openstack.org/#/c/161782/
> > >
> > > Action: we should make a solution here a top priority for enhanced
> > > testing and fixing in Liberty. Addressing this would remove a lot
> > > of pain from ops.
> > >
> > >
> > > To help us better track quota bugs I created a quotas tag:
> > >
> > > https://bugs.launchpad.net/nova/+bugs?field.tag=quotas
> > >
> > > Next step is re-triage those bugs: mark fixed bugs as fixed,
> > > deduplicate bugs etc.
> >
> > (Being quite far from nova code, so ignore if not applicable)
> >
> > I would like to note that other services experience races in quota
> > management too. Neutron has a spec approved to land in Kilo-3 that is
> > designed to introduce a new quota enforcement mechanism that is
> > expected to avoid (some of those) races:
> >
> > 
> > https://github.com/openstack/neutron-specs/blob/master/specs/kilo/better-quotas.rst
> >
> > I thought you may be interested in looking into it to apply similar
> > ideas to nova.
> >
> >
> > Working on a library for this hasn't been ruled out yet. But right now I
> > am simply trying to figure out how to reproduce the issue, and nothing else.
> Right, I think assuming an architecture change will magically fix this
> without scenarios that expose the existing bugs seems overly optimistic.
>
> I think there is a short / medium term test / reproduce question here,
> then a longer term question about different architecture.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
> __
> OpenStack Development Mailing 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] [all] oslo.concurrency 1.8.0 release

[Doug Hellmann]

The Oslo team is content to announce the release of:

oslo.concurrency 1.8.0: oslo.concurrency library

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

http://launchpad.net/oslo.concurrency/+milestone/1.8.0

Please report issues through launchpad:

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

Notable changes


We hope to make this the last release of the library for the Kilo cycle.

Changes in oslo.concurrency 1.7.0..1.8.0


ff54256 Switch to non-namespaced module imports
94624a7 Remove py33 env from default tox list
46fcdd3 Add lockutils.get_lock_path() function

Diffstat (except docs and test files)
-

oslo_concurrency/lockutils.py  | 16 +++-
oslo_concurrency/openstack/common/fileutils.py |  2 +-
tox.ini|  2 +-
4 files changed, 34 insertions(+), 3 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] [all] oslo.config 1.9.3 release

[Doug Hellmann]

The Oslo team is content to announce the release of:

oslo.config 1.9.3: Oslo Configuration API

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

http://launchpad.net/oslo.config/+milestone/1.9.3

Please report issues through launchpad:

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

Notable changes


We hope to make this the last release of the library for the Kilo cycle.

Changes in oslo.config 1.9.2..1.9.3
---

3c51838 Switch to non-namespaced module imports

Diffstat (except docs and test files)
-

oslo_config/generator.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

__
OpenStack Development Mailing 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] [QA][Keystone] Test plan template

[Adam Young]

I posted a test plan temoplate for review.  WHile my template is 
specific to Keystone, I think that it will benefit from a wider review.


I did not see a comparable document elsewhere.  There are the qa specs, 
but those look more like feature proposals for QA infrastructure than 
for test plans.  Tempest doesn't seem to have a specs repo, although 
with the push top do functional testing in the individual projects, I 
suspect that these would not belong to tempest, either.



Here is my review;  https://review.openstack.org/#/c/163882/

I took the document that we use in house and attempted to streamline 
it.  This template is long due mostly to the guidance text,  which 
should be removed in the submitted document.


__
OpenStack Development Mailing 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] oslo.concurrency runtime dependency on fixtures/testtools

[Ben Nemec]

On 03/12/2015 09:18 AM, Brant Knudson wrote:
> On Thu, Mar 12, 2015 at 7:20 AM, Davanum Srinivas  wrote:
> 
>> Alan,
>>
>> We are debating this on:
>> https://review.openstack.org/#/c/157135/
>>
>> Please hop on :)
>> -- dims
>>
>> On Thu, Mar 12, 2015 at 5:28 AM, Alan Pevec  wrote:
>>> Hi,
>>>
>>> hijacking this thread to point out something that feels wrong in the
>>> dependency chain which jumped out:
>>>
 Colecting testtools>=0.9.22 (from
>> fixtures>=0.3.14->oslo.concurrency>=1.4.1->keystone==2015.1.dev395)
>>>
>>> fixtures is imported in oslo_concurrency/fixture/lockutils.py but
>>> that's not really used at _runtime_
>>>
>>>
>>> Cheers,
>>> Alan
>>>
>>
> 
> And it's also being discussed in keystone for deps for non-default
> features: https://review.openstack.org/#/c/162360/
> 
> -- Brant

We actually have a spec open to discuss this for the Oslo libs.  Would
love to get more input on it: https://review.openstack.org/#/c/153966/

It's possible that will need to become a cross-project spec if we
determine that more projects need an optional deps policy (which is
sounding like the case).

-Ben


__
OpenStack Development Mailing 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] pip wheel' requires the 'wheel' package

[Timothy Swanson (tiswanso)]

Hi guys,

I got to this again today and realized that I had copied a local.conf w/ 
"OFFLINE=True”.  Removing that resolved the issue w/ the run of stack.sh.

Hope that helps!

—Tim

On Mar 11, 2015, at 12:41 PM, Donald Stufft 
mailto:don...@stufft.io>> wrote:

Is it using an old version of setuptools? Like <0.6.28.

On Mar 11, 2015, at 11:28 AM, Timothy Swanson (tiswanso) 
mailto:tiswa...@cisco.com>> wrote:

I don’t have any solution just chiming in that I see the same error with 
devstack pulled from master on a new ubuntu trusty VM created last night.

'pip install —upgrade wheel’ indicates:
Requirement already up-to-date: wheel in /usr/local/lib/python2.7/dist-packages

Haven’t gotten it cleared up.

Thanks,

Tim

On Mar 2, 2015, at 2:11 AM, Smigiel, Dariusz 
mailto:dariusz.smig...@intel.com>> wrote:



From: yuntong [mailto:yuntong...@gmail.com]
Sent: Monday, March 2, 2015 7:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [devstack] pip wheel' requires the 'wheel' package

Hello,
I got an error when try to ./stack.sh as:
2015-03-02 05:58:20.692 | net.ipv4.ip_local_reserved_ports = 35357,35358
2015-03-02 05:58:20.959 | New python executable in tmp-venv-NoMO/bin/python
2015-03-02 05:58:22.056 | Installing setuptools, pip...done.
2015-03-02 05:58:22.581 | ERROR: 'pip wheel' requires the 'wheel' package. To 
fix this, run: pip install wheel

After pip install wheel, got same error.
In [2]: wheel.__path__
Out[2]: ['/usr/local/lib/python2.7/dist-packages/wheel']
In [5]: pip.__path__
Out[5]: ['/usr/local/lib/python2.7/dist-packages/pip']

$ which python
/usr/bin/python

As above, the wheel can be imported successfully,
any hints ?

Thanks.

Did you try pip install –upgrade wheel ?
__
OpenStack Development Mailing 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

---
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 Development Mailing 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] proposing rameshg87 to ironic-core

[Devananda van der Veen]

Without further ado, and since everyone (even though some haven't replied
here) has +1'd this, and since we could really use ramesh's +2's in the run
up to Kilo-3 and feature freeze, even without the customary waiting/voting
period being completely satisfied (after all, when we all agree, why wait a
week?), I'd like to officially welcome him to the core team.

-Devananda

On Tue, Mar 10, 2015 at 10:03 AM David Shrewsbury 
wrote:

> +1
>
> On Mar 9, 2015, at 6:03 PM, Devananda van der Veen <
> devananda@gmail.com> wrote:
>
> Hi all,
>
> I'd like to propose adding Ramakrishnan (rameshg87) to ironic-core.
>
> He's been consistently providing good code reviews, and been in the top
> five active reviewers for the last 90 days and top 10 for the last 180
> days. Two cores have recently approached me to let me know that they, too,
> find his reviews valuable.
>
> Furthermore, Ramakrishnan has made significant code contributions to
> Ironic over the last year. While working primarily on the iLO driver, he
> has also done a lot of refactoring of the core code, touched on several
> other drivers, and maintains the proliantutils library on stackforge. All
> in all, I feel this demonstrates a good and growing knowledge of the
> codebase and architecture of our project, and feel he'd be a valuable
> member of the core team.
>
> Stats, for those that want them, are below the break.
>
> Best Regards,
> Devananda
>
>
>
> http://stackalytics.com/?release=all&module=ironic-group&user_id=rameshg87
>
> http://russellbryant.net/openstack-stats/ironic-reviewers-90.txt
> http://russellbryant.net/openstack-stats/ironic-reviewers-180.txt
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

[Okuma, Wayne]

My vote is for 1500.

-Original Message-
From: Hemanth Makkapati [mailto:hemanth.makkap...@rackspace.com] 
Sent: Thursday, March 12, 2015 8:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

+1 to consistent time. 
Both 1400 and 1500 work me.

-Hemanth

From: Ian Cordasco 
Sent: Wednesday, March 11, 2015 10:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

I have no opinions on the matter. Either 1400 or 1500 work for me. I think 
there are a lot of people asking for it to be at 1500 instead though.
Would anyone object to changing it to 1500 instead (as long as it is one 
consistent time for the meeting)?

On 3/11/15, 01:53, "Inessa Vasilevskaya" 
wrote:

>+1
>
>
>On Mon, Mar 9, 2015 at 2:43 AM, Alexander Tivelkov 
> wrote:
>
>Works for me, but the previous one worked as well. So, consider my vote 
>as +1 unless the majority is against this :)
>
>
>--
>Regards,
>Alexander Tivelkov
>
>
>
>
>On Mon, Mar 9, 2015 at 12:36 AM, Fei Long Wang 
> wrote:
>
>Oh, it means 3:00AM for me :-(
>
>
>On 09/03/15 09:07, Nikhil Komawar wrote:
>
>
>
>
>
>
>Hi all,
>
>
>Currently, we've alternating time for Glance meetings. Now, with the 
>Daylight savings being implemented in some parts of the world, we're 
>thinking of moving the meeting time to just one slot i.e. earlier in 
>the day(night). This solves the original conflicting  times issue that 
>a subset of the individuals had; to add to that the schedule is less 
>confusing and unified.
>
>
>
>So, the new proposal is:
>Glance meetings [1] to be conducted
>weekly on
>Thursdays at 1400UTC [2] on
>#openstack-meeting-4
>
>
>
>This would be implemented on Mar 19th, given there are no major 
>objections.
>
>
>Please vote with +1/-1 here.
>
>
>
>[1]
>https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting
>
>[2]
>http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=
>0 
>=0>
>
>
>Thanks,
>-Nikhil
>
>
>
>
>
>
>___
>___ OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.
>openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>--
>Cheers & Best regards,
>Fei Long Wang (王飞龙)
>---
>---
>Senior Cloud Software Engineer
>Tel: +64-48032246 
>Email: flw...@catalyst.net.nz
>Catalyst IT Limited
>Level 6, Catalyst House, 150 Willis Street, Wellington
>---
>---
>
>
>___
>___ OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>
>
>
>
>___
>___ OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>

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

Re: [openstack-dev] [nova] Enabling VM post-copy live migration

[John Garbutt]

On 12 March 2015 at 12:26, Luis Tomas  wrote:
> On 03/12/2015 12:34 PM, John Garbutt wrote:
>>
>> On 12 March 2015 at 08:41, Luis Tomas  wrote:
>>>
>>> Hi,
>>>
>>> As part of an European (FP7) project, named ORBIT
>>> (http://www.orbitproject.eu/), I'm working on including the possibility
>>> of
>>> live-migrating VMs in OpenStack in a post-copy mode.
>>> This way of live-migrating VMs basically moves the computation right away
>>> to
>>> the destination and then the VM starts working from there, while still
>>> copying the memory from the source to the new location of the VM. That
>>> way
>>> the memory pages are only copied as if the VM modifies them, they are
>>> already in the destination host. This basically ensures that migrations
>>> finish regardless of what the VM is doing, i.e., even extremely memory
>>> intensive VMs. Therefore removing the problem of having VMs hanging on in
>>> migrating state forever (as discussed in previous mails, e.g.,
>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2015-February/055725.html).
>>>
>>> So far, I have included and tested this new functionality at the JUNO
>>> version, and the code modifications can be found in the github repository
>>> of
>>> the project (branch named "post-copy"):
>>>  - https://github.com/orbitfp7/nova/tree/post-copy --> mainly
>>> enabling
>>> the possibility of using the libvirt post-copy flag (libvirt driver.py).
>>> Note post-copy migration is not using "tunneling" as LibVirt patch for
>>> that
>>> is not yet ready.
>>>  - https://github.com/orbitfp7/python-novaclient/tree/post-copy -->
>>> adding the possibility of using the post-copy mode when triggering the
>>> migration: nova live-migration [--block-migrate] [--post-copy] VM_ID
>>>  - https://github.com/orbitfp7/horizon/tree/post-copy --> include a
>>> checkbox in the live-migration panel to perform the migration in
>>> post-copy
>>> mode. (like the one for enabling block-migration)
>>>
>>> To be able to live-migrate VMs in a post-copy way, I'm relying on some
>>> kernel+qemu+libvirt modifications, not yet merged upstream (but in their
>>> way
>>> to it), also available at the project github:
>>>  - Kernel: https://lkml.org/lkml/2015/3/5/576
>>>  - Qemu: https://github.com/orbitfp7/qemu/tree/wp3-postcopy
>>>  - LibVirt: https://github.com/orbitfp7/libvirt/tree/wp3-postcopy
>>
>> Before merging the code in Nova, we usually like the dependent
>> features to be released by the respective projects.
>>
>> Ideally we would like it to be easy to run that on some distro so
>> people could test/use the feature fairly easily.
>
> Yes, that's why I proposed to target the version after kilo (or even the
> next to that one if need be)

Ah, cool. I just wanted to be explicit about that.

>>> If this is a nice feature to have in future versions of OpenStack, I'm
>>> happy
>>> to adapt the code for the next release (the one after KILO). Any comments
>>> are really welcome.
>>
>> It sounds like something that doesn't need an API call, as its a
>> deployer choice if they have support for this new live-migrate mode.
>> Is that true?
>>
>> Although maybe it has a substantial runtime penalty as a page read
>> miss causes a fetch across the network, making it a user choice? Or do
>> you only start the fetch mode at the point you detect a failure to
>> "merge" using the regular live-migrate mode?
>
>
> I think it should be up to the user/admin what option to choose.
> Although post-copy ensures that the migration will finish, as you said, it
> could have some impact into the VM performance due to having to wait until a
> missing memory page is fetched. Anyway, I wouldn't say there is a
> substantial runtime penalty. In fact, the libvirt flag that we have included
> in OpenStack basically tries pre-copy first (normal live-migration), and
> after trying to copy all the memory once (first iteration), automatically
> changes to post-copy, meaning moving the VM cpu to the destination and only
> having to copy the remaining pages (the ones dirtied while doing the first
> copy iteration). This way the impact into the application performance is
> minimized.

Ah, thats what I was trying to describe and failed. Sounds good.

> On the other hand, post-copy has a downside. If by any chance the migration
> crash during the process, unlike pre-copy, you can not recover the VM as not
> the source nor the destination has a fully working VM at the time (part of
> the memory in the source, part of it at the destination).

Eek, good point.

> These are basically the reasons we considered for making it as an optional
> choice.

Totally make sense.

Only tip is to include that sort of information when you submit your
nova-spec, once those features are merged and released.

Thanks,
John

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscr

Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

[Hemanth Makkapati]

+1 to consistent time. 
Both 1400 and 1500 work me.

-Hemanth

From: Ian Cordasco 
Sent: Wednesday, March 11, 2015 10:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

I have no opinions on the matter. Either 1400 or 1500 work for me. I think
there are a lot of people asking for it to be at 1500 instead though.
Would anyone object to changing it to 1500 instead (as long as it is one
consistent time for the meeting)?

On 3/11/15, 01:53, "Inessa Vasilevskaya" 
wrote:

>+1
>
>
>On Mon, Mar 9, 2015 at 2:43 AM, Alexander Tivelkov
> wrote:
>
>Works for me, but the previous one worked as well. So, consider my vote
>as +1 unless the majority is against this :)
>
>
>--
>Regards,
>Alexander Tivelkov
>
>
>
>
>On Mon, Mar 9, 2015 at 12:36 AM, Fei Long Wang
> wrote:
>
>Oh, it means 3:00AM for me :-(
>
>
>On 09/03/15 09:07, Nikhil Komawar wrote:
>
>
>
>
>
>
>Hi all,
>
>
>Currently, we've alternating time for Glance meetings. Now, with the
>Daylight savings being implemented in some parts of the world, we're
>thinking of moving the meeting time to just one slot i.e. earlier in the
>day(night). This solves the original conflicting
> times issue that a subset of the individuals had; to add to that the
>schedule is less confusing and unified.
>
>
>
>So, the new proposal is:
>Glance meetings [1] to be conducted
>weekly on
>Thursdays at 1400UTC [2] on
>#openstack-meeting-4
>
>
>
>This would be implemented on Mar 19th, given there are no major
>objections.
>
>
>Please vote with +1/-1 here.
>
>
>
>[1]
>https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting
>
>[2]
>http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0
>
>
>
>Thanks,
>-Nikhil
>
>
>
>
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.
>openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>--
>Cheers & Best regards,
>Fei Long Wang (王飞龙)
>--
>Senior Cloud Software Engineer
>Tel: +64-48032246 
>Email: flw...@catalyst.net.nz
>Catalyst IT Limited
>Level 6, Catalyst House, 150 Willis Street, Wellington
>--
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>
>
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>

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

Re: [openstack-dev] [stable] Icehouse 2014.1.4 freeze exceptions

[Tristan Cacqueray]

On 03/12/2015 07:33 AM, Ihar Hrachyshka wrote:
> For OSSA patch, there seems to be some concerns and issues with the
> patch that was developed under embargo. It seems it will take more
> time than expected to merge it in master. It may mean we will actually
> miss the backport for 2014.1.4.

The master review is now in the gate pipeline and should be merged anytime
soon. Considering the lengthy backlog for this bug, I would prefer having
people actually test the proposed solution before pushing the stable backports.

Can Paul (in CC) please have a look at the last patch set, as you are the one
who found the main drawback in the firsts iterations...


Regards,
Tristan



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] [Glance] Nitpicking in code reviews

[Nikhil Komawar]

+2A :P (Daniel and Ian)

Thanks,
-Nikhil


From: Ian Cordasco 
Sent: Thursday, March 12, 2015 10:59 AM
To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [Glance] Nitpicking in code reviews

On 3/12/15, 09:26, "Daniel P. Berrange"  wrote:

>On Thu, Mar 12, 2015 at 09:07:30AM -0500, Flavio Percoco wrote:
>> On 11/03/15 15:06 -1000, John Bresnahan wrote:
>> >FWIW I agree with #3 and #4 but not #1 and #2.  Spelling is an easy
>>enough
>> >thing to get right and speaks to the quality standard to which the
>>product
>> >is held even in commit messages and comments (consider the 'broken
>>window
>> >theory').  Of course everyone makes mistakes (I am a terrible speller)
>>but
>> >correcting a spelling error should be a trivial matter.  If a reviewer
>> >notices a spelling error I would expect them to point it.
>>
>> I'd agree depending on the status of the patch. If the patch has
>> already 2 +2s and someone blocks it because of a spelling error, then
>> the cost of fixing it, running the CI jobs and getting the reviews
>> again is higher than living with a simple typo.
>
>Also remember that submitting patches which fix typos is a great way
>for new contributors to gain a ATC and thus qualify for free design
>summit pass, so it is good to leave plenty of typos around :-P

So we should file more bugs with low-hanging fruit for these? I kind of
like that idea. Those bugs can be immediately triaged unlike some of
Glance’s other bugs.

Cheers,

Ian

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

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

Re: [openstack-dev] [Glance] Nitpicking in code reviews

[Ian Cordasco]

On 3/12/15, 09:26, "Daniel P. Berrange"  wrote:

>On Thu, Mar 12, 2015 at 09:07:30AM -0500, Flavio Percoco wrote:
>> On 11/03/15 15:06 -1000, John Bresnahan wrote:
>> >FWIW I agree with #3 and #4 but not #1 and #2.  Spelling is an easy
>>enough
>> >thing to get right and speaks to the quality standard to which the
>>product
>> >is held even in commit messages and comments (consider the 'broken
>>window
>> >theory').  Of course everyone makes mistakes (I am a terrible speller)
>>but
>> >correcting a spelling error should be a trivial matter.  If a reviewer
>> >notices a spelling error I would expect them to point it.
>> 
>> I'd agree depending on the status of the patch. If the patch has
>> already 2 +2s and someone blocks it because of a spelling error, then
>> the cost of fixing it, running the CI jobs and getting the reviews
>> again is higher than living with a simple typo.
>
>Also remember that submitting patches which fix typos is a great way
>for new contributors to gain a ATC and thus qualify for free design
>summit pass, so it is good to leave plenty of typos around :-P

So we should file more bugs with low-hanging fruit for these? I kind of
like that idea. Those bugs can be immediately triaged unlike some of
Glance’s other bugs.

Cheers,

Ian

__
OpenStack Development Mailing 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] proper way to extend index() and add a new property?

[Chris Friesen]

I'm looking for some technical advice on API extensions.

I want to add a new field to the output of the "nova service-list" command, 
which currently maps to ServiceController.index().


For the v2 API this seems straightforward, I can add a new extension and in the 
existing function I can call self.ext_mgr.is_loaded() to see if my extension is 
loaded, similar to the existing code that checks for 'os-extended-services-delete'.


For v2.1 (ie the plugins in the v3 directory) the extension management seems to 
be different though.  As far as I can tell I can only extend the controller and 
create a new index() that takes as arguments the request and the output of the 
existing index() function.


The problem I have with this is that the existing index() function returns a 
dict with one key per service in the cluster, which could be quite a few.  It 
seems highly inefficient to look up all the services *again* and extract the 
single value from each that I care about and add it to the output of the 
original index() function.  The best I can do for efficiency is O(n + n * log(n)).


Is there a better way to handle this?  Maybe a way to modify the existing v2.1 
index() function to check whether the new extension is loaded and add in the new 
field based on that (similar to how it's done in v2)?


Thanks,
Chris

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

Re: [openstack-dev] [nova][neutron][nfv] is there any reason neutron.allow_duplicate_networks should not be True by default?

[Matt Riedemann]

On 3/11/2015 7:23 PM, Ian Wells wrote:

On 11 March 2015 at 10:56, Matt Riedemann mailto:mrie...@linux.vnet.ibm.com>> wrote:

While looking at some other problems yesterday [1][2] I stumbled
across this feature change in Juno [3] which adds a config option
"allow_duplicate_networks" to the [neutron] group in nova. The
default value is False, but according to the spec [4] neutron allows
this and it's just exposing a feature available in neutron via nova
when creating an instance (create the instance with 2 ports from the
same network).

My question then is why do we have a config option to toggle a
feature that is already supported in neutron and is really just
turning a failure case into a success case, which is generally
considered OK by our API change guidelines [5].

I'm wondering if there is anything about this use case that breaks
other NFV use cases, maybe something with SR-IOV / PCI?  If not, I
plan on pushing a change to deprecate the option in Kilo and remove
it in Liberty with the default being to allow the operation.


This was all down to backward compatibility.

Nova didn't allow two interfaces on the same Neutron network.  We tried
to change this by filing a bug, and the patches got rejected because the
original behaviour was claimed to be intentional and desirable.  (It's
not clear that it was intentional behaviour because it was never
documented, but the same lack of documented intent meant it's also not
clear it was a bug, so the situation was ambiguous.)

Eventually it was fixed as new functionality using a spec [1] so that
the change and reasoning could be clearly described, and because of the
previous concerns, Racha, who implemented the spec, additionally chose
to use a config item to preserve the original behaviour unless the new
one was explicitly requested.
--
Ian.

[1]
https://review.openstack.org/#/c/97716/5/specs/juno/nfv-multiple-if-1-net.rst


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



For anyone following along, we're deprecating the 
allow_duplicated_networks option in Kilo and will remove it in Liberty 
(and just make it work like this by default):


https://review.openstack.org/#/c/163581/

--

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

Re: [openstack-dev] [Glance] Nitpicking in code reviews

[Daniel P. Berrange]

On Thu, Mar 12, 2015 at 09:07:30AM -0500, Flavio Percoco wrote:
> On 11/03/15 15:06 -1000, John Bresnahan wrote:
> >FWIW I agree with #3 and #4 but not #1 and #2.  Spelling is an easy enough
> >thing to get right and speaks to the quality standard to which the product
> >is held even in commit messages and comments (consider the 'broken window
> >theory').  Of course everyone makes mistakes (I am a terrible speller) but
> >correcting a spelling error should be a trivial matter.  If a reviewer
> >notices a spelling error I would expect them to point it.
> 
> I'd agree depending on the status of the patch. If the patch has
> already 2 +2s and someone blocks it because of a spelling error, then
> the cost of fixing it, running the CI jobs and getting the reviews
> again is higher than living with a simple typo.

Also remember that submitting patches which fix typos is a great way
for new contributors to gain a ATC and thus qualify for free design
summit pass, so it is good to leave plenty of typos around :-P

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

Re: [openstack-dev] [Openstack] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

[Lei Zhang]

I created project for the user admin(6433222efd78459bb70ad9adbcfac418).

The token horizon is past is a project scope token. So it can not passed
the cloud_admin rule.
I changed the rule to the admin_id is a little trick, and it works.

On Thu, Mar 12, 2015 at 5:16 PM, Trelohan Christophe <
ctrelo...@voyages-sncf.com> wrote:

> Hello,
>
> Does user_id replaced in cloud_admin rule is id of cloud_admin user ?
> I don't think you can log in with cloud_admin user in horizon, it seems
> that without project created for an user, you can't log in
> in horizon.
>
> I'm also interested in this, I also followed the mentioned article, but
> when I try to login with "admin" user in "default" domain,
> I have the same error (not authorized to list_projects). Both with horizon
> and Rest API.
>
>
>
>
> De : Lei Zhang [mailto:zhang.lei@gmail.com]
> Envoyé : jeudi 12 mars 2015 03:33
> À : openstack; OpenStack Development Mailing List
> Objet : [Openstack] [Horizon][Keystone] Failed to set up keystone v3 api
> for horizon
>
> is there anyone tryed this and successfully?
>
> On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang  wrote:
> Hi guys,
>
> I am setting up the keytone v3 api. Now I meet a issue about the
> `cloud_admin` policy.
>
> Base on the
> http://www.florentflament.com/blog/setting-keystone-v3-domains.html
> article, I modify the cloud_admin policy to
>
> ```
> "cloud_admin": "rule:admin_required and
> domain_id:ef0d30167f744401a0cbfcc938ea7d63",
> ```
>
> But the cloud_admin don't work as expected. I failed to open all the
> identity panel ( like http:///horizon/identity/domains/)
> Horizon tell me" Error: Unable to retrieve project list."
> And keystone log warning:
>
> ```
> 2015-03-09 16:00:06.423 9415 DEBUG keystone.policy.backends.rules [-]
> enforce identity:list_user_projects: {'is_delegated_auth': False,
> 'access_token_id': None, 'user_id': u'6433222efd78459bb70ad9adbcfac418',
> 'roles': [u'_member_', u'admin'], 'trustee_id': None, 'trustor_id': None,
> 'consumer_id': None, 'token':  (audit_id=DWsSa6yYSWi0ht9E7q4uhw, audit_chain_id=w_zLBBeFQ82KevtJrdKIJw) at
> 0x7f4503fab3c8>, 'project_id': u'4d170baaa89b4e46b239249eb5ec6b00',
> 'trust_id': None}, enforce
> /usr/lib/python2.7/dist-packages/keystone/policy/backends/rules.py:100
> 2015-03-09 16:00:06.061 9410 WARNING keystone.common.wsgi [-] You are not
> authorized to perform the requested action: identity:list_projects (Disable
> debug mode to suppress these details.)
> ```
>
> ​I make some debug and found that, the root cause is that the `context`
> variable in keystone has no `domain_id` field( like the above keystone
> log). So the `cloud_admin` rule failed.​ if i change the `cloud_admin` to
> following. It works as expected.
>
> ```
> "cloud_admin": "rule:admin_required and
> user_id:6433222efd78459bb70ad9adbcfac418",
> ```
>
> I found that in the keystone code[0], the domain_id only exist when it is
> a domain scope. But i believe that the horizon login token is a project
> one( I am not very sure this)
>
> ```
> if token.project_scoped:
> auth_context['project_id'] = token.project_id
> elif token.domain_scoped:
> auth_context['domain_id'] = token.domain_id
> else:
> LOG.debug('RBAC: Proceeding without project or domain scope')
>
> ```
>
> Is it a bug? or some wrong configuration?
>
>
> Following is my configuration.
>
>
> ```
> # /etc/keystone/keystone.conf
> [DEFAULT]
> debug=true
> verbose=true
> log_dir=/var/log/keystone
> [assignment]
> driver = keystone.assignment.backends.sql.Assignment
> [database]
> connection=mysql://:@controller/keystone
> [identity]
> driver=keystone.identity.backends.sql.Identity
> [memcache]
> servers=controller1:11211,controller2:11211,controller3:1121
> [token]
> provider=keystone.token.providers.uuid.Provider
> ```
>
> ```
> # /etc/openstack-dashboard/local_settings.py ( partly )
> POLICY_FILES_PATH = "/etc/openstack-dashboard/"
> POLICY_FILES = {
> 'identity': 'keystone_policy.json',
> }
> OPENSTACK_HOST = "127.0.0.1"
> OPENSTACK_KEYSTONE_URL = "http://%s:5000/v3"; % OPENSTACK_HOST
> OPENSTACK_KEYSTONE_DEFAULT_ROLE = "_member_"
> OPENSTACK_API_VERSIONS = {
>  "data_processing": 1.1,
>  "identity": 3,
>  "volume": 2
> }
> OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
> OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'admin'
> ```
>
> ​[0]
> https://github.com/openstack/keystone/blob/master/keystone/common/authorization.py#L58
> ​
>
> --
> Lei Zhang
> Blog: http://xcodest.me
> twitter/weibo: @jeffrey4l
>
>
>
>
> --
> Lei Zhang
> Blog: http://xcodest.me
> twitter/weibo: @jeffrey4l
>



-- 
Lei Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l
__
OpenStack Development Mailing 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] oslo.concurrency runtime dependency on fixtures/testtools

[Brant Knudson]

On Thu, Mar 12, 2015 at 7:20 AM, Davanum Srinivas  wrote:

> Alan,
>
> We are debating this on:
> https://review.openstack.org/#/c/157135/
>
> Please hop on :)
> -- dims
>
> On Thu, Mar 12, 2015 at 5:28 AM, Alan Pevec  wrote:
> > Hi,
> >
> > hijacking this thread to point out something that feels wrong in the
> > dependency chain which jumped out:
> >
> >> Colecting testtools>=0.9.22 (from
> fixtures>=0.3.14->oslo.concurrency>=1.4.1->keystone==2015.1.dev395)
> >
> > fixtures is imported in oslo_concurrency/fixture/lockutils.py but
> > that's not really used at _runtime_
> >
> >
> > Cheers,
> > Alan
> >
>

And it's also being discussed in keystone for deps for non-default
features: https://review.openstack.org/#/c/162360/

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

Re: [openstack-dev] [Horizon][Keystone] Failed to set up keystone v3 api for horizon

[Lei Zhang]

Hi Lin,

This two PS is what I wanted. Thx a lot.

btw, is it possible that these PS finished in Kilo?

On Thu, Mar 12, 2015 at 5:41 PM, Lin Hua Cheng  wrote:

> Hi,
>
> The 'cloud_admin' policy file requires domain-scoped to work to work.
>
> Horizon does not currently support domain scope token yet. So yes, it is a
> gap in horizon at the moment.
>
> There are on-going patches to address this in horizon:
> - https://review.openstack.org/#/c/141153/
> - https://review.openstack.org/#/c/148082/
>
> Dan (esp) prepared a nicely written document on this should eventually
> work.
>
> -Lin
>
> On Wed, Mar 11, 2015 at 7:33 PM, Lei Zhang 
> wrote:
>
>> is there anyone tryed this and successfully?
>>
>> On Mon, Mar 9, 2015 at 4:25 PM, Lei Zhang 
>> wrote:
>>
>>> Hi guys,
>>>
>>> I am setting up the keytone v3 api. Now I meet a issue about the
>>> `cloud_admin` policy.
>>>
>>> Base on the
>>> http://www.florentflament.com/blog/setting-keystone-v3-domains.html
>>> article, I modify the cloud_admin policy to
>>>
>>> ```
>>> "cloud_admin": "rule:admin_required and
>>> domain_id:ef0d30167f744401a0cbfcc938ea7d63",
>>> ```
>>>
>>> But the cloud_admin don't work as expected. I failed to open all the
>>> identity panel ( like http:///horizon/identity/domains/)
>>> Horizon tell me" Error: Unable to retrieve project list."
>>> And keystone log warning:
>>>
>>> ```
>>> 2015-03-09 16:00:06.423 9415 DEBUG keystone.policy.backends.rules [-]
>>> enforce identity:list_user_projects: {'is_delegated_auth': False,
>>> 'access_token_id': None, 'user_id': u'6433222efd78459bb70ad9adbcfac418',
>>> 'roles': [u'_member_', u'admin'], 'trustee_id': None, 'trustor_id': None,
>>> 'consumer_id': None, 'token': >> (audit_id=DWsSa6yYSWi0ht9E7q4uhw, audit_chain_id=w_zLBBeFQ82KevtJrdKIJw) at
>>> 0x7f4503fab3c8>, 'project_id': u'4d170baaa89b4e46b239249eb5ec6b00',
>>> 'trust_id': None}, enforce
>>> /usr/lib/python2.7/dist-packages/keystone/policy/backends/rules.py:100
>>> 2015-03-09 16:00:06.061 9410 WARNING keystone.common.wsgi [-] You are
>>> not authorized to perform the requested action: identity:list_projects
>>> (Disable debug mode to suppress these details.)
>>> ```
>>>
>>> ​I make some debug and found that, the root cause is that the `context`
>>> variable in keystone has no `domain_id` field( like the above keystone
>>> log). So the `cloud_admin` rule failed.​ if i change the `cloud_admin` to
>>> following. It works as expected.
>>>
>>> ```
>>> "cloud_admin": "rule:admin_required and user_id:
>>> 6433222efd78459bb70ad9adbcfac418",
>>> ```
>>>
>>> I found that in the keystone code[0], the domain_id only exist when it
>>> is a domain scope. But i believe that the horizon login token is a project
>>> one( I am not very sure this)
>>>
>>> ```
>>> if token.project_scoped:
>>> auth_context['project_id'] = token.project_id
>>> elif token.domain_scoped:
>>> auth_context['domain_id'] = token.domain_id
>>> else:
>>> LOG.debug('RBAC: Proceeding without project or domain scope')
>>>
>>> ```
>>>
>>> Is it a bug? or some wrong configuration?
>>>
>>>
>>> Following is my configuration.
>>>
>>>
>>> ```
>>> # /etc/keystone/keystone.conf
>>> [DEFAULT]
>>> debug=true
>>> verbose=true
>>> log_dir=/var/log/keystone
>>> [assignment]
>>> driver = keystone.assignment.backends.sql.Assignment
>>> [database]
>>> connection=mysql://:@controller/keystone
>>> [identity]
>>> driver=keystone.identity.backends.sql.Identity
>>> [memcache]
>>> servers=controller1:11211,controller2:11211,controller3:1121
>>> [token]
>>> provider=keystone.token.providers.uuid.Provider
>>> ```
>>>
>>> ```
>>> # /etc/openstack-dashboard/local_settings.py ( partly )
>>> POLICY_FILES_PATH = "/etc/openstack-dashboard/"
>>> POLICY_FILES = {
>>> 'identity': 'keystone_policy.json',
>>> }
>>> OPENSTACK_HOST = "127.0.0.1"
>>> OPENSTACK_KEYSTONE_URL = "http://%s:5000/v3"; % OPENSTACK_HOST
>>> OPENSTACK_KEYSTONE_DEFAULT_ROLE = "_member_"
>>> OPENSTACK_API_VERSIONS = {
>>>  "data_processing": 1.1,
>>>  "identity": 3,
>>>  "volume": 2
>>> }
>>> OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
>>> OPENSTACK_KEYSTONE_DEFAULT_DOMAIN = 'admin'
>>> ```
>>>
>>> ​[0]
>>> https://github.com/openstack/keystone/blob/master/keystone/common/authorization.py#L58
>>> ​
>>>
>>> --
>>> Lei Zhang
>>> Blog: http://xcodest.me
>>> twitter/weibo: @jeffrey4l
>>>
>>
>>
>>
>> --
>> Lei Zhang
>> Blog: http://xcodest.me
>> twitter/weibo: @jeffrey4l
>>
>> __
>> OpenStack Development Mailing 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.opens

Re: [openstack-dev] [nova] need input on possible API change for bug #1420848

[Christopher Yeoh]

FWIW I think we need to consider that the API is completely froxen for the
V2 API (so this freeze does not apply to v2.1 microversions) except under
very serious circumstances and only very high priority bug fixes and only
apply this to a suitable microversion bump. We really want to get rid of
the V2 API code asap anyway.  You can after all request a version number of
a per method basis as long as you are talking to v2.1. So the only forced
upgrade is the v2->v2.1 transition and those apis should be identical

On Fri, Mar 13, 2015 at 12:02 AM, Christopher Yeoh 
wrote:

>
>
>
> On Thu, Mar 12, 2015 at 11:19 PM, Christopher Yeoh 
> wrote:
>
>> On Wed, 11 Mar 2015 09:32:11 -0600
>> Chris Friesen  wrote:
>>
>> >
>> > Hi,
>> >
>> > I'm working on bug #1420848 which addresses the issue that doing a
>> > "service-disable" followed by a "service-enable" against a "down"
>> > compute node will result in the compute node going "up" for a while,
>> > possibly causing delays to operations that try to schedule on that
>> > compute node.
>> >
>> > The proposed solution is to add a new "reported_at" field in the DB
>> > schema to track when the service calls _report_state().
>> >
>> > The backend is straightforward, but I'm trying to figure out the best
>> > way to represent this via the REST API response.
>> >
>> > Currently we response includes an "updated_at" property, which maps
>> > directly to the auto-updated "updated_at" field in the database.
>> >
>> > Would it be acceptable to just put the "reported_at" value (if it
>> > exists) in the "updated_at" property?  Logically the "reported_at"
>> > value is just a determination of when the service updated its own
>> > state, so an argument could be made that this shouldn't break
>> > anything.
>> >
>>
>>
>> So i think this is the critical point here is this a backwards
>> compatibly API change or not. Would reporing reported_at in updated_at
>> cause *anyone* any pain. For this reason I think it has to go through
>> as a nova spec (and if you think its not going to cause pain get some
>> people from the mailing list +1 it as backwards API change because it
>> always has been a bug. If that is the conculsion and you just reuse
>> updated_at
>
> then the procedure would be:
>
>>
>> - Add it to v2 and no v2 extension required
>> - Add it to v2.1 without an extension
>> - No change required to in terms of microversions because it is lready
>>   in the base v2.1 code
>>
>> If you go the reported_at route the and there no changed to updated_at
>>
> but the fix is consiered a new feature rather than a bug fix then I think
> we should seriously consider if it should be fixed in V2 at all because the
> v2 api is basically frozen and we can just add it as a microversion (don't
> even need to to support it in v2.1), just  api microversion
>
> In which case the documents that Kevin pointed to should help - if you
> have any problems catch me on irc or on return email
>
>
__
OpenStack Development Mailing 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] Nitpicking in code reviews

[Flavio Percoco]

On 11/03/15 15:06 -1000, John Bresnahan wrote:
FWIW I agree with #3 and #4 but not #1 and #2.  Spelling is an easy 
enough thing to get right and speaks to the quality standard to which 
the product is held even in commit messages and comments (consider the 
'broken window theory').  Of course everyone makes mistakes (I am a 
terrible speller) but correcting a spelling error should be a trivial 
matter.  If a reviewer notices a spelling error I would expect them to 
point it.


I'd agree depending on the status of the patch. If the patch has
already 2 +2s and someone blocks it because of a spelling error, then
the cost of fixing it, running the CI jobs and getting the reviews
again is higher than living with a simple typo.

Process and rules are good but we must evaluate them in a case by case
basis to make sure we're not blocking important work on things that
are not that relevant after all.



On 3/11/15 2:22 PM, Kuvaja, Erno wrote:

Hi all,

Following the code reviews lately I’ve noticed that we (the fan club
seems to be growing on weekly basis) have been growing culture of
nitpicking [1] and bikeshedding [2][3] over almost every single change.

Seriously my dear friends, following things are not worth of “-1” vote
if even a comment:

1)Minor spelling errors on commit messages (as long as the message comes
through and flags are not misspelled).

2)Minor spelling errors on comments (docstrings and documentation is
there and there, but comments, come-on).

3)Used syntax that is functional, readable and does not break
consistency but does not please your poem bowel.

4)Other things you “just did not realize to check if they were there”.
After you have gone through the whole change go and look your comments
again and think twice if your concern/question/whatsoever was addressed
somewhere else than where your first intuition would have dropped it.

We have relatively high volume for glance at the moment and this
nitpicking and bikeshedding does not help anyone. At best it just
tightens nerves and breaks our group. Obviously if there is “you had ONE
job” kind of situations or there is relatively high amount of errors
combined with something serious it’s reasonable to ask fix the typos on
the way as well. The reason being need to increase your statistics,
personal perfectionist nature or actually I do not care what; just stop
or go and do it somewhere else.



Thanks for bringing all this up, Erno. I've been seeing the same
pattern for all the points you've mentioned above. It's a good
reminder for people to treat each patch individually so we avoid
making our process and rules a pain for everyone.

Flavio



Love and pink ponies,

-Erno

[1] www.urbandictionary.com/define.php?term=nitpicking


[2] http://bikeshed.com

[3] http://en.wiktionary.org/wiki/bikeshedding



__
OpenStack Development Mailing 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


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [nova] need input on possible API change for bug #1420848

[Christopher Yeoh]

On Thu, Mar 12, 2015 at 11:19 PM, Christopher Yeoh 
wrote:

> On Wed, 11 Mar 2015 09:32:11 -0600
> Chris Friesen  wrote:
>
> >
> > Hi,
> >
> > I'm working on bug #1420848 which addresses the issue that doing a
> > "service-disable" followed by a "service-enable" against a "down"
> > compute node will result in the compute node going "up" for a while,
> > possibly causing delays to operations that try to schedule on that
> > compute node.
> >
> > The proposed solution is to add a new "reported_at" field in the DB
> > schema to track when the service calls _report_state().
> >
> > The backend is straightforward, but I'm trying to figure out the best
> > way to represent this via the REST API response.
> >
> > Currently we response includes an "updated_at" property, which maps
> > directly to the auto-updated "updated_at" field in the database.
> >
> > Would it be acceptable to just put the "reported_at" value (if it
> > exists) in the "updated_at" property?  Logically the "reported_at"
> > value is just a determination of when the service updated its own
> > state, so an argument could be made that this shouldn't break
> > anything.
> >
>
>
> So i think this is the critical point here is this a backwards
> compatibly API change or not. Would reporing reported_at in updated_at
> cause *anyone* any pain. For this reason I think it has to go through
> as a nova spec (and if you think its not going to cause pain get some
> people from the mailing list +1 it as backwards API change because it
> always has been a bug. If that is the conculsion and you just reuse
> updated_at

then the procedure would be:

>
> - Add it to v2 and no v2 extension required
> - Add it to v2.1 without an extension
> - No change required to in terms of microversions because it is lready
>   in the base v2.1 code
>
> If you go the reported_at route the and there no changed to updated_at
>
but the fix is consiered a new feature rather than a bug fix then I think
we should seriously consider if it should be fixed in V2 at all because the
v2 api is basically frozen and we can just add it as a microversion (don't
even need to to support it in v2.1), just  api microversion

In which case the documents that Kevin pointed to should help - if you have
any problems catch me on irc or on return email

>
> > Otherwise, by my reading of
> > "
> https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK
> "
> > it seems like if I wanted to add a new "reported_at" property I would
> > need to do it via an API extension.
> >
> > Anyone have opinions?
> >
> > 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] Generic question about synchronizing neutron agent on compute node with DB

[Leo Y]

What does it mean under "if that notification is lost, the agent will
eventually resynchronize"? Is it proven/guaranteed? By what means?
Can you, please the process with more details? Or point me to resources
that describe it.

Thank you


On Mon, Mar 9, 2015 at 2:11 AM, Kevin Benton  wrote:

> Port changes will result in an update message being sent on the AMQP
> message bus. When the agent receives it, it will affect the communications
> then. If that notification is lost, the agent will eventually resynchronize.
>
> So during normal operations, the change should take effect within a few
> seconds.
>
> On Sat, Mar 7, 2015 at 4:10 AM, Leo Y  wrote:
>
>> Hello,
>>
>> What happens when neutron DB is updated to change network settings (e.g.
>> via Dashboard or manually) when there are communication sessions opened in
>> compute nodes. Does it influence those sessions? When the update is
>> propagated to compute nodes?
>>
>> 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
>>
>>
>
>
> --
> 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
>
>


-- 
Regards,
Leo
-
I enjoy the massacre of ads. This sentence will slaughter ads without a
messy bloodbath
__
OpenStack Development Mailing 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] VXLAN with single-NIC compute nodes: Avoiding the MTU pitfalls

[Fredy Neeser]

On 11.03.2015 19:31, Ian Wells wrote:
On 11 March 2015 at 04:27, Fredy Neeser > wrote:


7: br-ex.1:  mtu 1500 qdisc
noqueue state UNKNOWN group default
link/ether e0:3f:49:b4:7c:a7 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.14/24  brd
192.168.1.255 scope global br-ex.1
   valid_lft forever preferred_lft forever

8: br-ex.12:  mtu 1554 qdisc
noqueue state UNKNOWN group default
link/ether e0:3f:49:b4:7c:a7 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.14/24  brd
192.168.1.255 scope global br-ex.12
   valid_lft forever preferred_lft forever


I find it hard to believe that you want the same address configured on 
*both* of these interfaces - which one do you think will be sending 
packets?


Ian, thanks for your feedback!

I did choose the same address for the two interfaces, for three reasons:

1.  Within my home single-LAN (underlay) environment, traffic is 
switched, and VXLAN traffic is confined to VLAN 12, so there is never a 
conflict between IP 192.168.1.14 on VLAN 1 and the same IP on VLAN 12.
OTOH, for a more scalable VXLAN setup (with multiple underlays and L3 
routing in between), I would like to use different IPs for br-ex.1 and 
br-ex.12 -- for example by using separate subnets

  192.168.1.0/26  for VLAN 1
  192.168.12.0/26  for VLAN 12
However, I'm not quite there yet (see 3.).

2.  I'm using policy routing on my hosts to steer VXLAN traffic (UDP 
dest. port 4789) to interface br-ex.12 --  all other traffic from 
192.168.1.14 is source routed from br-ex.1, presumably because br-ex.1 
is a lower-numbered interface than br-ex.12  (?) -- interesting question 
whether I'm relying here on the order in which I created these two 
interfaces.


  [root@langrain ~]# ip a
  ...
  7: br-ex.1:  mtu 1500 qdisc noqueue 
state UNKNOWN group default

  link/ether e0:3f:49:b4:7c:a7 brd ff:ff:ff:ff:ff:ff
  inet 192.168.1.14/24 brd 192.168.1.255 scope global br-ex.1
 valid_lft forever preferred_lft forever
  8: br-ex.12:  mtu 1554 qdisc noqueue 
state UNKNOWN group default

  link/ether e0:3f:49:b4:7c:a7 brd ff:ff:ff:ff:ff:ff
  inet 192.168.1.14/24 brd 192.168.1.255 scope global br-ex.12
 valid_lft forever preferred_lft forever

3.  It's not clear to me how to setup multiple nodes with packstack if a 
node's tunnel IP does not equal its admin IP (or the OpenStack API IP in 
case of a controller node).  With packstack, I can only specify the 
compute node IPs through CONFIG_COMPUTE_HOSTS. Presumably, these IPs are 
used for both packstack deployment (admin IP) and for configuring the 
VXLAN tunnel IPs (local_ip and remote_ip parameters).  How would I 
specify different IPs for these purposes? (Recall that my hosts have a 
single NIC).



In any case, native traffic on bridge br-ex is sent via br-ex.1 (VLAN 
1), which is also the reason the Neutron gateway port qg-XXX needs to be 
an access port for VLAN 1 (tag: 1).   VXLAN traffic is sent from 
br-ex.12 on all compute nodes.  See the 2 cases below:



Case 1. Max-size ping from compute node 'langrain' (192.168.1.14) to 
another host on same LAN
 => Native traffic sent from br-ex.1; no traffic sent from 
br-ex.12


[fn@langrain ~]$ ping -M do -s 1472 -c 1 192.168.1.54
PING 192.168.1.54 (192.168.1.54) 1472(1500) bytes of data.
1480 bytes from 192.168.1.54: icmp_seq=1 ttl=64 time=0.766 ms

[root@langrain ~]# tcpdump -n -i br-ex.1 dst 192.168.1.54
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-ex.1, link-type EN10MB (Ethernet), capture size 65535 bytes
10:32:37.666572 IP 192.168.1.14 > 192.168.1.54: ICMP echo request, id 
10432, seq 1, length 1480
10:32:42.673665 ARP, Request who-has 192.168.1.54 tell 192.168.1.14, 
length 28



Case 2: Max-size ping from a guest1 (10.0.0.1) on compute node 
'langrain' (192.168.1.14)
 to a guest2 (10.0.0.3) on another compute node 
(192.168.1.21) via VXLAN tunnel.

 Guests are on the same virtual network 10.0.0.0/24
 => Encapsulated traffic sent from br-ex.12; no traffic 
sent from br-ex.1


$ ping -M do -s 1472 -c 1 10.0.0.3
PING 10.0.0.3 (10.0.0.3) 1472(1500) bytes of data.
1480 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=2.22 ms

[root@langrain ~]# tcpdump -n -i br-ex.12
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-ex.12, link-type EN10MB (Ethernet), capture size 65535 bytes

11:02:56.916265 IP 192.168.1.14.47872 > 192.168.1.21.4789: VXLAN, flags 
[I] (0x08), vni 10

ARP, Request who-has 10.0.0.3 tell 10.0.0.1, length 28
11:02:56.916991 IP 192.168.1.21.51408 > 192.168.1.14.4789: VXLAN, flags 
[I] (0x08), vni 10

ARP, Reply 10.0.0.3 is-at fa:16:3e:e6:e1:c8, length 28
11:02:56.917282 IP 192.168.1.14.57836 > 192.168.1.21.4789: VXLAN, flags 
[I] (0x08), vni 10

IP 10.0.0.1 > 10.0.0.3: ICMP echo request, id 25474, seq 1, length 1480

[openstack-dev] Fwd: [Neutron] IDSaaS: Request for features

[Mario Tejedor González]

I am copying this email from the openstack general list as I have not got
any responses from there yet. If any of you has a user profile besides
being a developer I would be very interested in your opinion.

Hello, I am a MSc student. I am developing an IDSaaS openstack-plugin for
my project and I would appreciate your opinions on the following:



1.  Do you agree that an IDAaaS plugin would be useful and, if so, what do
you see as the primary benefits to Cloud tenants? I will focus on 1, maybe
2, separate IDS software during my project, but the plugin should be as
software agnostic so drivers for other software can be developed afterwards.



2.  What IDS software would you recommend for this purpose? Specifically I
need to ensure that the plugin accommodates important core features so if
there are vital features please let me know.



3.  What features would you consider to be an important priority when
developing an IDSaaS plugin on openstack?



If you could spare 5 minutes (just five I promise), I have a few more very
short questions in the following survey link:


https://www.surveymonkey.com/s/89BDG72



These survey questions allow you to suggest features you might like to have
in the plugin (Think of it like a request list!). The benefit of this is
that I will prioritize these features for development.

Thank you very much for your time and interest.

--
Mario
__
OpenStack Development Mailing 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] Enabling VM post-copy live migration

[Luis Tomas]

On 03/12/2015 12:34 PM, John Garbutt wrote:

On 12 March 2015 at 08:41, Luis Tomas  wrote:

Hi,

As part of an European (FP7) project, named ORBIT
(http://www.orbitproject.eu/), I'm working on including the possibility of
live-migrating VMs in OpenStack in a post-copy mode.
This way of live-migrating VMs basically moves the computation right away to
the destination and then the VM starts working from there, while still
copying the memory from the source to the new location of the VM. That way
the memory pages are only copied as if the VM modifies them, they are
already in the destination host. This basically ensures that migrations
finish regardless of what the VM is doing, i.e., even extremely memory
intensive VMs. Therefore removing the problem of having VMs hanging on in
migrating state forever (as discussed in previous mails, e.g.,
http://lists.openstack.org/pipermail/openstack-dev/2015-February/055725.html).

So far, I have included and tested this new functionality at the JUNO
version, and the code modifications can be found in the github repository of
the project (branch named "post-copy"):
 - https://github.com/orbitfp7/nova/tree/post-copy --> mainly enabling
the possibility of using the libvirt post-copy flag (libvirt driver.py).
Note post-copy migration is not using "tunneling" as LibVirt patch for that
is not yet ready.
 - https://github.com/orbitfp7/python-novaclient/tree/post-copy -->
adding the possibility of using the post-copy mode when triggering the
migration: nova live-migration [--block-migrate] [--post-copy] VM_ID
 - https://github.com/orbitfp7/horizon/tree/post-copy --> include a
checkbox in the live-migration panel to perform the migration in post-copy
mode. (like the one for enabling block-migration)

To be able to live-migrate VMs in a post-copy way, I'm relying on some
kernel+qemu+libvirt modifications, not yet merged upstream (but in their way
to it), also available at the project github:
 - Kernel: https://lkml.org/lkml/2015/3/5/576
 - Qemu: https://github.com/orbitfp7/qemu/tree/wp3-postcopy
 - LibVirt: https://github.com/orbitfp7/libvirt/tree/wp3-postcopy

Before merging the code in Nova, we usually like the dependent
features to be released by the respective projects.

Ideally we would like it to be easy to run that on some distro so
people could test/use the feature fairly easily.
Yes, that's why I proposed to target the version after kilo (or even the 
next to that one if need be)





If this is a nice feature to have in future versions of OpenStack, I'm happy
to adapt the code for the next release (the one after KILO). Any comments
are really welcome.

It sounds like something that doesn't need an API call, as its a
deployer choice if they have support for this new live-migrate mode.
Is that true?

Although maybe it has a substantial runtime penalty as a page read
miss causes a fetch across the network, making it a user choice? Or do
you only start the fetch mode at the point you detect a failure to
"merge" using the regular live-migrate mode?


I think it should be up to the user/admin what option to choose.
Although post-copy ensures that the migration will finish, as you said, 
it could have some impact into the VM performance due to having to wait 
until a missing memory page is fetched. Anyway, I wouldn't say there is 
a substantial runtime penalty. In fact, the libvirt flag that we have 
included in OpenStack basically tries pre-copy first (normal 
live-migration), and after trying to copy all the memory once (first 
iteration), automatically changes to post-copy, meaning moving the VM 
cpu to the destination and only having to copy the remaining pages (the 
ones dirtied while doing the first copy iteration). This way the impact 
into the application performance is minimized.


On the other hand, post-copy has a downside. If by any chance the 
migration crash during the process, unlike pre-copy, you can not recover 
the VM as not the source nor the destination has a fully working VM at 
the time (part of the memory in the source, part of it at the destination).


These are basically the reasons we considered for making it as an 
optional choice.


Thank you for your comments!

Regards,
Luis


Thanks,
John

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



--
---
Dr. Luis Tomás
Postdoctoral Researcher
Department of Computing Science
Umeå University
l...@cs.umu.se
www.cloudresearch.se
www8.cs.umu.se/~luis



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

Re: [openstack-dev] [nova] readout from Philly Operators Meetup

[Salvatore Orlando]

I completely agree with you - Sean and Joe.

Since the argument was brought up I just wanted to point out that this
"quota service" thing is a bit of a unicorn at the moment, and it should
not distract from fixing and improving quota maangement & enforcement logic
in the various openstack projects.

I wan't be able to introduce hierarchical quotas in neutron by the end of
Kilo, but I'll keep it on the roadmap for Liberty.

Salvatore

On 12 March 2015 at 11:59, Sean Dague  wrote:

> On 03/11/2015 08:31 PM, Joe Gordon wrote:
> >
> >
> > On Wed, Mar 11, 2015 at 4:07 PM, Ihar Hrachyshka  > > wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 03/11/2015 07:48 PM, Joe Gordon wrote:
> > > Out of sync Quotas --
> > >
> > > https://etherpad.openstack.org/p/PHL-ops-nova-feedback L63
> > >
> > > The quotas code is quite racey (this is kind of a known if you look
> > > at the bug tracker). It was actually marked as a top soft spot
> > > during last fall's bug triage -
> > >
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html
> > >
> > >  There is an operator proposed spec for an approach here -
> > > https://review.openstack.org/#/c/161782/
> > >
> > > Action: we should make a solution here a top priority for enhanced
> > > testing and fixing in Liberty. Addressing this would remove a lot
> > > of pain from ops.
> > >
> > >
> > > To help us better track quota bugs I created a quotas tag:
> > >
> > > https://bugs.launchpad.net/nova/+bugs?field.tag=quotas
> > >
> > > Next step is re-triage those bugs: mark fixed bugs as fixed,
> > > deduplicate bugs etc.
> >
> > (Being quite far from nova code, so ignore if not applicable)
> >
> > I would like to note that other services experience races in quota
> > management too. Neutron has a spec approved to land in Kilo-3 that is
> > designed to introduce a new quota enforcement mechanism that is
> > expected to avoid (some of those) races:
> >
> >
> https://github.com/openstack/neutron-specs/blob/master/specs/kilo/better-quotas.rst
> >
> > I thought you may be interested in looking into it to apply similar
> > ideas to nova.
> >
> >
> > Working on a library for this hasn't been ruled out yet. But right now I
> > am simply trying to figure out how to reproduce the issue, and nothing
> else.
>
> Right, I think assuming an architecture change will magically fix this
> without scenarios that expose the existing bugs seems overly optimistic.
>
> I think there is a short / medium term test / reproduce question here,
> then a longer term question about different architecture.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] oslo.concurrency runtime dependency on fixtures/testtools

[Davanum Srinivas]

Alan,

We are debating this on:
https://review.openstack.org/#/c/157135/

Please hop on :)
-- dims

On Thu, Mar 12, 2015 at 5:28 AM, Alan Pevec  wrote:
> Hi,
>
> hijacking this thread to point out something that feels wrong in the
> dependency chain which jumped out:
>
>> Colecting testtools>=0.9.22 (from 
>> fixtures>=0.3.14->oslo.concurrency>=1.4.1->keystone==2015.1.dev395)
>
> fixtures is imported in oslo_concurrency/fixture/lockutils.py but
> that's not really used at _runtime_
>
>
> 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



-- 
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] [nova] Unshelve Instance Performance Optimization Questions

[John Garbutt]

Hi,

On 11 March 2015 at 06:35, Kekane, Abhishek  wrote:
> In case of start/stop API’s cpu/memory are not released/reassigned. We can
> modify these API’s to release
> the cpu and memory while stopping the instance and reassign the same while
> starting the instance. In this case
> also rescheduling logic need  to be modified to reschedule the instance on
> different host, if required resources
> are not available while starting the instance. This is similar to what I
> have implemented in [2] Improving the
> performance of unshelve API.

I am against start releasing the resources, as you can't guarantee
start will work quickly. Similar to suspend I suppose.

The idea of shelve/unshelve is to avoid that problem, by ensuring you
can resume the VM anywhere, should someone else use the resources you
have freed up. But the idea was to optimize for a quick unshelve,
where possible. The feature is not really complete, we need a
scheduling weighter to deal with avoiding that capacity till you need
it, etc. When you have shared storage, it maybes sense to add the
option of skipping the snapshot (boot from volume clearly doesn't need
a snapshot), if you are happy to assume there will always be space on
some host that can see that shared storage.

> Please let me know your opinion, whether we can modify start/stop API’s as
> an alternative to shelve/unshelve API’s.

I would rather we enhance shelve/unshelve, rather than fundamentally
change the semantics of start/stop.

Thanks,
John


> From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
> Sent: 24 February 2015 12:47
>
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] Unshelve Instance Performance
> Optimization Questions
>
>
>
> Hi Duncan,
>
>
>
> Thank you for the inputs.
>
>
>
> @Community-Members
>
> I want to know if there are any other alternatives to improve the
> performance of unshelve api ((booted from image only).
>
> Please give me your opinion on the same.
>
>
>
> Thank You,
>
>
>
> Abhishek Kekane
>
>
>
>
>
>
>
> From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
> Sent: 16 February 2015 16:46
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] Unshelve Instance Performance
> Optimization Questions
>
>
>
> There has been some talk in cinder meetings about making cinder<->glance
> interactions more efficient. They are already optimised in some deployments,
> e.g. ceph glance and ceph cinder, and some backends cache glance images so
> that many volumes created from the same image becomes very efficient.
> (search the meeting logs or channel logs for 'public snapshot' to get some
> entry points into the discussions)
>
> I'd like to see more work done on this, and perhaps re-examine a cinder
> backend to glance. This would give some of what you're suggesting
> (particularly fast, low traffic un-shelve), and there is more that can be
> done to improve that performance, particularly if we can find a better
> performing generic CoW technology than QCOW2.
>
> As suggested in the review, in the short term you might be better
> experimenting with moving to boot-from-volume instances if you have a
> suitable cinder deployed, since that gives you some of the performance
> improvements already.
>
>
>
> On 16 February 2015 at 12:10, Kekane, Abhishek 
> wrote:
>
> Hi Devs,
>
>
>
> Problem Statement: Performance and storage efficiency of shelving/unshelving
> instance booted from image is far worse than instance booted from volume.
>
>
>
> When you unshelve hundreds of instances at the same time, instance spawning
> time varies and it mainly depends on the size of the instance snapshot and
>
> the network speed between glance and nova servers.
>
>
>
> If you have configured file store (shared storage) as a backend in Glance
> for storing images/snapshots, then it's possible to improve the performance
> of
>
> unshelve instance dramatically by configuring
> nova.image.download.FileTransfer in nova. In this case, it simply copies the
> instance snapshot as if it is
>
> stored on the local filesystem of the compute node. But then again in this
> case, it is observed the network traffic between shared storage servers and
>
> nova increases enormously resulting in slow spawning of the instances.
>
>
>
> I would like to gather some thoughts about how we can improve the
> performance of unshelve api (booted from image only) in terms of downloading
> large
>
> size instance snapshots from glance.
>
>
>
> I have proposed a nova-specs [1] to address this performance issue. Please
> take a look at it.
>
>
>
> During the last nova mid-cycle summit, Michael Still has suggested
> alternative solutions to tackle this issue.
>
>
>
> Storage solutions like ceph (Software based) and NetApp (Hardare based)
> support exposing images from glance to nova-compute and cinder-volume with
>
> copy in write feature. This way there will be no need to download the
> instance snap

Re: [openstack-dev] [nova][heat] Autoscaling parameters blueprint

[ELISHA, Moshe (Moshe)]

This is a very nice idea but I’m afraid that the index is not the only 
parameter that is different between the instances.
I will write down the full use case so we could continue the discussion. Thanks!


From: Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com]
Sent: יום ד 11 מרץ 2015 14:59
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][heat] Autoscaling parameters blueprint

Hi,

as you have a separate monitoring solution (not Ceilometer), it seems you can 
use ResourceGroup instead of AutoscalingGroup and issue heatclient/rest calls 
to do a stack-update with desired size of the group when needed. The group 
members will be numbered, and as already said you can also control the removal. 
One possible downside is that AFAIR the numbers would not be reused on 
subsequent scale-down/ups.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Wed, Mar 11, 2015 at 2:46 PM, ELISHA, Moshe (Moshe) 
mailto:moshe.eli...@alcatel-lucent.com>> wrote:
I am familiar of the removal policies. Thanks!

Our use case for parameters on scale out is as follows:

Every server has a unique index that identifies it.
The first server has an index of 1, the second has an index of 2, etc.
The index of each server must exist prior to the configuration phase of the 
server.

This use case is an outcome of a virtualization process for an NFV application.
In the past this application was scaled manually by adding physical cards into 
slots - the index is the slot number.
In order to allow a smooth and fast transition of the app into the cloud - the 
requirement is to stay with the same architecture.


The current suggested solution is as follows:

The HOT will be created with an AutoScalingGroup and two ScalingPolicies for 
scale out and scale in.
Like many other NFV applications, this application also has a Life Cycle 
Manager of its own that monitors and decides when to scale.
When scale is needed, the LCM will invoke the alarm_url exposed by these 
ScalingPolicies while providing the server index for the newly created server.

The index is just one example of a parameter needed at scale out - there can be 
others.
Much more design is needed when the desired_capacity > 1 or  the 
scaling_adjustment > 1 or in percentage but let's first agree that the use case 
is OK.


-Original Message-
From: Steven Hardy [mailto:sha...@redhat.com]
Sent: Wednesday, March 11, 2015 12:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][heat] Autoscaling parameters blueprint

On Wed, Mar 11, 2015 at 09:01:04AM +, ELISHA, Moshe (Moshe) wrote:
>Hey,
>
>
>
>Can someone please share the current status of the "Autoscaling signals to
>allow parameter passing for UserData" blueprint -
> https://blueprints.launchpad.net/heat/+spec/autoscaling-parameters.

This is quite old, and subsequent discussions have happened which indicate a 
slightly different approach, e.g this thread here where I discuss approaches to 
signalling an AutoScalingGroup to remove a specific group member.  As Angus has 
noted, ResourceGroup already allows this via a different interface.

http://lists.openstack.org/pipermail/openstack-dev/2014-December/053447.html

>We have a very concrete use case that require passing parameters on scale
>out.
>
>What is the best way to revive this blueprint?

Probably the first thing is to provide a more detailed description of your 
use-case.

I'll try to revive the AutoScalingGroup signal patch mentioned in the thread 
above this week, it's been around for a while and is probably needed for any 
interface where we pass data in to influence AutoScalingGroup adjustment 
behaviour asynchronously (e.g not via the template definition).

https://review.openstack.org/#/c/143496/

Steve

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

__
OpenStack Development Mailing 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] [stacktach] [oslo] stachtach -> kombu -> pika ??

[Sean Dague]

On 03/10/2015 12:56 PM, Joshua Harlow wrote:
> Hi all,
> 
> I saw the following on
> https://etherpad.openstack.org/p/PHL-ops-rabbit-queue and was wondering
> if there was more explanation of why?
> 
> The StackTach team is switching from Kombu to Pika (at the
> recommendation of core rabbitmq devs). Hopefully oslo-messaging will do
> the same.
> 
> I'm wondering why/what?
> 
> Pika seems to be less supported, has less support for things other than
> rabbitmq, and seems less developed (it lacks python 3.3 support
> apparently).

So, something that came up was the supporting anything other MQ system
than Rabbit seemed irrelevant to the operator community. Rabbit is bad,
all others are demonstrably worse. Anything that makes the Rabbit path
better is good, anything that could regress the Rabbit path for the sake
of any of the other backends is bad (and also not useful to deployers).

> What's the details on this idea listed there?
> 
> Any stachtack folks got any more details?
> 
> -Josh
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing 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] readout from Philly Operators Meetup

[Sean Dague]

On 03/11/2015 08:31 PM, Joe Gordon wrote:
> 
> 
> On Wed, Mar 11, 2015 at 4:07 PM, Ihar Hrachyshka  > wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 03/11/2015 07:48 PM, Joe Gordon wrote:
> > Out of sync Quotas --
> >
> > https://etherpad.openstack.org/p/PHL-ops-nova-feedback L63
> >
> > The quotas code is quite racey (this is kind of a known if you look
> > at the bug tracker). It was actually marked as a top soft spot
> > during last fall's bug triage -
> > 
> http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html
> >
> >  There is an operator proposed spec for an approach here -
> > https://review.openstack.org/#/c/161782/
> >
> > Action: we should make a solution here a top priority for enhanced
> > testing and fixing in Liberty. Addressing this would remove a lot
> > of pain from ops.
> >
> >
> > To help us better track quota bugs I created a quotas tag:
> >
> > https://bugs.launchpad.net/nova/+bugs?field.tag=quotas
> >
> > Next step is re-triage those bugs: mark fixed bugs as fixed,
> > deduplicate bugs etc.
> 
> (Being quite far from nova code, so ignore if not applicable)
> 
> I would like to note that other services experience races in quota
> management too. Neutron has a spec approved to land in Kilo-3 that is
> designed to introduce a new quota enforcement mechanism that is
> expected to avoid (some of those) races:
> 
> 
> https://github.com/openstack/neutron-specs/blob/master/specs/kilo/better-quotas.rst
> 
> I thought you may be interested in looking into it to apply similar
> ideas to nova.
> 
> 
> Working on a library for this hasn't been ruled out yet. But right now I
> am simply trying to figure out how to reproduce the issue, and nothing else.

Right, I think assuming an architecture change will magically fix this
without scenarios that expose the existing bugs seems overly optimistic.

I think there is a short / medium term test / reproduce question here,
then a longer term question about different architecture.

-Sean

-- 
Sean Dague
http://dague.net

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