Re: [openstack-dev] [app-catalog][infra] Stale entries

+1 for the periodic job. I don't know how it fits to the current OpenStack infrastructure, but we definitely need this. As I know there is a place for 3rd party gates and CI\CD systems, so probably, the best way to do this for now, is to setup this externally to the OpenStack infra. Thanks Gosha

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

I also have an interest here and can approach it like Thai hoping to give some input and reviews as time allows this cycle. Just left a few comments on your spec, Brad. Thanks, Travis __ OpenStack Development Mailing List

Re: [openstack-dev] [Glance][Keystone] Glance and trusts

Continuing with David's example and the need to control access to a Swift object that Adam points out, How about using the Glance token from glance-API service to glance-registry but carry along extra data in the call, namely user-id, domain, and public/private information, so the object can be

Re: [openstack-dev] [nova] [glance] How to deal with aborted image read?

On 6/5/15, 02:55, "Flavio Percoco" wrote: >On 04/06/15 11:46 -0600, Chris Friesen wrote: >>On 06/04/2015 03:01 AM, Flavio Percoco wrote: >>>On 03/06/15 16:46 -0600, Chris Friesen wrote: We recently ran into an issue where nova couldn't write an image file due to lack of space and so

Re: [openstack-dev] [opnfv-tech-discuss] [Tricircle] Polling for weekly team meeting

Hi Iben, No worries about the name confusing :P Yes you are right Tricircle deals with the use of, not the setup or config. If I put my OPNFV hat on, I think we could definitely jointly investigate some of the multi-site automated setup-config-deploy requirements, among Pharos, IPv6 and Multisite

Re: [openstack-dev] [nova][all] Architecture Diagrams in ascii art?

On Fri, May 15, 2015 at 06:33:35PM -0700, Joe Gordon wrote: > On Fri, May 15, 2015 at 2:27 PM, Joe Gordon wrote: > > On Thu, May 14, 2015 at 3:52 AM, John Garbutt > > wrote: > >> Some great points make here. > >> > >> Lets try decide something, and move forward here. > >> > >> Key requirements se

[openstack-dev] [app-catalog][infra] Stale entries

We already have one Glance image in the app catalog that is 404. Since the app catalog contains entries that are hosted outside of OpenStack, Gerrit hooks are not necessarily the right way to check that links still work, since they can break weeks/months later. We may need some kind of job that

Re: [openstack-dev] Kilo v3 identity problems

Hi everyone, Thanks for helping me. I did wrong filter of my mailing, so I missed the topic. Thanks for Farhan forward the email to me. Thanks *Dolph Mathews, you gave the point. Binggo!!! I didn't assign the admin user to default domain. **I didn't have this problem when I worked with icehouse v

Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name

