Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
Team, I have published a top level blueprint for a magnum-horizon-plugin: https://blueprints.launchpad.net/magnum/+spec/magnum-horizon-plugin My suggestion is that any contributor interested in contributing to this feature should subscribe to that blueprint, and record their intent to contribute in the Whiteboard of the BP. Furthermore, I suggest that any contributors who are a good fit for core reviewer duties for this effort subscribe to the blueprint and mark themselves as “Participation Essential” so I can get a clear picture of how to deal with grouping the related core reviewer team (or adding them to the current core group). I think that this effort would benefit from a spec submitted as a review using the following template: http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/liberty-template.rst Adapt it for magnum (I have not contributed a spec template of our own yet. TODO.) Contribute it here: http://git.openstack.org/cgit/openstack/magnum/tree/specs Thanks, Adrian On Jun 4, 2015, at 12:58 PM, Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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] Missing allowed address pairs?
You have better chances of getting an answer if you asked the -dev list and add [Neutron] to the subject (done here). That said, can you tell us a bit more about your deployment? You can also hop on #openstack-neutron on Freenode to look for neutron developers who can help you more interactively. Cheers, Armando On 4 June 2015 at 14:03, Ken D'Ambrosio k...@jots.org wrote: Hi, all. I've got two instances -- a Juno and an Icehouse -- both set up via Ubuntu/Juju. And neither of them shows allowed address pairs when I do a neutron ext-list (I've tried on both the neutron-gateway and nova-cloud-controller). From everything my co-worker and I have read, it seems like it *should* be in both of them, leading us to assume that we've somehow disabled that particular functionality. Any ideas on what to look at? Thanks much, -Ken ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack __ OpenStack Development Mailing 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] Service Chain project IRC meeting minutes - 06/04/2015
On 4 June 2015 at 14:17, Cathy Zhang cathy.h.zh...@huawei.com wrote: Thanks for joining the service chaining meeting today! Sorry for the time confusion. We will correct the weekly meeting time to 1700UTC (10am pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting page. Cathy, thanks for driving this. I took the liberty to carry out one of the actions identified in the meeting: the creation of repo to help folks collaborate over code/documentation/testing etc [1]. As for the core team definition, we'll start with a single member who can add new folks as more docs/code gets poured in. One question I had when looking at the minutes, was regarding slides [2]. Not sure if discussing deployment architectures when the API is still baking is premature, but I wonder if you had given some thoughts into having a pure agentless architecture even for the OVS path. Having said that, as soon as the repo is up and running, I'd suggest to move any relevant document (e.g. API proposal, use cases, etc) over to the repo and reboot the review process so that everyone can be on the same page. Cheers, Armando [1] https://review.openstack.org/#/c/188637/ [2] https://docs.google.com/presentation/d/1SpVyLBCMRFBpMh7BsHmpENbSY6qh1s5NRsAS68ykd_0/edit#slide=id.p Meeting Minutes: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.html Meeting Minutes (text): http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.txt Meeting Log: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.log.html The next meeting is scheduled for June 11 (same place and time). Thanks, Cathy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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][horizon] Making a dashboard for Magnum - need a vote from the core team
Same here, I’m interested in helping out with reviews from Horizon standpoint. Regards Zhenguo Niu From: David Lyle [mailto:dkly...@gmail.com] Sent: Friday, June 05, 2015 3:42 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team I'm happy to provide reviews from the Horizon standpoint. David On Thu, Jun 4, 2015 at 12:55 PM, Jason Rist jr...@redhat.commailto:jr...@redhat.com wrote: On 06/04/2015 11:58 AM, Steven Dake (stdake) wrote: Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I am interested in helping as well. In my experience, #1 works best, but I'm not a core, so I'm not sure my wisdom is counted here. -J -- Jason E. Rist Senior Software Engineer OpenStack Infrastructure Integration Red Hat, Inc. openuc: +1.972.707.6408tel:%2B1.972.707.6408 mobile: +1.720.256.3933tel:%2B1.720.256.3933 Freenode: jrist github/identi.cahttp://identi.ca: knowncitizen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel
I have filed a bp for this https://blueprints.launchpad.net/magnum/+spec/auto-generate-name Thanks 2015-06-04 14:14 GMT+08:00 Jay Lau jay.lau@gmail.com: Thanks Adrian, I see. Clear now. 2015-06-04 11:17 GMT+08:00 Adrian Otto adrian.o...@rackspace.com: Jay, On Jun 3, 2015, at 6:42 PM, Jay Lau jay.lau@gmail.com wrote: Thanks Adrian, some questions and comments in-line. 2015-06-03 10:29 GMT+08:00 Adrian Otto adrian.o...@rackspace.com: I have reflected on this further and offer this suggestion: 1) Add a feature to Magnum to auto-generate human readable names, like Docker does for un-named containers, and ElasticSearch does for naming cluster nodes. Use this feature if no name is specified upon the creation of a Bay or Baymodel. +1 on this -and- 2) Add a configuration directives (default=FALSE) for allow_duplicate_bay_name and allow_duplicate_baymodel_name. If TRUE, duplicate named Bay and BayModel resources will be allowed, as they are today. This way, by default Magnum requires a unique name, and if none is specified, it will automatically generate a name. This way no additional burden is put on users who want to act on containers exclusively using UUIDs, and cloud operators can decide if they want to enforce name uniqueness or not. In the case of clouds that want to allow sharing access to a BayModel between multiple tenants (example: a global BayModel named “kubernetes”) with allow_duplicate_baymodel_name set to FALSE, a user will still be allowed to Here should be allow_duplicate_baymodel set to TRUE? I know this is confusing, but yes, what I wrote was correct. Perhaps I could rephrase it to clarify: Regardless of the setting of allow_duplicate_bay* settings, we should allow a user to create a BayModel with the same name as a global or shared one in order to override the one that already exists from another source with one supplied by the user. When referred to by name, the one created by the user would be selected in the case where each has the same name assigned. create a BayModel with the name “kubernetes” and it will override the global one. If a user-supplied BayModel is present with the same name as a global one, we shall automatically select the one owned by the tenant. +1 on this , one question is what does a global BayModel means? In Magnum, all BayModel belong to a tenant and seems there is no global BayModel? This is a concept we have not actually discussed, and we don't have today as a feature. The idea is that in addition to the BayModel resources that tenants create, we could also have ones that the cloud operator creates, and automatically expose to all tenants in the system. I am referring to these as global BayModel resources as a potential future enhancement. The rationale for such a global resource is a way for the Cloud Operator to pre-define the COE's they support, and pre-seed the Magnum environment with such a configuration for all users. Implementing this would require a solution for how to handle the ssh keypair, as one will need to be generated uniquely for every tenant. Perhaps we could have a procedure that a tenant uses to activate the BayModel by somehow adding their own public ssh key to a local subclass of it. Perhaps this could be implemented as a user defined BayModel that has a parent_id set to the uuid of a parent baymodel. When we instantiate one, we would merge the two into a single resource. All of this is about anticipating possible future features. The only reason I am mentioning this is that I want us to think about where we might go with resource sharing so that our name uniqueness decision does not preclude us from later going in this direction. Adrian About Sharing of BayModel Resources: Similarly, if we add features to allow one tenant to share a BayModel with another tenant (pending acceptance of the offered share), and duplicate names are allowed, then prefer in this order: 1) Use the resource owned by the same tenant, 2) Use the resource shared by the other tenant (post acceptance only), 3) Use the global resource. If duplicates exist in the same scope of ownership, then raise an exception requiring the use of a UUID in that case to resolve the ambiguity. We can file a bp to trace this. One expected drawback of this approach is that tools designed to integrate with one Magnum may not work the same with another Magnum if the allow_duplicate_bay* settings are changed from the default values on one but not the other. This should be made clear in the comments above the configuration directive in the example config file. Just curious why do we need this feature? Different Magnum clusters might using different CoE engine. So you are mentioning the case all of the Magnum clusters are using same CoE engine? If so, yes, this should be made clear in configuration file. Adrian On Jun 2, 2015, at 8:44 PM, Jay Lau
Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG
On Jun 4, 2015, at 11:03 AM, Devananda van der Veen devananda@gmail.commailto:devananda@gmail.com wrote: On Jun 4, 2015 12:00 AM, Xu, Hejie hejie...@intel.commailto:hejie...@intel.com wrote: Hi, guys, I’m working on adding Microversion into the API-WG’s guideline which make sure we have consistent Microversion behavior in the API for user. The Nova and Ironic already have Microversion implementation, and as I know Magnum https://review.openstack.org/#/c/184975/ is going to implement Microversion also. Hope all the projects which support( or plan to) Microversion can join the review of guideline. The Mircoversion specification(this almost copy from nova-specs): https://review.openstack.org/#/c/187112 And another guideline for when we should bump Mircoversion https://review.openstack.org/#/c/187896/ As I know, there already have a little different between Nova and Ironic’s implementation. Ironic return min/max version when the requested version doesn’t support in server by http-headers. There isn’t such thing in nova. But that is something for version negotiation we need for nova also. Sean have pointed out we should use response body instead of http headers, the body can includes error message. Really hope ironic team can take a look at if you guys have compelling reason for using http headers. And if we think return body instead of http headers, we probably need think about back-compatible also. Because Microversion itself isn’t versioned. So I think we should keep those header for a while, does make sense? Hope we have good guideline for Microversion, because we only can change Mircoversion itself by back-compatible way. Ironic returns the min/max/current API version in the http headers for every request. Why would it return this information in a header on success and in the body on failure? (How would this inconsistency benefit users?) To be clear, I'm not opposed to *also* having a useful error message in the body, but while writing the client side of api versioning, parsing the range consistently from the response header is, IMO, better than requiring a conditional. +1. I fully agree with Devananda on this point. Use the headers consistently, and add helpful errors into the body only as an addition to that behavior, not a substitute. Adrian -Deva __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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] Service Chain project IRC meeting minutes - 06/04/2015
Hi Cathy, Thanks for heading up this meeting. No worries about the timing, time zones are really difficult to handle ;) I do agree with Armando that finalization of the API is important and must be done at the earliest. As discussed over the last meeting I will start working on this and hope by the next meeting we have something in the kitty. Thanks Vikram On Fri, Jun 5, 2015 at 6:36 AM, Armando M. arma...@gmail.com wrote: On 4 June 2015 at 14:17, Cathy Zhang cathy.h.zh...@huawei.com wrote: Thanks for joining the service chaining meeting today! Sorry for the time confusion. We will correct the weekly meeting time to 1700UTC (10am pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting page. Cathy, thanks for driving this. I took the liberty to carry out one of the actions identified in the meeting: the creation of repo to help folks collaborate over code/documentation/testing etc [1]. As for the core team definition, we'll start with a single member who can add new folks as more docs/code gets poured in. One question I had when looking at the minutes, was regarding slides [2]. Not sure if discussing deployment architectures when the API is still baking is premature, but I wonder if you had given some thoughts into having a pure agentless architecture even for the OVS path. Having said that, as soon as the repo is up and running, I'd suggest to move any relevant document (e.g. API proposal, use cases, etc) over to the repo and reboot the review process so that everyone can be on the same page. Cheers, Armando [1] https://review.openstack.org/#/c/188637/ [2] https://docs.google.com/presentation/d/1SpVyLBCMRFBpMh7BsHmpENbSY6qh1s5NRsAS68ykd_0/edit#slide=id.p Meeting Minutes: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.html Meeting Minutes (text): http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.txt Meeting Log: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.log.html The next meeting is scheduled for June 11 (same place and time). Thanks, Cathy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
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, the user information provided to the ACL is the user ID information as found in X-User-Ids now, not user names. To Kevin’s point though, are these group IDs unique across domains now, or in the future? If not the more complex tuples suggested could be used, but seem more error prone to configure on an ACL. Thanks, John From: Fox, Kevin M kevin@pnnl.govmailto:kevin@pnnl.gov Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, June 4, 2015 at 6:01 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- in token validation In Juno I tried adding a user in Domain A to group in Domain B. That currently is not supported. Would be very handy though. We're getting a ways from the original part of the thread, so I may have lost some context, but I think the original question was, if barbarian can add group names to their resource acls. Since two administrative domains can issue the same group name, its not safe I believe. Simply ensuring the group name is associated with a user and the domain for the user matches the domain for the group wouldn't work because someone with control of their own domain can just make a user and give them the group with the name they want and come take your credentials. What may be safe is for the barbican ACL to contain the group_id if they are uniqueue across all domains, or take a domain_id group_name pair for the acl. Thanks, Kevin From: Dolph Mathews [dolph.math...@gmail.commailto:dolph.math...@gmail.com] Sent: Thursday, June 04, 2015 1:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- in token validation Problem! In writing a spec for this ( https://review.openstack.org/#/c/188564/ ), I remembered that groups are domain-specific entities, which complicates the problem of providing X-Group-Names via middleware. The problem is that we can't simply expose X-Group-Names to underlying services without either A) making a well-documented assumption about the ONE owning domain scope of ALL included groups, B) passing significantly more data to underlying services than just a list of names (a domain scope for every group), C) passing only globally-unique group IDs (services would then have to retrieve additional details about each from from keystone if they so cared). Option A) More specifically, keystone could opt to enumerate the groups that belong to the same domain as the user. In this case, it'd probably make more sense from an API perspective if the groups enumeration were part of the user resources in the token response body (the user object already has a containing domain ID. That means that IF a user were to be assigned a group membership in another domain (assuming we didn't move to disallowing that behavior at some point), then it would have to be excluded from this list. If that were true, then I'd also follow that X-Group-Names become X-User-Group-Names, so that it might be more clear that they belong to the X-User-Domain-*. Option B) This is probably the most complex solution, but also the most explicit. I have no idea how this interface would look in terms of headers using current conventions. If we're going to break conventions, then I'd want to pass a id+domain_id+name for each group reference. So, rather than including a list of names AND a list of IDs, we'd have some terribly encoded list of group objects (I'm not sure what the HTTP convention is on this sort of use case, and hoping someone can illustrate a better solution given the representation below): X-Groups: id%3D123%2Cdomain_id%3D456%2Cname%3Dabc,id%3D789%2Cdomain_id%3D357%2Cname%3Ddef Option C) Federated tokens would actually require solution (C) today because they only include group IDs, not names. But the group enumeration in federated tokens was also only intended to be consumed by keystone, so that's not really an issue for that one use case. But option (C) would mean there are no X-Group-Names passed to services, just X-Group-Ids. I'm guessing this won't provide the user experience that Barbican is looking for? I'm leaning towards solution (A), but curious if that'll work for Barbican and/or if anyone has an idea that I'm overlooking. On Thu, Jun 4, 2015 at 8:18 AM, Dolph Mathews dolph.math...@gmail.commailto:dolph.math...@gmail.com wrote: To clarify: we already have to include the groups
Re: [openstack-dev] [nova] [glance] How to deal with aborted image read?
On 06/04/2015 07:16 PM, Joshua Harlow wrote: Perhaps someone needs to use (or forgot to use) contextlib.closing? https://docs.python.org/2/library/contextlib.html#contextlib.closing Or contextlib2 also may be useful: http://contextlib2.readthedocs.org/en/latest/#contextlib2.ExitStack The complication is that the error happens in nova, but it's glance-api that holds the file descriptor open. So somehow the error has to be detected in nova, then the fact that nova is no longer interested in the file needs to be propagated through glanceclient via an HTTP call into glance-api so that it knows it can close the file descriptor. And I don't think that an API to do this exists currently. 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] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel
Thanks Jay. I have approved the direction for this, and have marked it as under discussion. I also added it to our next team meeting agenda so we can consider any alternate viewpoints before approving the specification as worded. Adrian On Jun 4, 2015, at 9:12 PM, Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com wrote: I have filed a bp for this https://blueprints.launchpad.net/magnum/+spec/auto-generate-name Thanks 2015-06-04 14:14 GMT+08:00 Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com: Thanks Adrian, I see. Clear now. 2015-06-04 11:17 GMT+08:00 Adrian Otto adrian.o...@rackspace.commailto:adrian.o...@rackspace.com: Jay, On Jun 3, 2015, at 6:42 PM, Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com wrote: Thanks Adrian, some questions and comments in-line. 2015-06-03 10:29 GMT+08:00 Adrian Otto adrian.o...@rackspace.commailto:adrian.o...@rackspace.com: I have reflected on this further and offer this suggestion: 1) Add a feature to Magnum to auto-generate human readable names, like Docker does for un-named containers, and ElasticSearch does for naming cluster nodes. Use this feature if no name is specified upon the creation of a Bay or Baymodel. +1 on this -and- 2) Add a configuration directives (default=FALSE) for allow_duplicate_bay_name and allow_duplicate_baymodel_name. If TRUE, duplicate named Bay and BayModel resources will be allowed, as they are today. This way, by default Magnum requires a unique name, and if none is specified, it will automatically generate a name. This way no additional burden is put on users who want to act on containers exclusively using UUIDs, and cloud operators can decide if they want to enforce name uniqueness or not. In the case of clouds that want to allow sharing access to a BayModel between multiple tenants (example: a global BayModel named “kubernetes”) with allow_duplicate_baymodel_name set to FALSE, a user will still be allowed to Here should be allow_duplicate_baymodel set to TRUE? I know this is confusing, but yes, what I wrote was correct. Perhaps I could rephrase it to clarify: Regardless of the setting of allow_duplicate_bay* settings, we should allow a user to create a BayModel with the same name as a global or shared one in order to override the one that already exists from another source with one supplied by the user. When referred to by name, the one created by the user would be selected in the case where each has the same name assigned. create a BayModel with the name “kubernetes” and it will override the global one. If a user-supplied BayModel is present with the same name as a global one, we shall automatically select the one owned by the tenant. +1 on this , one question is what does a global BayModel means? In Magnum, all BayModel belong to a tenant and seems there is no global BayModel? This is a concept we have not actually discussed, and we don't have today as a feature. The idea is that in addition to the BayModel resources that tenants create, we could also have ones that the cloud operator creates, and automatically expose to all tenants in the system. I am referring to these as global BayModel resources as a potential future enhancement. The rationale for such a global resource is a way for the Cloud Operator to pre-define the COE's they support, and pre-seed the Magnum environment with such a configuration for all users. Implementing this would require a solution for how to handle the ssh keypair, as one will need to be generated uniquely for every tenant. Perhaps we could have a procedure that a tenant uses to activate the BayModel by somehow adding their own public ssh key to a local subclass of it. Perhaps this could be implemented as a user defined BayModel that has a parent_id set to the uuid of a parent baymodel. When we instantiate one, we would merge the two into a single resource. All of this is about anticipating possible future features. The only reason I am mentioning this is that I want us to think about where we might go with resource sharing so that our name uniqueness decision does not preclude us from later going in this direction. Adrian About Sharing of BayModel Resources: Similarly, if we add features to allow one tenant to share a BayModel with another tenant (pending acceptance of the offered share), and duplicate names are allowed, then prefer in this order: 1) Use the resource owned by the same tenant, 2) Use the resource shared by the other tenant (post acceptance only), 3) Use the global resource. If duplicates exist in the same scope of ownership, then raise an exception requiring the use of a UUID in that case to resolve the ambiguity. We can file a bp to trace this. One expected drawback of this approach is that tools designed to integrate with one Magnum may not work the same with another Magnum if the allow_duplicate_bay* settings are changed from the default values on one but not the other. This should be made
Re: [openstack-dev] [all] IRC meetings agenda is now driven from Gerrit !
As we could generate data dynamically, it is possible to develop a web UI for it which shows real-time and readable scheduler table, provides download link of custom meetings group, etc. On Sat, May 30, 2015 at 2:51 PM yatin kumbhare yatinkumbh...@gmail.com wrote: Thank you, Thierry Tony --Daniel So could we publish the individual ical files for each meeting too. That way I could simply add nova.ical to my calendar and avoid other 80 openstack meetings appearing in my schedule. this answers my second questions. Regards, Yatin On Sat, May 30, 2015 at 3:30 AM, Tony Breeds t...@bakeyournoodle.com wrote: On Fri, May 29, 2015 at 10:42:58AM +0530, yatin kumbhare wrote: Great Work! New meetings or meeting changes would be proposed in Gerrit, and check/gate tests would make sure that there aren't any conflict. --Will this tell upfront, that in any given day of week, which are all meeting slots (time and irc meeting channels) are available? this could bring down no. patchset and gate tests failures. may be :) That'd be an interetsing feature but in reality it's trivial to run yaml2ical locally against the irc-meetings repo (which you already need to propose the change). Or you can just push the review see if it fails. There's some meeting with at weekly interval of 2, I assume we would get iCal by SUMMARY? I'm not sure I follow what you're asking here. Yours Tony. __ OpenStack Development Mailing 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] [Keystone] Domain and Project naming
- Original Message - From: Adam Young ayo...@redhat.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org 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 project is currentl restricted in its naming further than it should be. The domain entity enforces that all project namess under the domain domain be unique, but really what we should say is that all projects under a single parent project be unique. However, we have, at present, an API which allows a user to specify the domain either name or id and project again, either by name or ID, but here we care only about the name. This can be used either in specifying the token, or in operations ion the project API. We should change projec naming to be nestable, and since we don't have a delimiter set, we should expect the names to be an array, where today we might have: project: { domain: { id: 1789d1, name: example.com }, id: 263fd9, name: project-x } we should allow and expect: project: { domain: { id: 1789d1, name: example.com }, id: 263fd9, name: [ grandpa, dad, daughter] } This will, of course, break Horizon and lots of other things, which means we need a reasonable way to display these paths. The typical UI approach is a breadcrumb trail, and I think something where we put the segments of the path in the UI, each clickable, should be understandable: I'll defer to the UX experts if this is reasonable or not. The alternative is that we attempt to parse the project names. Since we have not reserved a delimeter, we will break someone somewhere if we force one on people. As an alternative, we should start looking in to following DNS standards for naming projects and hosts. While a domain should not be required to be a DNS registred domain name, we should allow for the case where a user wants that to be the case, and to synchronize nam,ing across multiple clouds. In order to enforce this, we would have to have an indicator on a domain name that it has been checked with DNS; ideally, the user would add a special SRV or Text record or something that Keystone could use to confirm that the user has oked this domain name being used by this cloud...or something perhaps with DNSSEC, checking that auser has permission to assign a specific domain name to a set of resources in the cloud. If we do that, the projects under that domain should also be valid DNS subzones, and the hosts either FQDNs or some alternate record...this would tie in Well with Designate. Note that I am not saying force this but rather allow this as it will simplify the naming when bursting from cloud to cloud: the Domain and project names would then be synchronized via DNS regardless of hosting provider. As an added benefit, we could provide a SRV or TEXT record (or some new URL type..I heard one is coming) that describes where to find the home Keystone server for a specified domain...it would work nicely with the K2K strategy. If we go with DNS project naming, we can leave all project names in a flat string. Note that the DNS approach can work even if the user does not wish to register their own DNS. A hosting provider (I'll pick dreamhost, cuz I know they are listening) could say the each of their tenants picks a user name...say that mine i admiyo, they would then create a subdomain of admiyo.dreamcompute.dreamhost.com. All of my subprojects would then get additional zones under that. If I were then to burst from there to Bluebox, the Keystone domain name would be the one that I was assigned back at Dreamhost. Back up. Is our current restrictions a problem? Even with hierarchical projects is it a problem to say that a project name still must be unique per domain? I get that in theory you might want to be able to identify a nested project by name under other projects but that's not something we have to allow immediately. I haven't followed the reseller case closely but in any situation where you had off control like that we are re-establishing a domain and so in a multitenancy situation each domain can still use their own project names. I feel like discussions around nested naming schemes and tieing domains to DNS is really premature until we have people that are actually using hierarchical projects. __ OpenStack Development Mailing 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] Standard way to indicate a partial blueprint implementation?
On 06/04/2015 05:23 PM, 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. snip 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 we need one, second one gets my vote. I'm not sure we actually need one though. Do we really care about the distinction between a commit that fully implements a blueprint and one that partially implements it? I'd expect that most blueprints require multiple commits, and so blueprint X could implicitly be assumed to be a partial implementation in the common case. 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] [all] IRC meetings agenda is now driven from Gerrit !
On Fri, Jun 05, 2015 at 01:18:57AM +, Gareth wrote: As we could generate data dynamically, it is possible to develop a web UI for it which shows real-time and readable scheduler table, provides download link of custom meetings group, etc. Sure I'm working on the second part (albeit slowly). I've been thinkign about what tooling we could create to find conflicts easier. Yours Tony. pgpG7LUQukAFq.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] novnc console connection timetout
Thanks folks, Its fixed via https://bugs.launchpad.net/mos/+bug/1409661 :-0 2015-06-04 20:29 GMT+08:00 张扬 w90p...@gmail.com: Hi Guys, I am a newbie on openstack, I deployed my first openstack env via Fuel 6.0, but unfortunately I always could not access the vm's vnc console, it hints the connection time, I also found the following calltrace in nova-novncproxy.log, Could anybody give me a hint on it? I am not sure whether its appropriate to send them to the mail list nor not, if not, please help me forward it to the right mail list. Thanks in advance! :-). BTW: I also tried to change the def_con_timeout, but it did not work for me The following is about the log information. controller: nova.conf root@node-9:~# cat /etc/nova/nova.conf [DEFAULT] dhcpbridge_flagfile=/etc/nova/nova.conf dhcpbridge=/usr/bin/nova-dhcpbridge logdir=/var/log/nova state_path=/var/lib/nova lock_path=/var/lock/nova force_dhcp_release=True iscsi_helper=tgtadm libvirt_use_virtio_for_bridges=True connection_type=libvirt root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf verbose=True ec2_private_dns_show_ip=True api_paste_config=/etc/nova/api-paste.ini volumes_path=/var/lib/nova/volumes enabled_apis=ec2,osapi_compute flat_interface=eth2.103 #debug=False debug=True log_dir=/var/log/nova network_manager=nova.network.manager.FlatDHCPManager amqp_durable_queues=False rabbit_hosts=10.0.21.5:5672 quota_volumes=100 notify_api_faults=False flat_network_bridge=br100 resume_guests_state_on_host_boot=True memcached_servers=10.0.21.5:11211 scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,CoreFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter rabbit_use_ssl=False quota_ram=51200 notification_driver=messaging max_io_ops_per_host=8 quota_max_injected_file_content_bytes=102400 s3_listen=0.0.0.0 quota_driver=nova.quota.NoopQuotaDriver glance_api_servers=192.168.1.103:9292 max_age=0 quota_security_groups=10 novncproxy_host=192.168.1.103 rabbit_userid=nova rabbit_ha_queues=True rabbit_password=FMskSLdn report_interval=10 scheduler_weight_classes=nova.scheduler.weights.all_weighers quota_cores=100 reservation_expire=86400 rabbit_virtual_host=/ force_snat_range=0.0.0.0/0 image_service=nova.image.glance.GlanceImageService use_cow_images=True quota_max_injected_files=50 notify_on_state_change=vm_and_task_state scheduler_host_subset_size=30 novncproxy_port=6080 ram_allocation_ratio=1.0 compute_scheduler_driver=nova.scheduler.filter_scheduler.FilterScheduler quota_security_group_rules=20 disk_allocation_ratio=1.0 quota_max_injected_file_path_bytes=4096 quota_floating_ips=100 quota_key_pairs=10 scheduler_max_attempts=3 cpu_allocation_ratio=8.0 multi_host=True max_instances_per_host=50 scheduler_available_filters=nova.scheduler.filters.all_filters public_interface=eth1 service_down_time=60 syslog_log_facility=LOG_LOCAL6 quota_gigabytes=1000 use_syslog_rfc_format=True quota_instances=100 scheduler_host_manager=nova.scheduler.host_manager.HostManager notification_topics=notifications osapi_compute_listen=0.0.0.0 ec2_listen=0.0.0.0 volume_api_class=nova.volume.cinder.API service_neutron_metadata_proxy=False use_forwarded_for=False osapi_volume_listen=0.0.0.0 metadata_listen=0.0.0.0 auth_strategy=keystone ram_weight_multiplier=1.0 keystone_ec2_url=http://10.0.21.5:5000/v2.0/ec2tokens quota_metadata_items=1024 osapi_compute_workers=8 rootwrap_config=/etc/nova/rootwrap.conf rpc_backend=nova.openstack.common.rpc.impl_kombu fixed_range=10.0.23.0/24 use_syslog=True metadata_workers=8 dhcp_domain=novalocal allow_resize_to_same_host=True flat_injected=False [DATABASE] max_pool_size=30 max_retries=-1 max_overflow=40 [database] idle_timeout=3600 connection=mysql://nova:LcHgm0PN@127.0.0.1/nova?read_timeout=60 [keystone_authtoken] signing_dirname=/tmp/keystone-signing-nova signing_dir=/tmp/keystone-signing-nova auth_port=35357 admin_password=FMxM1wqW admin_user=nova auth_protocol=http auth_host=10.0.21.5 admin_tenant_name=services auth_uri=http://10.0.21.5:5000/ [conductor] workers=8 === compute node: nova.conf root@node-8:~# cat /etc/nova/nova.conf [DEFAULT] notification_driver=ceilometer.compute.nova_notifier notification_driver=nova.openstack.common.notifier.rpc_notifier dhcpbridge_flagfile=/etc/nova/nova.conf dhcpbridge=/usr/bin/nova-dhcpbridge logdir=/var/log/nova state_path=/var/lib/nova lock_path=/var/lock/nova force_dhcp_release=True iscsi_helper=tgtadm libvirt_use_virtio_for_bridges=True connection_type=libvirt root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf verbose=True ec2_private_dns_show_ip=True api_paste_config=/etc/nova/api-paste.ini volumes_path=/var/lib/nova/volumes enabled_apis=metadata flat_interface=eth2.103 debug=False
[openstack-dev] What's Up, Doc? 5 June 2015
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, With our Kilo branch now cut, we're running headlong into the Liberty development cycle! And don't forget to have your say on what the M release should be called: https://wiki.openstack.org/wiki/Release_Naming/M_Proposals If you have content you would like to add, or you would like to be added to the distribution list, please email me directly at openst...@lanabrindley.com. I've also decided to start drafting these 'in the open' (as it were). If you want to see my early drafts and typos, or check on old newsletters, you can do so here: https://wiki.openstack.org/w/index.php?title=Documentation/WhatsUpDoc == Progress towards Liberty == * RST conversion: ** Install Guide: there's now a spec awaiting review: https://review.openstack.org/#/c/183138/ ** Cloud Admin Guide: has been started! Get in touch with Brian or Joe, or sign up here: [[https://wiki.openstack.org/wiki/Documentation/Migrate#Cloud_Admin_Guide_Migration]] ** HA Guide: is also underway! Get in touch with Meg or Matt: https://wiki.openstack.org/wiki/Documentation/HA_Guide_Update * User Guides information architecture overhaul ** Waiting on the RST conversion of the Cloud Admin Guide to be complete * Greater focus on helping out devs with docs in their repo ** No progress this week * Improve how we communicate with and support our corporate contributors ** I met with Alison of Oracle to discuss how we can help out their team * Improve communication with Cross Team Liaisons ** The current list of liaisons is available here: https://wiki.openstack.org/wiki/CrossProjectLiaisons#Documentation ** I will be contacting CPLs shortly to discuss ways to improve == Kilo Branching == Thanks to Andreas, Anne, and Tom for getting the Stable/Kilo branch completed this week. With this, Kilo is now complete* and patches for the Install Guide and the Config Reference will now be against Liberty unless you specifically backport a change to Kilo. You can do this by committing to master with the line ''Backport: Kilo'' in your commit message. Remember that all other book are continuously integrated, and this isn't necessary. [*] Anne: feel free to go have a lie down ;) == RST Migration == The next books we are focusing on for RST conversion are the Install Guide, Cloud Admin Guide, and the HA Guide. If you would like to assist, please get in touch with the appropriate speciality team. * Install Guide: ** Contact Karin Levenstein karin.levenst...@rackspace.com ** Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/installguide-liberty ** Spec WIP: https://review.openstack.org/#/c/183138/ * Cloud Admin Guide: ** Contact Brian Moss kallimac...@gmail.com Joseph Robinson joseph.r.em...@gmail.com ** Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/reorganise-user-guides ** Sign up to help out here: https://wiki.openstack.org/wiki/Documentation/Migrate#Cloud_Admin_Guide_Migration * HA Guide ** Contact Meg McRoberts dreidellh...@yahoo.com or Matt Griffin matt.grif...@percona.com ** Blueprint: https://blueprints.launchpad.net/openstack-manuals/+spec/improve-ha-guide For books that are now being converted, don't forget that any change you make to the XML must also be made to the RST version until conversion is complete. Our lovely team of cores will be keeping an eye out to make sure loose changes to XML don't pass the gate, but try to help them out by pointing out both patches in your reviews. == New Core Reviewer Process == We did our first monthly round of Core Team review this week, and would like to welcome our newest core team member, Darren Chan. We also bid a fond farewell to Summer Long and Bryan Payne, who have been great core team members and contributors, but have now moved on to other adventures. We sincerely thank them both for their commitment over the time they were core. The new core process is documented here: https://wiki.openstack.org/wiki/Documentation/HowTo#Achieving_core_reviewer_status The next round will be around 1 July. == Doc team meeting == The US meeting was held this week, see the minutes here to catch up: https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2015-06-03 Thanks Shilla for running the US team meeting! Next meetings are: APAC: Wednesday 10 June, 00:30:00 UTC US: Wednesday 17 June, 14:00:00 UTC Please go ahead and add any agenda items to the meeting page here: https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting Thanks! Lana - -- Lana Brindley Technical Writer Rackspace Cloud Builders Australia http://lanabrindley.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVcQZ4AAoJELppzVb4+KUy7D4H/jgU9I9eC6MNSpCrW6AYMPsi AKmBP+ZiTtXm3iVk1EapzhTUXYINJBtSgP8LfO2QpofqJdbU8KW9f4oIMno86W3G 1GpfGwoFDxLPDDvamxHNNgdihxQRojD7rZE+TspMZV0LU5O5vu3O1JsgNq4268H1 iLncfmfSDLFUU2qbLco6MuNqjK8kSG3U3GoafnPjJTQ4q4/hG5UW6iWSKeHAAay9 VnQ2e06mzOKFWGigcW4gZ8yTtW/kWmzuLcLsC8CAphely7Ru3jdwHH9BJsNdk7+V
Re: [openstack-dev] [Keystone] Domain and Project naming
On Wed, Jun 3, 2015 at 11:25 PM, Adam Young ayo...@redhat.com 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 that all project namess under the domain domain be unique, but really what we should say is that all projects under a single parent project be unique. However, we have, at present, an API which allows a user to specify the domain either name or id and project again, either by name or ID, but here we care only about the name. This can be used either in specifying the token, or in operations ion the project API. We should change projec naming to be nestable, and since we don't have a delimiter set, we should expect the names to be an array, where today we might have: project: { domain: { id: 1789d1, name: example.com }, id: 263fd9, name: project-x } we should allow and expect: project: { domain: { id: 1789d1, name: example.com }, id: 263fd9, name: [ grandpa, dad, daughter] } What is the actual project name here, and how do I specify it using my existing OS_PROJECT_NAME environment variable? This will, of course, break Horizon and lots of other things, which means we need a reasonable way to display these paths. The typical UI approach is a breadcrumb trail, and I think something where we put the segments of the path in the UI, each clickable, should be understandable: I'll defer to the UX experts if this is reasonable or not. The alternative is that we attempt to parse the project names. Since we have not reserved a delimeter, we will break someone somewhere if we force one on people. As an alternative, we should start looking in to following DNS standards for naming projects and hosts. While a domain should not be required to be a DNS registred domain name, we should allow for the case where a user wants that to be the case, and to synchronize nam,ing across multiple clouds. In order to enforce this, we would have to have an indicator on a domain name that it has been checked with DNS; ideally, the user would add a special SRV or Text record or something that Keystone could use to confirm that the user has oked this domain name being used by this cloud...or something perhaps with DNSSEC, checking that auser has permission to assign a specific domain name to a set of resources in the cloud. If we do that, the projects under that domain should also be valid DNS subzones, and the hosts either FQDNs or some alternate record...this would tie in Well with Designate. Note that I am not saying force this but rather allow this as it will simplify the naming when bursting from cloud to cloud: the Domain and project names would then be synchronized via DNS regardless of hosting provider. As an added benefit, we could provide a SRV or TEXT record (or some new URL type..I heard one is coming) that describes where to find the home Keystone server for a specified domain...it would work nicely with the K2K strategy. If we go with DNS project naming, we can leave all project names in a flat string. Note that the DNS approach can work even if the user does not wish to register their own DNS. A hosting provider (I'll pick dreamhost, cuz I know they are listening) could say the each of their tenants picks a user name...say that mine i admiyo, they would then create a subdomain of admiyo.dreamcompute.dreamhost.com. All of my subprojects would then get additional zones under that. If I were then to burst from there to Bluebox, the Keystone domain name would be the one that I was assigned back at Dreamhost. __ OpenStack Development Mailing 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] Service Chain project IRC meeting minutes - 06/04/2015
On 4 June 2015 at 19:32, Vikram Choudhary viks...@gmail.com wrote: Hi Cathy, Thanks for heading up this meeting. No worries about the timing, time zones are really difficult to handle ;) I do agree with Armando that finalization of the API is important and must be done at the earliest. As discussed over the last meeting I will start working on this and hope by the next meeting we have something in the kitty. Are you going to use a polished up version of spec [1] (which needs a rebase and a transition to the networking-sfc repo when that's ready)? [1] https://review.openstack.org/#/c/177946/ Thanks Vikram On Fri, Jun 5, 2015 at 6:36 AM, Armando M. arma...@gmail.com wrote: On 4 June 2015 at 14:17, Cathy Zhang cathy.h.zh...@huawei.com wrote: Thanks for joining the service chaining meeting today! Sorry for the time confusion. We will correct the weekly meeting time to 1700UTC (10am pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting page. Cathy, thanks for driving this. I took the liberty to carry out one of the actions identified in the meeting: the creation of repo to help folks collaborate over code/documentation/testing etc [1]. As for the core team definition, we'll start with a single member who can add new folks as more docs/code gets poured in. One question I had when looking at the minutes, was regarding slides [2]. Not sure if discussing deployment architectures when the API is still baking is premature, but I wonder if you had given some thoughts into having a pure agentless architecture even for the OVS path. Having said that, as soon as the repo is up and running, I'd suggest to move any relevant document (e.g. API proposal, use cases, etc) over to the repo and reboot the review process so that everyone can be on the same page. Cheers, Armando [1] https://review.openstack.org/#/c/188637/ [2] https://docs.google.com/presentation/d/1SpVyLBCMRFBpMh7BsHmpENbSY6qh1s5NRsAS68ykd_0/edit#slide=id.p Meeting Minutes: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.html Meeting Minutes (text): http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.txt Meeting Log: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.log.html The next meeting is scheduled for June 11 (same place and time). Thanks, Cathy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] [glance] How to deal with aborted image read?
Perhaps someone needs to use (or forgot to use) contextlib.closing? https://docs.python.org/2/library/contextlib.html#contextlib.closing Or contextlib2 also may be useful: http://contextlib2.readthedocs.org/en/latest/#contextlib2.ExitStack -Josh 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 stuck with an open file descriptor, which meant that the image consumed space even after it was deleted. I have a crude fix for nova at https://review.openstack.org/#/c/188179/; which basically continues to read the image even though it can't write it. That seems less than ideal for large images though. Is there a better way to do this? Is there a way for nova to indicate to glance that it's no longer interested in that image and glance can close the file? If I've followed this correctly, on the glance side I think the code in question is ultimately glance_store._drivers.filesystem.ChunkedFile.__iter__(). Actually, to be honest, I was quite confused by the email :P Correct me if I still didn't understand what you're asking. You ran out of space on the Nova side while downloading the image and there's a file descriptor leak somewhere either in that lovely (sarcasm) glance wrapper or in glanceclient. The first part is correct, but the file descriptor is actually held by glance-api. Just by reading your email and glancing your patch, I believe the bug might be in glanceclient but I'd need to five into this. The piece of code you'll need to look into is[0]. glance_store is just used server side. If that's what you meant - glance is keeping the request and the ChunkedFile around - then yes, glance_store is the place to look into. [0] https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v1/images.py#L152 I believe what's happening is that the ChunkedFile code opens the file and creates the iterator. Nova then starts iterating through the file. If nova (or any other user of glance) iterates all the way through the file then the ChunkedFile code will hit the finally clause in __iter__() and close the file descriptor. If nova starts iterating through the file and then stops (due to running out of room, for example), the ChunkedFile.__iter__() routine is left with an open file descriptor. At this point deleting the image will not actually free up any space. I'm not a glance guy so I could be wrong about the code. The externally-visible data are: 1) glance-api is holding an open file descriptor to a deleted image file 2) If I kill glance-api the disk space is freed up. 3) If I modify nova to always finish iterating through the file the problem doesn't occur in the first place. Chris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting
On 06/04/2015 05:49 PM, Morgan Fainberg wrote: Hi Everyone! I've been reading through this thread and have had some conversations along the side and wanted to jump in to distill out what I think are the key points we are trying to address here. I'm going to outline about 4 items that seem to make sense to me regarding the evolution of policy. I also want to say that the notification that something has changed from the defaults in a way that may cause odd behavior to the side (the warning Sean was outlining); we can keep the desire to have those types of warnings for operators down the line (nothing that is being proposed here or what I'm going to outline will make it more or less difficult to add the functionality later on). This is not to say we wouldn't provide validation of an override, but a subjective this is a problematic policy configuration doesn't need to be directly part of this conversation today (it can happen once we know what the model of policy looks like going forward). 1. The first thing that I'm hearing from the conversation (this is based upon Sean's proposal) is that we already trust the individual projects to know the enforcement profile for their resources. It seems like the project should be authoritative on what that enforcement should look like. Handing off the enforcement definition to Keystone is the wrong direction. I really like the concept of defining within Nova the default policy that nova works with (we do this already today, and I don't want to require the nova team to come to Keystone to make changes to the policy down the line). The Projects are trusted to know what the enforcement points are and trusted to distribute a basic profile of enforcement. To the end that the enforcement definition is handled by the individual projects, making it something that is more than a blob of text also makes a lot of sense. A code-like model that is easier to understand for the developers that are implementing enforcement would be useful. The key pieces are that this code-like-construct must be able to be serialized out into the common format. The policy file format is JSON, which is the standard for all of the APIs in OpenStack thus far. Second, this code-construct is just the basic level of truth, the idea is that the dynamic policy will provide the overrides - and *everything* can be overridden. The code-like construct will also aid in profiling/testing the base/defaults (and then the dynamic policy overrides) without having to standup the entire stack. We can enable base functionality testing / validation and then the more integrated testing with the full stack (in different environments). This will enable more accurate and better base policy development by the teams we already trust to build the enforcement for a given project (e.g. Nova). We already have this. It is the default policy.json that each project keeps up to date. Please don't suggest putting annotations on the coder and running a preprocessor. That way leads to madness. I see no reason to have a team write policy in Python and then serialize to JSON. -- The real current problem we have is this: On a given API, we don't know where to look for the project ID and (almost all) policy needs to be enforced on the project scope. What is required is for the base repository to have a document of how to set up the scoping for the call (token.proiject.id must match fetched_object.tenant_id), and we could mark that as dangerous to change. What I would not want is to have the project hardcode the Role required. Perhaps the API indicates one of two levels: Admin vs Member, on an API, indicating the expected consumer of the API. However, the current Policy file format represents this sufficiently. We just need the Nova team to stay on top of this for Nova, and the other teams for their projects. What I would love to be able to get from Nova is this api will end up calling these apis in Glance, Cinder, and neutron. So we can properly delegate. 2. We will need a way to handle the bi-directional notifications for policy changes. This would encompass when a project is restarted and has a new code-policy construct and how that gets to Keystone. We also need to ensure that changes to the overrides are pushed down to the projects. This is not an easy canned solution today, but I am sure we can solve it. Likely this is tied to Keystone Middleware or something similar (I believe code is already in the works to this end). I appreciate that Nova is growing, but I would not expect huge amounts of new policy code with each updtate...at this point, new policy would be deny until there is a new rule to handle it and upload these new rules. Upgrading code is already part of an organizations deployment stategy, and trying to build in an additional two way notification system is more than we should be doing here. If Nova feels that each micro
Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel
I think this is perfectly fine, as long as it's reasonably large and the algorithm is sufficiently intelligent. The UUID algorithm is good at this, for instance, although it fails at readability. Docker's is not terribly great and could be limiting if you were looking to run several thousand containers on a single machine. Something better than Docker's algorithm but more readable than UUID could be explored. Also, something to consider is if this should also mean a change to the UUIDs themselves. You could use UUID-5 to create a UUID from your tenant's UUID and your unique name. The tenant's UUID would be the namespace, with the bay's name being the name field. The benefit of this is that clients, by knowing their tenant ID could automatically determine their bay ID, while also guaranteeing uniqueness (or as unique as UUID gets, anyway). Cool idea! I'm clear with the solution, but still have some questions: So we need to set the bay/baymodel name in the format of UUID-name format? Then if we get the tenant ID, we can use magnum bay-list | grep tenant-id or some other filter logic to get all the bays belong to the tenant? By default, the magnum bay-list/baymodel-list will only show the bay/baymodels for one specified tenant. The name would be an arbitrary string, but you would also have a unique-identifier which is a UUID. I'm proposing the UUID could be generated using the UUID5 algorithm which is basically sha1(tenant_id + unique_name) converted into a GUID. The Python uuid library can do this easily, out of the box. Taking from the dev-quickstart, I've changed the instructions for creating a container according to how this could work using uuid5: $ magnum create-bay --name swarmbay --baymodel testbaymodel $ BAY_UUID=$(python -c import uuid; print uuid.uuid5(uuid.UUID('urn:uuid:${TENANT_ID}'), 'swarmbay')) $ cat ~/container.json END { bay_uuid: $BAY_UUID, name: test-container, image_id: cirros, command: ping -c 4 8.8.8.8 } END $ magnum container-create ~/container.json The key difference in this example, of course, is that users would not need to contact the server using bay-show in order to obtain the UUID of their bay. Regards, Eric Windisch __ OpenStack Development Mailing 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][horizon] Making a dashboard for Magnum - need a vote from the core team
Hongbin, I hadn’t thought of that, even though it seems obvious ;) We can absolutely do that. I almost like this option better then #1 but I don’t want the ui folks to feel like second class citizens. This goes back to the trust the ui developers to not review things they know not about :) Bradley, How are other OpenStack projects handling the UI teams which clearly have a totally different specialty than the typical core team for a project with the Horizon big tent changes? Regards -steve From: Hongbin Lu hongbin...@huawei.commailto:hongbin...@huawei.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, June 4, 2015 at 1:30 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Could we have a new group magnum-ui-core and include magnum-core as a subgroup, like the heat-coe-tempalte-core group. Thanks, Hongbin From: Steven Dake (stdake) [mailto:std...@cisco.com] Sent: June-04-15 1:58 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. 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
[openstack-dev] [neutron] Service Chain project IRC meeting minutes - 06/04/2015
Thanks for joining the service chaining meeting today! Sorry for the time confusion. We will correct the weekly meeting time to 1700UTC (10am pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting page. Meeting Minutes: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.html Meeting Minutes (text): http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.txt Meeting Log: http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.log.html The next meeting is scheduled for June 11 (same place and time). Thanks, Cathy __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [openstack-operators][openstack][chef] Pre-release of knife-openstack is out (1.2.0.rc1)
Hey everyone! I have cut a new release of the knife-openstack[1] gem today. We have a couple new features[2] which has been asked for a while. If you would like to give it a shot and report back any issues you might find[3]. gem install knife-openstack --pre I’m hoping to give this a week or two to bake, then I’ll push it to master and a 1.2.0 release. If you have any questions, thoughts, concerns please don’t hesitate to reach out! [1]: https://rubygems.org/gems/knife-openstack https://rubygems.org/gems/knife-openstack [2]: https://github.com/chef/knife-openstack/pull/165/files https://github.com/chef/knife-openstack/pull/165/files [3]: https://github.com/chef/knife-openstack/issues https://github.com/chef/knife-openstack/issues -JJ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][api] 3 new guidelines entering freeze period
The API working group has three new guidelines that are entering the 1 week freeze period. We would like to ask all PTLs and CPLs, and other interested parties, to take a look at these reviews. We will use lazy consensus at the end of the freeze to merge them if there are no objections. Remember, these are guidelines, they are not meant to be taken as strict rules from on high that must be followed or else /ominous music. For further information about the API working group and it's purpose, please see the group wiki[1]. The three guidelines up for review are: * Guidance on 500 internal server error, https://review.openstack.org/#/c/179365 * Clarification on state-conflicting requests, https://review.openstack.org/#/c/180094 * Clarification on when to use 409, https://review.openstack.org/#/c/179386 thanks, mike [1]: https://wiki.openstack.org/wiki/API_Working_Group#Purpose __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Hard Code Freeze status update - Just 4th 2PM PDT
Hello everyone, The Keystone patch passed staging tests, we are now building the ISO with this patch and other merged fixes. Test results for this ISO will be available tonight/early morning tomorrow PDT. If they are good, this will be our RC. So, our plan to declare HCF tomorrow morning/afternoon PDT (June 5th) looks realistic. -- EugeneB __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] When to bump the microversion?
On Jun 4, 2015 11:11 AM, Chris Friesen chris.frie...@windriver.com wrote: On 06/04/2015 10:14 AM, Devananda van der Veen wrote: On Jun 4, 2015 8:57 AM, Monty Taylor mord...@inaugust.com So, seriously - let's grow up and start telling people that they do not get to pick and choose user-visible feature sets. If they have an unholy obsession with a particular backend technology that does not allow a public feature of the API to work, then they are deploying a broken cloud and they need to fix it. So I just had dinner last night with a very large user of OpenStack (yes, they exist) whose single biggest request is that we stop differentiating in the API. To them, any difference in the usability / behavior / API between OpenStack deployment X and Y is a serious enough problem that it will have two effects: - vendor lock in - they stop using OpenStack And since avoiding single vendor lock in is important to them, well, really it has only one result. Tl;Dr; Monty is right. We MUST NOT vary the API or behaviour significantly or non-discoverably between clouds. Or we simply won't have users. If a vendor wants to differentiate themselves, what about having two sets of API endpoints? One that is full vanilla openstack with bog-standard behaviour, and one that has vendor-specific stuff in it? That way the end-users that want interop can just use the standard API and get common behaviour across clouds, while the end-users that want the special sauce and are willing to lock in to a vendor to get it can use the vendor-specific API. You've just described what ironic has already done with the /vendor_passthu/ end point. However, the issue, more broadly, is just discovery of differences in the API which make one cloud behave differently than another. Sometimes those aren't related to vendor-specific features at all. Eg, changes which are the result of config settings, or where a fix or feature gets back ported (because sometimes someone thinks that's easier than a full upgrade). These things exist today, but create a terrible experience for users who want to move a workload between OpenStack clouds, and find that the APIs don't behave quite the same, even for basic functionality. -D Chris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting
Hi Everyone! I've been reading through this thread and have had some conversations along the side and wanted to jump in to distill out what I think are the key points we are trying to address here. I'm going to outline about 4 items that seem to make sense to me regarding the evolution of policy. I also want to say that the notification that something has changed from the defaults in a way that may cause odd behavior to the side (the warning Sean was outlining); we can keep the desire to have those types of warnings for operators down the line (nothing that is being proposed here or what I'm going to outline will make it more or less difficult to add the functionality later on). This is not to say we wouldn't provide validation of an override, but a subjective this is a problematic policy configuration doesn't need to be directly part of this conversation today (it can happen once we know what the model of policy looks like going forward). 1. The first thing that I'm hearing from the conversation (this is based upon Sean's proposal) is that we already trust the individual projects to know the enforcement profile for their resources. It seems like the project should be authoritative on what that enforcement should look like. Handing off the enforcement definition to Keystone is the wrong direction. I really like the concept of defining within Nova the default policy that nova works with (we do this already today, and I don't want to require the nova team to come to Keystone to make changes to the policy down the line). The Projects are trusted to know what the enforcement points are and trusted to distribute a basic profile of enforcement. To the end that the enforcement definition is handled by the individual projects, making it something that is more than a blob of text also makes a lot of sense. A code-like model that is easier to understand for the developers that are implementing enforcement would be useful. The key pieces are that this code-like-construct must be able to be serialized out into the common format. Second, this code-construct is just the basic level of truth, the idea is that the dynamic policy will provide the overrides - and *everything* can be overridden. The code-like construct will also aid in profiling/testing the base/defaults (and then the dynamic policy overrides) without having to standup the entire stack. We can enable base functionality testing / validation and then the more integrated testing with the full stack (in different environments). This will enable more accurate and better base policy development by the teams we already trust to build the enforcement for a given project (e.g. Nova). -- 2. We will need a way to handle the bi-directional notifications for policy changes. This would encompass when a project is restarted and has a new code-policy construct and how that gets to Keystone. We also need to ensure that changes to the overrides are pushed down to the projects. This is not an easy canned solution today, but I am sure we can solve it. Likely this is tied to Keystone Middleware or something similar (I believe code is already in the works to this end). -- 3. The HA-Proxy mode of deployment with projects that can handle no-downtime upgrades mean that we need to add in versioning into the policy structures. The policy files for a Kilo vintage of Nova may (likely) will be incompatible with Liberty nova. This means we cannot assume that policy can be centralized easily even for a specific grouping of api-services running as a single endpoint. This becomes an even more important mechanism as we move towards more and more services with microversioned APIs. It means it is totally reasonable to upgrade 1 or 2 nova APIs behind an HA Proxy since the new APIs will handle the old microversion of the API. This leads to needing policy to likewise be versioned. This also means that only the service can be authoritative with the base-policy construct. This means whatever tool we use for handling the overrides on the Keystone side will need to be aware of policy versions as well. Having Keystone side being exclusively authoratative for the entire policy makes development, testing, and understanding of policy harder. This is another case of the project itself should be in control of the base policy definition. -- 4. As a note that came out of the conversation I had with Sean, we should look at no longer making the policy definition for an API keyed on the intern-method name of a project. While instance_create is relatively descriptive, there are many other API calls that you cannot really know what changing the policy will do without trying it. Sean and I were discussing moving towards supplying a representation of the URI path instead of image_create. This is something that consumers and deployers of OpenStack will be more familiar with. It also eliminates some of the mapping needed to know what the URI of image create is when utilized in the Horizon context (asking
Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
I will get a spec out for review by end of day tomorrow. Thanks, Brad Jones On 4 Jun 2015, at 22:30, Adrian Otto adrian.o...@rackspace.commailto:adrian.o...@rackspace.com wrote: Team, I have published a top level blueprint for a magnum-horizon-plugin: https://blueprints.launchpad.net/magnum/+spec/magnum-horizon-plugin My suggestion is that any contributor interested in contributing to this feature should subscribe to that blueprint, and record their intent to contribute in the Whiteboard of the BP. Furthermore, I suggest that any contributors who are a good fit for core reviewer duties for this effort subscribe to the blueprint and mark themselves as “Participation Essential” so I can get a clear picture of how to deal with grouping the related core reviewer team (or adding them to the current core group). I think that this effort would benefit from a spec submitted as a review using the following template: http://git.openstack.org/cgit/openstack/nova-specs/tree/specs/liberty-template.rst Adapt it for magnum (I have not contributed a spec template of our own yet. TODO.) Contribute it here: http://git.openstack.org/cgit/openstack/magnum/tree/specs Thanks, Adrian On Jun 4, 2015, at 12:58 PM, Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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.orgmailto: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] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
Problem! In writing a spec for this ( https://review.openstack.org/#/c/188564/ ), I remembered that groups are domain-specific entities, which complicates the problem of providing X-Group-Names via middleware. The problem is that we can't simply expose X-Group-Names to underlying services without either A) making a well-documented assumption about the ONE owning domain scope of ALL included groups, B) passing significantly more data to underlying services than just a list of names (a domain scope for every group), C) passing only globally-unique group IDs (services would then have to retrieve additional details about each from from keystone if they so cared). Option A) More specifically, keystone could opt to enumerate the groups that belong to the same domain as the user. In this case, it'd probably make more sense from an API perspective if the groups enumeration were part of the user resources in the token response body (the user object already has a containing domain ID. That means that IF a user were to be assigned a group membership in another domain (assuming we didn't move to disallowing that behavior at some point), then it would have to be excluded from this list. If that were true, then I'd also follow that X-Group-Names become X-User-Group-Names, so that it might be more clear that they belong to the X-User-Domain-*. Option B) This is probably the most complex solution, but also the most explicit. I have no idea how this interface would look in terms of headers using current conventions. If we're going to break conventions, then I'd want to pass a id+domain_id+name for each group reference. So, rather than including a list of names AND a list of IDs, we'd have some terribly encoded list of group objects (I'm not sure what the HTTP convention is on this sort of use case, and hoping someone can illustrate a better solution given the representation below): X-Groups: id%3D123%2Cdomain_id%3D456%2Cname%3Dabc,id%3D789%2Cdomain_id%3D357%2Cname%3Ddef Option C) Federated tokens would actually require solution (C) today because they only include group IDs, not names. But the group enumeration in federated tokens was also only intended to be consumed by keystone, so that's not really an issue for that one use case. But option (C) would mean there are no X-Group-Names passed to services, just X-Group-Ids. I'm guessing this won't provide the user experience that Barbican is looking for? I'm leaning towards solution (A), but curious if that'll work for Barbican and/or if anyone has an idea that I'm overlooking. On Thu, Jun 4, 2015 at 8:18 AM, Dolph Mathews dolph.math...@gmail.com wrote: To clarify: we already have to include the groups produced as a result of federation mapping **in the payload** of Fernet tokens so that scoped tokens can be created later: https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/token/providers/fernet/token_formatters.py#L523 These are OpenStack group IDs, so it's up to the deployer to keep those under control to keep Fernet token sizes down. It's the only place in the current Fernet implementation that's (somewhat alarmingly) unbounded in the real world. But we do **not** have a use case to add groups to *all* Fernet payloads: only to token creation validation responses. On Thu, Jun 4, 2015 at 2:36 AM, Morgan Fainberg morgan.fainb...@gmail.com wrote: For Fernet, the groups would only be populated on validate as Dolph outlined. They would not be added to the core payload. We do not want to expand the payload in this manner. --Morgan Sent via mobile On Jun 3, 2015, at 21:51, Lance Bragstad lbrags...@gmail.com wrote: I feel if we allowed group ids to be an attribute of the Fernet's core payload, we continue to open up the possibility for tokens to be greater than the initial acceptable size limit for a Fernet token (which I believe was 255 bytes?). With this, I think we need to provide guidance on the number of group ids allowed within the token before that size limit is compromised. We've landed patches recently that allow for id strings to be included in the Fernet payload [0], regardless of being uuid format (which can be converted to bytes before packing to save space, this is harder for us to do with non-uuid format id strings). This can also cause the Fernet token size to grow. If we plan to include more information in the Fernet token payload I think we should determine if the original acceptable size limit still applies and regardless of what that size limit is provide some sort of best practices for helping deployments keep their token size as small as possible. Keeping the tokens user (and developer) friendly was a big plus in the design of Fernet, and providing resource for deployments to maintain that would be helpful. [0] https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:bug/1459382,n,z On Wed, Jun 3, 2015 at 10:19
Re: [openstack-dev] [Neutron] L3 agent rescheduling issue
Hi, After trying to reproduce this, I'm suspecting that the issue is actually on the server side from failing to drain the agent report state queue in time. I have seen before. I thought the senario at that time as follows. * a lot of create/update resource API issued * rpc_conn_pool_size pool exhausted for sending notify and blocked farther sending side of RPC. * rpc_thread_pool_size pool exhausted by waiting rpc_conn_pool_size pool for replying RPC. * receiving state_report is blocked because rpc_thread_pool_size pool exhausted. Thanks Itsuro Oda On Thu, 4 Jun 2015 14:20:33 -0700 Kevin Benton blak...@gmail.com wrote: After trying to reproduce this, I'm suspecting that the issue is actually on the server side from failing to drain the agent report state queue in time. I set the report_interval to 1 second on the agent and added a logging statement and I see a report every 1 second even when sync_routers is taking a really long time. On Thu, Jun 4, 2015 at 11:52 AM, Carl Baldwin c...@ecbaldwin.net wrote: Ann, Thanks for bringing this up. It has been on the shelf for a while now. Carl On Thu, Jun 4, 2015 at 8:54 AM, Salvatore Orlando sorla...@nicira.com wrote: One reason for not sending the heartbeat from a separate greenthread could be that the agent is already doing it [1]. The current proposed patch addresses the issue blindly - that is to say before declaring an agent dead let's wait for some more time because it could be stuck doing stuff. In that case I would probably make the multiplier (currently 2x) configurable. The reason for which state report does not occur is probably that both it and the resync procedure are periodic tasks. If I got it right they're both executed as eventlet greenthreads but one at a time. Perhaps then adding an initial delay to the full sync task might ensure the first thing an agent does when it comes up is sending a heartbeat to the server? On the other hand, while doing the initial full resync, is the agent able to process updates? If not perhaps it makes sense to have it down until it finishes synchronisation. Yes, it can! The agent prioritizes updates from RPC over full resync activities. I wonder if the agent should check how long it has been since its last state report each time it finishes processing an update for a router. It normally doesn't take very long (relatively) to process an update to a single router. I still would like to know why the thread to report state is being starved. Anyone have any insight on this? I thought that with all the system calls, the greenthreads would yield often. There must be something I don't understand about it. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton -- Itsuro ODA o...@valinux.co.jp __ OpenStack Development Mailing 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] L3 agent rescheduling issue
On Thu, Jun 4, 2015 at 3:20 PM, Kevin Benton blak...@gmail.com wrote: After trying to reproduce this, I'm suspecting that the issue is actually on the server side from failing to drain the agent report state queue in time. I set the report_interval to 1 second on the agent and added a logging statement and I see a report every 1 second even when sync_routers is taking a really long time. Very good insight. That makes a lot more sense to me. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project
On Wed, Jun 03, 2015 at 04:30:17PM -0400, Sean Dague wrote: The closer we can get logic about what a service should look like on disk back into that service itself, the less work duplicated by any of the installers, and the more common OpenStack envs would be. The fact that every installer / package needs to copy in a bunch of etc files (because the python packages don't do it) has always seemed rather odd to me. I agree with this, and given the disparate and seemingly contradictory goals driving these discussions, I think it will be exceedingly difficult to make everyone happy. So here's my suggestion: 1. Maintain all important data for packaging as first-class members of the respective repositories. Initscripts, systemd service files, licensing (SPDX?), and so on should be in the master branch of each project. Just enough glue should be present such that functional packaging can be programmatically generated from HEAD with debdry or similar tooling, and this is how test jobs should operate (f.ex.: run debdry, mangle version number to something unique, build package in chroot or equivalent, store output for use in other testing). 2. Create a single repository, with one subdirectory per source package, in which overrides or patches to third-party packaging can be committed and used to trigger builds. This way OpenStack could - produce and consume its own package artifacts for testing changes of varying complexity - get early warning of changes which will break packaging, insanity in dependency graphs, and so on - be a central point of collaboration without introducing a bunch of repo duplication or bypass of code review Distributors could - clone the upstream repos and branch to add any special tweaks, then potentially run the same automation to get source/binary packages - collaborate upstream to fix things of common utility __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
Sounds like the community would like CI's regardless, and I agree. Just because the driver code works for one backend solution, doesn't mean it's going to work with some other. Lets continue with code reviews with these patches only if they have a CI reporting, unless someone has a compelling reason we should not let any rebranded drivers in. -- Mike Perez On Wed, Jun 3, 2015 at 10:32 AM, Mike Perez thin...@gmail.com wrote: There are a couple of cases [1][2] I'm seeing where new Cinder volume drivers for Liberty are rebranding other volume drivers. This involves inheriting off another volume driver's class(es) and providing some config options to set the backend name, etc. Two problems: 1) There is a thought of no CI [3] is needed, since you're using another vendor's driver code which does have a CI. 2) IMO another way of satisfying a check mark of being OpenStack supported and disappearing from the community. What gain does OpenStack get from these kind of drivers? Discuss. [1] - https://review.openstack.org/#/c/187853/ [2] - https://review.openstack.org/#/c/187707/4 [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Rebranded Volume Drivers
Agreed, I'd also like to mention that rebranded arrays may differ slightly in functionality as well so the CIs would need to run against a physical rebranded device. These differences also justify the need for letting rebranded drivers in. -Alex On Thu, Jun 4, 2015 at 4:41 PM, Mike Perez thin...@gmail.com wrote: Sounds like the community would like CI's regardless, and I agree. Just because the driver code works for one backend solution, doesn't mean it's going to work with some other. Lets continue with code reviews with these patches only if they have a CI reporting, unless someone has a compelling reason we should not let any rebranded drivers in. -- Mike Perez On Wed, Jun 3, 2015 at 10:32 AM, Mike Perez thin...@gmail.com wrote: There are a couple of cases [1][2] I'm seeing where new Cinder volume drivers for Liberty are rebranding other volume drivers. This involves inheriting off another volume driver's class(es) and providing some config options to set the backend name, etc. Two problems: 1) There is a thought of no CI [3] is needed, since you're using another vendor's driver code which does have a CI. 2) IMO another way of satisfying a check mark of being OpenStack supported and disappearing from the community. What gain does OpenStack get from these kind of drivers? Discuss. [1] - https://review.openstack.org/#/c/187853/ [2] - https://review.openstack.org/#/c/187707/4 [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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][horizon] Making a dashboard for Magnum - need a vote from the core team
Jason, I will definitely weigh all feedback on this. I’m interested in guidance from anyone taking an interest in this subject. Thanks, Adrian On Jun 4, 2015, at 1:55 PM, Jason Rist jr...@redhat.com wrote: On 06/04/2015 11:58 AM, Steven Dake (stdake) wrote: Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. 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 I am interested in helping as well. In my experience, #1 works best, but I'm not a core, so I'm not sure my wisdom is counted here. -J -- Jason E. Rist Senior Software Engineer OpenStack Infrastructure Integration Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/identi.ca: knowncitizen __ OpenStack Development Mailing 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] L3 agent rescheduling issue
After trying to reproduce this, I'm suspecting that the issue is actually on the server side from failing to drain the agent report state queue in time. I set the report_interval to 1 second on the agent and added a logging statement and I see a report every 1 second even when sync_routers is taking a really long time. On Thu, Jun 4, 2015 at 11:52 AM, Carl Baldwin c...@ecbaldwin.net wrote: Ann, Thanks for bringing this up. It has been on the shelf for a while now. Carl On Thu, Jun 4, 2015 at 8:54 AM, Salvatore Orlando sorla...@nicira.com wrote: One reason for not sending the heartbeat from a separate greenthread could be that the agent is already doing it [1]. The current proposed patch addresses the issue blindly - that is to say before declaring an agent dead let's wait for some more time because it could be stuck doing stuff. In that case I would probably make the multiplier (currently 2x) configurable. The reason for which state report does not occur is probably that both it and the resync procedure are periodic tasks. If I got it right they're both executed as eventlet greenthreads but one at a time. Perhaps then adding an initial delay to the full sync task might ensure the first thing an agent does when it comes up is sending a heartbeat to the server? On the other hand, while doing the initial full resync, is the agent able to process updates? If not perhaps it makes sense to have it down until it finishes synchronisation. Yes, it can! The agent prioritizes updates from RPC over full resync activities. I wonder if the agent should check how long it has been since its last state report each time it finishes processing an update for a router. It normally doesn't take very long (relatively) to process an update to a single router. I still would like to know why the thread to report state is being starved. Anyone have any insight on this? I thought that with all the system calls, the greenthreads would yield often. There must be something I don't understand about it. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Standard way to indicate a partial blueprint implementation?
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 a small number of projects reveals at least the following formats in use: partial blueprint: x Implements: partial blueprint x Implements: partial-blueprint x Partial-Blueprint: x part of blueprint x partial blueprint x Implements: blueprint x (partial) Partially implements: blueprint x Partially Implements: blueprint x Partially-Implements: blueprint x Partial implements blueprint x Partially-Implements-Blueprint: x Part of blueprint x Partial-implements: blueprint x Partial-Implements: blueprint x partially implement: blueprint x No guidance is available on the wiki page.[2] Clearly the regex doesn't care so long as it sees the word blueprint followed by the blueprint name. 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 I do think it should have a colon so that it fits the format of the rest of the sign-off stanza, I don't think it should have any spaces before the colon for the same reason, and ideally it would have 'Implements' in there somewhere for consistency. Sahara folks have documented a standard,[3] but it fails on some of those criteria and in any event they haven't actually been following it. Can we agree on and document a standard way of doing this? Yes, someone -1'd my patch for this. How did you guess? cheers, Zane. [1] http://lists.openstack.org/pipermail/openstack-dev/2013-August/012945.html [2] https://wiki.openstack.org/wiki/GitCommitMessages [3] https://wiki.openstack.org/wiki/Sahara/GitCommits __ OpenStack Development Mailing 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][horizon] Making a dashboard for Magnum - need a vote from the core team
Thanks for the details Brad! I would also be interested in helping out with the work. From: Bradley Jones (bradjone) bradj...@cisco.commailto:bradj...@cisco.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, June 4, 2015 at 12:59 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team It’s difficult to put a quantifiable figure on how big a work item this is but I can try to give an overview of the steps required. The first step will be to extend the Horizon API to include CRUD operations that we need to perform with Magnum. Assuming that there are no issues here and API changes/additions are not required at this point, we can begin to flesh out how we would like the UI to look. We will aim to reduce the amount of Magnum specific UI code that will need to be maintained by reusing components from Horizon. This will also speed up the development significantly. In version 1 of Magnum UI a user should be able to perform all normal interactions with Magnum through the UI with no need for interaction with the python client. Future versions of Magnum UI would include admin specific views and any additional Magnum specific UI components we may want to add (maybe some visualisations). That is a brief overview of my vision for this effort and I believe that version 1 should comfortably be achievable this release cycle. Thanks, Brad Jones On 4 Jun 2015, at 19:49, Brad Topol bto...@us.ibm.commailto:bto...@us.ibm.com wrote: How big a work item is this? Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.commailto:bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From:Thai Q Tran/Silicon Valley/IBM@IBMUS To:OpenStack Development Mailing List \(not for usage questions\) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date:06/04/2015 02:20 PM Subject:Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team I am interested but not sure how much time I have this release cycle. I can take on a more hands-off approach and help review to make sure that magnum-ui is align with future horizon directions. -Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: - To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org From: Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com Date: 06/04/2015 11:03AM Subject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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.orgmailto: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.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
Steve, Thanks for raising this. I am definitely looking forward to a UI effort for Magnum, and will be happy to decide based on community input about how best to organize this. I’d also like direct input from those contributors who plan to work on this to take those individual preferences into account. If you are not comfortable voicing your concern on the ML, then you may contact me individually, and I will post a summary based on any consensus we form as a team. Adrian On Jun 4, 2015, at 3:35 PM, Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: Hongbin, I hadn’t thought of that, even though it seems obvious ;) We can absolutely do that. I almost like this option better then #1 but I don’t want the ui folks to feel like second class citizens. This goes back to the trust the ui developers to not review things they know not about :) Bradley, How are other OpenStack projects handling the UI teams which clearly have a totally different specialty than the typical core team for a project with the Horizon big tent changes? Regards -steve From: Hongbin Lu hongbin...@huawei.commailto:hongbin...@huawei.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, June 4, 2015 at 1:30 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Could we have a new group magnum-ui-core and include magnum-core as a subgroup, like the heat-coe-tempalte-core group. Thanks, Hongbin From: Steven Dake (stdake) [mailto:std...@cisco.com] Sent: June-04-15 1:58 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [packaging] Adding packaging as an OpenStack project
Hi Clint, Thanks for your contribution to this thread. On 06/04/2015 10:35 PM, Clint Adams wrote: On Wed, Jun 03, 2015 at 04:30:17PM -0400, Sean Dague wrote: The closer we can get logic about what a service should look like on disk back into that service itself, the less work duplicated by any of the installers, and the more common OpenStack envs would be. The fact that every installer / package needs to copy in a bunch of etc files (because the python packages don't do it) has always seemed rather odd to me. I agree with this, and given the disparate and seemingly contradictory goals driving these discussions, I think it will be exceedingly difficult to make everyone happy. I don't think anyone involved in the packaging of OpenStack has expressed disparity or contradiction. Quite the opposite: it is my strong opinion that all parties involved are on the same page. So here's my suggestion: 1. Maintain all important data for packaging as first-class members of the respective repositories. Initscripts, systemd service files, licensing (SPDX?), and so on should be in the master branch of each project. Are you here saying we should move startup scripts upstream, and not on the packaging repos? If so, that's a bad idea. Let me explain. The init scripts used to be hard to maintain because they were many, but since Debian Ubuntu are using automatic generation out of a tiny template (with sysv-rc, systemd and upstart all supported), this is a problem solved. If individual projects are getting into the business of publishing their own startup scripts, I doubt that we would even use them, because having a central place to patch all of the startup scripts at once (ie: openstack-pkg-tools) is much better than having to maintain each and every startup script by hand. As for the licensing, I agree here. I have multiple times express my opinion about it: the project as a hole needs to make some progress, as it's nearly impossible for downstream distributions to second guess who is the copyright holders (please pay attention: copyright holders and licensing are 2 separate things...). Though SPDX?!? Do you know the famous quote (Jay Pipes) Get your dirty XML out of my Json ? :) And there's also the fact that Debian uses a different parseable format. Not sure what the RPM folks use, but I suppose that's embedded in a .spec file. Also, all of OpenStack is mostly using the Apache-2.0 license, the licensing issues are with (build-)dependencies, and that, we can't solve it. Just enough glue should be present such that functional packaging can be programmatically generated from HEAD with debdry or similar tooling, and this is how test jobs should operate (f.ex.: run debdry, mangle version number to something unique, build package in chroot or equivalent, store output for use in other testing). I already use pkgos-debpypi (from openstack-pkg-tools) to automate a big chunk of the Python module packaging. Though the automated thing can only drive you so far. It wont fix missing dependencies in requirement.txt, wrong lower bounds, SSLv3 removal related issues, and all of this kind of issues which we constantly need to address to make sure all unit tests are passing. The thing is, unit functional tests in OpenStack are designed for Devstack. I supposed you already saw the It worked on Devstack XKCD t-shirt... Well, I'm sure all package maintainers of OpenStack have this in mind every day! :) As you are a DD, you know it too: getting a correct debian/copyright also represent some work, which cannot be automated, or the FTP masters will really hate you. :P Plus there's also the fact that sometimes, distributions don't use the matching versions. For example, Debian Jessie was released with Django 1.7 and OpenStack Icehouse, and I had to work on patching Horizon to make it work with it (at the time, Horizon didn't work with something higher than 1.6). The same thing happened with SQLAlchemy. This has slowed down a little bit over the years, but we also used to spend most of our time simply packaging new dependencies. We already have a big amount of redundancy (alembic vs sqlalchemy-migrate, WSGI frameworks, nose vs testr, pymysql vs mysqlclient vs mysql-python, you name it...). And each new project, with its specificities, bring new dependencies. I used to say that 80% of the packaging work is spent there: packaging new stuff. These days, it has a bit shifted to packaging oslo and client libs, which is a good thing (as they are respecting a standard, so we have less surprise). Though what actually represent an OpenStack release has grown bigger. After Jessie was released, uploading all of Kilo to Sid took me about 3 or 4 days, and maybe about the same amount of time to upload it to the official Jessie backports (all done in dependency order, with as few dependency breakage as possible...). I really hope that the effort on having a gate on the lower bounds of our
Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
From a quick look around there doesn’t seem to be a consensus on how to deal with UI teams, some projects seem to use just the main projects core team (group based policy ui), others use a mix of the project core team and the Horizon core team (monasca-ui) and in the case of tuskar-ui they use just the Horizon core team. I can’t find a case of another project having a dedicated ui-core team but as I say it was a quick look through the project config acls so I may have missed some. My two cents are that it is important that the people working on this effort have some level of control over the code base in order for things to progress quickly and to that end either approach #1, #2 or Hongbin’s suggestions achieves that goal. So either of the options work for me from that point of view and the decision really has to come down to what will work best in getting current Magnum folks participating in all aspects of the ui design, implementation and particularly reviewing. It is also important to have Horizon cores participate in reviews to ensure that we don’t diverge too much from upstream changes in Horizon, it sounds like we already have that commitment for reviews from David and Thai so thanks guys :) Brad Jones On 4 Jun 2015, at 21:35, Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: Hongbin, I hadn’t thought of that, even though it seems obvious ;) We can absolutely do that. I almost like this option better then #1 but I don’t want the ui folks to feel like second class citizens. This goes back to the trust the ui developers to not review things they know not about :) Bradley, How are other OpenStack projects handling the UI teams which clearly have a totally different specialty than the typical core team for a project with the Horizon big tent changes? Regards -steve From: Hongbin Lu hongbin...@huawei.commailto:hongbin...@huawei.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, June 4, 2015 at 1:30 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Could we have a new group magnum-ui-core and include magnum-core as a subgroup, like the heat-coe-tempalte-core group. Thanks, Hongbin From: Steven Dake (stdake) [mailto:std...@cisco.com] Sent: June-04-15 1:58 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation
In Juno I tried adding a user in Domain A to group in Domain B. That currently is not supported. Would be very handy though. We're getting a ways from the original part of the thread, so I may have lost some context, but I think the original question was, if barbarian can add group names to their resource acls. Since two administrative domains can issue the same group name, its not safe I believe. Simply ensuring the group name is associated with a user and the domain for the user matches the domain for the group wouldn't work because someone with control of their own domain can just make a user and give them the group with the name they want and come take your credentials. What may be safe is for the barbican ACL to contain the group_id if they are uniqueue across all domains, or take a domain_id group_name pair for the acl. Thanks, Kevin From: Dolph Mathews [dolph.math...@gmail.com] Sent: Thursday, June 04, 2015 1:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group- in token validation Problem! In writing a spec for this ( https://review.openstack.org/#/c/188564/ ), I remembered that groups are domain-specific entities, which complicates the problem of providing X-Group-Names via middleware. The problem is that we can't simply expose X-Group-Names to underlying services without either A) making a well-documented assumption about the ONE owning domain scope of ALL included groups, B) passing significantly more data to underlying services than just a list of names (a domain scope for every group), C) passing only globally-unique group IDs (services would then have to retrieve additional details about each from from keystone if they so cared). Option A) More specifically, keystone could opt to enumerate the groups that belong to the same domain as the user. In this case, it'd probably make more sense from an API perspective if the groups enumeration were part of the user resources in the token response body (the user object already has a containing domain ID. That means that IF a user were to be assigned a group membership in another domain (assuming we didn't move to disallowing that behavior at some point), then it would have to be excluded from this list. If that were true, then I'd also follow that X-Group-Names become X-User-Group-Names, so that it might be more clear that they belong to the X-User-Domain-*. Option B) This is probably the most complex solution, but also the most explicit. I have no idea how this interface would look in terms of headers using current conventions. If we're going to break conventions, then I'd want to pass a id+domain_id+name for each group reference. So, rather than including a list of names AND a list of IDs, we'd have some terribly encoded list of group objects (I'm not sure what the HTTP convention is on this sort of use case, and hoping someone can illustrate a better solution given the representation below): X-Groups: id%3D123%2Cdomain_id%3D456%2Cname%3Dabc,id%3D789%2Cdomain_id%3D357%2Cname%3Ddef Option C) Federated tokens would actually require solution (C) today because they only include group IDs, not names. But the group enumeration in federated tokens was also only intended to be consumed by keystone, so that's not really an issue for that one use case. But option (C) would mean there are no X-Group-Names passed to services, just X-Group-Ids. I'm guessing this won't provide the user experience that Barbican is looking for? I'm leaning towards solution (A), but curious if that'll work for Barbican and/or if anyone has an idea that I'm overlooking. On Thu, Jun 4, 2015 at 8:18 AM, Dolph Mathews dolph.math...@gmail.commailto:dolph.math...@gmail.com wrote: To clarify: we already have to include the groups produced as a result of federation mapping **in the payload** of Fernet tokens so that scoped tokens can be created later: https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/token/providers/fernet/token_formatters.py#L523 These are OpenStack group IDs, so it's up to the deployer to keep those under control to keep Fernet token sizes down. It's the only place in the current Fernet implementation that's (somewhat alarmingly) unbounded in the real world. But we do **not** have a use case to add groups to *all* Fernet payloads: only to token creation validation responses. On Thu, Jun 4, 2015 at 2:36 AM, Morgan Fainberg morgan.fainb...@gmail.commailto:morgan.fainb...@gmail.com wrote: For Fernet, the groups would only be populated on validate as Dolph outlined. They would not be added to the core payload. We do not want to expand the payload in this manner. --Morgan Sent via mobile On Jun 3, 2015, at 21:51, Lance Bragstad lbrags...@gmail.commailto:lbrags...@gmail.com wrote: I feel if we allowed group ids to be an
Re: [openstack-dev] [Neutron] L3 agent rescheduling issue
I doubt it's a server side issue. Usually there are plenty of rpc workers to drain much higher amount of rpc messages going from agents. So the issue could be in 'fairness' on L3 agent side. But from my observations it was more an issue of DHCP agent than L3 agent due to difference in resource processing. Thanks, Eugene. On Thu, Jun 4, 2015 at 4:29 PM, Itsuro ODA o...@valinux.co.jp wrote: Hi, After trying to reproduce this, I'm suspecting that the issue is actually on the server side from failing to drain the agent report state queue in time. I have seen before. I thought the senario at that time as follows. * a lot of create/update resource API issued * rpc_conn_pool_size pool exhausted for sending notify and blocked farther sending side of RPC. * rpc_thread_pool_size pool exhausted by waiting rpc_conn_pool_size pool for replying RPC. * receiving state_report is blocked because rpc_thread_pool_size pool exhausted. Thanks Itsuro Oda On Thu, 4 Jun 2015 14:20:33 -0700 Kevin Benton blak...@gmail.com wrote: After trying to reproduce this, I'm suspecting that the issue is actually on the server side from failing to drain the agent report state queue in time. I set the report_interval to 1 second on the agent and added a logging statement and I see a report every 1 second even when sync_routers is taking a really long time. On Thu, Jun 4, 2015 at 11:52 AM, Carl Baldwin c...@ecbaldwin.net wrote: Ann, Thanks for bringing this up. It has been on the shelf for a while now. Carl On Thu, Jun 4, 2015 at 8:54 AM, Salvatore Orlando sorla...@nicira.com wrote: One reason for not sending the heartbeat from a separate greenthread could be that the agent is already doing it [1]. The current proposed patch addresses the issue blindly - that is to say before declaring an agent dead let's wait for some more time because it could be stuck doing stuff. In that case I would probably make the multiplier (currently 2x) configurable. The reason for which state report does not occur is probably that both it and the resync procedure are periodic tasks. If I got it right they're both executed as eventlet greenthreads but one at a time. Perhaps then adding an initial delay to the full sync task might ensure the first thing an agent does when it comes up is sending a heartbeat to the server? On the other hand, while doing the initial full resync, is the agent able to process updates? If not perhaps it makes sense to have it down until it finishes synchronisation. Yes, it can! The agent prioritizes updates from RPC over full resync activities. I wonder if the agent should check how long it has been since its last state report each time it finishes processing an update for a router. It normally doesn't take very long (relatively) to process an update to a single router. I still would like to know why the thread to report state is being starved. Anyone have any insight on this? I thought that with all the system calls, the greenthreads would yield often. There must be something I don't understand about it. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton -- Itsuro ODA o...@valinux.co.jp __ OpenStack Development Mailing 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] [fuel] bp updates spec maintenance
Since the meeting was closed prior to having a discussion for this topic, I will post my notes here as well. I will start updating some of the BP's that have landed in 6.1 to reflect their current status There are a number of specs open for BP's that have code landed. We will merge the current revisions of theses specs, if there are any other issues, or revisions we will need to open a new CR for it and likely on 7.0 For specs open that didn't make 6.1. I will push revisions to move them to 7.0 For specs that landed that code didn't make 6.1, I will create reviews for moving them to 7.0 Lastly, I will start to update bp's that are already planned to target to 7.0. If you have something that should be targeted please raise it on the ML. __ OpenStack Development Mailing 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] Dynamic Policy for Access Control Subteam Meeting
On 06/04/2015 01:03 PM, Adam Young wrote: On 06/04/2015 09:40 AM, Sean Dague wrote: So I feel like I understand the high level dynamic policy end game. I feel like what I'm proposing for policy engine with encoded defaults doesn't negatively impact that. I feel there is a middle chunk where perhaps we've got different concerns or different dragons that we see, and are mostly talking past each other. And I don't know how to bridge that. All the keystone specs I've dived into definitely assume a level of understanding of keystone internals and culture that aren't obvious from the outside. Policy is not currently designed to be additive; let's take the Nova rule|| || ||get_network: rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc|| || |FROM http://git.openstack.org/cgit/openstack/neutron/tree/etc/policy.json#n27| || |This pulls in | external: field:networks:router:external=True, | Now, we have a single JSON file that implements this. Lets say that you ended up coding exactly this rule in python. What would that mean? Either you make some way of initializing oslo.policy from a Python object, or you enforce outside of Oslo.policy (custom nova Code). If it is custom code, you have to say run oslo or run my logic everywhere...you can see that this approach leads to fragementation of policy enforcement. So, instead, you go the initialize oslo from Python. We currentl have the idea of multiple policy files in the directory, so you just treat the Python code as a file with either the lowest or highest ABC order, depending. Now, each policy file gets read, and the rules are a hashtable, keyed by the rule name. So both get_network and external are keys that get read in. If 'overwrite' is set, it will only process the last set of rules (replaces all rules) but I think what we want here is just update: http://git.openstack.org/cgit/openstack/oslo.policy/tree/oslo_policy/policy.py#n361 Which would mix together the existing rules with the rules from the policy files. So...what would your intention be with hardcoding the policy in Nova? That your rule gets overwritten with the rule that comes from the centralized policy store, or that you rule gets executed in addition to the rule from central? Neither are going to get you what you want, which is Make sure you can't break Nova by changing Policy It gets overwritten by the central store. And you are wrong, that gives me what I want, because we can emit a WARNING in the logs if the patch is something crazy. The operators will see it, and be able to fix it later. I'm not trying to prevent people from changing their policy in crazy ways. I'm trying to build in some safety net where we can detect it's kind of a bad idea and emit that information a place that Operators can see and sort out later, instead of pulling their hair out. But you can only do that if you have encoded what's the default, plus annotations about ways that changing the default are unwise. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
I’m really keen to take on this effort, to echo what Steve said I think adding a dashboard component to Magnum is critical in adoption and delivering good usability to all. Thanks, Brad Jones On 4 Jun 2015, at 18:58, Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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] Dynamic Policy for Access Control Subteam Meeting
I am confused about the goal. Are we saying we should allow operators to modify the access policies but then warn them if they do? But if operators *intend* to modify the policies in order to fit their compliance/security needs, which is likely the case, aren't the warning messages confusing and counterintuitive? Guang -Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: Thursday, June 04, 2015 10:16 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting On 06/04/2015 01:03 PM, Adam Young wrote: On 06/04/2015 09:40 AM, Sean Dague wrote: So I feel like I understand the high level dynamic policy end game. I feel like what I'm proposing for policy engine with encoded defaults doesn't negatively impact that. I feel there is a middle chunk where perhaps we've got different concerns or different dragons that we see, and are mostly talking past each other. And I don't know how to bridge that. All the keystone specs I've dived into definitely assume a level of understanding of keystone internals and culture that aren't obvious from the outside. Policy is not currently designed to be additive; let's take the Nova rule|| || ||get_network: rule:admin_or_owner or rule:shared or rule:external ||or rule:context_is_advsvc|| || |FROM http://git.openstack.org/cgit/openstack/neutron/tree/etc/policy.json#n 27| || |This pulls in | external: field:networks:router:external=True, | Now, we have a single JSON file that implements this. Lets say that you ended up coding exactly this rule in python. What would that mean? Either you make some way of initializing oslo.policy from a Python object, or you enforce outside of Oslo.policy (custom nova Code). If it is custom code, you have to say run oslo or run my logic everywhere...you can see that this approach leads to fragementation of policy enforcement. So, instead, you go the initialize oslo from Python. We currentl have the idea of multiple policy files in the directory, so you just treat the Python code as a file with either the lowest or highest ABC order, depending. Now, each policy file gets read, and the rules are a hashtable, keyed by the rule name. So both get_network and external are keys that get read in. If 'overwrite' is set, it will only process the last set of rules (replaces all rules) but I think what we want here is just update: http://git.openstack.org/cgit/openstack/oslo.policy/tree/oslo_policy/p olicy.py#n361 Which would mix together the existing rules with the rules from the policy files. So...what would your intention be with hardcoding the policy in Nova? That your rule gets overwritten with the rule that comes from the centralized policy store, or that you rule gets executed in addition to the rule from central? Neither are going to get you what you want, which is Make sure you can't break Nova by changing Policy It gets overwritten by the central store. And you are wrong, that gives me what I want, because we can emit a WARNING in the logs if the patch is something crazy. The operators will see it, and be able to fix it later. I'm not trying to prevent people from changing their policy in crazy ways. I'm trying to build in some safety net where we can detect it's kind of a bad idea and emit that information a place that Operators can see and sort out later, instead of pulling their hair out. But you can only do that if you have encoded what's the default, plus annotations about ways that changing the default are unwise. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. 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][horizon] Making a dashboard for Magnum - need a vote from the core team
I am interested but not sure how much time I have this release cycle. I can take on a more hands-off approach and help review to make sure that magnum-ui is align with future horizon directions.-"Steven Dake (stdake)" std...@cisco.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: "Steven Dake (stdake)" std...@cisco.comDate: 06/04/2015 11:03AMSubject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as how to get patches approved, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isnt large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -steve __OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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][horizon] Making a dashboard for Magnum - need a vote from the core team
+1 to single team -- dims On Thu, Jun 4, 2015 at 2:02 PM, Steven Dake (stdake) std...@cisco.com wrote: My vote is +1 for a unified core team for all Magnum development which in the future will include the magnum-ui repo, the python-magnumclient repo, the magnum repo, and the python-k8sclient repo. Regards -steve From: Steven Dake std...@cisco.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Thursday, June 4, 2015 at 10:58 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. 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 -- 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] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
Same here. I’m definitely interested in helping out but not sure how much time I can commit to. Will most definitely help out with reviews and other decision making process to help ensure magnum-ui is implemented and in the correct direction relating to Horizon. From: Thai Q Tran tqt...@us.ibm.commailto:tqt...@us.ibm.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, June 4, 2015 at 2:07 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team I am interested but not sure how much time I have this release cycle. I can take on a more hands-off approach and help review to make sure that magnum-ui is align with future horizon directions. -Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com wrote: - To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org From: Steven Dake (stdake) std...@cisco.commailto:std...@cisco.com Date: 06/04/2015 11:03AM Subject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.orgmailto: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] [glance] How to deal with aborted image read?
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 stuck with an open file descriptor, which meant that the image consumed space even after it was deleted. I have a crude fix for nova at https://review.openstack.org/#/c/188179/; which basically continues to read the image even though it can't write it. That seems less than ideal for large images though. Is there a better way to do this? Is there a way for nova to indicate to glance that it's no longer interested in that image and glance can close the file? If I've followed this correctly, on the glance side I think the code in question is ultimately glance_store._drivers.filesystem.ChunkedFile.__iter__(). Actually, to be honest, I was quite confused by the email :P Correct me if I still didn't understand what you're asking. You ran out of space on the Nova side while downloading the image and there's a file descriptor leak somewhere either in that lovely (sarcasm) glance wrapper or in glanceclient. The first part is correct, but the file descriptor is actually held by glance-api. Just by reading your email and glancing your patch, I believe the bug might be in glanceclient but I'd need to five into this. The piece of code you'll need to look into is[0]. glance_store is just used server side. If that's what you meant - glance is keeping the request and the ChunkedFile around - then yes, glance_store is the place to look into. [0] https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v1/images.py#L152 I believe what's happening is that the ChunkedFile code opens the file and creates the iterator. Nova then starts iterating through the file. If nova (or any other user of glance) iterates all the way through the file then the ChunkedFile code will hit the finally clause in __iter__() and close the file descriptor. If nova starts iterating through the file and then stops (due to running out of room, for example), the ChunkedFile.__iter__() routine is left with an open file descriptor. At this point deleting the image will not actually free up any space. I'm not a glance guy so I could be wrong about the code. The externally-visible data are: 1) glance-api is holding an open file descriptor to a deleted image file 2) If I kill glance-api the disk space is freed up. 3) If I modify nova to always finish iterating through the file the problem doesn't occur in the first place. Chris __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [horizon] Prioritize tests over JSCS
Hi folks,I know a lot of people are tackling the JSCS stuff, and thats really great. But it would be extra nice to see JSCS stuff along with JP's guidelines in your patches. Furthermore, if the file you are working on doesn't have an accompanying spec file, please make sure that the tests for it exists. If it is not there, please prioritize and spend some time reviewing patches with the tests you need, or create a spec file and get that merge first.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] [Neutron] L3 agent rescheduling issue
- Original Message - One reason for not sending the heartbeat from a separate greenthread could be that the agent is already doing it [1]. The current proposed patch addresses the issue blindly - that is to say before declaring an agent dead let's wait for some more time because it could be stuck doing stuff. In that case I would probably make the multiplier (currently 2x) configurable. The reason for which state report does not occur is probably that both it and the resync procedure are periodic tasks. If I got it right they're both executed as eventlet greenthreads but one at a time. Perhaps then adding an initial delay to the full sync task might ensure the first thing an agent does when it comes up is sending a heartbeat to the server? There's a patch that is related to this issue: https://review.openstack.org/#/c/186584/ I made a comment there where, at least to me, it makes a lot of sense to insert a report_state call in the after_start method, right after the agent initializes but before it performs the first full sync. So, right here before line 560: https://github.com/openstack/neutron/blob/master/neutron/agent/l3/agent.py#L560 That should help *some* of the issues discussed in this thread, but not all. On the other hand, while doing the initial full resync, is the agent able to process updates? If not perhaps it makes sense to have it down until it finishes synchronisation. Salvatore [1] http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/l3/agent.py#n587 On 4 June 2015 at 16:16, Kevin Benton blak...@gmail.com wrote: Why don't we put the agent heartbeat into a separate greenthread on the agent so it continues to send updates even when it's busy processing changes? On Jun 4, 2015 2:56 AM, Anna Kamyshnikova akamyshnik...@mirantis.com wrote: Hi, neutrons! Some time ago I discovered a bug for l3 agent rescheduling [1]. When there are a lot of resources and agent_down_time is not big enough neutron-server starts marking l3 agents as dead. The same issue has been discovered and fixed for DHCP-agents. I proposed a change similar to those that were done for DHCP-agents. [2] There is no unified opinion on this bug and proposed change, so I want to ask developers whether it worth to continue work on this patch or not. [1] - https://bugs.launchpad.net/neutron/+bug/1440761 [2] - https://review.openstack.org/171592 -- Regards, Ann Kamyshnikova Mirantis, Inc __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
My vote is +1 for a unified core team for all Magnum development which in the future will include the magnum-ui repo, the python-magnumclient repo, the magnum repo, and the python-k8sclient repo. Regards -steve From: Steven Dake std...@cisco.commailto:std...@cisco.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, June 4, 2015 at 10:58 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. 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] [Ironic] When to bump the microversion?
On 06/04/2015 10:14 AM, Devananda van der Veen wrote: On Jun 4, 2015 8:57 AM, Monty Taylor mord...@inaugust.com So, seriously - let's grow up and start telling people that they do not get to pick and choose user-visible feature sets. If they have an unholy obsession with a particular backend technology that does not allow a public feature of the API to work, then they are deploying a broken cloud and they need to fix it. So I just had dinner last night with a very large user of OpenStack (yes, they exist) whose single biggest request is that we stop differentiating in the API. To them, any difference in the usability / behavior / API between OpenStack deployment X and Y is a serious enough problem that it will have two effects: - vendor lock in - they stop using OpenStack And since avoiding single vendor lock in is important to them, well, really it has only one result. Tl;Dr; Monty is right. We MUST NOT vary the API or behaviour significantly or non-discoverably between clouds. Or we simply won't have users. If a vendor wants to differentiate themselves, what about having two sets of API endpoints? One that is full vanilla openstack with bog-standard behaviour, and one that has vendor-specific stuff in it? That way the end-users that want interop can just use the standard API and get common behaviour across clouds, while the end-users that want the special sauce and are willing to lock in to a vendor to get it can use the vendor-specific API. 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] [cinder] Rebranded Volume Drivers
On 06/03/2015 02:53 PM, Eric Harney wrote: On 06/03/2015 01:59 PM, John Griffith wrote: On Wed, Jun 3, 2015 at 11:32 AM, Mike Perez thin...@gmail.com wrote: There are a couple of cases [1][2] I'm seeing where new Cinder volume drivers for Liberty are rebranding other volume drivers. This involves inheriting off another volume driver's class(es) and providing some config options to set the backend name, etc. Two problems: 1) There is a thought of no CI [3] is needed, since you're using another vendor's driver code which does have a CI. 2) IMO another way of satisfying a check mark of being OpenStack supported and disappearing from the community. What gain does OpenStack get from these kind of drivers? Discuss. [1] - https://review.openstack.org/#/c/187853/ [2] - https://review.openstack.org/#/c/187707/4 [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers -- Mike Perez This case is interesting mostly because it's the same contractor submitting the driver for all the related platforms. Frankly I find the whole rebranding annoying, but there's certainly nothing really wrong with it, and well... why not, it's Open Source. What I do find annoying is the lack of give back; so this particular contributor has submitted a few drivers thus far (SCST, DotHill and some others IIRC), and now has three more proposed. This would be great except I personally have spent a very significant amount of time with this person helping with development, CI and understanding OpenStack and Cinder. To date, I don't see that he's provided a single code review (good or bad) or contributed anything back other than to his specific venture. Anyway... I think your point was for input on the two questions: For item '1': I guess as silly as it seems they should probably have 3'rd party CI. There are firmware differences etc that may actually change behaviors, or things my diverge, or maybe their code is screwed up and the inheritance doesn't work (doubtful). Given that part of the case made for CI was ensure that Cinder ships drivers that work, the case of backend behavior diverging over time from what originally worked with Cinder seems like a valid concern. We lose the ability to keep tabs on that for derived drivers without CI. Yes, it's just a business venture in this case (good or bad, not for me to decide). The fact is we don't discriminate or place a value on peoples contributions, and this shouldn't be any different. I think the best answer is follow same process for any driver and move on. This does point out that maybe OpenStack/Cinder has grown to a point where there are so many options and choices that it's time to think about changing some of the policies and ways we do things. In my opinion, OpenStack doesn't gain much in this particular case, which brings me back to; remove all drivers except the ref-impl and have them pip installable and on a certified list based on CI. Thanks, John The other issue I see with not requiring CI for derived drivers is that, inevitably, small changes will be made to the driver code, and we will find ourselves having to sort out how much change can happen before CI is then required. I don't know how to define that in a way that would be useful as a general policy. Eric __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev At first I wasn't too sure that requiring an additional CI for a derived driver made sense. The concerns raised, however, are compelling and I think that a CI should be required for rebranded drivers. It is inevitable that subtle differences will sneak in and we need to have CI in place to catch any failures that may also be introduced. Jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
Could we have a new group magnum-ui-core and include magnum-core as a subgroup, like the heat-coe-tempalte-core group. Thanks, Hongbin From: Steven Dake (stdake) [mailto:std...@cisco.com] Sent: June-04-15 1:58 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as how to get patches approved, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn't large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. 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] [Murano] Help needed with TOSCA support in Murano
undefined __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Help needed with TOSCA support in Murano
undefined __ OpenStack Development Mailing 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] Which middleware does keystone use for authentication and authorization?
Hi all, Does any one know which middleware does Openstack use to authenticate users in Keystone in Kilo release? I saw two middleware, one is in Keystone client, the other is an independent directory. I know the previous version, the middleware in keystone client is used, but in Kilo, I am not sure if they are still using the middleware in keystone client or the other. Anyone has any idea? Thanks! -- Best regards, Amy (Yun Zhang) __ OpenStack Development Mailing 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] L3 agent rescheduling issue
Is there a way to parallelize the period tasks? I wanted to go this route because I encountered cases where a bunch of routers would get scheduled to l3 agents and they would all hit the server nearly simultaneously with a sync routers task. This could result in thousands of routers and their floating IPs being retrieved, which would result in tens of thousands of SQL queries. During this time, the agents would time out and have all their routers rescheduled, leading to a downward spiral of doom. I spent a bunch of time optimizing the sync routers calls on the l3 side so it's hard to trigger this now, but I would be more comfortable if we didn't depend on sync routers taking less time than the agent down time. If we can have the heartbeats always running, it should solve both issues. On Jun 4, 2015 8:56 AM, Salvatore Orlando sorla...@nicira.com wrote: One reason for not sending the heartbeat from a separate greenthread could be that the agent is already doing it [1]. The current proposed patch addresses the issue blindly - that is to say before declaring an agent dead let's wait for some more time because it could be stuck doing stuff. In that case I would probably make the multiplier (currently 2x) configurable. The reason for which state report does not occur is probably that both it and the resync procedure are periodic tasks. If I got it right they're both executed as eventlet greenthreads but one at a time. Perhaps then adding an initial delay to the full sync task might ensure the first thing an agent does when it comes up is sending a heartbeat to the server? On the other hand, while doing the initial full resync, is the agent able to process updates? If not perhaps it makes sense to have it down until it finishes synchronisation. Salvatore [1] http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/l3/agent.py#n587 On 4 June 2015 at 16:16, Kevin Benton blak...@gmail.com wrote: Why don't we put the agent heartbeat into a separate greenthread on the agent so it continues to send updates even when it's busy processing changes? On Jun 4, 2015 2:56 AM, Anna Kamyshnikova akamyshnik...@mirantis.com wrote: Hi, neutrons! Some time ago I discovered a bug for l3 agent rescheduling [1]. When there are a lot of resources and agent_down_time is not big enough neutron-server starts marking l3 agents as dead. The same issue has been discovered and fixed for DHCP-agents. I proposed a change similar to those that were done for DHCP-agents. [2] There is no unified opinion on this bug and proposed change, so I want to ask developers whether it worth to continue work on this patch or not. [1] - https://bugs.launchpad.net/neutron/+bug/1440761 [2] - https://review.openstack.org/171592 -- Regards, Ann Kamyshnikova Mirantis, Inc __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] [puppet] stubs considered harmful in spec tests
Summary - In puppet module spec tests, do not use stubs, which means the method will be called 0 or more times. Instead, use expects, which means the method must be called exactly 1 time, or some other more fine grained expectation method stubber. Our puppet unit tests mostly use rspec, but use Mocha http://gofreerange.com/mocha/docs/index.html for object mocking and method stubbing. I have already run into several cases where the spec test result is misleading because stubs was used instead of expects, and I have spent a lot of time trying to figure out why a method was not called, because adding an expectation like provider.class.stubs(:openstack) .with('endpoint', 'list', '--quiet', '--format', 'csv', []) .returns('ID,Region,Service Name,Service Type,Enabled,Interface,URL 2b38d77363194018b2b9b07d7e6bdc13,RegionOne,keystone,identity,True,admin,http://127.0.0.1:5002/v3; 3097d316c19740b7bc866c5cb2d7998b,RegionOne,keystone,identity,True,internal,http://127.0.0.1:5001/v3; 3445dddcae1b4357888ee2a606ca1585,RegionOne,keystone,identity,True,public,http://127.0.0.1:5000/v3; ') implies that openstack endpoint list will be called. If at all possible, we should use an explicit expectation. For example, in the above case, use expects instead: provider.class.expects(:openstack) .with('endpoint', 'list', '--quiet', '--format', 'csv', []) .returns('ID,Region,Service Name,Service Type,Enabled,Interface,URL 2b38d77363194018b2b9b07d7e6bdc13,RegionOne,keystone,identity,True,admin,http://127.0.0.1:5002/v3; 3097d316c19740b7bc866c5cb2d7998b,RegionOne,keystone,identity,True,internal,http://127.0.0.1:5001/v3; 3445dddcae1b4357888ee2a606ca1585,RegionOne,keystone,identity,True,public,http://127.0.0.1:5000/v3; ') This means that openstack endpoint list must be called once, and only once. For odd cases where you want a method to be called some certain number of times, or to return different values each time it is called, the Expectation class http://gofreerange.com/mocha/docs/Mocha/Expectation.html should be used to modify the initial expectation. Unfortunately, I don't think we can just do a blanket s/stubs/expects/g in *_spec.rb, without incurring a lot of test failures. So perhaps we don't have to do this right away, but I think future code reviews should -1 any spec file that uses stubs without a strong justification. __ OpenStack Development Mailing 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] Why do we drop branches? (WAS: Re: Targeting icehouse-eol?)
We can do the opposite to avoid more and more ACLs: ALLOW push on some specific stable branches [access refs/heads/stable/kilo] push = allow group ***-stable-maint [access refs/heads/stable/juno] push = allow group ***-stable-maint BLOCK push on others stable branches [access refs/heads/stable/juno] push = block group Anonymous Users Cedric/ZZelle@IRC On Thu, Jun 4, 2015 at 6:15 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-04 16:23:12 +0200 (+0200), Ihar Hrachyshka wrote: 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. Why not just leaving them sitting there, marked read only? It becomes especially important now that we say that stable HEAD *is* a stable release. It's doable, but we'll need ACL changes applied to every project participating in this release model to reject new change submissions and prevent anyone from approving them on every branch which reaches its EOL date. These ACLs will also grow longer and longer over time as we need to add new sections for each EOL branch. Also, it seems to me like a feature if downstream consumers have to take notice and explicitly adjust their tooling to intentionally continue deploying a release for which we no longer provide support and security updates. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] Dynamic Policy for Access Control Subteam Meeting
On 06/04/2015 09:40 AM, Sean Dague wrote: So I feel like I understand the high level dynamic policy end game. I feel like what I'm proposing for policy engine with encoded defaults doesn't negatively impact that. I feel there is a middle chunk where perhaps we've got different concerns or different dragons that we see, and are mostly talking past each other. And I don't know how to bridge that. All the keystone specs I've dived into definitely assume a level of understanding of keystone internals and culture that aren't obvious from the outside. Policy is not currently designed to be additive; let's take the Nova rule|| || ||get_network: rule:admin_or_owner or rule:shared or rule:external or rule:context_is_advsvc|| || |FROM http://git.openstack.org/cgit/openstack/neutron/tree/etc/policy.json#n27| || |This pulls in | external: field:networks:router:external=True, | Now, we have a single JSON file that implements this. Lets say that you ended up coding exactly this rule in python. What would that mean? Either you make some way of initializing oslo.policy from a Python object, or you enforce outside of Oslo.policy (custom nova Code). If it is custom code, you have to say run oslo or run my logic everywhere...you can see that this approach leads to fragementation of policy enforcement. So, instead, you go the initialize oslo from Python. We currentl have the idea of multiple policy files in the directory, so you just treat the Python code as a file with either the lowest or highest ABC order, depending. Now, each policy file gets read, and the rules are a hashtable, keyed by the rule name. So both get_network and external are keys that get read in. If 'overwrite' is set, it will only process the last set of rules (replaces all rules) but I think what we want here is just update: http://git.openstack.org/cgit/openstack/oslo.policy/tree/oslo_policy/policy.py#n361 Which would mix together the existing rules with the rules from the policy files. So...what would your intention be with hardcoding the policy in Nova? That your rule gets overwritten with the rule that comes from the centralized policy store, or that you rule gets executed in addition to the rule from central? Neither are going to get you what you want, which is Make sure you can't break Nova by changing Policy | __ OpenStack Development Mailing 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] Proposing Assaf Muller for the Neutron Core Reviewer Team
Congrats! Well deserved On Thu, Jun 4, 2015 at 8:50 AM, Assaf Muller amul...@redhat.com wrote: Thank you. We have a lot of work ahead of us :) - Original Message - It's a been a week since I proposed this, with no objections. Welcome to the Neutron core reviewer team as the new QA Lieutenant Assaf! On Tue, Jun 2, 2015 at 12:35 PM, Maru Newby ma...@redhat.com wrote: +1 from me, long overdue! On May 28, 2015, at 9:42 AM, Kyle Mestery mest...@mestery.com wrote: Folks, I'd like to propose Assaf Muller to be a member of the Neutron core reviewer team. Assaf has been a long time contributor in Neutron, and he's also recently become my testing Lieutenant. His influence and knowledge in testing will be critical to the team in Liberty and beyond. In addition to that, he's done some fabulous work for Neutron around L3 HA and DVR. Assaf has become a trusted member of our community. His review stats place him in the pack with the rest of the Neutron core reviewers. I'd also like to take this time to remind everyone that reviewing code is a responsibility, in Neutron the same as other projects. And core reviewers are especially beholden to this responsibility. I'd also like to point out that +1/-1 reviews are very useful, and I encourage everyone to continue reviewing code even if you are not a core reviewer. Existing Neutron cores, please vote +1/-1 for the addition of Assaf to the core reviewer team. Thanks! Kyle [1] http://stackalytics.com/report/contribution/neutron-group/180 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] When to bump the microversion?
On 06/04/2015 11:27 AM, Dmitry Tantsur wrote: On 06/04/2015 05:03 PM, Sean Dague wrote: On 06/04/2015 10:50 AM, Dmitry Tantsur wrote: On 06/04/2015 04:40 PM, Ruby Loo wrote: Hi, In Kilo, we introduced microversions but it seems to be a work-in-progress. There is an effort now to add microversion into the API-WG's guidelines, to provide a consistent way of using microversions across OpenStack projects [1]. Specifically, in the context of this email, there is a proposed guideline for when to bump the microversion [2]. As I understand this guideline tells to bump microversion on every change which I strongly -1 as usual. Reason: it's bump for the sake of bump, without any direct benefit for users (no, API discoverability is not one, because microversion do not solve it). I'll post the same comment to the guideline. Backwards compatible API adds with no user signaling is a fallacy because it assumes the arrow of time flows only one way. If at version 1.5 you have a resource that is foo { bar: ... } And then you decide you want to add another attribute foo { bar: ... baz: ... } And you don't bump the version, you'll get a set of users that use a cloud with baz, and incorrectly assume that version 1.5 of the API means that baz will always be there. Except, there are lots of clouds out there, including ones that might be at the code commit before it was added. Because there are lots of deploys in the world, your users can effectively go back in time. So now your API definition for version 1.5 is: foo, may or may not contain baz, and there is no way of you knowing if it will until you try. good luck. Which is pretty aweful. Which is not very different from your definition. Version 1.5 contains feature xyz, unless it's disabled by the configuration or patched out downstream. Well, 1.4 can also contain the feature, if downstream backported it. So good luck again. The whole point of interop is you can't call it OpenStack if you are patching it downstream to break the upstream contract. Microversions are a contract. Downstream can hack code all they want, it's no longer OpenStack when they do. If they are ok with it, that's fine. But them taking OpenStack code and making something that's not OpenStack is beyond the scope of the problem here. This is about good actors, acting in good faith, to provide a consistent experience to application writers. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Proposing Assaf Muller for the Neutron Core Reviewer Team
Congrats Assaf ;) On Thu, Jun 4, 2015 at 9:35 PM, Somanchi Trinath trinath.soman...@freescale.com wrote: Congratulations Assaf J *From:* Jaume Devesa [mailto:devv...@gmail.com] *Sent:* Thursday, June 04, 2015 9:25 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [neutron] Proposing Assaf Muller for the Neutron Core Reviewer Team Congratulations Assaf!! On 4 June 2015 at 17:45, Paul Michali p...@michali.net wrote: +100 Great addition! Congratulations Assaf! On Thu, Jun 4, 2015 at 11:41 AM Miguel Lavalle mig...@mlavalle.com wrote: Congrats! Well deserved On Thu, Jun 4, 2015 at 8:50 AM, Assaf Muller amul...@redhat.com wrote: Thank you. We have a lot of work ahead of us :) - Original Message - It's a been a week since I proposed this, with no objections. Welcome to the Neutron core reviewer team as the new QA Lieutenant Assaf! On Tue, Jun 2, 2015 at 12:35 PM, Maru Newby ma...@redhat.com wrote: +1 from me, long overdue! On May 28, 2015, at 9:42 AM, Kyle Mestery mest...@mestery.com wrote: Folks, I'd like to propose Assaf Muller to be a member of the Neutron core reviewer team. Assaf has been a long time contributor in Neutron, and he's also recently become my testing Lieutenant. His influence and knowledge in testing will be critical to the team in Liberty and beyond. In addition to that, he's done some fabulous work for Neutron around L3 HA and DVR. Assaf has become a trusted member of our community. His review stats place him in the pack with the rest of the Neutron core reviewers. I'd also like to take this time to remind everyone that reviewing code is a responsibility, in Neutron the same as other projects. And core reviewers are especially beholden to this responsibility. I'd also like to point out that +1/-1 reviews are very useful, and I encourage everyone to continue reviewing code even if you are not a core reviewer. Existing Neutron cores, please vote +1/-1 for the addition of Assaf to the core reviewer team. Thanks! Kyle [1] http://stackalytics.com/report/contribution/neutron-group/180 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Jaume Devesa Software Engineer at Midokura __ OpenStack Development Mailing 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] [infra][third-party] Common-CI Virtual Sprint
Hi, It was nice to meet many of you at the Vancouver Infra Working Session. Quite a bit of progress was made finding owners for some of the common-ci refactoring work [1] and puppet testing work. A few patches were proposed, reviewed, and some merged! As we continue the effort over the coming weeks, I thought it would be helpful to schedule a virtual sprint to complete the remaining tasks. GOAL: By the end of the sprint, we should be able to set up a 3rd party CI system using the same puppet components that the OpenStack infrastructure team is using in its production CI system. I proposed this in Tuesday's Infra meeting [1] there was general consensus that this would be valuable (if clear goals are documented) and that July 8 9 are good dates. (After the US Canada July 1st and 4th holidays, not on Tuesday, and not near a Liberty Milestone) I would like to get comments from a broader audience on the goals and dates. You can show interest by adding your name to the etherpad [3]. Thank you, Ramy irc: asselin [1] http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html [2] http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-06-02-19.01.html [3] https://etherpad.openstack.org/p/common-ci-sprint __ OpenStack Development Mailing 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] Dynamic Policy for Access Control Subteam Meeting
On 06/04/2015 09:40 AM, Sean Dague wrote: Is there some secret dragon I'm missing here? No. But it is a significant bit of coding to do; you would need to crawl every API and make sure you hit every code path that could enforce policy. Um, I don't understand that. I'm saying that you'd GEThttps://my.nova.api.server/policy; What would that return? The default policy.json file that you ship? Or would it be auto-generated based on enforcement in the code? If it is auto-generated, you need to crawl the code, somehow, to generate that. If it is policy.json, then you are not implementing the defaults in code, just returning the one managed by the CMS and deployed with the Service endpoint. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Help needed with TOSCA support in Murano
Hi Gosha, Sorry, not sure why my last message was delivered as undefined. Anyways, thanks for pointing me to those materials. I have a feeling though that due to the nature of Heat-Translator we would need to deal with HOT based templates and not MuranoPL. Regards, - Vahid Hashemian, Ph.D. Advisory Software Engineer, IBM Cloud Labs -Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: - To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org From: Georgy Okrokvertskhov gokrokvertsk...@mirantis.com Date: 06/03/2015 03:26PM Subject: Re: [openstack-dev] [Murano] Help needed with TOSCA support in Murano Hi, Murano documentation about all internals is here: http://murano.readthedocs.org/en/latest/ You probably need to take some example applications from here: https://github.com/openstack/murano-apps Take something simple like Tomcat and PostgresSQL. You will need to have an image for Ubuntu/Debian with murano agent. It could be downloaded form here: http://apps.openstack.org/#tab=glance-imagesasset=Debian%208%20x64%20(pre-installed%20murano-agent) Thanks Gosha On Wed, Jun 3, 2015 at 2:21 PM, Vahid S Hashemian vahidhashem...@us.ibm.com wrote: Thanks Gosha. That's right. I have been using HOT based applications. I have not used workflows before and need to dig into them. If you have any pointers on how to go about workflows please share them with me. Thanks. Regards, - Vahid Hashemian, Ph.D. Advisory Software Engineer, IBM Cloud Labs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Help needed with TOSCA support in Murano
undefined __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] When to bump the microversion?
On 06/04/2015 11:27 AM, Dmitry Tantsur wrote: On 06/04/2015 05:03 PM, Sean Dague wrote: On 06/04/2015 10:50 AM, Dmitry Tantsur wrote: On 06/04/2015 04:40 PM, Ruby Loo wrote: Hi, In Kilo, we introduced microversions but it seems to be a work-in-progress. There is an effort now to add microversion into the API-WG's guidelines, to provide a consistent way of using microversions across OpenStack projects [1]. Specifically, in the context of this email, there is a proposed guideline for when to bump the microversion [2]. As I understand this guideline tells to bump microversion on every change which I strongly -1 as usual. Reason: it's bump for the sake of bump, without any direct benefit for users (no, API discoverability is not one, because microversion do not solve it). I'll post the same comment to the guideline. Backwards compatible API adds with no user signaling is a fallacy because it assumes the arrow of time flows only one way. If at version 1.5 you have a resource that is foo { bar: ... } And then you decide you want to add another attribute foo { bar: ... baz: ... } And you don't bump the version, you'll get a set of users that use a cloud with baz, and incorrectly assume that version 1.5 of the API means that baz will always be there. Except, there are lots of clouds out there, including ones that might be at the code commit before it was added. Because there are lots of deploys in the world, your users can effectively go back in time. So now your API definition for version 1.5 is: foo, may or may not contain baz, and there is no way of you knowing if it will until you try. good luck. Which is pretty aweful. Which is not very different from your definition. Version 1.5 contains feature xyz, unless it's disabled by the configuration or patched out downstream. Well, 1.4 can also contain the feature, if downstream backported it. So good luck again. If you allow to group features under one microversion, that becomes even worse - you can have deployment that got microversion only partially. For example, that's what I would call API discoverability: $ ironic has-capability foobar true and that's how it would play with versioning: $ ironic --ironic-api-version 1.2 has-capability foobar false $ ironic --ironic-api-version 1.6 has-capability foobar true On the contrary, the only thing that microversion tells me is that the server installation is based on a particular upstream commit. To me these are orthogonal problems, and I believe they should be solved differently. Our disagreement is due to seeing them as one problem. We should stop doing this everywhere in OpenStack. It is the absolute worst experience ever. Stop allowing people to disable features with config. there is literally no user on the face of the planet for whom this is a positive thing. 1.5 should mean that your server has Set(A) of features. 1.6 should mean Set(A+B) - etc. There should be NO VARIATION and any variation on that should basically mean that the cloud in question is undeniably broken. I understand that vendors and operators keep wanting to wank around with their own narccisitic arrogance to differentiate from one another. STOP IT Seriously, it causes me GIANT amount of pain and quite honestly if I wasn't tied to using OpenStack because I work on it, I would have given up on it a long time ago because of evil stuff like this. So, seriously - let's grow up and start telling people that they do not get to pick and choose user-visible feature sets. If they have an unholy obsession with a particular backend technology that does not allow a public feature of the API to work, then they are deploying a broken cloud and they need to fix it. Looking at your comments in the WG repo you also seem to only be considering projects shipped at Major release versions (Kilo, Liberty). Which might be true of Red Hat's product policy, but it's not generally true that all clouds are at a release boundary. Continous Deployment of OpenStack has been a value from Day 1, and many public clouds are not using releases, but are using arbitrary points off of master. I don't know why you decided I don't know it, but you're wrong. A microversion describes when a changes happens so that applications writers have a very firm contract about what they are talking to. No, they don't. Too many things can modify behavior - see above. -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 Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [neutron] Proposing Assaf Muller for the Neutron Core Reviewer Team
Congratulations Assaf ☺ From: Jaume Devesa [mailto:devv...@gmail.com] Sent: Thursday, June 04, 2015 9:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] Proposing Assaf Muller for the Neutron Core Reviewer Team Congratulations Assaf!! On 4 June 2015 at 17:45, Paul Michali p...@michali.netmailto:p...@michali.net wrote: +100 Great addition! Congratulations Assaf! On Thu, Jun 4, 2015 at 11:41 AM Miguel Lavalle mig...@mlavalle.commailto:mig...@mlavalle.com wrote: Congrats! Well deserved On Thu, Jun 4, 2015 at 8:50 AM, Assaf Muller amul...@redhat.commailto:amul...@redhat.com wrote: Thank you. We have a lot of work ahead of us :) - Original Message - It's a been a week since I proposed this, with no objections. Welcome to the Neutron core reviewer team as the new QA Lieutenant Assaf! On Tue, Jun 2, 2015 at 12:35 PM, Maru Newby ma...@redhat.commailto:ma...@redhat.com wrote: +1 from me, long overdue! On May 28, 2015, at 9:42 AM, Kyle Mestery mest...@mestery.commailto:mest...@mestery.com wrote: Folks, I'd like to propose Assaf Muller to be a member of the Neutron core reviewer team. Assaf has been a long time contributor in Neutron, and he's also recently become my testing Lieutenant. His influence and knowledge in testing will be critical to the team in Liberty and beyond. In addition to that, he's done some fabulous work for Neutron around L3 HA and DVR. Assaf has become a trusted member of our community. His review stats place him in the pack with the rest of the Neutron core reviewers. I'd also like to take this time to remind everyone that reviewing code is a responsibility, in Neutron the same as other projects. And core reviewers are especially beholden to this responsibility. I'd also like to point out that +1/-1 reviews are very useful, and I encourage everyone to continue reviewing code even if you are not a core reviewer. Existing Neutron cores, please vote +1/-1 for the addition of Assaf to the core reviewer team. Thanks! Kyle [1] http://stackalytics.com/report/contribution/neutron-group/180 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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:unsubscribehttp://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:unsubscribehttp://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:unsubscribehttp://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:unsubscribehttp://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:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Jaume Devesa Software Engineer at Midokura __ OpenStack Development Mailing 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] Which middleware does keystone use for authentication and authorization?
You are referring to keystonemiddleware ( https://github.com/openstack/keystonemiddleware) - the Keystone team switched over many OpenStack services to use this new library in Kilo. It was originally a copy of the code in keystoneclient, the driving factor for the change was to decouple the middleware from keystoneclient. Thanks, Steve Martinelli OpenStack Keystone Core Amy Zhang amy.u.zh...@gmail.com wrote on 06/04/2015 12:04:54 PM: From: Amy Zhang amy.u.zh...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 06/04/2015 12:05 PM Subject: [openstack-dev] Which middleware does keystone use for authentication and authorization? Hi all, Does any one know which middleware does Openstack use to authenticate users in Keystone in Kilo release? I saw two middleware, one is in Keystone client, the other is an independent directory. I know the previous version, the middleware in keystone client is used, but in Kilo, I am not sure if they are still using the middleware in keystone client or the other. Anyone has any idea? Thanks! -- Best regards, Amy (Yun Zhang) __ OpenStack Development Mailing 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] Proposing Assaf Muller for the Neutron Core Reviewer Team
+100 Great addition! Congratulations Assaf! On Thu, Jun 4, 2015 at 11:41 AM Miguel Lavalle mig...@mlavalle.com wrote: Congrats! Well deserved On Thu, Jun 4, 2015 at 8:50 AM, Assaf Muller amul...@redhat.com wrote: Thank you. We have a lot of work ahead of us :) - Original Message - It's a been a week since I proposed this, with no objections. Welcome to the Neutron core reviewer team as the new QA Lieutenant Assaf! On Tue, Jun 2, 2015 at 12:35 PM, Maru Newby ma...@redhat.com wrote: +1 from me, long overdue! On May 28, 2015, at 9:42 AM, Kyle Mestery mest...@mestery.com wrote: Folks, I'd like to propose Assaf Muller to be a member of the Neutron core reviewer team. Assaf has been a long time contributor in Neutron, and he's also recently become my testing Lieutenant. His influence and knowledge in testing will be critical to the team in Liberty and beyond. In addition to that, he's done some fabulous work for Neutron around L3 HA and DVR. Assaf has become a trusted member of our community. His review stats place him in the pack with the rest of the Neutron core reviewers. I'd also like to take this time to remind everyone that reviewing code is a responsibility, in Neutron the same as other projects. And core reviewers are especially beholden to this responsibility. I'd also like to point out that +1/-1 reviews are very useful, and I encourage everyone to continue reviewing code even if you are not a core reviewer. Existing Neutron cores, please vote +1/-1 for the addition of Assaf to the core reviewer team. Thanks! Kyle [1] http://stackalytics.com/report/contribution/neutron-group/180 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Getting `ValueError: Field `volume_id' cannot be None`
The problem is in your test case. There is no such methods as remotefs.db.snapshot_get or remotefs.db.snapshot_admin_metadata_get. You need to use with mock.patch('cinder.db.snapshot_get') as snapshot_get, mock.patch('cinder.db.snapshot_admin_metadata_get') as snapshot_admin_metadata_get. These incorrect calls somehow created a side effect in the other test cases. I updated you patch with what is correct, so you should follow it for you other tests. Your test case needs a lot more work, I just edited it to just have it pass the unit tests. Thang On Thu, Jun 4, 2015 at 4:36 AM, Deepak Shetty dpkshe...@gmail.com wrote: I was able to narrow down to the scenario where it fails only when i do: ./run_tests.sh -N cinder.tests.unit.test_remotefs cinder.tests.unit.test_volume.VolumeTestCase and fails with: {0} cinder.tests.unit.test_volume.VolumeTestCase.test_can_delete_errored_snapshot [0.507361s] ... FAILED Captured traceback: ~~~ Traceback (most recent call last): File cinder/tests/unit/test_volume.py, line 3029, in test_can_delete_errored_snapshot snapshot_obj = objects.Snapshot.get_by_id(self.context, snapshot_id) File /usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py, line 169, in wrapper result = fn(cls, context, *args, **kwargs) File cinder/objects/snapshot.py, line 130, in get_by_id expected_attrs=['metadata']) File cinder/objects/snapshot.py, line 112, in _from_db_object snapshot[name] = value File /usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py, line 691, in __setitem__ setattr(self, name, value) File /usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py, line 70, in setter field_value = field.coerce(self, name, value) File /usr/lib/python2.7/site-packages/oslo_versionedobjects/fields.py, line 183, in coerce return self._null(obj, attr) File /usr/lib/python2.7/site-packages/oslo_versionedobjects/fields.py, line 161, in _null raise ValueError(_(Field `%s' cannot be None) % attr) ValueError: Field `volume_id' cannot be None Both the testsuites run fine when i run them individually, as in the below is success: ./run_tests.sh -N cinder.tests.unit.test_remotefs - no errors ./run_tests.sh -N cinder.tests.unit.test_volume.VolumeTestCase - no errors So i modified my patch @ https://review.openstack.org/#/c/172808/ (Patch set 6) and removed all testcase i added in test_remotefs.py except one, so that we have lesser code to debug/deal with! See https://review.openstack.org/#/c/172808/6/cinder/tests/unit/test_remotefs.py Now when i disable test_create_snapshot_online_success then running both the suites work, but when i enable test_create_snapshot_online_success then it fails as above. I am unable to figure whats the connection between test_create_snapshot_online_success in test_remotefs.py and VolumeTestCase.test_can_delete_errored_snapshot in test_volume.py failure Can someone help here ? thanx, deepak On Thu, Jun 4, 2015 at 1:37 PM, Deepak Shetty dpkshe...@gmail.com wrote: Hi Thang, Since you are working on Snapshot Objects, any idea on why the testcase when run all by itself, works, but when run as part of the overall suite, fails ? This seems to be related to the Snapshot Objects, hence Ccing you. On Wed, Jun 3, 2015 at 9:54 PM, Deepak Shetty dpkshe...@gmail.com wrote: Hi All, I am hitting a strange issue when running Cinder unit tests against my patch @ https://review.openstack.org/#/c/172808/5 I have spent 1 day and haven't been successfull at figuring how/why my patch is causing it! All tests failing are part of VolumeTestCase suite and from the error (see below) it seems the Snapshot Object is complaining that 'volume_id' field is null (while it shouldn't be) An example error from the associated Jenkins run can be seen @ http://logs.openstack.org/08/172808/5/check/gate-cinder-python27/0abd15e/console.html.gz#_2015-05-22_13_28_47_140 I am seeing a total of 21 such errors. Its strange because, when I try to reproduce it locally in my devstack env, I see the below: 1) When i just run: ./run_tests.sh -N cinder.tests.unit.test_volume. VolumeTestCase all testcases pass 2) When i run 1 individual testcase: ./run_tests.sh -N cinder.tests.unit.test_volume.VolumeTestCase.test_delete_busy_snapshot that passes too 3) When i run : ./run_tests.sh -N I see 21 tests failing and all are failing with error similar to the below {0} cinder.tests.unit.test_volume.VolumeTestCase.test_delete_busy_snapshot [0.537366s] ... FAILED Captured traceback: ~~~ Traceback (most recent call last): File cinder/tests/unit/test_volume.py, line 3219, in test_delete_busy_snapshot snapshot_obj = objects.Snapshot.get_by_id(self.context, snapshot_id) File
Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG
On Jun 4, 2015 12:00 AM, Xu, Hejie hejie...@intel.com wrote: Hi, guys, I’m working on adding Microversion into the API-WG’s guideline which make sure we have consistent Microversion behavior in the API for user. The Nova and Ironic already have Microversion implementation, and as I know Magnum https://review.openstack.org/#/c/184975/ is going to implement Microversion also. Hope all the projects which support( or plan to) Microversion can join the review of guideline. The Mircoversion specification(this almost copy from nova-specs): https://review.openstack.org/#/c/187112 And another guideline for when we should bump Mircoversion https://review.openstack.org/#/c/187896/ As I know, there already have a little different between Nova and Ironic’s implementation. Ironic return min/max version when the requested version doesn’t support in server by http-headers. There isn’t such thing in nova. But that is something for version negotiation we need for nova also. Sean have pointed out we should use response body instead of http headers, the body can includes error message. Really hope ironic team can take a look at if you guys have compelling reason for using http headers. And if we think return body instead of http headers, we probably need think about back-compatible also. Because Microversion itself isn’t versioned. So I think we should keep those header for a while, does make sense? Hope we have good guideline for Microversion, because we only can change Mircoversion itself by back-compatible way. Ironic returns the min/max/current API version in the http headers for every request. Why would it return this information in a header on success and in the body on failure? (How would this inconsistency benefit users?) To be clear, I'm not opposed to *also* having a useful error message in the body, but while writing the client side of api versioning, parsing the range consistently from the response header is, IMO, better than requiring a conditional. -Deva __ OpenStack Development Mailing 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] Dynamic Policy for Access Control Subteam Meeting
Inline. On Thu, Jun 4, 2015 at 6:40 AM, Sean Dague s...@dague.net wrote: On 06/04/2015 08:52 AM, Adam Young wrote: On 06/04/2015 06:32 AM, Sean Dague wrote: On 06/03/2015 08:40 PM, Tim Hinrichs wrote: As long as there's some way to get the *declarative* policy from the system (as a data file or as an API call) that sounds fine. But I'm dubious that it will be easy to keep the API call that returns the declarative policy in sync with the actual code that implements that policy. Um... why? Nova (or any other server project) needs to know what the currently computed policy is to actually enforce it internally. Turning around and spitting that back out on the wire is pretty straight forward. Is there some secret dragon I'm missing here? No. But it is a significant bit of coding to do; you would need to crawl every API and make sure you hit every code path that could enforce policy. Um, I don't understand that. I'm saying that you'd GET https://my.nova.api.server/policy; And it would return basically policy.json. There is no crawling every bit, this is a standard entry point to return a policy representation. Getting all services to implement this would mean that Keystone could support interesting policy things with arbitrary projects, not just a small curated list, which is going to be really important in a big tent world. Monasca and Murano are just as important to support here as Nova and Swift. Definitely agree it'd be great to have an API call that returns policy. The question that I think Adam and I are trying to answer is how do projects implement that call? We've (perhaps implicitly) suggested 3 different options. 1. Have a data file called say 'default_policy.json' that the oslo-policy engine knows how to use (and override with policy.json or whatever). The policy-API call that returns policy then just reads in this file and returns it. 2. Hard-code the return value of the Python function that implements the policy-API call. Different options as to how to do this. 3. Write code that automatically generates the policy-API result by analyzing the code that implements the rest of the API calls (like create_vm, delete_vm) and extracting the policy that they implement. This would require hitting all code paths that implement policy, etc. I'm guessing you had option (2) in mind. Is that right? Assuming that's the case I see two possibilities. a. The policy-API call is used internally by Nova to check that an API call is permitted before executing it. (I'm talking conceptually. Obviously you'd not go through http.) b. The policy-API call is never used internally; rather, each of the other API calls (like create-server, delete-server) just use arbitrary Python logic to decide whether an API call is permitted or not. This requires the policy-API call implementation to be kept in sync manually with the other API calls to ensure the policy-API call returns the actual policy. I'd be happy with (a) and doubt the practicality of (b). Tim However, I've contemplated doing something like that with oslo.policy already; run a workload through a server with policy non-enforcing (Permissive mode) and log the output to a file, then use that output to modify either the policy or the delegations (role assignments or trusts) used in a workflow. The Hard coded defaults worry me, though. Nova is one piece (a big one, admittedly) of a delicate dance across multiple (not-so-micro) services that make up OpenStack. Other serivces are going to take their cue from what Nova does, and that would make the overall flow that much harder to maintain. I don't understand why having hard coded defaults makes things harder, as long as they are discoverable. Defaults typically make things easier, because people then only change what they need, instead of setting a value for everything, having the deployment code update, and making their policy miss an important thing, or make something wrong because they didn't update it correctly at the same time as code. I think we need to break some very ingrained patterns in out policy enforcement. I would worry that enforcing policy in code would give us something that we could not work around. Instead, I think we need to ensure that the Nova team leads the rest of the OpenStack core services in setting up best practices, and that is primarily a communication issue. Getting to a common understanding of RBAC, and making it clear how roles are modified on a per-api basis will make Nova more robust. So I feel like I understand the high level dynamic policy end game. I feel like what I'm proposing for policy engine with encoded defaults doesn't negatively impact that. I feel there is a middle chunk where perhaps we've got different concerns or different dragons that we see, and are mostly talking past each other. And I don't know how to bridge that. All the keystone specs I've
Re: [openstack-dev] [Murano] Help needed with TOSCA support in Murano
Hi Serg,Sorry, I seem to be having issues sending messages to the mailing list.Thanks for your message. I can work on the blueprint spec. Just trying to get a good picture of related Murano processes and where the connection points to Heat-Translator should be.And I agreed with your comment on MuranoPL. I think for TOSCA support and integration with Heat-Translator we need to consider HOT based packages.Regards,-Vahid Hashemian, Ph.D.Advisory Software Engineer, IBM Cloud Labs-Serg Melikyan smelik...@mirantis.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Serg Melikyan smelik...@mirantis.comDate: 06/04/2015 06:31AMSubject: Re: [openstack-dev] [Murano] Help needed with TOSCA support in MuranoHi Vahid,Your analysis is correct, and integration of heat-translator is assimple as you described that in your document. It would be reallyawesome if you would turn this PDF to the proper specification for theblueprint.P.S. Regarding several stack for applications - currently HOT-basedpackages create stack per application, and we don't support same levelof composition as we have in murano-pl based packages. This is anotherquestion for improvement.On Wed, Jun 3, 2015 at 12:44 AM, Georgy Okrokvertskhovgokrokvertsk...@mirantis.com wrote: Hi Vahid, Thank you for sharing your thoughts. I have a questions about application life-cycle if we use TOSCA translator. In Murano the main advantage of using HOT format is that we can update Het stack with resources as soon as we need to deploy additional application. We can dynamically create multi-tier applications with using other apps as a building blocks. Imagine Java app on tom of Tomcat (VM1) and PostgreDB (VM2). All three components are three different apps in the catalog. Murano allows you to bring them and deploy together. Do you think it will be possible to use TOSCA translator for Heat stack updates? What we will do if we have two apps with two TOSCA templates like Tomcat and Postgre. How we can combine them together? Thanks Gosha On Tue, Jun 2, 2015 at 12:14 PM, Vahid S Hashemian vahidhashem...@us.ibm.com wrote: This is my what I have so far. Would love to hear feedback on it. Thanks. Regards, - Vahid Hashemian, Ph.D. Advisory Software Engineer, IBM Cloud Labs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev-- Serg Melikyan, Senior Software Engineer at Mirantis, Inc.http://mirantis.com| smelik...@mirantis.com__OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [Murano] Help needed with TOSCA support in Murano
undefined __ OpenStack Development Mailing 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] Proposing Assaf Muller for the Neutron Core Reviewer Team
Congratulations Assaf!! On 4 June 2015 at 17:45, Paul Michali p...@michali.net wrote: +100 Great addition! Congratulations Assaf! On Thu, Jun 4, 2015 at 11:41 AM Miguel Lavalle mig...@mlavalle.com wrote: Congrats! Well deserved On Thu, Jun 4, 2015 at 8:50 AM, Assaf Muller amul...@redhat.com wrote: Thank you. We have a lot of work ahead of us :) - Original Message - It's a been a week since I proposed this, with no objections. Welcome to the Neutron core reviewer team as the new QA Lieutenant Assaf! On Tue, Jun 2, 2015 at 12:35 PM, Maru Newby ma...@redhat.com wrote: +1 from me, long overdue! On May 28, 2015, at 9:42 AM, Kyle Mestery mest...@mestery.com wrote: Folks, I'd like to propose Assaf Muller to be a member of the Neutron core reviewer team. Assaf has been a long time contributor in Neutron, and he's also recently become my testing Lieutenant. His influence and knowledge in testing will be critical to the team in Liberty and beyond. In addition to that, he's done some fabulous work for Neutron around L3 HA and DVR. Assaf has become a trusted member of our community. His review stats place him in the pack with the rest of the Neutron core reviewers. I'd also like to take this time to remind everyone that reviewing code is a responsibility, in Neutron the same as other projects. And core reviewers are especially beholden to this responsibility. I'd also like to point out that +1/-1 reviews are very useful, and I encourage everyone to continue reviewing code even if you are not a core reviewer. Existing Neutron cores, please vote +1/-1 for the addition of Assaf to the core reviewer team. Thanks! Kyle [1] http://stackalytics.com/report/contribution/neutron-group/180 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Jaume Devesa Software Engineer at Midokura __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Murano] Help needed with TOSCA support in Murano
Hi Serg, Sorry, I seem to be having issues sending messages to the mailing list. Thanks for your message. I can work on the blueprint spec. Just trying to get a good picture of related Murano processes and where the connection points to Heat-Translator should be. And I agreed with your comment on MuranoPL. I think for TOSCA support and integration with Heat-Translator we need to consider HOT based packages. Regards, - Vahid Hashemian, Ph.D. Advisory Software Engineer, IBM Cloud Labs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] When to bump the microversion?
On 06/04/2015 05:43 PM, Sean Dague wrote: On 06/04/2015 11:27 AM, Dmitry Tantsur wrote: On 06/04/2015 05:03 PM, Sean Dague wrote: On 06/04/2015 10:50 AM, Dmitry Tantsur wrote: On 06/04/2015 04:40 PM, Ruby Loo wrote: Hi, In Kilo, we introduced microversions but it seems to be a work-in-progress. There is an effort now to add microversion into the API-WG's guidelines, to provide a consistent way of using microversions across OpenStack projects [1]. Specifically, in the context of this email, there is a proposed guideline for when to bump the microversion [2]. As I understand this guideline tells to bump microversion on every change which I strongly -1 as usual. Reason: it's bump for the sake of bump, without any direct benefit for users (no, API discoverability is not one, because microversion do not solve it). I'll post the same comment to the guideline. Backwards compatible API adds with no user signaling is a fallacy because it assumes the arrow of time flows only one way. If at version 1.5 you have a resource that is foo { bar: ... } And then you decide you want to add another attribute foo { bar: ... baz: ... } And you don't bump the version, you'll get a set of users that use a cloud with baz, and incorrectly assume that version 1.5 of the API means that baz will always be there. Except, there are lots of clouds out there, including ones that might be at the code commit before it was added. Because there are lots of deploys in the world, your users can effectively go back in time. So now your API definition for version 1.5 is: foo, may or may not contain baz, and there is no way of you knowing if it will until you try. good luck. Which is pretty aweful. Which is not very different from your definition. Version 1.5 contains feature xyz, unless it's disabled by the configuration or patched out downstream. Well, 1.4 can also contain the feature, if downstream backported it. So good luck again. The whole point of interop is you can't call it OpenStack if you are patching it downstream to break the upstream contract. Microversions are a contract. Downstream can hack code all they want, it's no longer OpenStack when they do. If they are ok with it, that's fine. But them taking OpenStack code and making something that's not OpenStack is beyond the scope of the problem here. This is about good actors, acting in good faith, to provide a consistent experience to application writers. I disagree with all said above, but putting aside discussion about ideal vs real world, my point actually boils down to: if you want feature discovery (or as you call it - contract), make it explicit. Create API for it. Here you're upset with users guessing features - and you invent one more way to guess them. Probably working in ideal world, but still a guessing game. And pretty inconvenient to use (to test, to document), I would say. And within Ironic community (including people deploying from master), I'm still waiting to hear requests for such feature at all, but that's another question. -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
Re: [openstack-dev] [Ironic] When to bump the microversion?
On Jun 4, 2015 8:57 AM, Monty Taylor mord...@inaugust.com wrote: On 06/04/2015 11:27 AM, Dmitry Tantsur wrote: On 06/04/2015 05:03 PM, Sean Dague wrote: On 06/04/2015 10:50 AM, Dmitry Tantsur wrote: On 06/04/2015 04:40 PM, Ruby Loo wrote: Hi, In Kilo, we introduced microversions but it seems to be a work-in-progress. There is an effort now to add microversion into the API-WG's guidelines, to provide a consistent way of using microversions across OpenStack projects [1]. Specifically, in the context of this email, there is a proposed guideline for when to bump the microversion [2]. As I understand this guideline tells to bump microversion on every change which I strongly -1 as usual. Reason: it's bump for the sake of bump, without any direct benefit for users (no, API discoverability is not one, because microversion do not solve it). I'll post the same comment to the guideline. Backwards compatible API adds with no user signaling is a fallacy because it assumes the arrow of time flows only one way. If at version 1.5 you have a resource that is foo { bar: ... } And then you decide you want to add another attribute foo { bar: ... baz: ... } And you don't bump the version, you'll get a set of users that use a cloud with baz, and incorrectly assume that version 1.5 of the API means that baz will always be there. Except, there are lots of clouds out there, including ones that might be at the code commit before it was added. Because there are lots of deploys in the world, your users can effectively go back in time. So now your API definition for version 1.5 is: foo, may or may not contain baz, and there is no way of you knowing if it will until you try. good luck. Which is pretty aweful. Which is not very different from your definition. Version 1.5 contains feature xyz, unless it's disabled by the configuration or patched out downstream. Well, 1.4 can also contain the feature, if downstream backported it. So good luck again. If you allow to group features under one microversion, that becomes even worse - you can have deployment that got microversion only partially. For example, that's what I would call API discoverability: $ ironic has-capability foobar true and that's how it would play with versioning: $ ironic --ironic-api-version 1.2 has-capability foobar false $ ironic --ironic-api-version 1.6 has-capability foobar true On the contrary, the only thing that microversion tells me is that the server installation is based on a particular upstream commit. To me these are orthogonal problems, and I believe they should be solved differently. Our disagreement is due to seeing them as one problem. We should stop doing this everywhere in OpenStack. It is the absolute worst experience ever. Stop allowing people to disable features with config. there is literally no user on the face of the planet for whom this is a positive thing. 1.5 should mean that your server has Set(A) of features. 1.6 should mean Set(A+B) - etc. There should be NO VARIATION and any variation on that should basically mean that the cloud in question is undeniably broken. I understand that vendors and operators keep wanting to wank around with their own narccisitic arrogance to differentiate from one another. STOP IT Seriously, it causes me GIANT amount of pain and quite honestly if I wasn't tied to using OpenStack because I work on it, I would have given up on it a long time ago because of evil stuff like this. So, seriously - let's grow up and start telling people that they do not get to pick and choose user-visible feature sets. If they have an unholy obsession with a particular backend technology that does not allow a public feature of the API to work, then they are deploying a broken cloud and they need to fix it. So I just had dinner last night with a very large user of OpenStack (yes, they exist) whose single biggest request is that we stop differentiating in the API. To them, any difference in the usability / behavior / API between OpenStack deployment X and Y is a serious enough problem that it will have two effects: - vendor lock in - they stop using OpenStack And since avoiding single vendor lock in is important to them, well, really it has only one result. Tl;Dr; Monty is right. We MUST NOT vary the API or behaviour significantly or non-discoverably between clouds. Or we simply won't have users. Looking at your comments in the WG repo you also seem to only be considering projects shipped at Major release versions (Kilo, Liberty). Which might be true of Red Hat's product policy, but it's not generally true that all clouds are at a release boundary. Continous Deployment of OpenStack has been a value from Day 1, and many public clouds are not using releases, but are using arbitrary points off of master. I don't know why you decided I
Re: [openstack-dev] Why do we drop branches? (WAS: Re: Targeting icehouse-eol?)
On 2015-06-04 16:23:12 +0200 (+0200), Ihar Hrachyshka wrote: 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. Why not just leaving them sitting there, marked read only? It becomes especially important now that we say that stable HEAD *is* a stable release. It's doable, but we'll need ACL changes applied to every project participating in this release model to reject new change submissions and prevent anyone from approving them on every branch which reaches its EOL date. These ACLs will also grow longer and longer over time as we need to add new sections for each EOL branch. Also, it seems to me like a feature if downstream consumers have to take notice and explicitly adjust their tooling to intentionally continue deploying a release for which we no longer provide support and security updates. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] When to bump the microversion?
So we should have told the folks to so developing agent? (Not sure why you all think I'm talking about us) Maybe. But anyway anyone deliberately ignores my points, so I'm done with this discussion. 04 июня 2015 г. 18:17 пользователь Devananda van der Veen devananda@gmail.com написал: On Jun 4, 2015 8:57 AM, Monty Taylor mord...@inaugust.com wrote: On 06/04/2015 11:27 AM, Dmitry Tantsur wrote: On 06/04/2015 05:03 PM, Sean Dague wrote: On 06/04/2015 10:50 AM, Dmitry Tantsur wrote: On 06/04/2015 04:40 PM, Ruby Loo wrote: Hi, In Kilo, we introduced microversions but it seems to be a work-in-progress. There is an effort now to add microversion into the API-WG's guidelines, to provide a consistent way of using microversions across OpenStack projects [1]. Specifically, in the context of this email, there is a proposed guideline for when to bump the microversion [2]. As I understand this guideline tells to bump microversion on every change which I strongly -1 as usual. Reason: it's bump for the sake of bump, without any direct benefit for users (no, API discoverability is not one, because microversion do not solve it). I'll post the same comment to the guideline. Backwards compatible API adds with no user signaling is a fallacy because it assumes the arrow of time flows only one way. If at version 1.5 you have a resource that is foo { bar: ... } And then you decide you want to add another attribute foo { bar: ... baz: ... } And you don't bump the version, you'll get a set of users that use a cloud with baz, and incorrectly assume that version 1.5 of the API means that baz will always be there. Except, there are lots of clouds out there, including ones that might be at the code commit before it was added. Because there are lots of deploys in the world, your users can effectively go back in time. So now your API definition for version 1.5 is: foo, may or may not contain baz, and there is no way of you knowing if it will until you try. good luck. Which is pretty aweful. Which is not very different from your definition. Version 1.5 contains feature xyz, unless it's disabled by the configuration or patched out downstream. Well, 1.4 can also contain the feature, if downstream backported it. So good luck again. If you allow to group features under one microversion, that becomes even worse - you can have deployment that got microversion only partially. For example, that's what I would call API discoverability: $ ironic has-capability foobar true and that's how it would play with versioning: $ ironic --ironic-api-version 1.2 has-capability foobar false $ ironic --ironic-api-version 1.6 has-capability foobar true On the contrary, the only thing that microversion tells me is that the server installation is based on a particular upstream commit. To me these are orthogonal problems, and I believe they should be solved differently. Our disagreement is due to seeing them as one problem. We should stop doing this everywhere in OpenStack. It is the absolute worst experience ever. Stop allowing people to disable features with config. there is literally no user on the face of the planet for whom this is a positive thing. 1.5 should mean that your server has Set(A) of features. 1.6 should mean Set(A+B) - etc. There should be NO VARIATION and any variation on that should basically mean that the cloud in question is undeniably broken. I understand that vendors and operators keep wanting to wank around with their own narccisitic arrogance to differentiate from one another. STOP IT Seriously, it causes me GIANT amount of pain and quite honestly if I wasn't tied to using OpenStack because I work on it, I would have given up on it a long time ago because of evil stuff like this. So, seriously - let's grow up and start telling people that they do not get to pick and choose user-visible feature sets. If they have an unholy obsession with a particular backend technology that does not allow a public feature of the API to work, then they are deploying a broken cloud and they need to fix it. So I just had dinner last night with a very large user of OpenStack (yes, they exist) whose single biggest request is that we stop differentiating in the API. To them, any difference in the usability / behavior / API between OpenStack deployment X and Y is a serious enough problem that it will have two effects: - vendor lock in - they stop using OpenStack And since avoiding single vendor lock in is important to them, well, really it has only one result. Tl;Dr; Monty is right. We MUST NOT vary the API or behaviour significantly or non-discoverably between clouds. Or we simply won't have users. Looking at your comments in the WG repo
Re: [openstack-dev] Dynamic Policy for Access Control Subteam Meeting
On 06/04/2015 12:12 PM, Tim Hinrichs wrote: Inline. On Thu, Jun 4, 2015 at 6:40 AM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: On 06/04/2015 08:52 AM, Adam Young wrote: On 06/04/2015 06:32 AM, Sean Dague wrote: On 06/03/2015 08:40 PM, Tim Hinrichs wrote: As long as there's some way to get the *declarative* policy from the system (as a data file or as an API call) that sounds fine. But I'm dubious that it will be easy to keep the API call that returns the declarative policy in sync with the actual code that implements that policy. Um... why? Nova (or any other server project) needs to know what the currently computed policy is to actually enforce it internally. Turning around and spitting that back out on the wire is pretty straight forward. Is there some secret dragon I'm missing here? No. But it is a significant bit of coding to do; you would need to crawl every API and make sure you hit every code path that could enforce policy. Um, I don't understand that. I'm saying that you'd GET https://my.nova.api.server/policy; And it would return basically policy.json. There is no crawling every bit, this is a standard entry point to return a policy representation. Getting all services to implement this would mean that Keystone could support interesting policy things with arbitrary projects, not just a small curated list, which is going to be really important in a big tent world. Monasca and Murano are just as important to support here as Nova and Swift. Definitely agree it'd be great to have an API call that returns policy. The question that I think Adam and I are trying to answer is how do projects implement that call? We've (perhaps implicitly) suggested 3 different options. 1. Have a data file called say 'default_policy.json' that the oslo-policy engine knows how to use (and override with policy.json or whatever). The policy-API call that returns policy then just reads in this file and returns it. 2. Hard-code the return value of the Python function that implements the policy-API call. Different options as to how to do this. 3. Write code that automatically generates the policy-API result by analyzing the code that implements the rest of the API calls (like create_vm, delete_vm) and extracting the policy that they implement. This would require hitting all code paths that implement policy, etc. I'm guessing you had option (2) in mind. Is that right? Assuming that's the case I see two possibilities. a. The policy-API call is used internally by Nova to check that an API call is permitted before executing it. (I'm talking conceptually. Obviously you'd not go through http.) b. The policy-API call is never used internally; rather, each of the other API calls (like create-server, delete-server) just use arbitrary Python logic to decide whether an API call is permitted or not. This requires the policy-API call implementation to be kept in sync manually with the other API calls to ensure the policy-API call returns the actual policy. I'd be happy with (a) and doubt the practicality of (b). Right, I'm thinking 2 (a). There is some engine internally (presumably part of oslo.policy) where we can feed it sources in order (sources could be code structures or files on disk, we already support multi file with current oslo.policy and incubator code): Base + Patch1 + Patch2 + ... policy.add(Base) policy.add(Patch1) policy.add(Patch2) You can then call: policy.enforce(context, rulename, ...) like you do today, it knows what it's doing. And you can also call: for_export = policy.export() To dump the computed policy back out. Which is a thing that doesn't exist today. The GET /policy would just build the same policy engine, which computes the final rule set, and exports it. The bulk of the complicated code would be in oslo.policy, so shared. Different projects have different wsgi stacks, so will have a bit of different handling code for the request, but the fact that all the interesting payload is a policy.export() means the development overhead should be pretty minimal. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [global-requirements][pbr] tarball and git requirements no longer supported in requirements.txt
+1. I had setup a CI for a third-party plugin and the easiest thing to do to make sure it was running tests with the latest copy of the corresponding neutron branch was to put the git URL in requirements.txt. We wanted to always test the latest code so we had early detection of failures. What's the appropriate way to do that without using a git reference? On Thu, Jun 4, 2015 at 2:06 AM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/03/2015 11:08 PM, Robert Collins wrote: Hi, right now there is a little used (e.g. its not in any active project these days) previous feature of pbr/global-requirements: we supported things that setuptools does not: to whit, tarball and git requirements. Now, these things are supported by pip, so the implementation involved recursing into pip from our setup.py (setup.py - pbr - pip). What we exported into setuptools was only the metadata about the dependency name. This meant that we were re-entering pip, potentially many times - it was, to be blunt, awful. Fortunately we removed the recursive re-entry into pip in pbr 1.0. This didn't remove the ability to parse requirements.txt files that contain urls, but it does mean they are converted to the simple dependency name when doing 'pip install .' in a project tree (or pip install $projectname), and so they are effectively unversioned - no lower and no upper bound. This works poorly in the gate: please don't use tarball or git urls in requirements.txt (or setup.cfg for that matter). We can still choose to use something from git or a tarball in test jobs, *if* thats the right thing (which it rarely is: I'm just being clear that the technical capability still exists)... but it needs to be done outside of requirements.txt going forward. Its also something that we can support with the new constraints system if desired [which will operate globally once in place (it is an extension of global-requirements)]. One question that this raises, and this is why I wrote the email: is there any need to support this at all:- can we say that we won't use tarball/vcs support at all and block it as a policy step in global requirements? AIUI both git and tarball support is problematic for CI jobs due to the increased flakiness of depending on network resources... so its actively harmful anyway. Lots of Neutron modules, like advanced services, or out-of-tree plugins, rely on neutron code being checked out from git [1]. I don't say it's the way to go forward, and there were plans to stop relying on latest git to avoid frequent breakages, but it's not yet implemented. [1]: http://git.openstack.org/cgit/openstack/neutron-vpnaas/tree/tox.ini#n10 Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVcBUnAAoJEC5aWaUY1u57N2EH/jUFd0H9pQ7LApSAIlDTEl2v WR1EXnc9Vxf5nCWq/qmncj3OCpMDlgL/ZMrFu74LRTDbe38+16kh+Fb+FvBEPGA4 ZkQC3gyg22Se/QcerTxdPil16hnT912Hr3E0cTuu/4ktyipPrVsO39N56Jbrb6WQ SRCrEohIg7C3c0NgFcvBGh+S4rNf8IKT1oLzKrRhSLzIE8lSeGa1GNnSXPAXk19/ 2KIEnqBz3Q5J6umTprB5DFdxMe93Pj6jZmGIMFaHXYgG/yTdKz3zzGM3hpuLyGUQ kKYEzFJZ4vf2c6NBg//GYTcAkGjkM2QmAnS+uoztU5vm4QRkLgGcDCz29eQ5ufA= =6bUu -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] ENROLL state and changing node driver
On Jun 4, 2015 5:53 AM, Dmitry Tantsur dtant...@redhat.com wrote: Hi! While working on the enroll spec [1], I got a thinking: within the new state machine, when should we allow to change a node driver? My initial idea was to only allow driver change in ENROLL. Which sounds good to me, but then it will be impossible to change a driver after moving forward: we don't plan on having a way back to ENROLL from MANAGEABLE. What do you folks think we should do: 1. Leave driver field as it was before 2. Allow changing driver in ENROLL, do not allow later 3. Allow changing driver in ENROLL only, but create a way back from MANAGEABLE to ENROLL (unmanage??) What problem are you trying to solve? Because I don't see a problem with the current behavior, and you're proposing breaking the API and requiring users to follow a significantly more complex process should they need to change what driver is in use for a node, and preventing ever doing that while a workload is running... -Deva Cheers, Dmitry [1] https://review.openstack.org/#/c/179151 __ OpenStack Development Mailing 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] Why do we drop branches? (WAS: Re: Targeting icehouse-eol?)
argh BLOCK push on others stable branches [access refs/heads/stable/*] push = block group Anonymous Users On Thu, Jun 4, 2015 at 6:34 PM, ZZelle zze...@gmail.com wrote: We can do the opposite to avoid more and more ACLs: ALLOW push on some specific stable branches [access refs/heads/stable/kilo] push = allow group ***-stable-maint [access refs/heads/stable/juno] push = allow group ***-stable-maint BLOCK push on others stable branches [access refs/heads/stable/juno] push = block group Anonymous Users Cedric/ZZelle@IRC On Thu, Jun 4, 2015 at 6:15 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-04 16:23:12 +0200 (+0200), Ihar Hrachyshka wrote: 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. Why not just leaving them sitting there, marked read only? It becomes especially important now that we say that stable HEAD *is* a stable release. It's doable, but we'll need ACL changes applied to every project participating in this release model to reject new change submissions and prevent anyone from approving them on every branch which reaches its EOL date. These ACLs will also grow longer and longer over time as we need to add new sections for each EOL branch. Also, it seems to me like a feature if downstream consumers have to take notice and explicitly adjust their tooling to intentionally continue deploying a release for which we no longer provide support and security updates. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] [Ironic] When to bump the microversion?
Hi, In Kilo, we introduced microversions but it seems to be a work-in-progress. There is an effort now to add microversion into the API-WG's guidelines, to provide a consistent way of using microversions across OpenStack projects [1]. Specifically, in the context of this email, there is a proposed guideline for when to bump the microversion [2]. Last week, in an IRC discussion [3], Devananda suggested that we bump the microversion in these situations: ' required for any non-backwards-compatible change, and strongly encouraged for any significant features ? (and yes, that's subjective) '. What do people think of that? I think it is clear that we should do it for any non-backwards-compatible change. The subjective part worries me a bit -- who decides, the feature submitter or the cores or ? Alternatively, if people aren't too worried or care that much, we can decide to follow the guideline [3] (and limp along until that guideline is finalized). --ruby [1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/065793.html [2] https://review.openstack.org/#/c/187896/ [3] around 2015-05-26T16:29:05, http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2015-05-26.log __ OpenStack Development Mailing 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] L3 agent rescheduling issue
One reason for not sending the heartbeat from a separate greenthread could be that the agent is already doing it [1]. The current proposed patch addresses the issue blindly - that is to say before declaring an agent dead let's wait for some more time because it could be stuck doing stuff. In that case I would probably make the multiplier (currently 2x) configurable. The reason for which state report does not occur is probably that both it and the resync procedure are periodic tasks. If I got it right they're both executed as eventlet greenthreads but one at a time. Perhaps then adding an initial delay to the full sync task might ensure the first thing an agent does when it comes up is sending a heartbeat to the server? On the other hand, while doing the initial full resync, is the agent able to process updates? If not perhaps it makes sense to have it down until it finishes synchronisation. Salvatore [1] http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/l3/agent.py#n587 On 4 June 2015 at 16:16, Kevin Benton blak...@gmail.com wrote: Why don't we put the agent heartbeat into a separate greenthread on the agent so it continues to send updates even when it's busy processing changes? On Jun 4, 2015 2:56 AM, Anna Kamyshnikova akamyshnik...@mirantis.com wrote: Hi, neutrons! Some time ago I discovered a bug for l3 agent rescheduling [1]. When there are a lot of resources and agent_down_time is not big enough neutron-server starts marking l3 agents as dead. The same issue has been discovered and fixed for DHCP-agents. I proposed a change similar to those that were done for DHCP-agents. [2] There is no unified opinion on this bug and proposed change, so I want to ask developers whether it worth to continue work on this patch or not. [1] - https://bugs.launchpad.net/neutron/+bug/1440761 [2] - https://review.openstack.org/171592 -- Regards, Ann Kamyshnikova Mirantis, Inc __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] [keystone][reseller] New way to get a project scoped token by name
First I have some questions: if we are going to add a delimiter, how can we handle OpenStack API Stability guidelines [1]? If we add this delimiter in keystone.conf (and having the default value being . or /), do we fall into the same API stability problems? Personally, I'm in favor of having a way to represent the hierarchy since it will loose the naming restrictions across projects and domains entities - resulting in a better UX. The only remaining restriction will be that we won't be able to create an entity with the same name in the same level of the hierarchy. In addition, besides the token request, using a delimiter also solves the problem of representing a hierarchy in SAML Assertions generated by a keystone identity provider as well. Also, if we are going to use a delimiter, we need to update the way projects names are returned in the GET v3/projects API to include the hierarchy so the user (or client) knows how to request a token using the project name. On Thu, Jun 4, 2015 at 4:33 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: I agree that it is better to choose one global delimiter (ideally this should have been done from day one, when hierarchical naming should have been used as the basic name form for Openstack). Whatever you choose now will cause someone somewhere some pain, but perhaps the overall pain to the whole community will be less if you dictate what this delimiter is going to be now, but dont introduce for a year. This allows everyone a year to remove the delimiter from their names. regards David On 03/06/2015 22:05, 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) experience to our users. I'm worried a custom defined delimiter (even at the domain level) is going to make it difficult to consume this data outside of the context of OpenStack (there are applications that are written to use the APIs directly). The alternative is to explicitly list the delimiter in the project ( e.g. {hierarchy: {delim: ., domain.project.project2}} ). The additional need to look up the delimiter / set the delimiter when creating a domain is likely to make for a worse user experience than selecting one that is not different across installations. --Morgan On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote: On 03/06/2015 14:54, Henrique Truta wrote: Hi David, You mean creating some kind of delimiter attribute in the domain entity? That seems like a good idea, although it does not solve the problem Morgan's mentioned that is the global hierarchy delimiter. There would be no global hierarchy delimiter. Each domain would define its own and this would be carried in the JSON as a separate parameter so that the recipient can tell how to parse hierarchical names David Henrique Em qua, 3 de jun de 2015 às 04:21, David Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk escreveu: On 02/06/2015 23:34, Morgan Fainberg wrote: Hi Henrique, I don't think we need to specifically call out that we want a domain, we should always reference the namespace as we do today. Basically, if we ask for a project name we need to also provide it's namespace (your option #1). This clearly lines up with how we handle projects in domains today. I would, however, focus on how to represent the namespace in a single (usable) string. We've been delaying the work on this for a while since we have historically not provided a clear way to delimit the hierarchy. If we solve the issue with what is the delimiter between domain, project, and subdomain/subproject, we end up solving the usability why not allow the top level domain/project to define the delimiter for its tree, and to carry the delimiter in the JSON as a new parameter. That provides full flexibility for all languages and locales David issues with proposal #1, and not breaking the current behavior you'd expect with implementing option #2 (which at face value feels to be API incompatible/break of current behavior). Cheers, --Morgan On Tue, Jun 2, 2015 at 7:43 AM, Henrique Truta
Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG
On 4 June 2015 at 02:58, Xu, Hejie hejie...@intel.com wrote: ... And another guideline for when we should bump Mircoversion *https://review.openstack.org/#/c/187896/* https://review.openstack.org/#/c/187896/ This is timely because just this very minute I was going to send out email to the Ironic community about this -- when *should* we bump the microversion. For fear of hijacking this thread, I'm going to start a new thread to discuss with Ironic folks first. As I know, there already have a little different between Nova and Ironic’s implementation. Ironic return min/max version when the requested version doesn’t support in server by http-headers. There isn’t such thing in nova. But that is something for version negotiation we need for nova also. Sean have pointed out we should use response body instead of http headers, the body can includes error message. Really hope ironic team can take a look at if you guys have compelling reason for using http headers. I don't want to change the ironic code so let's go with http headers. (That's a good enough reason, isn't it?) :-) By the way, did you see Ironic's spec on the/our desired behaviour between Ironic's server and client [1]? It's ... add your own adjective here. Thanks Alex! --ruby [1] http://specs.openstack.org/openstack/ironic-specs/specs/kilo/api-microversions.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] When to bump the microversion?
On 06/04/2015 04:40 PM, Ruby Loo wrote: Hi, In Kilo, we introduced microversions but it seems to be a work-in-progress. There is an effort now to add microversion into the API-WG's guidelines, to provide a consistent way of using microversions across OpenStack projects [1]. Specifically, in the context of this email, there is a proposed guideline for when to bump the microversion [2]. As I understand this guideline tells to bump microversion on every change which I strongly -1 as usual. Reason: it's bump for the sake of bump, without any direct benefit for users (no, API discoverability is not one, because microversion do not solve it). I'll post the same comment to the guideline. Last week, in an IRC discussion [3], Devananda suggested that we bump the microversion in these situations: ' required for any non-backwards-compatible change, and strongly encouraged for any significant features ? (and yes, that's subjective) '. What do people think of that? I think it is clear that we should do it for any non-backwards-compatible change. The subjective part worries me a bit -- who decides, the feature submitter or the cores or ? My vote is: if we can proof that a sane user will be broken by the change, we bump the microversion. Alternatively, if people aren't too worried or care that much, we can decide to follow the guideline [3] (and limp along until that guideline is finalized). --ruby [1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/065793.html [2] https://review.openstack.org/#/c/187896/ [3] around 2015-05-26T16:29:05, http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2015-05-26.log __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Time to decide something on the vendor tools repo
On 4 June 2015 at 09:29, Dmitry Tantsur dtant...@redhat.com wrote: On the summit we were discussing things like chassis discovery, and arrived at rough conclusion that we want it to be somewhere in a separate repo. More precisely, we wanted some place for vendor to contribute code (aka scripts) that aren't good fit for both standard interfaces and existing vendor passthrough (chassis discovery again is a good example). Our summit notes are sparse on this topic [1], but I'll add in what I see there. I suggest to decide something finally to unblock people. A few questions follow: Should we 1. create one repo for all vendors (say, ironic-contrib-tools) from summit, the advantage of having them in one place is that they will get used and improved by other vendors Presumably there'd be subdirectories, one for each vendor and/or based on functionality. The disadvantage maybe, is who will maintain/own (and merge stuff) in this repo. 2. create a repo for every vendor appearing from summit, Creating an ironic-utils-vendor repo on stackforge to host each manufacturer set of tools and document the directo 3. ask vendors to go for stackforge, at least until their solution shapes (like we did with inspector)? I think whatever is decided, should be in stackforge. 4. %(your_variant)s If we go down 1-2 route, should 1. ironic-core team own the new repo(s)? 2. or should we form a new team from interested people? (1 and 2 and not exclusive actually). I personally would go for #3 - stackforge. We already have e.g. stackforge/proliantutils as an example of something closely related to Ironic, but still independent. I'm also fine with #1#1 (one repo, owned by group of interested people). I don't think any of these third-party tools should be owned by the ironic team. I think that interested parties should get together (or not) to decide where they'd like to put their stuff. Ironic wiki pages (or somewhere) can have a link pointing to these other repo(s). --ruby [1] https://etherpad.openstack.org/p/liberty-ironic-rack-to-ready-state __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] When to bump the microversion?
On 06/04/2015 05:03 PM, Sean Dague wrote: On 06/04/2015 10:50 AM, Dmitry Tantsur wrote: On 06/04/2015 04:40 PM, Ruby Loo wrote: Hi, In Kilo, we introduced microversions but it seems to be a work-in-progress. There is an effort now to add microversion into the API-WG's guidelines, to provide a consistent way of using microversions across OpenStack projects [1]. Specifically, in the context of this email, there is a proposed guideline for when to bump the microversion [2]. As I understand this guideline tells to bump microversion on every change which I strongly -1 as usual. Reason: it's bump for the sake of bump, without any direct benefit for users (no, API discoverability is not one, because microversion do not solve it). I'll post the same comment to the guideline. Backwards compatible API adds with no user signaling is a fallacy because it assumes the arrow of time flows only one way. If at version 1.5 you have a resource that is foo { bar: ... } And then you decide you want to add another attribute foo { bar: ... baz: ... } And you don't bump the version, you'll get a set of users that use a cloud with baz, and incorrectly assume that version 1.5 of the API means that baz will always be there. Except, there are lots of clouds out there, including ones that might be at the code commit before it was added. Because there are lots of deploys in the world, your users can effectively go back in time. So now your API definition for version 1.5 is: foo, may or may not contain baz, and there is no way of you knowing if it will until you try. good luck. Which is pretty aweful. Which is not very different from your definition. Version 1.5 contains feature xyz, unless it's disabled by the configuration or patched out downstream. Well, 1.4 can also contain the feature, if downstream backported it. So good luck again. If you allow to group features under one microversion, that becomes even worse - you can have deployment that got microversion only partially. For example, that's what I would call API discoverability: $ ironic has-capability foobar true and that's how it would play with versioning: $ ironic --ironic-api-version 1.2 has-capability foobar false $ ironic --ironic-api-version 1.6 has-capability foobar true On the contrary, the only thing that microversion tells me is that the server installation is based on a particular upstream commit. To me these are orthogonal problems, and I believe they should be solved differently. Our disagreement is due to seeing them as one problem. Looking at your comments in the WG repo you also seem to only be considering projects shipped at Major release versions (Kilo, Liberty). Which might be true of Red Hat's product policy, but it's not generally true that all clouds are at a release boundary. Continous Deployment of OpenStack has been a value from Day 1, and many public clouds are not using releases, but are using arbitrary points off of master. I don't know why you decided I don't know it, but you're wrong. A microversion describes when a changes happens so that applications writers have a very firm contract about what they are talking to. No, they don't. Too many things can modify behavior - see above. -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
Re: [openstack-dev] [Ironic] When to bump the microversion?
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 time flows only one way. If at version 1.5 you have a resource that is foo { bar: ... } And then you decide you want to add another attribute foo { bar: ... baz: ... } And you don't bump the version, you'll get a set of users that use a cloud with baz, and incorrectly assume that version 1.5 of the API means that baz will always be there. Except, there are lots of clouds out there, including ones that might be at the code commit before it was added. Because there are lots of deploys in the world, your users can effectively go back in time. So now your API definition for version 1.5 is: foo, may or may not contain baz, and there is no way of you knowing if it will until you try. good luck. Which is pretty aweful. Oh, that's a good point, I can see the value on that. Perhaps the guide should define bumping the micro version something along these words: Whenever a change is made to the API which is visible to the client the micro version should be incremented ? This is powerful because gives the clients a fine grained way to detect what are the API features available. Cheers, Lucas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev