Re: [openstack-dev] [magnum] Proposing Kai Qiang Wu (Kennan) for Core for Magnum

[Madhuri Kumari]

+1 for Kennan.

Thanks & Regards
Madhuri Kumari


From: Steven Dake (stdake) [std...@cisco.com]
Sent: Sunday, May 31, 2015 11:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [magnum] Proposing Kai Qiang Wu (Kennan) for Core for 
Magnum

Hi core team,

Kennan (Kai Qiang Wu’s nickname) has really done a nice job in Magnum 
contributions.  I would like to propose Kennan for the core reviewer team.  I 
don’t think we necessarily need more core reviewers on Magnum, but Kennan has 
demonstrated a big commitment to Magnum and is a welcome addition in my opinion.

For the lifetime of the project, Kennan has contributed 8% of the reviews, and 
8% of the commits.  Kennan is also active in IRC.  He meets my definition of 
what a core developer for Magnum should be.

Consider my proposal to be a +1 vote.

Please vote +1 to approve or vote –1 to veto.  A single –1 vote acts as a veto, 
meaning Kennan would not be approved for the core team.  I believe we require 3 
+1 core votes presently, but since our core team is larger now then when we 
started, I’d like to propose at our next team meeting we formally define the 
process by which we accept new cores post this proposal for Magnum into the 
magnum-core group and document it in our wiki.

I’ll leave voting open for 1 week until June 6th to permit appropriate time for 
the core team to vote.  If there is a unanimous decision or veto prior to that 
date, I’ll close voting and make the appropriate changes in gerrit as 
appropriate.

Thanks
-steve




DISCLAIMER:
---
The contents of this e-mail and any attachment(s) are confidential and
intended
for the named recipient(s) only. 
It shall not attach any liability on the originator or NEC or its
affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the
opinions of NEC or its affiliates. 
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have 
received this email in error please delete it and notify the sender
immediately. .
---__
OpenStack Development Mailing 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] [designate] and [lbaas] - GSLB API and backend support

[Samuel Bercovici]

Good for me - Tuesday at 1600UTC


-Original Message-
From: Doug Wiegley [mailto:doug...@parksidesoftware.com] 
Sent: Thursday, May 28, 2015 10:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and backend 
support


> On May 28, 2015, at 12:47 PM, Hayes, Graham  wrote:
> 
> On 28/05/15 19:38, Adam Harwell wrote:
>> I haven't seen any responses from my team yet, but I know we'd be 
>> interested as well - we have done quite a bit of work on this in the 
>> past, including dealing with the Designate team on this very subject. 
>> We can be available most hours between 9am-6pm Monday-Friday CST.
>> 
>> --Adam
>> 
>> https://keybase.io/rm_you
>> 
>> 
>> From: Rakesh Saha > >
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> > >
>> Date: Thursday, May 28, 2015 at 12:22 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> > >
>> Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and 
>> backend support
>> 
>>Hi Kunal,
>>I would like to participate as well.
>>Mon-Fri morning US Pacific time works for me.
>> 
>>Thanks,
>>Rakesh Saha
>> 
>>On Tue, May 26, 2015 at 8:45 PM, Vijay Venkatachalam
>>>> wrote:
>> 
>>We would like to participate as well.
>> 
>>__ __
>> 
>>Monday-Friday Morning US time works for me..
>> 
>>__ __
>> 
>>Thanks,
>> 
>>Vijay V.
>> 
>>__ __
>> 
>>*From:*Samuel Bercovici [mailto:samu...@radware.com
>>]
>>*Sent:* 26 May 2015 21:39
>> 
>> 
>>*To:* OpenStack Development Mailing List (not for usage questions)
>>*Cc:* kunalhgan...@gmail.com ;
>>v.jain...@gmail.com ;
>>do...@a10networks.com 
>>*Subject:* Re: [openstack-dev] [designate] and [lbaas] - GSLB
>>API and backend support
>> 
>>__ __
>> 
>>Hi,
>> 
>>__ __
>> 
>>I would also like to participate.
>> 
>>Friday is a non-working day in Israel (same as Saturday for most
>>of you).
>> 
>>So Monday- Thursday works best for me.
>> 
>>__ __
>> 
>>-Sam.
>> 
>>__ __
>> 
>>__ __
>> 
>>*From:*Doug Wiegley [mailto:doug...@parksidesoftware.com]
>>*Sent:* Saturday, May 23, 2015 8:45 AM
>>*To:* OpenStack Development Mailing List (not for usage questions)
>>*Cc:* kunalhgan...@gmail.com ;
>>v.jain...@gmail.com ;
>>do...@a10networks.com 
>>*Subject:* Re: [openstack-dev] [designate] and [lbaas] - GSLB
>>API and backend support
>> 
>>__ __
>> 
>>Of those two options, Friday would work better for me.
>> 
>>__ __
>> 
>>Thanks,
>> 
>>doug
>> 
>>__ __
>> 
>>On May 22, 2015, at 9:33 PM, ki...@macinnes.ie
>> wrote:
>> 
>>__ __
>> 
>>Hi Kunal,
>> 
>>Thursday/Friday works for me - early morning PT works best,
>>as I'm based in Ireland.
>> 
>>I'll find some specific times the Designate folks are
>>available over the next day or two and provide some
>>options.. 
>> 
>>Thanks,
>>Kiall
>> 
>>On 22 May 2015 7:24 pm, "Gandhi, Kunal"
>>mailto:kunalhgan...@gmail.com>>
>>wrote:
>> 
>>Hi All
>> 
>>__ __
>> 
>>I wanted to start a discussion about adding support for GSLB
>>to neutron-lbaas and designate. To be brief for folks who
>>are new to GLB, GLB stands for Global Load Balancing and we
>>use it for load balancing traffic across various
>>geographical regions. A more detail description of GLB can
>>be found at my talk at the summit this week here
>>.
>> 
>>__ __
>> 
>>To my understanding, there are two sides to a GSLB - DNS
>>side and LB side. 
>> 
>>__ __
>> 
>>DNS side
>> 
>> Most of the GSLB's provided by various vendors
>>are DNS servers and are authoritative for the GLB domains.
>>The global fqdn's that belong the GLB domains resolve to
>>multiple public VIP's across various regions based on
>>various configurations on the global fqdn on the GLB.
>> 

[openstack-dev] Does one keytone have multiple identity providers?

[cmcc.dylan]