On 06/05/2015 01:15 PM, Henry Nash wrote: I am sure I have missed something along the way, but can someone explain to me why we need this at all. Project names are unique within a domain, with the exception of the project that is acting as its domain (i.e. they can only every be two names clas

Re: [openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/04/2015

Cathy, Make sure to take note when Fall rolls around that "pacific time" is ambiguous. UTC does not observe daylight savings so a meeting at 1700UTC will be 10:00 PDT but 09:00 PST. On 6/4/2015 5:17 PM, Cathy Zhang wrote: Thanks for joining the service chaining meeting today! Sorry for the t

Re: [openstack-dev] [Keystone] Domain and Project naming

On 06/04/2015 10:49 PM, Dolph Mathews wrote: On Wed, Jun 3, 2015 at 11:25 PM, Adam Young > wrote: With Hierarchical Multitenantcy, we have the issue that a project is currentl restricted in its naming further than it should be. The domain entity enforces

Re: [openstack-dev] [Glance][Keystone] Glance and trusts

On 06/05/2015 10:39 AM, Dolph Mathews wrote: On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick mailto:d.w.chadw...@kent.ac.uk>> wrote: I did suggest another solution to Adam whilst we were in Vancouver, and this mirrors what happens in the real world today when I order something

Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team

Initial draft of spec is out for review here https://review.openstack.org/188958 feedback welcome :) Thanks, Brad Jones On 4 Jun 2015, at 22:30, Adrian Otto mailto:adrian.o...@rackspace.com>> wrote: Team, I have published a top level blueprint for a magnum-horizon-plugin: https://blueprints.

Re: [openstack-dev] [neutron] Regarding Flow classifiers existing roposals

Hi, Sounds good, but I could join if it’s at the very start of the meeting, after 17:15 UTC I’m unavailable on Thursdays. Let me know if that’d be possible. Thanks in advance, Miguel Ángel Ajo On Friday 5 June 2015 at 20:36, Cathy Zhang wrote: > Sure. I will add this item to the nex

Re: [openstack-dev] Why do we drop branches? (WAS: Re: Targeting icehouse-eol?)

> Why do we even drop stable branches? If anything, it introduces > unneeded problems to those who have their scripts/cookbooks set to > chase those branches. They would need to switch to eol tag. Because they would otherwise expect updates which will never come. They should take a notice and remo

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

Hopefully it's somewhat obvious to folks that altering the PBR version schema (yet again), breaks *all the people* from using it in a reliable manner, and if the goal of PBR is to bring reasonableness, well changing it in a way that breaks things seems like the-anti-pattern of PBR. I know from

[openstack-dev] [Fuel] 6.1 Hard Code Freeze status update June 5th

Hello everyone, Unfortunately the recent patch for SWIFT issue [1] broke our staging tests last night. The problem is now resolved, new staging tests passed successfully. We need ~12 hours more to run the newly built ISO through SWARM tests, so we will have the results tomorrow morning MSK. If

[openstack-dev] [devstack] RTNETLINK permission denied on setting IPv6 on br-ex

We have been having this issue with devstack installation since Tuesday 6/2. On trying to add IPv6 address to br-ex, it fails with permission denied. Here's the output from stack.sh: + IPV6_ROUTER_GW_IP=2001:db8::1 + die_if_not_set 1299 IPV6_ROUTER_GW_IP 'Failure retrieving IPV6_ROUTER_GW_IP' + l

Re: [openstack-dev] Barbican : Retrieval of the secret in text/plain format generated from Barbican order resource

Hi All , I am currently working on use cases for database and file Encryption.It is really important for us to know since my Encryption use case would be using the key generated by Barbican through order resource as the key. The encyption algorithms would not accept the binary format and even if c

Re: [openstack-dev] [nova][all] Architecture Diagrams in ascii art?

+1 On Fri, Jun 5, 2015 at 6:38 PM, Vilobh Meshram < vilobhmeshram.openst...@gmail.com> wrote: > +1 > > On Thu, May 14, 2015 at 3:52 AM, John Garbutt > wrote: > >> On 12 May 2015 at 20:33, Sean Dague wrote: >> > On 05/12/2015 01:12 PM, Jeremy Stanley wrote: >> >> On 2015-05-12 10:04:11 -0700 (-0

[openstack-dev] [javascript] Linters

Right now, there are several JS linters in use in OpenStack: JSHint, JSCS, and Eslint. I really would like to only use one of them, so that I can figure out how to sanely share the configuration between projects. Can all those who have a strong opinion please stand up and state their opinions? Mi

Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals

Sure. I will add this item to the next IRC meeting agenda. Thanks, Cathy From: Henry Fourie Sent: Friday, June 05, 2015 11:27 AM To: Miguel Angel Ajo; Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org;

Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals

Hi Vikram, Definitely. We should have one unified and generic flow classifier/filter (whatever name we call it) that can be used by all cases. Thank you for driving this! Thanks, Cathy From: Miguel Angel Ajo [mailto:mangel...@redhat.com] Sent: Friday, June 05, 2015 1:42 AM To: Vikram Choudhary

Re: [openstack-dev] [Barbican] Multiple KMIP servers on a single barbican

> You would just store the url in the DTO. You will need to have the KMIP secret store return the KMIP server that handled the request in the metadata that is returned to Barbican Core. > each kmip server url would need to be in the barbican-api.conf file? I would assume that would be true. > I

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

Hi, Maybe we should just give a try: 1) I will prepare all modifications out of infra and show demo 2) Get it in Infra as experimental feature 3) Try it in Rally 4) Share experience and if it is worth keep it or get rid of it. Best regards, Boris Pavlovic On Fri, Jun 5, 2015 at 9:21 PM, Valeriy

Re: [openstack-dev] [rally][scaling up development] Rally core team re-organization

Excerpts from Boris Pavlovic's message of 2015-06-05 21:16:04 +0300: > All, > > Sorry for picking very bad words. I am not native speaker. =( > > In Russia this word has as well another meaning like being "to aggressive > against somebody". I used it in that meaning. I didn't thought about > sex

Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals

Miguel, I agree, we can probably use the service-chaining meeting to discuss this. We can have it as an agenda item for the next meeting: http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting - Louis From: Miguel Angel Ajo [mailto:mangel...@redhat.com] Sent: Friday, June

[openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

If such possibility appears then definitely will be people that will try it without weighing in to this discussion (like me). And, the only social problem is that such "maintainers" of project-sub-parts should be responsible enough. It is very likely that some vendor-specific-things maintainers ca

Re: [openstack-dev] [rally][scaling up development] Rally core team re-organization

All, Sorry for picking very bad words. I am not native speaker. =( In Russia this word has as well another meaning like being "to aggressive against somebody". I used it in that meaning. I didn't thought about sexually violated at all. Sorry sorry and one more time sorry! About using improper wo

Re: [openstack-dev] [rally][scaling up development] Rally core team re-organization

On 06/05/2015 06:31 PM, Doug Hellmann wrote: > Excerpts from Boris Pavlovic's message of 2015-06-05 20:03:44 +0300: >> Hi stackers, >> >> Seems likes after stackforge/rally -> openstack/rally Rally project started >> being more attractive. >> According recent stats we are on top 3 position (based o

Re: [openstack-dev] [rally][scaling up development] Rally core team re-organization

Sylvain, Are you sure your tone is appropriate once you read again your email ? I don't see anything wrong in tone & email at all. I just summarize for Rally team results of that thread. So they won't need to read it. And explain why we won't have sub cores and need trust model. That's all. >

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

The one proviso is that in single LDAP situations, the cloud provider can chose (for backward compatibility reasons) to allow the underlying LDAP user/group ID….so we might want to advise this to be disabled (there’s a config switch to use the Public ID mapping for even this case). Henry > On 5

Re: [openstack-dev] [rally][scaling up development] Rally core team re-organization

Le 05/06/2015 19:03, Boris Pavlovic a écrit : Hi stackers, Seems likes after stackforge/rally -> openstack/rally Rally project started being more attractive. According recent stats we are on top 3 position (based on Patch sets stats) http://stackalytics.com/?release=liberty&metric=patches&p

Re: [openstack-dev] [rally][scaling up development] Rally core team re-organization

Doug, I understand that you feel that the negative response to your > proposal was strong, but this is *COMPLETELY* inappropriate wording > for this mailing list. Okay, next time I will copy paste parts of emails from others (with the even more offensive tone in my side) Instead of making such

[openstack-dev] [Barbican] Multiple KMIP servers on a single barbican

Hey all. I wanted to get people's opinion on allowing barbican to talk to multiple KMIP servers. I got good advice from Nathan and John and it seems like it would be pretty easy keeping track of which secret resides in which KMIP applicance. You would just store the url in the DTO. However, in ord

Re: [openstack-dev] [nova][all] Architecture Diagrams in ascii art?

+1 On Thu, May 14, 2015 at 3:52 AM, John Garbutt wrote: > On 12 May 2015 at 20:33, Sean Dague wrote: > > On 05/12/2015 01:12 PM, Jeremy Stanley wrote: > >> On 2015-05-12 10:04:11 -0700 (-0700), Clint Byrum wrote: > >>> It's a nice up side. However, as others have pointed out, it's only > >>> ca

Re: [openstack-dev] [rally][scaling up development] Rally core team re-organization

Excerpts from Boris Pavlovic's message of 2015-06-05 20:03:44 +0300: > Hi stackers, > > Seems likes after stackforge/rally -> openstack/rally Rally project started > being more attractive. > According recent stats we are on top 3 position (based on Patch sets stats) > http://stackalytics.com/?rele

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

Excerpts from Thierry Carrez's message of 2015-06-05 05:46:07 -0700: > So.. summarizing the various options again: > Thanks for the excellent summary Thierry > Plan C > Let projects randomly tag point releases whenever > (-) Still a bit costly in terms of herding cats > I feel like plan C is th

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash wrote: > So I think that GroupID's are actually unique and safesince in the > multi LDAP case we provide an indirection already in Keystone and issue a > "Public ID" (this is true for bother users and groups), that we map to the > underlying local I

Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name

I am sure I have missed something along the way, but can someone explain to me why we need this at all. Project names are unique within a domain, with the exception of the project that is acting as its domain (i.e. they can only every be two names clashing in a hierarchy at the domain level and

[openstack-dev] [rally][scaling up development] Rally core team re-organization

Hi stackers, Seems likes after stackforge/rally -> openstack/rally Rally project started being more attractive. According recent stats we are on top 3 position (based on Patch sets stats) http://stackalytics.com/?release=liberty&metric=patches&project_type=All And if we compare half year ago we ha

Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name

On 06/03/2015 05:05 PM, Morgan Fainberg wrote: Hi David, There needs to be some form of global hierarchy delimiter - well more to the point there should be a common one across OpenStack installations to ensure we are providing a good and consistent (and more to the point inter-operable) exper

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

So I think that GroupID's are actually unique and safesince in the multi LDAP case we provide an indirection already in Keystone and issue a "Public ID" (this is true for BOTH users and groups), that we map to the underlying local ID in the particular LDAP backend. Henry > On 5 Jun 2015,

Re: [openstack-dev] [puppet] Change abandonment policy

Hi, +1 for #1 and if patch is not touched for N weeks just finish it using current active team. Best regards, Boris Pavlovic On Fri, Jun 5, 2015 at 7:27 PM, Richard Raseley wrote: > Colleen Murphy wrote: > >> 3) Manually abandon after N months/weeks changes that have a -1 that was >> never res

Re: [openstack-dev] [puppet] Change abandonment policy

Colleen Murphy wrote: 3) Manually abandon after N months/weeks changes that have a -1 that was never responded to ``` If a change is submitted and given a -1, and subsequently the author becomes unresponsive for a few weeks, reviewers should leave reminder comments on the review or attempt to co

Re: [openstack-dev] [nova][all] Architecture Diagrams in ascii art?

Markus Zoeller wrote: Joe Gordon wrote on 05/16/2015 03:33:35 AM: After further investigation in blockdiag, is useless for moderately complex diagrams. Here is my attempt at graphing nova [0], but due to a blockdiag bug from 2013, [1] it is impossible to clearly read. For example, in the diagr

Re: [openstack-dev] [horizon] Prioritize tests over JSCS

Thai - I thought there was a conscious decision to separate addressing the JSCS issues and applying JP's guidelines.Smaller more precise patches are easier to land! I plan on applying JP's guidelines in a follow on patch.Especially since one of my JSCS patches merged this morning. Aar

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

Daniel P. Berrange wrote: On Fri, Jun 05, 2015 at 02:46:07PM +0200, Thierry Carrez wrote: So.. summarizing the various options again: Plan A Just drop stable point releases. (-) No more release notes (-) Lack of reference points to compare installations Plan B Push date-based tags across suppo

Re: [openstack-dev] [all] cross project communication: Return request-id to caller

On Wednesday 3 June 2015 at 12:13, Miguel Ángel Ajo wrote: > Doesn’t this overlap with the work done for the OSProfiler ? > > > More comments inline. > > Miguel Ángel Ajo > > > On Wednesday, 3 de June de 2015 at 11:43, Kekane, Abhishek wrote: > > > Hi Devs, > > > > So for I hav

[openstack-dev] [ptl] Skipping Release management 0800-1000 UTC office hours next Tuesday

Hi PTLs and release liaisons, Due to being on a plane without wifi, I'll be missing my 0800-1000 UTC release management office hours on Tuesday, June 9. We'll still have office hours between 1800 and 2000 UTC on that day, in case you have anything to discuss or questions to ask. If you can't mak

Re: [openstack-dev] [Keystone] Domain and Project naming

Hi Jamie I think if we are going for hierarchical names we should do it properly in one go ie. have a recursive scheme that allows infinite nesting of name components, and then it will solve all current and future problems. Having a half baked scheme which only allows one level of nesting, or requ

Re: [openstack-dev] [keystone] [nova] [oslo] [cross-project] Dynamic Policy

On 06/03/2015 01:43 PM, Sean Dague wrote: On 06/03/2015 10:10 AM, Adam Young wrote: I gave a presentation on Dynamic Policy for Access Control at the Summit. https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/dynamic-policy-for-access-control My slides are here: http:/

[openstack-dev] [all][release] updating client requirements

We have a bunch of client libraries with out-dated requirements to varying degrees [1], and some of them are causing dependency conflicts in gate jobs. It would be good if project teams could prioritize those reviews so we can release updates early next week. Thanks, Doug [1] https://review.open

Re: [openstack-dev] Standard way to indicate a partial blueprint implementation?

Chris Friesen said on Thu, Jun 04, 2015 at 10:57:54PM -0600: > On 06/04/2015 05:23 PM, Zane Bitter wrote: > > I have personally been using: > > > > Implements: partial-blueprint x > > > >but I don't actually care much. I would also be fine with: > > > > Partially-Implements: blueprint x > > If

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

I seem yo remember there being a mapping driver of some kind in juno+ that when enabled doesnt just use the ldap unique identifier raw. Its optional though. I also dont know if it doublechecks for uniqueness or just hashes. Thanks, Kevin From: Dolph Mathews Sent

Re: [openstack-dev] The Nova API in Kilo and Beyond

On 06/05/2015 07:32 AM, Sean Dague wrote: One of the things we realized at the summit was that we'd been working through a better future for the Nova API for the past 5 cycles, gotten somewhere quite useful, but had really done a poor job on communicating what was going on and why, and where thin

Re: [openstack-dev] The Nova API in Kilo and Beyond

On 05/06/15 12:32, Sean Dague wrote: https://dague.net/2015/06/05/the-nova-api-in-kilo-and-beyond-2/ This is really informative and useful, thanks. A few comments / questions, with bits of your text in quotes: "Even figuring out what a cloud could do was pretty terrible. You could approximat

[openstack-dev] [Tricircle] Polling for weekly team meeting

Hi All, The Tricircle Project has been on stackforge for a while, and without much activities. Now we will completely restructure the code base to make it more community open source friendly, less corporate PoC looking hopefully :P At the mean time I want to call for attention for people who are

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

On 06/05/2015 09:34 AM, Alan Pevec wrote: >> If the downsteam consumer has their own extra patches ontop of the >> stable branch, then it seems D is even less useful than A. > > It is not - downstream (speaking for RDO) I would keep Version: > 2015.1.N where N is stable patch# so that we have a co

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

On Thu, Jun 4, 2015 at 10:17 PM, John Wood wrote: > Hello folks, > > Regarding option C, if group IDs are unique within a given > cloud/context, and these are discoverable by clients that can then set the > ACL on a secret in Barbican, then that seems like a viable option to me. As > it is now,

Re: [openstack-dev] [Glance][Keystone] Glance and trusts

On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick wrote: > I did suggest another solution to Adam whilst we were in Vancouver, and > this mirrors what happens in the real world today when I order something > from a supplier and a whole supply chain is involved in creating the end > product that I or

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

On 06/05/2015 05:46 AM, Thierry Carrez wrote: > So.. summarizing the various options again: > > Plan A > Just drop stable point releases. > (-) No more release notes > (-) Lack of reference points to compare installations > > Plan B > Push date-based tags across supported projects from time to ti

Re: [openstack-dev] The Nova API in Kilo and Beyond

On Fri, 5 Jun 2015, Sean Dague wrote: Thanks for your time, Thanks for writing that up. I recognize that microversions exist and are as they are so I don't want to derail, but my curiosity was piqued: Riddle me this: If Microversions are kind of like content-negotiation (and we love content-

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

Good summary, Ed! Ed Leafe said on Wed, Jun 03, 2015 at 07:53:02AM -0500: > > I totally agree the scheduler doesn't have to know anything about > > flavors though. We should push them out to request validation in the > > Nova API. This can be considered part of cleaning up the scheduler API. > > T

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

> If the downsteam consumer has their own extra patches ontop of the > stable branch, then it seems D is even less useful than A. It is not - downstream (speaking for RDO) I would keep Version: 2015.1.N where N is stable patch# so that we have a common reference point with other distros. Our patch

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

On 06/05/2015 07:46 AM, Thierry Carrez wrote: > So.. summarizing the various options again: > > Plan A > Just drop stable point releases. > (-) No more release notes > (-) Lack of reference points to compare installations > > Plan B > Push date-based tags across supported projects from time to ti

Re: [openstack-dev] [nova] Mellanox CI Issues

Hi Dan, I just want to update you that the report success after short less-than-a-minute run is Zuul problem see [1]. This is happened because we apply filter rules to run only on PCI code to reduce load on our CI System. Unfortunately we missed this issue in our monitoring because all the j

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

Daniel P. Berrange wrote: > On Fri, Jun 05, 2015 at 02:46:07PM +0200, Thierry Carrez wrote: >> Plan A >> Just drop stable point releases. >> (-) No more release notes >> (-) Lack of reference points to compare installations >> >> Plan B >> Push date-based tags across supported projects from time to

Re: [openstack-dev] [all][release] summit session summary: Release Versioning for Server Applications

Excerpts from Doug Hellmann's message of 2015-05-29 17:38:04 -0400: > This message is a summary of the notes from the “Release Versioning Servers” > discussion held during the release management/QA/infrastructure meetup period > on Friday morning at the summit, along with some commentary I though

Re: [openstack-dev] [nova][security] Enable user password complexity verification

On Wed, Jun 3, 2015 at 6:49 AM, David Stanek wrote: > > On Wed, Jun 3, 2015 at 6:04 AM liusheng wrote: > >> Thanks for this topic, also, I think it is similar situation when >> talking about keystone users, not only the instances's password. >> >> > In the past we've talked about having more ad

Re: [openstack-dev] [infra][qa] Empty "Build succeeded" when filtering jobs

Hello! Please, look at the change: https://review.openstack.org/188383 On 03.06.2015 18:56, James E. Blair wrote: Evgeny Antyshev writes: Some CIs like to narrow their scope to a certain set of files. For that, they specify file mask on per-job basis. So there appear annoying comments with

Re: [openstack-dev] [all]Big Tent Mode within respective projects

Nice pointer Boris ! :) On Fri, Jun 5, 2015 at 3:32 AM, Jay Pipes wrote: > On 06/04/2015 07:46 AM, Boris Pavlovic wrote: > >> Jay, >> >> >> At this time, Neutron is the only project that has done any >> splitting out of driver and advanced services repos. Other projects >> have discu

[openstack-dev] [api] [docs] Spec updated for API reference info and app dev guides

Hi all, I wanted to point out the updated specification for the approach we're taking for the API docs, basically scraping the code with a WSGI layer to build Swagger files. See https://review.openstack.org/#/c/177934/5/specs/liberty/api-site.rst for the gory details. A huge thanks to Tom Fifield

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

On 2015-06-05 14:56:30 +0200 (+0200), Thierry Carrez wrote: [...] > I was wondering if we could switch to post-versioning on stable > branches, and basically generate: > > "2015.1.0.post38" [...] I think the recommendation from the PyPI maintainers is to not use .postN suffixes since they are int

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

On Fri, Jun 05, 2015 at 02:46:07PM +0200, Thierry Carrez wrote: > So.. summarizing the various options again: > > Plan A > Just drop stable point releases. > (-) No more release notes > (-) Lack of reference points to compare installations > > Plan B > Push date-based tags across supported projec

Re: [openstack-dev] [Keystone] Domain and Project naming

On 06/04/2015 11:13 PM, Jamie Lennox wrote: - Original Message - From: "Adam Young" To: "OpenStack Development Mailing List" Sent: Thursday, 4 June, 2015 2:25:52 PM Subject: [openstack-dev] [Keystone] Domain and Project naming With Hierarchical Multitenantcy, we have the issue that a

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

Jeremy Stanley wrote: > On 2015-06-01 15:57:17 + (+), Jeremy Stanley wrote: > [...] >> The biggest hurdle is that we'd need a separate upload job name >> for those since the current version of Zuul lacks a way to run a >> particular job for different branches in different pipelines (we'd >>

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

So.. summarizing the various options again: Plan A Just drop stable point releases. (-) No more release notes (-) Lack of reference points to compare installations Plan B Push date-based tags across supported projects from time to time. (-) Encourages to continue using same version across the boa

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

On 06/05/2015 01:28 AM, Adrian Otto wrote: > >> On Jun 4, 2015, at 11:03 AM, Devananda van der Veen >> mailto:devananda@gmail.com>> wrote: >> >> >> On Jun 4, 2015 12:00 AM, "Xu, Hejie" > > wrote: >> > >> > Hi, guys, >> > >> > I’m working on adding Microversion into

[openstack-dev] The Nova API in Kilo and Beyond

One of the things we realized at the summit was that we'd been working through a better future for the Nova API for the past 5 cycles, gotten somewhere quite useful, but had really done a poor job on communicating what was going on and why, and where things are headed next. I've written a bunch of

Re: [openstack-dev] [nova][all] Architecture Diagrams in ascii art?

Joe Gordon wrote on 05/16/2015 03:33:35 AM: > > After further investigation in blockdiag, is useless for moderately > complex diagrams. > > Here is my attempt at graphing nova [0], but due to a blockdiag bug > from 2013, [1] it is impossible to clearly read. For example, in the > diagram the

Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals

Gal, if you have some time to coordinate this with the service chaining/firewall folks and start a spec, it’d be amazing. Best regards, Miguel Angel Ajo On Friday 5 June 2015 at 12:42, Vikram Choudhary wrote: > Hi Gal, > > It's really nice that you are also interested. Myself and Miguel wa

Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals

Hi Gal, It's really nice that you are also interested. Myself and Miguel was also talking about this over the summit ;) Let's take care of this together ;) Thanks Vikram On Fri, Jun 5, 2015 at 3:45 PM, Gal Sagie wrote: > Another use case is for security/firewall classifiers. > > I agree with t

Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals

Another use case is for security/firewall classifiers. I agree with this and i think me and Miguel talked about it in the summit, but in order for this to go forward someone need to start creating a spec and managing this effort. Since you proposed it first Vikram, will you do it? If not i will g

Re: [openstack-dev] [Nova] Voting on the Nova project meeting times

On 4 June 2015 at 12:54, John Garbutt wrote: > Hi, > > We have a regular Nova project meeting with alternating times, as > described here: > https://wiki.openstack.org/wiki/Meetings/Nova > > I will lean towards no change of the times, given we are used to them. > But I want to double check there i

[openstack-dev] [Nova] Follow up actions from the Summit: please help

Hi, So in the interests of filling up your inbox yet further... We have lots of etherpads from the summit: https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Nova I have extracted all the action items here: https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items Pleas

Re: [openstack-dev] [puppet] Change abandonment policy

+1 for #3 with N = 1 regards /sanjay On Fri, Jun 5, 2015 at 1:27 AM, Mike Dorman wrote: > I vote #2, with a smaller N. > > We can always adjust this policy in the future if find we have to > manually abandon too many old reviews. > > > From: Colleen Murphy > Reply-To: "puppet-openst...@pup

Re: [openstack-dev] [neutron] Regarding Flow classifiers existing proposals

Thanks Miguel! From: Miguel Angel Ajo [mailto:mangel...@redhat.com] Sent: 05 June 2015 14:12 To: Vikram Choudhary Cc: azama-y...@mxe.nes.nec.co.jp; Henry Fourie; Cathy Zhang; arma...@gmail.com; Dongfeng (C); Kyle Mestery; openstack-dev@lists.openstack.org; Dhruv Dhody; Kalyankumar Asangi Subject

[openstack-dev] [neutron] Regarding Flow Classifier proposals for Liberty!

Dear All, There are multiple proposal floating around flow classifier rules for Liberty [1], [2] and [3]. I feel we all should work together and try to address all our use case having a unified framework rather than working separately achieving the same goal. Moreover, I can find the prop

[openstack-dev] [neutron] Regarding Flow classifiers existing proposals

Added openstack-dev, where I believe this conversation must live. I totally agree on this, thank you for bringing up this conversation. This is not something we want to do for QoS this cycle, but probably next cycle. Anyway, an unified data model and API to create/update classifiers will not

Re: [openstack-dev] [nova][trove][neutron][octavia] Protected openstack resources

Hi, I still think we need to look at lot more carefully at why using an isolated "service" tenant would not work. Sure, thats a bit rich coming from someone trying to limit the scope of Nova, but really I am just trying to work out what the problem is you are tying to solve, and specifically what

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

Hi, Jay, I would say follow what happened on this guideline https://review.openstack.org/#/c/187112 :) From: Jay Lau [mailto:jay.lau@gmail.com] Sent: Thursday, June 4, 2015 5:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [api] [Nova] [Iron

Re: [openstack-dev] [nova] [glance] How to deal with aborted image read?

On 04/06/15 11:46 -0600, Chris Friesen wrote: On 06/04/2015 03:01 AM, Flavio Percoco wrote: On 03/06/15 16:46 -0600, Chris Friesen wrote: We recently ran into an issue where nova couldn't write an image file due to lack of space and so just quit reading from glance. This caused glance to be st

Re: [openstack-dev] [Ironic] When to bump the microversion?

On 06/04/2015 05:27 PM, Lucas Alvares Gomes wrote: Hi Ruby, Thanks for starting this thread, just like you I've been always confused about when and when not bump the microversioning of the API. Backwards compatible API adds with no user signaling is a fallacy because it assumes the arrow of ti

Re: [openstack-dev] Standard way to indicate a partial blueprint implementation?

On 04/06/15 19:23 -0400, Zane Bitter wrote: Ever since we established[1] a format for including metadata about bugs in Git commit messages that included a 'Partial-Bug' tag, people have been looking for a way to do the equivalent for partial blueprint implementations. A non-exhaustive search of

Re: [openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/04/2015

Armando, yes I will be using the latest version for heading up the work. From: Armando M. [mailto:arma...@gmail.com] Sent: 05 June 2015 08:57 To: OpenStack Development Mailing List (not for usage questions) Cc: Kalyankumar Asangi; Ramanjaneya palleti Subject: Re: [openstack-dev] [neutron] Service