Re: [openstack-dev] [tc] [all] TC Report 18-10

On 07/03/18 20:24, Lance Bragstad wrote: > > > On 03/07/2018 06:12 AM, Chris Dent wrote: >> >> HTML: https://anticdent.org/tc-report-18-10.html >> >> This is a TC Report, but since everything that happened in its window >> of observation is preparing for the >>

[openstack-dev] [api-wg][api][neutron] How to handle invalid query parameters

Hi all, This is a follow-up for the discussion in Dublin PTG about how Neutron API server should handle invalid query parameter [1]. According to the feedback, I sent this ML to seek advice from API-WG in this regards. As a brief recap, we were discussing how Neutron API server should behave

Re: [openstack-dev] [tc] [all] TC Report 18-10

On 03/07/2018 06:12 AM, Chris Dent wrote: > > HTML: https://anticdent.org/tc-report-18-10.html > > This is a TC Report, but since everything that happened in its window > of observation is preparing for the > [PTG](https://www.openstack.org/ptg), being at the PTG, trying to get > home from the

[openstack-dev] [api-wg][api][neutron] How to handle invalid query parameters

Hi all, This is a follow-up for the discussion in Dublin PTG about how Neutron API server should handle invalid query parameter [1]. According to the feedback, I sent this ML to seek advice from API-WG in this regards. As a brief recap, we were discussing how Neutron API server should behave

Re: [openstack-dev] [keystone] [oslo] new unified limit library

On 03/07/2018 09:49 AM, Lance Bragstad wrote: On 03/07/2018 09:31 AM, Chris Friesen wrote: On 03/07/2018 08:58 AM, Lance Bragstad wrote: Hi all, Per the identity-integration track at the PTG [0], I proposed a new oslo library for services to use for hierarchical quota enforcement [1]. Let

Re: [openstack-dev] [tc] [all] TC Report 18-10

On 3/7/2018 6:12 AM, Chris Dent wrote: # Talking about the PTG at the PTG At the [board meeting](http://lists.openstack.org/pipermail/foundation/2018-March/002570.html), the future of the PTG was a big topic. As currently constituted it presents some challenges: * It is difficult for some

Re: [openstack-dev] [keystone] [oslo] new unified limit library

On 03/07/2018 10:33 AM, Tim Bell wrote: Sorry, I remember more detail now... it was using the 'owner' of the VM as part of the policy rather than quota. Is there a per-user/per-group quota in Nova? Nova supports setting quotas for individual users within a project (as long as they are

Re: [openstack-dev] [TripleO][CI][QA][HA][Eris][LCOO] Validating HA on upstream

Hi Adam, > Raoul Scarazzini wrote: > >On 06/03/2018 13:27, Adam Spiers wrote: > >> Hi Raoul and all, > >> Sorry for joining this discussion late! > >[...] > >> I do not work on TripleO, but I'm part of the wider OpenStack > >> sub-communities which focus on HA[0] and more

Re: [openstack-dev] [api-wg][api][neutron] How to handle invalid query parameters

Hi all, Please disregard the email below since I used the wrong template. Sorry about that. The email with the same content was re-sent in a new thread http://lists.openstack.org/pipermail/openstack-dev/2018-March/128022.html . Best regards, Hongbin From: Hongbin Lu Sent: March-07-18 4:02 PM

Re: [openstack-dev] [api-wg][api][neutron] How to handle invalid query parameters

On Wed, 7 Mar 2018, Hongbin Lu wrote: As a brief recap, we were discussing how Neutron API server should behave if invalid query parameters were inputted. Per my understanding, the general consensus is to make Neutron API server behave consistently with other OpenStack projects. The question

Re: [openstack-dev] [tc] [all] TC Report 18-10

On 3/7/2018 2:24 PM, Lance Bragstad wrote: I tried bringing this up during the PTG feedback session last Thursday Unless you wanted to talk about snow, there was no feedback to be had at the feedback session. Being able to actually give feedback on the PTG during the PTG feedback session

[openstack-dev] [keystone] batch processing with unified limits

The keystone team is parsing the unified limits discussions from last week. One of the things we went over as a group was the usability of the current API [0]. Currently, the create and update APIs support batch processing. So specifying a list of limits is valid for both. This was a part of the

[openstack-dev] [tacker] tacker project team meeting is changed to GMT 0800 on Tuesdays

FYI https://review.openstack.org/#/c/550326/ yong sheng gong 99CLOUD Co. Ltd. Email：gong.yongsh...@99cloud.net Addr : Room 806, Tower B, Jiahua Building, No. 9 Shangdi 3rd Street, Haidian District, Beijing, China Mobile：+86-18618199879 http://99cloud.net

Re: [openstack-dev] [Openstack-sigs] [keystone] [oslo] new unified limit library

On 03/07/2018 10:44 AM, Tim Bell wrote: I think nested quotas would give the same thing, i.e. you have a parent project for the group and child projects for the users. This would not need user/group quotas but continue with the ‘project owns resources’ approach. Agreed, I think that if we

Re: [openstack-dev] [keystone] [oslo] new unified limit library

Yeah, we need a unified limit library , from oslo side we need a spec according to new library process. The spec will be useful to track the background and update oslo wiki [1] [0] http://specs.openstack.org/openstack/oslo-specs/specs/policy/new-libraries.html [1]

[openstack-dev] [QA] Meeting Thursday Mar 8th at 8:00 UTC

Hello everyone, Hope everyone is back to home after Dublin PTG. This is reminder for QA team meeting on Thursday, Mar 8th at 8:00 UTC in the #openstack-meeting channel. The agenda for the meeting can be found here:

[openstack-dev] [release] Release countdown for week R-24 and R-23, March 12-23

Welcome back to our regular release countdown email. Now that the PTG is over (hopefully no one is still waiting for their flight in DUB), we will send regular weekly countdown emails. Development Focus - Teams should be focusing on taking back discussions from the PTG and

Re: [openstack-dev] [cyborg][glance][nova]cyborg FPGA management flow disscusion.

Thanks Shaohe, Let's schedule a video conf session next week. On Thu, Mar 8, 2018 at 11:41 AM, Feng, Shaohe wrote: > Hi All: > > The POC is here: > *https://github.com/shaohef/cyborg* > > BR > Shaohe Feng > >

Re: [openstack-dev] [keystone] [oslo] new unified limit library

So the following was a prior effort: https://github.com/openstack/delimiter Maybe just continue down the path of that and/or take that whole repo over and iterate (or adjust the prior code, or ...)?? Or if not that's ok to, ya'll get to decide.

Re: [openstack-dev] [api-wg][api][neutron] How to handle invalid query parameters

On Thu, Mar 8, 2018 at 6:12 AM, Chris Dent wrote: > On Wed, 7 Mar 2018, Hongbin Lu wrote: > >> As a brief recap, we were discussing how Neutron API server should behave >> if invalid query parameters were inputted. Per my understanding, the general >> consensus is to make

[openstack-dev] [PTG] [Infra] [all] zuulv3 Job Template vs irrelevant files/branch var

Hi All, Before PTG, we were discussing about Job Template and irrelevant files issues on multiple mailing thread [1]. Both things does not work as expected and it leads to run the jobs on irrelevant files also and on excluded branch. In Dublin PTG, during infra help hours on Tuesday, we had

Re: [openstack-dev] [cyborg][glance][nova]cyborg FPGA management flow disscusion.

Hi All: The POC is here: https://github.com/shaohef/cyborg BR Shaohe Feng _ From: Feng, Shaohe Sent: 2018年2月12日 15:06 To: openstack-dev@lists.openstack.org; openstack-operat...@lists.openstack.org Cc: Du, Dolpher ; Zhipeng Huang

Re: [openstack-dev] [PTG] [Infra] [all] zuulv3 Job Template vs irrelevant files/branch var

On 2018-03-08 02:44, Ghanshyam Mann wrote: > Hi All, > > Before PTG, we were discussing about Job Template and irrelevant files > issues on multiple mailing thread [1]. > > Both things does not work as expected and it leads to run the jobs on > irrelevant files also and on excluded branch. > >

[openstack-dev] [vitrage] alarm and resource equivalence

Hi, Since we need to design these days both alarm equivalence/merge [1] and resource equivalence/merge features, I thought it might be a good idea to start with a use cases document. Let’s agree on the requirements, and then see if we can come up with a design that matches both cases. I pushed

[openstack-dev] [mistral] PTG Summary

Hey Mistralites (maybe?), I have been through the etherpad from the PTG and attempted to expand on the topics with details that I remember. If I have missed anything or you have any questions, please get in touch. I want to update it while the memory is as fresh as possible. For each main topic

[openstack-dev] [watcher] weekly meeting is cancelled

We will not be holding a weekly meeting this time since people experience some jet lag. Let’s meet on March 14 at 08:00 UTC as usual. Best Regards, Alex __ OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [TripleO][CI][QA][HA][Eris][LCOO] Validating HA on upstream

Raoul Scarazzini wrote: On 06/03/2018 13:27, Adam Spiers wrote: Hi Raoul and all, Sorry for joining this discussion late! [...] I do not work on TripleO, but I'm part of the wider OpenStack sub-communities which focus on HA[0] and more recently, self-healing[1].  With that

[openstack-dev] [heat] weekly meeting is cancelled

Hi team, As we just get back from #*SnowpenStack* (PTG), let's skip meeting this week. Here are sessions that we discussed in PTG, so if you would like to add some input to it, now is the time(try to leave your name, so we might know who it

[openstack-dev] [nova] [placement] Notes on eventually extracting placement

At the PTG we decided that while it was unlikely we could manage extracting Placement to its own project during Rocky, it would be useful to make incremental progress in that direction so the ground is prepared for when we do get around to it. This means making sure there are clear boundaries

Re: [openstack-dev] Fwd: [Release-job-failures] Release of openstack/paunch failed

On 2018-03-07 00:55:15 -0600 (-0600), Sean McGinnis wrote: [...] > When someone from infra gets a chance, would you be able to > reenqueue this job? I'm just now catching up on E-mail, but I reenqueued this tag at 11:55 UTC after Thierry brought it to my attention in the #openstack-release

Re: [openstack-dev] [Nova] [Cyborg] Tracking multiple functions

On 03/06/2018 09:36 PM, Alex Xu wrote: 2018-03-07 10:21 GMT+08:00 Alex Xu >: 2018-03-06 22:45 GMT+08:00 Mooney, Sean K >: __ __ __ __ *From:*Matthew Booth

Re: [openstack-dev] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project

On Wed, Mar 7, 2018 at 10:15 PM, Andrea Frittoli wrote: > > > On Wed, Mar 7, 2018 at 12:42 PM Ghanshyam Mann > wrote: > >> Hi All, >> >> QA had discussion in Dublin PTG about interop adds-on tests location. >> First of all thanks all

Re: [openstack-dev] [horizon][ptg] Horizon PTG Highlights

On 2018-03-07 00:08:39 +0200 (+0200), Ivan Kolodyazhny wrote: [...] > - we agreed to make go forward with Eventlet by default and make it >configurable to allow native Python threads which are used now >- let's ask the community about their experience with Eventlet >- Eventlet is not

Re: [openstack-dev] [Interop-wg] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project

On Wed, Mar 7, 2018 at 12:42 PM Ghanshyam Mann wrote: > Hi All, > > QA had discussion in Dublin PTG about interop adds-on tests location. > First of all thanks all (specially markvoelker, dhellmann, mugsie) for > joining the sessions. and I am glad we conclude the

[openstack-dev] [PTG][QA] QA PTG Rocky Summary

Hi All, First of all, thanks for joining Rocky PTG and making it really productive and successful. I am writing the QA PTG summary. Wwe started the 'owner' for each working item so that we have single point of contact to track those. That will help to make each priority item to complete on time.

[openstack-dev] [ptg] Release cycles vs. downstream consuming models discussion summary

Hi everyone, On Tuesday afternoon of the PTG week we had a track of discussions to brainstorm how to better align our release cycle and stable branch maintenance with the OpenStack downstream consumption models. You can find the notes at: https://etherpad.openstack.org/p/release-cycles-ptg-rocky

Re: [openstack-dev] [mistral] PTG Summary

On 7 March 2018 at 09:28, Dougal Matthews wrote: > Hey Mistralites (maybe?), > > I have been through the etherpad from the PTG and attempted to expand on > the topics with details that I remember. If I have missed anything or you > have any questions, please get in touch. I

[openstack-dev] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project

Hi All, QA had discussion in Dublin PTG about interop adds-on tests location. First of all thanks all (specially markvoelker, dhellmann, mugsie) for joining the sessions. and I am glad we conclude the things and agreed on solution. Discussion was carry forward from the ML discussion [1] and to

[openstack-dev] [tc] [all] TC Report 18-10

HTML: https://anticdent.org/tc-report-18-10.html This is a TC Report, but since everything that happened in its window of observation is preparing for the [PTG](https://www.openstack.org/ptg), being at the PTG, trying to get home from the PTG, and recovering from the PTG, perhaps think of this

[openstack-dev] [nova] Notification update week 10 (PTG)

Hi, Here is the status update / focus settings mail for w10. We discussed couple of new notification related changes during the PTG. I tried to mention all of them below but if I missed something then please extend my list. Bugs [High] https://bugs.launchpad.net/nova/+bug/1737201

Re: [openstack-dev] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project

On Wed, Mar 7, 2018 at 6:10 PM, Ghanshyam Mann wrote: > Hi All, > > QA had discussion in Dublin PTG about interop adds-on tests location. > First of all thanks all (specially markvoelker, dhellmann, mugsie) for > joining the sessions. and I am glad we conclude the

[openstack-dev] [docs] Documentation meeting canceled

Hi all, Canceling today's docs meeting as there is not much to share beyond what was in the PTG summary I sent. As always, we're in #openstack-doc if you want to talk to us! Thanks, pk __ OpenStack Development Mailing

Re: [openstack-dev] [QA] [PTG] [Interop] [Designate] [Heat] [TC]: QA PTG Summary- Interop test for adds-on project

On Wed, 7 Mar 2018, Rabi Mishra wrote: Projects (designate and heat) and QA team will work closely to move interop tests to Tempest repo which might needs some extra work of standardizing their tests and interface used by them like service clients etc. Though I've not been part of any of

[openstack-dev] [keystone] [oslo] new unified limit library

Hi all, Per the identity-integration track at the PTG [0], I proposed a new oslo library for services to use for hierarchical quota enforcement [1]. Let me know if you have any questions or concerns about the library. If the oslo team would like, I can add an agenda item for next weeks oslo

Re: [openstack-dev] [keystone] [oslo] new unified limit library

On 03/07/2018 09:31 AM, Chris Friesen wrote: > On 03/07/2018 08:58 AM, Lance Bragstad wrote: >> Hi all, >> >> Per the identity-integration track at the PTG [0], I proposed a new oslo >> library for services to use for hierarchical quota enforcement [1]. Let >> me know if you have any questions

Re: [openstack-dev] [keystone] [oslo] new unified limit library

On 03/07/2018 08:58 AM, Lance Bragstad wrote: Hi all, Per the identity-integration track at the PTG [0], I proposed a new oslo library for services to use for hierarchical quota enforcement [1]. Let me know if you have any questions or concerns about the library. If the oslo team would like, I

Re: [openstack-dev] [Openstack-sigs] [keystone] [oslo] new unified limit library

I think nested quotas would give the same thing, i.e. you have a parent project for the group and child projects for the users. This would not need user/group quotas but continue with the ‘project owns resources’ approach. It can be generalised to other use cases like the value add partner or

Re: [openstack-dev] [oslo.db] oslo_db "max_retries" option

On 02/27/2018 11:55 PM, Vitalii Solodilov wrote: Hi folks! I have a question about oslo_db "max_retries" option. https://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/engines.py#L381 Why only DBConnectionError is considered as a reason for reconnecting here? Wouldn't it be a

Re: [openstack-dev] [keystone] [oslo] new unified limit library

There was discussion that Nova would deprecate the user quota feature since it really didn't fit well with the 'projects own resources' approach and was little used. At one point, some of the functionality stopped working and was repaired. The use case we had identified goes away if you have 2

Re: [openstack-dev] [keystone] [oslo] new unified limit library

Sorry, I remember more detail now... it was using the 'owner' of the VM as part of the policy rather than quota. Is there a per-user/per-group quota in Nova? Tim -Original Message- From: Tim Bell Reply-To: "OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [keystone] [oslo] new unified limit library

This is certainly a feature will make Public Cloud providers very happy :) On Thu, Mar 8, 2018 at 12:33 AM, Tim Bell wrote: > Sorry, I remember more detail now... it was using the 'owner' of the VM as > part of the policy rather than quota. > > Is there a per-user/per-group