Hi,all. I have a question about keystone federation. Does one keystone have 
multiple identity providers?
For examle, there are 3 keystone - A, B and C.  Can I  configure B and C as the 
A‘s identity provider at the same time?
If it's OK, so what's the sequence if we send a request to keystone A?

Further more， A not only be configured as idp for itself, but has another idp - 
B?
if A receives a request, what's the sequence to select B  and C.

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

Re: [openstack-dev] [magnum] Proposing Kai Qiang Wu (Kennan) for Core for Magnum

[Davanum Srinivas]

+1 from me!

On Sun, May 31, 2015 at 1:56 AM, Steven Dake (stdake)  wrote:
> Hi core team,
>
> Kennan (Kai Qiang Wu’s nickname) has really done a nice job in Magnum
> contributions.  I would like to propose Kennan for the core reviewer team.
> I don’t think we necessarily need more core reviewers on Magnum, but Kennan
> has demonstrated a big commitment to Magnum and is a welcome addition in my
> opinion.
>
> For the lifetime of the project, Kennan has contributed 8% of the reviews,
> and 8% of the commits.  Kennan is also active in IRC.  He meets my
> definition of what a core developer for Magnum should be.
>
> Consider my proposal to be a +1 vote.
>
> Please vote +1 to approve or vote –1 to veto.  A single –1 vote acts as a
> veto, meaning Kennan would not be approved for the core team.  I believe we
> require 3 +1 core votes presently, but since our core team is larger now
> then when we started, I’d like to propose at our next team meeting we
> formally define the process by which we accept new cores post this proposal
> for Magnum into the magnum-core group and document it in our wiki.
>
> I’ll leave voting open for 1 week until June 6th to permit appropriate time
> for the core team to vote.  If there is a unanimous decision or veto prior
> to that date, I’ll close voting and make the appropriate changes in gerrit
> as appropriate.
>
> Thanks
> -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
>



-- 
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][api] New micro-version needed for api bug fix or not?

[Xu, Hejie]

Replied in line with prefix [alex]

-Original Message-
From: John Garbutt [mailto:j...@johngarbutt.com] 
Sent: Friday, May 29, 2015 8:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][api] New micro-version needed for api bug 
fix or not?

On 29 May 2015 at 09:00, Sahid Orentino Ferdjaoui  
wrote:
> On Fri, May 29, 2015 at 08:47:01AM +0200, Jens Rosenboom wrote:
>> As the discussion in https://review.openstack.org/179569 still 
>> continues about whether this is "just" a bug fix, or an API change 
>> that will need a new micro version, maybe it makes sense to take this 
>> issue over here to the ML.
>
> Changing version of the API probably makes sense also for bug if it 
> changes the behavior of a command/option to something backward 
> incompatible. I do not believe it is the case for your change.
>
>> My personal opinion is undecided, I can see either option as being 
>> valid, but maybe after having this open bug for four weeks now we can 
>> come to some conclusion either way.

Apologies for this, we are still trying to evolve the rules for when to bump 
the API micro versions, there will be some pain while we work that out :(


>From the summit discussion, I think got three things roughly agreed (although 
>we have not yet got them written up into a devref document, to make the formal 
>agreement, and we need to do that ASAP):

1)
We agreed changing a 500 error to an existing error (or making it succeed in 
the usual way) is a change that doesn't need a version bump, its a bug fix.

[alex] from the etherpad 
https://etherpad.openstack.org/p/YVR-nova-contributor-meetup it said fix 500 
for existed error can be without bump version. If it is new type of error code, 
that would need bump. But I'm not quite understand this one. There maybe some 
new functionality add to API, then there are some exception forget to catching, 
then server return 500. After we found this error, I didn't found out the 
reason we should bump version.

2)
We also agreed that all micro version bumps need a spec, to help avoid is 
adding more "bad" things to the API as we try and move forward.
This is heavy weight. In time, we might find certain "good" patterns where we 
want to relax that restriction, but we haven't done enough changes to agree on 
those patterns yet. This will mean we are moving a bit slower at first, but it 
feels like the right trade off against releasing (i.e. something that lands in 
any commit on master) an API with a massive bug we have to support for a long 
time.

[alex]: For this case, do we need register a blueprint for it? Maybe we just 
reference the bug in the nova-spec is enough.

3)
Discuss other cases as they came up, and evolve the plans based on the examples 
that come up, with a focus on bumping the version being
(almost) free, and useful for clients to work out what has changed.

Is that how everyone else remembers that discussion?


Now when it comes to your change. It is a bug in the default policy.
Sadly this policy is also quite hard wired to admin vs non-admin. We still need 
work to make policy more discoverable, so I don't think we need to make this 
any more discoverable as such.

[alex]: This isn't controlled by policy currently, or your think those query 
parameter should controlled by policy?

Having said all that, we probably need to look at this case more carefully, 
after your patch has merged, and work out how this should work now we assuming 
strong validation, and granular policy, etc.

But maybe there is something massive here?


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

__
OpenStack Development Mailing 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][api] New micro-version needed for api bug fix or not?

[Xu, Hejie]

I also learn that from Sean!

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: Saturday, May 30, 2015 2:58 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][api] New micro-version needed for api bug 
fix or not?

On 05/29/2015 05:04 AM, John Garbutt wrote:
> On 29 May 2015 at 09:00, Sahid Orentino Ferdjaoui 
>  wrote:
>> On Fri, May 29, 2015 at 08:47:01AM +0200, Jens Rosenboom wrote:
>>> As the discussion in https://review.openstack.org/179569 still 
>>> continues about whether this is "just" a bug fix, or an API change 
>>> that will need a new micro version, maybe it makes sense to take 
>>> this issue over here to the ML.
>>
>> Changing version of the API probably makes sense also for bug if it 
>> changes the behavior of a command/option to something backward 
>> incompatible. I do not believe it is the case for your change.
>>
>>> My personal opinion is undecided, I can see either option as being 
>>> valid, but maybe after having this open bug for four weeks now we 
>>> can come to some conclusion either way.
>
> Apologies for this, we are still trying to evolve the rules for when 
> to bump the API micro versions, there will be some pain while we work 
> that out :(
>
>
>  From the summit discussion, I think got three things roughly agreed 
> (although we have not yet got them written up into a devref document, 
> to make the formal agreement, and we need to do that ASAP):
>
> 1)
> We agreed changing a 500 error to an existing error (or making it 
> succeed in the usual way) is a change that doesn't need a version 
> bump, its a bug fix.
>
> 2)
> We also agreed that all micro version bumps need a spec, to help avoid 
> is adding more "bad" things to the API as we try and move forward.
> This is heavy weight. In time, we might find certain "good" patterns 
> where we want to relax that restriction, but we haven't done enough 
> changes to agree on those patterns yet. This will mean we are moving a 
> bit slower at first, but it feels like the right trade off against 
> releasing (i.e. something that lands in any commit on master) an API 
> with a massive bug we have to support for a long time.
>
> 3)
> Discuss other cases as they came up, and evolve the plans based on the 
> examples that come up, with a focus on bumping the version being
> (almost) free, and useful for clients to work out what has changed.
>
> Is that how everyone else remembers that discussion?

Yes.

> Now when it comes to your change. It is a bug in the default policy.
> Sadly this policy is also quite hard wired to admin vs non-admin. We 
> still need work to make policy more discoverable, so I don't think we 
> need to make this any more discoverable as such.
>
> Having said all that, we probably need to look at this case more 
> carefully, after your patch has merged, and work out how this should 
> work now we assuming strong validation, and granular policy, etc.

Actually, after reading the IRC conversation between Dims and Sean, I believe 
Sean is right to want a microversion bump for this patch. If two clouds are 
deployed, one with this patch and another without, a client issuing commands to 
both will have no idea whether the ip6 filter will be considered or not. Having 
a microversion increment in the patch would allow clients to request behaviour 
they want (the ip6 filter).

Best,
-jay

> But maybe there is something massive here?
>
>
> 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
>

__
OpenStack Development Mailing 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] [Manila] Expected Manila behavior for creation of share from snapshot

[Deepak Shetty]

On Thu, May 28, 2015 at 4:54 PM, Duncan Thomas 
wrote:

> On 28 May 2015 at 13:03, Deepak Shetty  wrote:
>
>> Isn't this similar to what cinder transfer-* cmds are for ? Ability to
>> transfer cinder volume across tenants
>> So Manila should be implementing the transfer-* cmds, after which
>> admin/user can create a clone
>> then initiate a transfer to a diff tenant  ?
>>
>>
> Cinder doesn't seem to have any concept analogous to a share network from
> what I can see; the cinder transfer commands are for moving a volume
> between tenants, which is a different thing, I think.
>

Yes, cinder doesn't have any eq of share network. But my comment was from
the functionality perpsective. In cinder transfer-* commands are used to
transfer ownership of volumes across tenants. IIUC the ability in Manila to
create a share from snapshot and have that share in a different share
network is eq to creating a share from a snapshot for a different tenant,
no ? Share networks are typically 1-1 with tenant network AFAIK, correct me
if i am wrong


>
> --
> 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][sahara]

[lu jander]

hi Rob

thx for your information, i have updated my horizon master, but it seems
the issue still exists,  do you running this well after update the master?

2015-05-29 17:35 GMT+08:00 Rob Cresswell (rcresswe) :

>  This was a known bug with the modals, which was fixed yesterday. Update
> horizon master, and you’re good to go :)
>
>  Bug: https://bugs.launchpad.net/horizon/+bug/1459115
> Patch: https://review.openstack.org/#/c/185927/
>
>  Rob
>
>
>   From: lu jander 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Friday, 29 May 2015 03:14
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [Horizon][sahara]
>
>   Hi, guys.
>
>  I installed latest devstack many times, but it seems there are many
> issue with that,  one snapshot pic below for example, have you ever met
> recently?
>
>  [image:  1]
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] "ip netns exec" creates new filesystem namespace

[Chris Friesen]

As a public service announcement I thought I'd mention something that we 
recently spent quite a few hours tracking down.


When neutron runs "ip netns exec" to run dnsmasq or neutron-ns-metadata-proxy, 
this causes the creation of a new filesystem namespace (in addition to setting 
the network namespace), which means that any devices that are mounted will be 
mounted in the new filesystem namespace as well, causing their refcounts to be 
incremented.  The new filesystem namespace exists as long as the executable 
started by the command.


So if you have something like a drbd block device that you want to demote (or 
any number of other similar scenarios) you have to go into all of the filesystem 
namespaces and unmount that block device in each namespace before the refcount 
actually drops back to zero.


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] Proposing Kai Qiang Wu (Kennan) for Core for Magnum

[Hongbin Lu]

+1!

From: Steven Dake (stdake) [mailto:std...@cisco.com]
Sent: May-31-15 1:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [magnum] Proposing Kai Qiang Wu (Kennan) for Core for 
Magnum

Hi core team,

Kennan (Kai Qiang Wu's nickname) has really done a nice job in Magnum 
contributions.  I would like to propose Kennan for the core reviewer team.  I 
don't think we necessarily need more core reviewers on Magnum, but Kennan has 
demonstrated a big commitment to Magnum and is a welcome addition in my opinion.

For the lifetime of the project, Kennan has contributed 8% of the reviews, and 
8% of the commits.  Kennan is also active in IRC.  He meets my definition of 
what a core developer for Magnum should be.

Consider my proposal to be a +1 vote.

Please vote +1 to approve or vote -1 to veto.  A single -1 vote acts as a veto, 
meaning Kennan would not be approved for the core team.  I believe we require 3 
+1 core votes presently, but since our core team is larger now then when we 
started, I'd like to propose at our next team meeting we formally define the 
process by which we accept new cores post this proposal for Magnum into the 
magnum-core group and document it in our wiki.

I'll leave voting open for 1 week until June 6th to permit appropriate time for 
the core team to vote.  If there is a unanimous decision or veto prior to that 
date, I'll close voting and make the appropriate changes in gerrit as 
appropriate.

Thanks
-steve

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

Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead

[Ildikó Váncsa]

Hi All,

I would like to ask about the user-facing notifications part of the list. Do 
you have a roadmap for this? Is this driven by the Zaqar team? What are the 
next steps?

Thanks and Best Regards,
Ildikó

-Original Message-
From: Clint Byrum [mailto:cl...@fewbar.com] 
Sent: May 27, 2015 18:42
To: openstack-dev
Subject: Re: [openstack-dev] [Zaqar][all] Zaqar will stay... Lots of work ahead

Excerpts from Flavio Percoco's message of 2015-05-26 01:28:06 -0700:
> Greetings,
> 
> TL;DR: Thanks everyone for your feedback. Based on the discussed plans 
> at the summit - I'll be writing more about these later - Zaqar will 
> stick around and play its role in the community.
> 
> Summit Summary
> ==
> 
> I'm happy to say that several use cases were discussed at the summit 
> and the difference from previous summits is that we left the room with 
> some action items to make them happen.
> 
> Cross-project user-facing notifications 
> ===
> 
> https://etherpad.openstack.org/p/liberty-cross-project-user-notificati
> ons
> 
> Besides brainstorming a bit on what things should/should not be 
> notified and what format should be used, we also talked a bit about 
> the available technologies that could be used for this tasks. Zaqar 
> was among those and, AFAICT, at the end of the session we agreed on 
> giving this a try. It'll likely not happen as fast as we want but the 
> action item out of this session was to write a cross-project spec 
> describing the things discussed and the technology that will be 
> adopted.
> 

My takeaway from that session was that there's need for something like yagi to 
filter the backend notifications into user-consumable tenant-scoped messages, 
and that Zaqar would be an interesting target for those messages along with 
Atom feeds or perhaps other pub/sub oriented things that deployers would be 
comfortable hosting for their users.

> Heat + Zaqar
> 
> 
> The 2 main areas where Zaqar will be used in Heat are Software Config 
> and Hooks. The minimum requirements (server side) for this are in 
> place already. There's some work to do on the client side that the 
> team will get to asap.
> 

The bigger one to me is just user-notificiation which I think is covered in the 
cross project session, but it's worth noting that Heat is one of the projects 
that already does some user notification and suffers problems because of it 
(the events API is what I mean here).

> Next Steps
> ==
> 
> In light of the above, and as mentioned in the TL;DR, Zaqar will stick 
> around and the team, as promised, will focus on making those 
> integrations happen. The team is small, which means we'll carefully 
> pick the tasks we'll be spending time on.
> 
> As a first step, we should restore our meetings and get to work right 
> away. To favor our contributors in NZ, next week's meeting will be at
> 21:00 UTC and we'll keep it at that time for 2 weeks.
> 
> For the Zaqar team (and folks interested), I'll be sending out further 
> emails to sync on the work to do.
> 
> Special thanks for all the folks that showed interest, participated in 
> sessions and that are committed on making this happen.
> 

Thanks for setting things up for success before the summit. I think we all went 
into the discussions with an open mind because we knew where the team stood.


== Crazy idea section ==

One thing I never had a chance to discuss with any of the Zaqar devs that I 
would find interesting is an email-only backend for Zaqar. Basically make Zaqar 
an HTTP-to-email gateway. There are quite a few hyper-scale options for SMTP 
and IMAP, and they're inherently multi-tenant, so I'd find it interesting to 
see if the full Zaqar API could be mapped onto that. This would probably be 
more comfortable to scale for some deployers than Redis or MongoDB, and might 
have the nice side-effect that a deployer could expose IMAP IDLE for efficient 
end-user subscription, and it could also allow Zaqar to serve as 
email-as-a-service for senders too (to prevent getting all your vms' IPs added 
to spam lists overnight. ;)

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

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

Re: [openstack-dev] [magnum] Proposing Kai Qiang Wu (Kennan) for Core for Magnum

[Jay Lau]

+1!

2015-05-31 23:30 GMT+08:00 Hongbin Lu :

>  +1!
>
>
>
> *From:* Steven Dake (stdake) [mailto:std...@cisco.com]
> *Sent:* May-31-15 1:56 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [magnum] Proposing Kai Qiang Wu (Kennan) for
> Core for Magnum
>
>
>
> Hi core team,
>
>
>
> Kennan (Kai Qiang Wu’s nickname) has really done a nice job in Magnum
> contributions.  I would like to propose Kennan for the core reviewer team.
> I don’t think we necessarily need more core reviewers on Magnum, but Kennan
> has demonstrated a big commitment to Magnum and is a welcome addition in my
> opinion.
>
>
>
> For the lifetime of the project, Kennan has contributed 8% of the reviews,
> and 8% of the commits.  Kennan is also active in IRC.  He meets my
> definition of what a core developer for Magnum should be.
>
>
>
> Consider my proposal to be a +1 vote.
>
>
>
> Please vote +1 to approve or vote –1 to veto.  A single –1 vote acts as a
> veto, meaning Kennan would not be approved for the core team.  I believe we
> require 3 +1 core votes presently, but since our core team is larger now
> then when we started, I’d like to propose at our next team meeting we
> formally define the process by which we accept new cores post this proposal
> for Magnum into the magnum-core group and document it in our wiki.
>
>
>
> I’ll leave voting open for 1 week until June 6th to permit appropriate
> time for the core team to vote.  If there is a unanimous decision or veto
> prior to that date, I’ll close voting and make the appropriate changes in
> gerrit as appropriate.
>
>
>
> Thanks
>
> -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
>
>


-- 
Thanks,

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

Re: [openstack-dev] [puppet] [ceph] Managing a ceph cluster's lifecycle with puppet

[David Moreau Simard]

Hey Bryan,

The configuration is done through a provider - you can use it in your
composition layer, your site.pp or wherever else you want - a bit like this:

ceph_config {
'osd/osd_journal_size', value => '16384';
'osd/osd_max_backfills', value => '1';
# ...
'client/rbd_cache': value => 'true';
'client/rbd_cache_writethrough_until_flush' => 'true'
#...
}

Off the top of my head, the major things that the module does not
currently do:
- Advanced pool configuration (Erasure coded pools, Cache tiering)
- CRUSH Map management

In general, puppet-ceph is still early in the development process
compared to mature and feature-full modules like puppet-nova,
puppet-neutron or puppet-cinder.
Contributions and feedback is definitely welcome !

Personally I use puppet-ceph to bootstrap the installation of the
nodes/OSDs and manage the cluster's critical configuration manually.

For upgrading the cluster, I'm biased towards orchestrating this with
another tool like Ansible since you usually want to control which server
you upgrade first.

-- 
David Moreau Simard

On 2015-05-29 05:32 PM, Stillwell, Bryan wrote:
> Hey guys,
>
> One of my top tasks this quarter is to puppetize our ceph environments.
> I've already spent some time going over the module, but wanted to start a
> conversation around some of the tasks I would like the module to do.
> Currently I'm planning on doing the work in the following phases:
>
> Phase 1 - Switch the installation of ceph packages, management of
> ceph.conf,
>   and management of cephx keys from ceph-deploy to puppet-ceph.
>
> Phase 2 - Switch the installation and management of mon nodes to be handled
>   by puppet-ceph.
>
> Phase 3 - Switch the installation and management of osd nodes to be handled
>   by puppet-ceph.
>
> I'm mostly done with phase 1, but wanted to ask what the best way to handle
> additional options are in the config file?  I want to be able to manage
> options like the following:
>
> [osd]
> osd_journal_size = 16384
> osd_max_backfills = 1
> osd_recovery_max_active = 1
> osd_recovery_op_priority = 1
> osd_recovery_max_single_start = 1
> osd_op_threads = 12
> osd_crush_initial_weight = 0
>
> [client]
> rbd cache = true
> rbd cache writethrough until flush = true
>
>
> Phase 2 seems pretty straight-forward at this point, but if you guys have
> any things I should watch out for I wouldn't mind hearing them.
>
> Phase 3 is where I have the most questions:
>
> How well does puppet-ceph handle pool configuration?
>
> Can it handle setting the room/row/rack/node in the CRUSH map when adding
> new nodes?
>
> What's the best process for replace a failed HDD?  Journal drive?
>
> How could we use best utilize puppet-ceph for augmenting an existing
> cluster
> without causing performance problems?
>
> Is there a good way to decommission hardware?
>
> Any ideas around managing ceph rules?  (default, ssd-only pools, primary
> affinity, cache tiering, erasure coding)
>
> What's it look like to upgrade a ceph cluster with puppet-ceph?
>
>
> Thanks,
>
> Bryan Stillwell
>
>
> This E-mail and any of its attachments may contain Time Warner Cable 
> proprietary information, which is privileged, confidential, or subject to 
> copyright belonging to Time Warner Cable. This E-mail is intended solely for 
> the use of the individual or entity to which it is addressed. If you are not 
> the intended recipient of this E-mail, you are hereby notified that any 
> dissemination, distribution, copying, or action taken in relation to the 
> contents of and attachments to this E-mail is strictly prohibited and may be 
> unlawful. If you have received this E-mail in error, please notify the sender 
> immediately and permanently delete the original and any copy of this E-mail 
> and any printout.
>
> __
> OpenStack Development Mailing 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] [akanda] meeting time change

[sean roberts]

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

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

[Jay Lau]

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

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

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

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

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

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

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

-- 
Thanks,

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

Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

[Steven Dake (stdake)]

Jay 513

+1 on mandatory name requirement.

From: Jay Lau mailto:jay.lau@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, May 31, 2015 at 2:38 PM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required 
option when creating a Bay/Baymodel


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

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

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

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

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

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

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

Please show your comments if any.

--
Thanks,

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

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

[Alan Pevec]

2015-05-29 18:30 GMT+02:00 Jeremy Stanley :
> On 2015-05-29 16:30:12 +0100 (+0100), Dave Walker wrote:
>> This is generally my opinion as-well, I always hoped that *every*
>> commit would be considered a release rather than an arbitrary
>> tagged date.
> [...]
>
> If we switch away from lockstep major/minor release versioning
> anyway (again separate discussion underway but seems a distinct
> possibility) then I think the confusion over why stable point
> releases are mismatched becomes less of an issue. At that point we
> may want to reconsider and actually tag each of them with a
> sequential micro (patch in semver terminology) version bump. Could
> help in communication around security fixes in particular.

Yes, if dropping stable point releases, sub-version schema is still
needed for clear communication in OSSAs and proposed continuous
releases notes.
One issue is how would we provide source tarballs, statically hosting
tarballs for each and every micro version is not realistic, also those
wouldn't be signed.
RPM packages traditionally expect pristine upstream tarballs which can
be verified and generating them from git is not reproducible e.g.
right now in nova stable/kilo branch:
python ./setup.py sdist
mv dist/nova-2015.1.1.dev20.tar.gz dist/nova-2015.1.1.dev20.tar.gz-TAKE1
python ./setup.py sdist
diff dist/nova-2015.1.1.dev20.tar.gz-TAKE1 dist/nova-2015.1.1.dev20.tar.gz
Binary files dist/nova-2015.1.1.dev20.tar.gz-TAKE1 and
dist/nova-2015.1.1.dev20.tar.gz differ

Before dropping point releases, I would like to have:
* idempotent sdist on the same SHA
* dynamic tarball generation service like github archive
* switch to micro-version i.e. current nova stable/kilo would be 2015.1.20


Cheers,
Alan

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

[openstack-dev] [kolla] Meeting Reminder - Wednesday, June 3rd, 2200 UTC

[Steven Dake (stdake)]

Hey folks,

Since this is our first odd week meeting and the time is different from our 
original time, I’d like to remind folks interested in Kolla to attend our IRC 
meeting in openstack-meeting-4 at 2200 UTC on Wednesday, June 3rd.

Agenda is here:
https://wiki.openstack.org/wiki/Meetings/Kolla#Agenda_for_next_meeting

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

Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

[Davanum Srinivas]

+1 from me as well

On Sun, May 31, 2015 at 6:08 PM, Steven Dake (stdake)  wrote:
> Jay 513
>
> +1 on mandatory name requirement.
>
> From: Jay Lau 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Sunday, May 31, 2015 at 2:38 PM
> To: OpenStack Development Mailing List 
> Subject: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a
> required option when creating a Bay/Baymodel
>
>
> Just want to use ML to trigger more discussion here. There are now
> bugs/patches tracing this, but seems more discussions are needed before we
> come to a conclusion.
>
> https://bugs.launchpad.net/magnum/+bug/1453732
> https://review.openstack.org/#/c/181839/
> https://review.openstack.org/#/c/181837/
> https://review.openstack.org/#/c/181847/
> https://review.openstack.org/#/c/181843/
>
> IMHO, making the Bay/Baymodel name as a MUST will bring more flexibility to
> end user as Magnum also support operating Bay/Baymodel via names and the
> name might be more meaningful to end users.
>
> Perhaps we can borrow some iead from nova, the concept in magnum can be
> mapped to nova as following:
>
> 1) instance => bay
> 2) flavor => baymodel
>
> So I think that a solution might be as following:
> 1) Make name as a MUST for both bay/baymodel
> 2) Update magnum client to use following style for bay-create and
> baymodel-create: DO NOT add "--name" option
>
> root@devstack007:/tmp# nova boot
> usage: nova boot [--flavor ] [--image ]
>  [--image-with ] [--boot-volume ]
>  [--snapshot ] [--min-count ]
>  [--max-count ] [--meta ]
>  [--file ] [--key-name ]
>  [--user-data ]
>  [--availability-zone ]
>  [--security-groups ]
>  [--block-device-mapping ]
>  [--block-device key1=value1[,key2=value2...]]
>  [--swap ]
>  [--ephemeral size=[,format=]]
>  [--hint ]
>  [--nic
> ]
>  [--config-drive ] [--poll]
>  
> error: too few arguments
> Try 'nova help boot' for more information.
> root@devstack007:/tmp# nova flavor-create
> usage: nova flavor-create [--ephemeral ] [--swap ]
>   [--rxtx-factor ] [--is-public ]
>   
>
> Please show your comments if any.
>
> --
> Thanks,
>
> Jay Lau (Guangya Liu)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[Matthew Thode]

On 05/31/2015 05:50 PM, Alan Pevec wrote:
> 2015-05-29 18:30 GMT+02:00 Jeremy Stanley :
>> On 2015-05-29 16:30:12 +0100 (+0100), Dave Walker wrote:
>>> This is generally my opinion as-well, I always hoped that *every*
>>> commit would be considered a release rather than an arbitrary
>>> tagged date.
>> [...]
>>
>> If we switch away from lockstep major/minor release versioning
>> anyway (again separate discussion underway but seems a distinct
>> possibility) then I think the confusion over why stable point
>> releases are mismatched becomes less of an issue. At that point we
>> may want to reconsider and actually tag each of them with a
>> sequential micro (patch in semver terminology) version bump. Could
>> help in communication around security fixes in particular.
> 
> Yes, if dropping stable point releases, sub-version schema is still
> needed for clear communication in OSSAs and proposed continuous
> releases notes.
> One issue is how would we provide source tarballs, statically hosting
> tarballs for each and every micro version is not realistic, also those
> wouldn't be signed.
> RPM packages traditionally expect pristine upstream tarballs which can
> be verified and generating them from git is not reproducible e.g.
> right now in nova stable/kilo branch:
> python ./setup.py sdist
> mv dist/nova-2015.1.1.dev20.tar.gz dist/nova-2015.1.1.dev20.tar.gz-TAKE1
> python ./setup.py sdist
> diff dist/nova-2015.1.1.dev20.tar.gz-TAKE1 dist/nova-2015.1.1.dev20.tar.gz
> Binary files dist/nova-2015.1.1.dev20.tar.gz-TAKE1 and
> dist/nova-2015.1.1.dev20.tar.gz differ
> 
> Before dropping point releases, I would like to have:
> * idempotent sdist on the same SHA
> * dynamic tarball generation service like github archive
> * switch to micro-version i.e. current nova stable/kilo would be 2015.1.20
> 
> 
> 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
> 
Generating tarballs from commit sha's isn't enough?

I'm personally thinking of installing a file somewhere that references
what commit hash the package was sourced from.  I'm thinking of doing
weekly releases.

Tarball generation would be nice.

You will get different checksums with tar and/or gzip, you can check the
extracted files and they should be the same.

I would like to see signed commits in the 'official' repos (at
git.openstack.org), if only because relying on sha alone doesn't seem
enough for some.

-- 
Matthew Thode



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

[Steve Gordon]

- Original Message -
> From: "Maish Saidel-Keesing" 
> To: openstack-dev@lists.openstack.org
> 
> On 05/29/15 18:25, Matthew Thode wrote:
> > On 05/29/2015 10:18 AM, Ihar Hrachyshka wrote:
> >> What about release notes? How can we now communicate some changes that
> >> require operator consideration or action?
> >>
> >> Ihar
> >>
> >> On 05/29/2015 03:41 PM, Thierry Carrez wrote:
> >>> Hi everyone,
> >>> TL;DR: - We propose to stop tagging coordinated point releases
> >>> (like 2015.1.1) - We continue maintaining stable branches as a
> >>> trusted source of stable updates for all projects though
> >>> Long version:
> >>> At the "stable branch" session in Vancouver we discussed recent
> >>> evolutions in the stable team processes and how to further adapt
> >>> the work of the team in a "big tent" world.
> >>> One of the key questions there was whether we should continue
> >>> doing stable point releases. Those were basically tags with the
> >>> same version number ("2015.1.1") that we would periodically push to
> >>> the stable branches for all projects.
> >>> Those create three problems.
> >>> (1) Projects do not all follow the same versioning, so some
> >>> projects (like Swift) were not part of the "stable point releases".
> >>> More and more projects are considering issuing intermediary
> >>> releases (like Swift does), like Ironic. That would result in a
> >>> variety of version numbers, and ultimately less and less projects
> >>> being able to have a common "2015.1.1"-like version.
> >>> (2) Producing those costs a non-trivial amount of effort on a very
> >>> small team of volunteers, especially with projects caring about
> >>> stable branches in various amounts. We were constantly missing the
> >>> pre-announced dates on those ones. Looks like that effort could be
> >>> better spent improving the stable branches themselves and keeping
> >>> them working.
> >>> (3) The resulting "stable point releases" are mostly useless.
> >>> Stable branches are supposed to be always usable, and the
> >>> "released" version did not undergo significantly more testing.
> >>> Issuing them actually discourages people from taking whatever point
> >>> in stable branches makes the most sense for them, testing and
> >>> deploying that.
> >>> The suggestion we made during that session (and which was approved
> >>> by the session participants) is therefore to just get rid of the
> >>> "stable point release" concept altogether for non-libraries. That
> >>> said:
> >>> - we'd still do individual point releases for libraries (for
> >>> critical bugs and security issues), so that you can still depend on
> >>> a specific version there
> >>> - we'd still very much maintain stable branches (and actually focus
> >>> our efforts on that work) to ensure they are a continuous source of
> >>> safe upgrades for users of a given series
> >>> Now we realize that the cross-section of our community which was
> >>> present in that session might not fully represent the consumers of
> >>> those artifacts, which is why we expand the discussion on this
> >>> mailing-list (and soon on the operators ML).
> >>> If you were a consumer of those and will miss them, please explain
> >>> why. In particular, please let us know how consuming that version
> >>> (which was only made available every n months) is significantly
> >>> better than picking your preferred time and get all the current
> >>> stable branch HEADs at that time.
> >>> Thanks in advance for your feedback,
> >>> [1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch
> >>
> >> __
> >> OpenStack Development Mailing 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 release notes just do git log between commit hashes?
> Do you really think that is what an Operator will do? I do not think is
> a realistic expectation or something that will work.
> --
> Best Regards,
> Maish Saidel-Keesing

While I agree most operators probably don't want to necessarily dig this out of 
git themselves and it would need to be collated/exposed in a nicer way it seems 
like it would actually be more accurate than the current "release notes" for 
all the non-security bug fixes in stable which basically amount to a list of 
launchpad bug queries per project. You then have to sift through each bug to 
work out if the description reflects what was actually done etc:

https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.3

-Steve

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

Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

[Haiwei Xu]

+1 for Jay's suggestion.

xuhaiwei
-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: Monday, June 01, 2015 8:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a 
required option when creating a Bay/Baymodel

+1 from me as well

On Sun, May 31, 2015 at 6:08 PM, Steven Dake (stdake)  wrote:
> Jay 513
>
> +1 on mandatory name requirement.
>
> From: Jay Lau 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Sunday, May 31, 2015 at 2:38 PM
> To: OpenStack Development Mailing List 
> 
> Subject: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a 
> required option when creating a Bay/Baymodel
>
>
> Just want to use ML to trigger more discussion here. There are now 
> bugs/patches tracing this, but seems more discussions are needed 
> before we come to a conclusion.
>
> https://bugs.launchpad.net/magnum/+bug/1453732
> https://review.openstack.org/#/c/181839/
> https://review.openstack.org/#/c/181837/
> https://review.openstack.org/#/c/181847/
> https://review.openstack.org/#/c/181843/
>
> IMHO, making the Bay/Baymodel name as a MUST will bring more 
> flexibility to end user as Magnum also support operating Bay/Baymodel 
> via names and the name might be more meaningful to end users.
>
> Perhaps we can borrow some iead from nova, the concept in magnum can 
> be mapped to nova as following:
>
> 1) instance => bay
> 2) flavor => baymodel
>
> So I think that a solution might be as following:
> 1) Make name as a MUST for both bay/baymodel
> 2) Update magnum client to use following style for bay-create and
> baymodel-create: DO NOT add "--name" option
>
> root@devstack007:/tmp# nova boot
> usage: nova boot [--flavor ] [--image ]
>  [--image-with ] [--boot-volume ]
>  [--snapshot ] [--min-count ]
>  [--max-count ] [--meta ]
>  [--file ] [--key-name ]
>  [--user-data ]
>  [--availability-zone ]
>  [--security-groups ]
>  [--block-device-mapping ]
>  [--block-device key1=value1[,key2=value2...]]
>  [--swap ]
>  [--ephemeral size=[,format=]]
>  [--hint ]
>  [--nic
> ]
>  [--config-drive ] [--poll]
>  
> error: too few arguments
> Try 'nova help boot' for more information.
> root@devstack007:/tmp# nova flavor-create
> usage: nova flavor-create [--ephemeral ] [--swap ]
>   [--rxtx-factor ] [--is-public ]
>   
>
> Please show your comments if any.
>
> --
> Thanks,
>
> Jay Lau (Guangya Liu)
>
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

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

[Mohammad Hanif]

Hi Thomas,

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

Thanks,
—Hanif. 



On 5/29/15, 12:57 PM, "Vikram Choudhary"  wrote:

>Hi Thomos/Mathieu,
>
>Thanks for starting this mail thread. Let's discuss over the IRC as
>suggested by Paul.
>
>Thanks
>Vikram
>
>On 5/29/15, Paul Michali  wrote:
>> You can use the VPNaaS IRC channel/time... we don't have much on the agenda
>> right now, other than discussion VPN flavors for Liberty, in which it would
>> be good to discuss BGP VPN and Edge VPN.
>>
>> Regards,
>>
>> Paul Michali (pc_m)
>>
>> On Fri, May 29, 2015 at 11:08 AM  wrote:
>>
>>> Hi everyone,
>>>
>>> As a follow-up to discussions last week on a BGP VPN interconnection API
>>> and the work started with the people already involved, we are going to
>>> hold IRC meetings to discuss how to progress the different pieces of
>>> work, in particular on the API itself [1] and its implementation+drivers
>>> [2].
>>>
>>> The slot we propose is ** Tuesday 15:00 UTC ** with the first meeting
>>> next Tuesday (June 2nd).
>>>
>>> Note that, based on last week feedback, we submitted the existing
>>> stackforge project for inclusion in the Neutron "big tent" earlier this
>>> week [3].
>>>
>>> We will do a proper meeting registration (patch to openstack-infra
>>> irc-meeting) and send meeting info with wiki and meeting room before
>>> next Tuesday.
>>>
>>> Looking forward to discussing with everyone interested!
>>>
>>> -Thomas & Mathieu
>>>
>>> [1] currently being discussed at https://review.openstack.org/#/c/177740
>>> [2] https://github.com/stackforge/networking-bgpvpn
>>> [3] https://review.openstack.org/#/c/186041
>>>
>>>
>>>
>>>
>>> _
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations
>>> confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>> recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>>> electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme
>>> ou
>>> falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or privileged
>>> information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and
>>> delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have
>>> been
>>> modified, changed or falsified.
>>> Thank you.
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing 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] [Magnum] Magnum installation problem with devstack kilo

[Baohua Yang]

Hi, all
   I am following
http://git.openstack.org/cgit/openstack/magnum/tree/doc/source/dev/dev-quickstart.rst
to
install magnum with openstack kilo version.

   At the end, there are error messages like

python update.py /opt/stack/magnum
...
 Syncing /opt/stack/magnum/requirements.txt
2015-05-29 12:50:28.075 | 'oslo.versionedobjects' is not in
global-requirements.txt
2015-05-29 12:50:28.083 | + exit_trap
2015-05-29 12:50:28.083 | + local r=1
2015-05-29 12:50:28.084 | ++ jobs -p
2015-05-29 12:50:28.085 | + jobs=
2015-05-29 12:50:28.085 | + [[ -n '' ]]
2015-05-29 12:50:28.085 | + kill_spinner
2015-05-29 12:50:28.085 | + '[' '!' -z '' ']'
2015-05-29 12:50:28.085 | + [[ 1 -ne 0 ]]
2015-05-29 12:50:28.085 | + echo 'Error on exit'
2015-05-29 12:50:28.085 | Error on exit
2015-05-29 12:50:28.085 | + [[ -z /opt/stack/logs ]]
2015-05-29 12:50:28.085 | + /opt/stack/devstack/tools/worlddump.py -d
/opt/stack/logs
2015-05-29 12:50:28.122 | df: '/run/user/1000/gvfs': Permission denied
2015-05-29 12:50:28.165 | + exit 1


This repeats several times, does any one know the reason?

Thanks!

-- 
Best wishes!
Baohua
__
OpenStack Development Mailing 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] Magnum installation problem with devstack kilo

[Steven Dake (stdake)]

I have this same problem with devstack master.  I’m not sure what it is other 
then it involves the requirements repo possibly not containing 
oslo.versionedobjects on my system.  Dims has a suggestion to do something 
about it, but I didn’t get back to it.  Try joining channel 
#openstack-containers and hunting down dims.

Regards
-steve

From: Baohua Yang mailto:yangbao...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, May 31, 2015 at 10:08 PM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Magnum] Magnum installation problem with devstack kilo

Hi, all
   I am following 
http://git.openstack.org/cgit/openstack/magnum/tree/doc/source/dev/dev-quickstart.rst
 to install magnum with openstack kilo version.

   At the end, there are error messages like

python update.py /opt/stack/magnum
...
 Syncing /opt/stack/magnum/requirements.txt
2015-05-29 12:50:28.075 | 'oslo.versionedobjects' is not in 
global-requirements.txt
2015-05-29 12:50:28.083 | + exit_trap
2015-05-29 12:50:28.083 | + local r=1
2015-05-29 12:50:28.084 | ++ jobs -p
2015-05-29 12:50:28.085 | + jobs=
2015-05-29 12:50:28.085 | + [[ -n '' ]]
2015-05-29 12:50:28.085 | + kill_spinner
2015-05-29 12:50:28.085 | + '[' '!' -z '' ']'
2015-05-29 12:50:28.085 | + [[ 1 -ne 0 ]]
2015-05-29 12:50:28.085 | + echo 'Error on exit'
2015-05-29 12:50:28.085 | Error on exit
2015-05-29 12:50:28.085 | + [[ -z /opt/stack/logs ]]
2015-05-29 12:50:28.085 | + /opt/stack/devstack/tools/worlddump.py -d 
/opt/stack/logs
2015-05-29 12:50:28.122 | df: '/run/user/1000/gvfs': Permission denied
2015-05-29 12:50:28.165 | + exit 1


This repeats several times, does any one know the reason?

Thanks!

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

[openstack-dev] [cinder] Spec for volume migration improvement

[Sheng Bo Hou]

Hi all folks from Cinder,

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

Thanks, folks.

Best wishes,
Vincent Hou (侯胜博)

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

Tel: 86-10-82450778 Fax: 86-10-82453660
Notes ID: Sheng Bo Hou/China/IBM@IBMCNE-mail: sb...@cn.ibm.com 
Address:3F Ring, Building 28 Zhongguancun Software Park, 8 Dongbeiwang 
West Road, Haidian District, Beijing, P.R.C.100193
地址:北京市海淀区东北旺西路8号中关村软件园28号楼环宇大厦3层 邮编：100193
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

[Maish Saidel-Keesing]

On 06/01/15 03:20, Steve Gordon wrote:

- Original Message -

From: "Maish Saidel-Keesing" 
To: openstack-dev@lists.openstack.org

On 05/29/15 18:25, Matthew Thode wrote:

On 05/29/2015 10:18 AM, Ihar Hrachyshka wrote:

What about release notes? How can we now communicate some changes that
require operator consideration or action?

Ihar

On 05/29/2015 03:41 PM, Thierry Carrez wrote:

Hi everyone,
TL;DR: - We propose to stop tagging coordinated point releases
(like 2015.1.1) - We continue maintaining stable branches as a
trusted source of stable updates for all projects though
Long version:
At the "stable branch" session in Vancouver we discussed recent
evolutions in the stable team processes and how to further adapt
the work of the team in a "big tent" world.
One of the key questions there was whether we should continue
doing stable point releases. Those were basically tags with the
same version number ("2015.1.1") that we would periodically push to
the stable branches for all projects.
Those create three problems.
(1) Projects do not all follow the same versioning, so some
projects (like Swift) were not part of the "stable point releases".
More and more projects are considering issuing intermediary
releases (like Swift does), like Ironic. That would result in a
variety of version numbers, and ultimately less and less projects
being able to have a common "2015.1.1"-like version.
(2) Producing those costs a non-trivial amount of effort on a very
small team of volunteers, especially with projects caring about
stable branches in various amounts. We were constantly missing the
pre-announced dates on those ones. Looks like that effort could be
better spent improving the stable branches themselves and keeping
them working.
(3) The resulting "stable point releases" are mostly useless.
Stable branches are supposed to be always usable, and the
"released" version did not undergo significantly more testing.
Issuing them actually discourages people from taking whatever point
in stable branches makes the most sense for them, testing and
deploying that.
The suggestion we made during that session (and which was approved
by the session participants) is therefore to just get rid of the
"stable point release" concept altogether for non-libraries. That
said:
- we'd still do individual point releases for libraries (for
critical bugs and security issues), so that you can still depend on
a specific version there
- we'd still very much maintain stable branches (and actually focus
our efforts on that work) to ensure they are a continuous source of
safe upgrades for users of a given series
Now we realize that the cross-section of our community which was
present in that session might not fully represent the consumers of
those artifacts, which is why we expand the discussion on this
mailing-list (and soon on the operators ML).
If you were a consumer of those and will miss them, please explain
why. In particular, please let us know how consuming that version
(which was only made available every n months) is significantly
better than picking your preferred time and get all the current
stable branch HEADs at that time.
Thanks in advance for your feedback,
[1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch

__
OpenStack Development Mailing 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 release notes just do git log between commit hashes?

Do you really think that is what an Operator will do? I do not think is
a realistic expectation or something that will work.
--
Best Regards,
Maish Saidel-Keesing

While I agree most operators probably don't want to necessarily dig this out of git 
themselves and it would need to be collated/exposed in a nicer way it seems like it would 
actually be more accurate than the current "release notes" for all the 
non-security bug fixes in stable which basically amount to a list of launchpad bug 
queries per project. You then have to sift through each bug to work out if the 
description reflects what was actually done etc:

 https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.3

-Steve
I agree - and if this could be automated in some way to make is 
presentable - that would be ideal

--
Best Regards,
Maish Saidel-Keesing

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