Re: [Openstack] [Horizon] UX Discussions - proposal for better organization, rising activity and awareness
I've been hoping some of the more design-oriented folks would weigh in on this issue, but that hasn't particularly happened... My concern is that as engineers we're all comfortable with GitHub, but that it will end up being an impediment or discouragement for people who fall more on the creative side. I don't disagree with the benefits as stated and I'm willing to give any solution a try, but I want to be careful that we don't alienate a portion of the contributors by our choice of tools. In general I leave it to the community, though. :-) - Gabriel -Original Message- From: Openstack [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Toshiyuki Hayashi Sent: Friday, June 14, 2013 11:50 AM To: Jaromir Coufal Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Horizon] UX Discussions - proposal for better organization, rising activity and awareness Hi Jarda, Thank you for sharing the G+ community, I just joined and will check the discussions! I hope we can move to GH shortly, the new G+ UI is not so good for discussions. On Wed, Jun 12, 2013 at 10:49 PM, Jaromir Coufal jcou...@redhat.com wrote: Hi Toshi, it's great to meet you and thanks for support. What you mentioned here is one of the issues: worse awareness of such an activity. Hopefully GH will enhance this (as well as the other issues). Apart from being among other projects, we can also help making it more visible with some note on OpenStack pages / Horizon Launchpad then. Anyway, the G+ community is at following address: https://plus.google.com/communities/100954512393463248122. If we agree here, I'd like to move to GH as soon as possible, so we have all discussions, proposals and materials archived there. Best -- Jarda On 2013/12/06 23:25, Toshiyuki Hayashi wrote: Hi Jarda, I'm Toshi, I'm also working on Horizon UI improvement (mainly network topology view). I totally agree with you. I've been wondering how to discuss the design ideas for Horizon, and I think we need some documents such as a design guideline to keep Horizon UI as a certain level of lookfeel and interactions. I believe your idea works very well for Horizon! BTW, I didn't know the Google+ community for Horizon. Could you please share the URL? On Tue, Jun 11, 2013 at 9:51 PM, Jaromir Coufal jcou...@redhat.com wrote: Hello Everybody! my name is Jarda (shortening from Jaromir) and I'm working on Horizon in a way of improvement the UX. Couple of weeks ago, there was set up community on Google+ to group UX related people to discuss designing issues. I think it was really great idea to start this effort and I love to see all people interested in helping Horizon being a better place. However, Google+ posts and discussions don't work very well for broader discussions about design issues, and I'd like to state here few examples of why I think so: - Comments are very narrow (worse readability, long comments are really bad supported). - Comments don't include images support. - There is no way where to store supportive materials. - Nobody knows what issues are resolved, what are still active. - No possibility to search for related topic (was this already discussed? Am I the first one to ask this?). - Notifications are also not from the best ones (activity of members just slipped down); not big awareness. ... and I have little bit more troubles with using it for design discussions. But long story short - I'd like to propose using GitHub for storing documentation and starting discussions related to UX of OpenStack (Horizon). In my opinion the best way to deal with UX in Horizon is to create a GitHub repository user_experience within OpenStack account, store related documentation in there and use GitHub Issues for discussions. Here are some benefits: * You can get subscribed to the repositoryor even just issue you are interested in, so you get notifications on your mail or just online (whatever works for you). * Issues are grouping topics very well together so the discussion for the topic stays at one place and everything is connected. * Once the issue is solved we can close it (and it is archived). * Issues have quite good options for text formatting. * You can past image directly to the post. * You can upload bigger temporary supportive materials to your forked repository. * The upstream repository itself can work as a good place to store UX documentations for Horizon (wireframes, documents, guides, etc). * What goes to the repository itself goes through pull-request process so we can make sure that there are ideas which were publicly discussed and accepted. Also, it provides better accessible way for any contributor, who is having some UX related issue. Since user_experience repository would be placed among other projects, it will be very easy to
Re: [Openstack] API version in Grizzly
OMG, table of contents on the API reference site is SO MUCH BETTER! :) Good to know about the Launchpad for the site. Didn't know about that one. - Gabriel From: annegen...@justwriteclick.com [mailto:annegen...@justwriteclick.com] On Behalf Of Anne Gentle Sent: Thursday, May 09, 2013 7:41 AM To: Gabriel Hurley Cc: Devendra Gupta; openstack@lists.launchpad.net Subject: Re: [Openstack] API version in Grizzly On Wed, May 8, 2013 at 6:57 PM, Gabriel Hurley gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote: In Grizzly I can send Keystone requests to either http://keystone_host:5000/v2.0/http://%3ckeystone_host%3e:5000/v2.0/ or to http://keystone_host:5000/v3/http://%3ckeystone_host%3e:5000/v3/ and both work just fine (provided I send the right request). Both APIs are enabled, and simply have different API controllers wired to different code paths under the hood. The only thing making one default is the fact that DevStack (and by extension a lot of guides and a lot of people's existing copy-pasted installations) have the Keystone v2.0 endpoint hard-coded into the service catalog. See the various threads and my TC proposal for further detail on what I think about that fact and what to do with it going forward. Okay, thanks for this explanation. Keystone team, this does not feel well documented. Let's come up with a plan for further explaining that in the docs. As for api.openstack.orghttp://api.openstack.org, I always look at the Complete Reference (http://api.openstack.org/api-ref.html) which lists one version for each service API (currently still Keystone v2.0). As long as you're taking feature requests, what I'd *like* to see when I land on that page is a collapsed list of each service API type (e.g. Identity, Compute, etc.) which I can then expand, revealing the list of available versions. Expanding one of those should yield what I currently see on the Complete Reference page. :) Good news, we have a new floating TOC and version labels that helps us go towards documenting all versions on the reference page as well. See http://api.openstack.org/api-ref.html. Ideally when you have ideas and needs like this you'll log a bug or blueprint at http://bugs.launchpad.net/openstack-api-site. Anne All the best, * Gabriel From: annegen...@justwriteclick.commailto:annegen...@justwriteclick.com [mailto:annegen...@justwriteclick.com] On Behalf Of Anne Gentle Sent: Wednesday, May 08, 2013 4:38 PM To: Gabriel Hurley Cc: Devendra Gupta; openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] API version in Grizzly On Wed, May 8, 2013 at 4:54 PM, Gabriel Hurley gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote: Identity service has both a v2.0 and v3 side-by-side. There isn't necessarily a default except for the fact that most people's Service Catalogs still say v2.0 in them because they're hard-coded that way. Wow, really? I have asked and asked about that API in particular and still don't understand how that really works. Can you explain more about how that can happen other than mis-labeled endpoints? In the future I believe the api.openstack.orghttp://api.openstack.org site would gain a lot by storing documentation for each version of the API for historical purposes, legacy deployments, etc. Sure would help me, too. ;-) Could you explain more about what storing documentation for each version of the API for historical purposes would look like to you? We have all versions (v 1.1, v2, v3.0) of each API spec stored. Do you want them published as well? We do so for Image API for example. Tell me more. Anne - Gabriel From: Openstack [mailto:openstack-bounces+gabriel.hurleymailto:openstack-bounces%2Bgabriel.hurley=nebula@lists.launchpad.netmailto:nebula@lists.launchpad.net] On Behalf Of Anne Gentle Sent: Wednesday, May 08, 2013 2:44 PM To: Devendra Gupta Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] API version in Grizzly Hi Devendra, Generally the guidance for the api.openstack.orghttp://api.openstack.org site is to publish documents that reflect the latest version, grizzly, as the underlying implementation for the API. However the cloud provider can pick and choose which extensions they have in place, for example, so some Compute extensions may be unavailable on essex for example. Generally I believe this list of API versions is true for Grizzly default implementations. PTLs please correct as needed: Identity Service API 2.0 Compute API 2 and Extensions Image Service API 2 (a provider could choose to implement v1) Object Storage API 1.0 Networking API 2.0 Block Storage Service API 2.0 Thanks, Anne On Wed, May 8, 2013 at 3:23 PM, Devendra Gupta dev29...@gmail.commailto:dev29...@gmail.com wrote: Hi, I am trying to find the lasted stable API versions of all the OpenStack components, I am looking around in OpenStack
Re: [Openstack] API version in Grizzly
When you say Identity v3.0 development is going on side-by-side so I think if I have Grizzly setup with Identity v2.0 then it'll be upgraded to Identity v3.0 with Grizzly when new version is available in updates. Though I might have option to upgrade it or not? OR Identity v3.0 will be released with Havana ? I believe you're still a little confused by what it means to upgrade to an API. The API version(s) are an inherent part of a particular release. Grizzly features both v2.0 and v3 Keystone APIs. They're both there. It's up to you when you want to upgrade to it by changing your endpoints, scripts, clients, etc. to take advantage of the new API. There will be further refinements in Havana, but v3 is here now. Another thing looks confusing to me in API Specification page http://docs.openstack.org/api/api-specs.html, we have version number mentioned with v1.0/v2.0 for some components (e.g. Object, Identity, Networking) but v1/v2 for few others (e.g. Image, Compute). Is there any special reason to not put .0 in version for some components ? The inconsistency is legitimate, not merely an oversight. Keystone dropped the .0 for the major versions in its URL structure. As such you would use http://host:5000/v2.0/ for v2.0 and http://host:5000/v3/ for the v3 API. Other services have chosen to include or exclude the .0 as they see fit. Unfortunately right now you just have to look up what the proper numbering format is for a particular API. All the best, - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] horizon nova endpoint usage question
If that config option is not being respected for the Nova API calls that's a bug. Please file a ticket on Launchpad so we can track fixing it. Thanks! - Gabriel From: Openstack [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Wyllys Ingersoll Sent: Thursday, May 09, 2013 1:19 PM To: openstack@lists.launchpad.net Subject: [Openstack] horizon nova endpoint usage question The Horizon UI novaclient method requests nova endpoints from the service catalog without specifying an endpoint_type parameter. Would it be more correct for those requests to default to the 'internalURL' instead? There are use cases where the publicURL is not exposed or defined, but if you leave publicURL undefined it causes some operations to fail because the code assumes the publicURL is always present and valid. The default for horizon-keystone service requests is to use the 'internalURL' and can be configured by the OPENSTACK_ENDPOINT_TYPE parameter in local_settings.py, but that doesn't seem to apply to any of the horizon-nova operations. Perhaps it should, or another parameter could be created to affect horizon-nova interactions. -Wyllys Ingersoll Evault ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Horizon - Internal Server Error when hitting /nova/instances_and_volumes/
If you have Instances Volumes then you're not running Grizzly Horizon. Those two were split apart in Grizzly. Prior to Grizzly the Volume Service was required. In Grizzly Horizon it's not. As such you have two choices: run Cinder like you are but don't use it, or upgrade so you're actually running Grizzly Horizon and don't run Cinder. All the best, - Gabriel -Original Message- From: Openstack [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Daniel Ellison Sent: Tuesday, May 07, 2013 11:01 AM To: OpenStack Users Subject: [Openstack] Horizon - Internal Server Error when hitting /nova/instances_and_volumes/ As the subject says, I'm having issues getting at Instances Volumes (also Images Snapshots) in Horizon. I'm running grizzly on precise. Everything else works fine; the entire Admin tab works as expected. The Overview and Access Security also work fine. Is there any way to see what calls are being made from horizon to nova? I debugged some previous issues by using --debug on some python client calls. But I don't think there's an equivalent in this case. The Apache log on my horizon machine (a VM under nova) shows the 500 error, then has a bunch of 404s when trying to retrieve media and other resources, e.g. /nova/images_and_snapshots/dashboard/css/style.css. For all other calls there are no 404 errors (and no 500 errors, needless to say). I'm only using Nova, Keystone and Glance for the moment. So no Cinder to consider, and no attached volumes. Does any of this sound familiar to anyone? Thanks, Daniel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] horizon dashboard error 500
There's something very wrong is false doesn't raise an exception. In Python False is a Boolean value, false is a variable name which should be undefined. That aside, you should set COMPRESS_OFFLINE=False in your openstack_dashboard/local/local_settings.py file. - Gabriel -Original Message- From: Openstack [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Rajesh Upadhayay Sent: Friday, May 03, 2013 10:18 AM To: Julie Pichon Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] horizon dashboard error 500 This has issue has been fixed by changing False as false. COMPRESS_OFFLINE = false -Original Message- From: Julie Pichon [mailto:jpic...@redhat.com] Sent: Friday, May 03, 2013 8:29 PM To: Rajesh Upadhayay Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] horizon dashboard error 500 Hi, Rajesh Upadhayay rupadha...@xavient.com wrote: I have just installed Openstack Grizzly on Ubuntu 12.04 LTS.. Everything was fine but after server reboot, I lost dashboard and getting error 500 Internal Server Error. I have verified all configuration but didn't get any idea. Have a look in the Apache error logs, there should be more information about the error. If this is a dev or test environment (not production), you could also set DEBUG to True in your local_settings.py to display more information when the error occurs. Regards, Julie ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] API version in Grizzly
Identity service has both a v2.0 and v3 side-by-side. There isn't necessarily a default except for the fact that most people's Service Catalogs still say v2.0 in them because they're hard-coded that way. In the future I believe the api.openstack.org site would gain a lot by storing documentation for each version of the API for historical purposes, legacy deployments, etc. Sure would help me, too. ;-) - Gabriel From: Openstack [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Anne Gentle Sent: Wednesday, May 08, 2013 2:44 PM To: Devendra Gupta Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] API version in Grizzly Hi Devendra, Generally the guidance for the api.openstack.orghttp://api.openstack.org site is to publish documents that reflect the latest version, grizzly, as the underlying implementation for the API. However the cloud provider can pick and choose which extensions they have in place, for example, so some Compute extensions may be unavailable on essex for example. Generally I believe this list of API versions is true for Grizzly default implementations. PTLs please correct as needed: Identity Service API 2.0 Compute API 2 and Extensions Image Service API 2 (a provider could choose to implement v1) Object Storage API 1.0 Networking API 2.0 Block Storage Service API 2.0 Thanks, Anne On Wed, May 8, 2013 at 3:23 PM, Devendra Gupta dev29...@gmail.commailto:dev29...@gmail.com wrote: Hi, I am trying to find the lasted stable API versions of all the OpenStack components, I am looking around in OpenStack docs but unable to see some specific page which says about particular version of APIs are available with Grizzly. I can see following pages but they don't say what version of API is latest stable with Grizzly. http://docs.openstack.org/api/api-specs.html http://api.openstack.org/api-ref.html I need this information to plan some work related to OpenStack, guidance around this would be highly appreciate. Thanks, Devendra ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] API version in Grizzly
In Grizzly I can send Keystone requests to either http://keystone_host:5000/v2.0/ or to http://keystone_host:5000/v3/ and both work just fine (provided I send the right request). Both APIs are enabled, and simply have different API controllers wired to different code paths under the hood. The only thing making one default is the fact that DevStack (and by extension a lot of guides and a lot of people's existing copy-pasted installations) have the Keystone v2.0 endpoint hard-coded into the service catalog. See the various threads and my TC proposal for further detail on what I think about that fact and what to do with it going forward. As for api.openstack.org, I always look at the Complete Reference (http://api.openstack.org/api-ref.html) which lists one version for each service API (currently still Keystone v2.0). As long as you're taking feature requests, what I'd *like* to see when I land on that page is a collapsed list of each service API type (e.g. Identity, Compute, etc.) which I can then expand, revealing the list of available versions. Expanding one of those should yield what I currently see on the Complete Reference page. :) All the best, - Gabriel From: annegen...@justwriteclick.com [mailto:annegen...@justwriteclick.com] On Behalf Of Anne Gentle Sent: Wednesday, May 08, 2013 4:38 PM To: Gabriel Hurley Cc: Devendra Gupta; openstack@lists.launchpad.net Subject: Re: [Openstack] API version in Grizzly On Wed, May 8, 2013 at 4:54 PM, Gabriel Hurley gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote: Identity service has both a v2.0 and v3 side-by-side. There isn't necessarily a default except for the fact that most people's Service Catalogs still say v2.0 in them because they're hard-coded that way. Wow, really? I have asked and asked about that API in particular and still don't understand how that really works. Can you explain more about how that can happen other than mis-labeled endpoints? In the future I believe the api.openstack.orghttp://api.openstack.org site would gain a lot by storing documentation for each version of the API for historical purposes, legacy deployments, etc. Sure would help me, too. ;-) Could you explain more about what storing documentation for each version of the API for historical purposes would look like to you? We have all versions (v 1.1, v2, v3.0) of each API spec stored. Do you want them published as well? We do so for Image API for example. Tell me more. Anne - Gabriel From: Openstack [mailto:openstack-bounces+gabriel.hurleymailto:openstack-bounces%2Bgabriel.hurley=nebula@lists.launchpad.netmailto:nebula@lists.launchpad.net] On Behalf Of Anne Gentle Sent: Wednesday, May 08, 2013 2:44 PM To: Devendra Gupta Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] API version in Grizzly Hi Devendra, Generally the guidance for the api.openstack.orghttp://api.openstack.org site is to publish documents that reflect the latest version, grizzly, as the underlying implementation for the API. However the cloud provider can pick and choose which extensions they have in place, for example, so some Compute extensions may be unavailable on essex for example. Generally I believe this list of API versions is true for Grizzly default implementations. PTLs please correct as needed: Identity Service API 2.0 Compute API 2 and Extensions Image Service API 2 (a provider could choose to implement v1) Object Storage API 1.0 Networking API 2.0 Block Storage Service API 2.0 Thanks, Anne On Wed, May 8, 2013 at 3:23 PM, Devendra Gupta dev29...@gmail.commailto:dev29...@gmail.com wrote: Hi, I am trying to find the lasted stable API versions of all the OpenStack components, I am looking around in OpenStack docs but unable to see some specific page which says about particular version of APIs are available with Grizzly. I can see following pages but they don't say what version of API is latest stable with Grizzly. http://docs.openstack.org/api/api-specs.html http://api.openstack.org/api-ref.html I need this information to plan some work related to OpenStack, guidance around this would be highly appreciate. Thanks, Devendra ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
Do you have plans to add comparison matrices, user counts, github stats, categories (aside from arbitrary tags), etc.? No offense meant to stackmeat, but the OpenComparison project is way ahead in terms of features that make it easy for consumers to make educated choices about the projects/tools they're choosing. It's Python-based and used for lots of other Python communities. If stackmeat wants to re-invest the energy to get there that's your prerogative, but we desperately need better tooling for our ecosystem. All the best, - Gabriel From: Openstack [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Marton Kiss Sent: Friday, May 03, 2013 12:15 PM To: Thierry Carrez Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Related Projects I'm taking care of stackmeat, and some feature upgrade is in the queue. If somebody like to join and help in content management, any help is welcome from my part. Regards, Márton 2013/5/3 Thierry Carrez thie...@openstack.orgmailto:thie...@openstack.org Jeremy Stanley wrote: On 2013-05-03 12:12:25 +0200 (+0200), Thierry Carrez wrote: Isn't that what stackmeat.orghttp://stackmeat.org was supposed to cover ? Doesn't this transcluded RelatedProjects wikipage kind of duplicate this effort ? [...] Good point--I'd sadly forgotten about stackmeat.org... perhaps https://wiki.openstack.org/wiki/RelatedProjects should just be deleted, the project owners encouraged to register their entries on http://stackmeat.org/ (if they haven't already), and link that from https://wiki.openstack.org/wiki/Projects#Unofficial.2Frelated_projects to improve its discoverability a little more? Unless stackmeat is considered abandoned, that sounds like the right way to go. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Related Projects
+1. And I'd add that we need to do everything in our collective power to treat OpenStack as a coherent whole, not as a loosely federated set of projects that are released together. We are still a young community, but doing things to build supporting tools, expose commonalities and overlaps, and further healthy competition are all tremendously valuable. Don't force the solutions, build the ecosystem in which projects can compete. Tend the garden so the plants can thrive. The line between fragmentation and healthy competition lies mostly in the bounds set by the community and the leadership. Let's work on that. - Gabriel From: Openstack [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Matt Joyce Sent: Friday, May 03, 2013 2:25 PM To: Marton Kiss Cc: Michael Bright; Thierry Carrez; openstack@lists.launchpad.net Subject: Re: [Openstack] Related Projects This is going to come off as a bit of a rant. Pardon me. I feel it needs saying. There's a few ways to look at what OpenStack is. It's an IaaS solution. It's a cloud solution. But at it's heart, core to the design principles of OpenStack development ideology it is a collection of tools designed specifically to support elastic design patterns. The reason I bring this up is because of some thinking I've been doing about the future of OpenStack. Where it's place is in the world. Where it's place will be in the world. I've found that despite the crass nature of the puppies vs cattle explanation of elastic design, it really does get the most important selling point home to potential customers, and engineers who don't do ec2 already. And that point is that OpenStack exists to further a design pattern. It's not about clouds, or IaaS. It's about a design pattern. The pattern of horizontal scalability. The pattern of ephemeral resources. The pattern of share nothing. These core design ethics allow us to build software in a fashion that makes it consumable, scalable, and fault tolerant beyond any existing pattern by far. It makes development efforts become commodities that can be openly traded on a market free or otherwise. We need to stop thinking of OpenStack as just an IaaS solution. Or just a cloud. It's a development platform. It's a way of building software well. Once we do that, we can look to the past and see where we need to go. We want OpenStack to enjoy the some level of success as Java, or python as a collaborative development environment. We want kids in colleges to be training to write the next 50 years of applications in our environment, following our design patterns. But to do that, and to do it well, we'll need to solve a few things. This thread points to a growing problem in our community. One that was a primary focus of discussion in the last summit. OpenStack deployments are growing up and they are growing apart. We're building things too differently. The reason we employed PEP-8 gate tests, and the reason python works as a language in general is in part because when you give developers too many options, you end up losing a common language, or methodology that allows us to easily come up to speed on each others work. It makes collaboration hard. Now, not to start a language war, but I love perl. Nothing rips apart text like perl. Nothing. But, at the same time, I know that if I write perl code, it's going to be a pain in the ass for someone to come back to that code later and maintain it. Python on the other hand, especially with PEP-8, restricts a developers aesthetic options. It forces us to follow a common grammar. My point here, is that when you ask people what languages work with a 100+ active developers working on the same project, you get responses like Java, C#, maybe python. And you say, well why? And one of the responses is that Java and C# have an extensive common library. It allows developers to share a common method set. We've already begun the task of creating oslo to solve part of that problem for us in development. But in deployment, we're woefully behind the curve. We want to support diversity in the market eco system, but we also want to ensure that an OpenStack environment is adherent to some sort of baseline or flavor set. That is why folks have begun pushing things like refstack. I look at this thread, and what I see is a further need to unify solutions into a community supported method set that trumps outliers and one offs. A common set of tools. A common library of solutions. If OpenStack is to be the development environment of the next 75 years or more, we need to build this. It's one part of the many things we need to and are doing. But it's an important part. I think we can't just say, this isn't part of openstack, or this is outside of scope. It's part of the development environment that OpenStack is the runtime environment for ( forgive the analogy ). Anyways,
Re: [Openstack] Related Projects
I'll throw it out there again: We really ought to deploy an OpenComparison site (http://opencomparison.org/) for OpenStack. It's awesome, and does massive amounts of goodness for managed information and discovery. - Gabriel -Original Message- From: Openstack [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Jeremy Stanley Sent: Thursday, May 02, 2013 3:45 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Related Projects On 2013-05-02 07:05:46 -0700 (-0700), Michael J Fork wrote: [...] Could one of the admins link it from https://wiki.openstack.org/ wiki/Projects? I've added a section heading for this and transcluded your article at... https://wiki.openstack.org/wiki/Projects#Unofficial.2Frelated_projects Hopefully this satisfies everyone involved, but if not we can easily change it. -- Jeremy Stanley ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Grizzly Dashboard Quota Problem...
We landed a fix in Horizon yesterday ( tracked in https://bugs.launchpad.net/horizon/+bug/1155876 ) that addresses this problem for the Grizzly RC. Nova should have followed a proper deprecation path here and accepted the parameters in this release and reject them (if they really must) in Havana. Stripping them out in novaclient and logging a deprecation warning would also have been an acceptable solution. In general, any backwards-incompatible change in an API needs to be versioned and/or properly deprecated. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Kevin L. Mitchell Sent: Monday, March 18, 2013 11:11 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Grizzly Dashboard Quota Problem... On Mon, 2013-03-18 at 14:57 -0300, Martinx - ジェームズ wrote: I'm reinstalling everything (Grizzly from PPA) from scratch again, if I hit the BUG one more time, I'll let you guys know. I believe the quota settings error is a bug in nova, rather than in horizon or novaclient. The problem is that, recently, a change went in that causes nova to reject quota update requests that have unrecognized quotas. The problem is that older versions of nova had two quota resources (gigabytes and volumes) that have been removed in Grizzly, because of the nova/cinder split. Thus, all clients that operate against pre-Grizzly nova will fail to work with Grizzly nova…and it is also the case that novaclient and probably horizon have not been updated to remove those two quota resources. The correct fix will probably be to revert the nova merge that causes this HttpBadRequest to be raised, and to subsequently apply the IETF mantra: Be liberal in what you accept and conservative in what you send. -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Horizon PTL Candidacy
Hi folks! I'm nominating myself for Horizon PTL for another term. I want to continue fighting for cross-service integration/standardization, better APIs for everyone, and the best possible user interface to introduce people to what OpenStack can do. Quick recap of my qualifications: current Horizon PTL, Horizon core and Keystone core since Essex, Django core contributor, commits to nearly all of the core OpenStack projects, extremely comprehensive knowledge of OpenStack's APIs, and a connoisseur of both OpenStack and fine whiskeys. Here's to a fantastic Havana release cycle! - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Horizon Keystone Nova miscommunication
That particular endpoint not found log message is a red herring. It's been
removed in keystoneclient trunk because it was logging an *expected* error.
There isn't supposed to be a service catalog available at the point at which it
logged that message, and it lead to confusion just like this.
However, as for your actual problem, I've got a couple broad ideas:
Since you're able to log in that means Keystone is working. And since you're
not seeing any error messages indicating that the data couldn't be retrieved
from Nova, that means Nova is working and is truly believes that the tenant
you're requesting data for has no instances, etc.
What that sounds like to me is that you're creating things in Nova with one
tenant, and then looking for them in Horizon with a different tenant. The
easiest way to check for that would be to log into horizon with a user who has
the admin role on a project, navigate to the Instances panel in the Admin
dashboard, and see if you can see the missing instances there. The admin
instances panel shows *all* running instances across all tenants, so if the
instances exist and Nova is returning data then they'll show up there.
The other (much less likely) possibility is that you somehow have two Nova
services running which are unaware of each other, and you're managing to talk
to different ones via the client vs. Horizon. I have to think you'd know if you
were running two Nova's, however.
The last option would be that Keystone's service catalog is misconfigured and
you're not actually communicating with Nova, but if that were the case you
should be seeing errors all over the place, so I find that highly unlikely.
Hope something there helps.
- Gabriel
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On
Behalf Of Greg Chavez
Sent: Saturday, February 16, 2013 11:54 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] Horizon Keystone Nova miscommunication
It seems that nova and horizon are not communicating on my controller node.
Acces and security objects created with nova are not seen by Horizon and vice
versa. This includes key pairs and secgroup rules. For example, if I create a
keypair with the nova client, it isn't visible in horizon, and if I create one
in horizon it is not visible via the nova client.
Possibly related: VMs that I create, whether via the nova client or Horizon,
are not shown with I run nova list. The nova-api.log shows a successful
servers-detail query, but it comes back empty.
Also possibly related: Although I have all my services and endpoints configured
correctly, I can't get individual endpoint detail with endpoint-get. What's
more, I see this error in Horizon's error log:
[Sun Feb 17 07:02:50 2013] [error] EndpointNotFound: Endpoint not found.
[Sun Feb 17 07:06:55 2013] [error] unable to retrieve service catalog with token
This matches what I get when I run:
$ keystone endpoint-get --service nova
Endpoint not found.
But that can't be because endpoint-list shows all six endpoints I created and
all the information seems correct in the database:
mysql select * from endpoint where service_id
='9e40d355b49342f8ac6947c497df76d2'\G
*** 1. row ***
id: 922baafde75f4cffa7dbe7f57cddb951
region: RegionOne
service_id: 9e40d355b49342f8ac6947c497df76d2
extra: {adminurl: http://192.168.241.100:35357/v2.0;, internalurl:
http://192.168.241.100:5000/v2.0;, publicurl:
http://10.21.164.75:5000/v2.0}
1 row in set (0.00 sec)
mysql select * from service where id ='9e40d355b49342f8ac6947c497df76d2'\G
*** 1. row ***
id: 9e40d355b49342f8ac6947c497df76d2
type: identity
extra: {description: OpenStack Identity, name: keystone}
1 row in set (0.00 sec)
Please please please help me. My boss is giving my project the ax on Monday if
I can't get this to work.
--
\*..+.-
--Greg Chavez
+//..;};
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Horizon and open connections
Even though I don't experience this problem (and prefer nginx to apache), I can help diagnose: Connections ending up in CLOSE_WAIT means that the socket isn't being fully closed, which is controlled by the client lib (in this case python-keystoneclient) which uses httplib2 under the hood. When requests complete successfully httplib2 *does* close the connections just fine, so I'm wondering if you're actually triggering some kind of unhandled exception in keystoneclient. Are you seeing any errors in your logs anywhere? It's also worth noting that httplib2 has some very peculiar retry behaviors and other vagaries that come into play when the remote endpoint is unresponsive, etc. Another potential problem is if you're running a proxy layer (such as haproxy) in the middle there are various configuration options which can cause the connection to remain open even after the backend has sent a complete response (adding inappropriate keep-alive headers, stripping connection: close, filtering packets, etc.). The same is true of any other middleware you might be running that could get between the python process opening the socket and the remote end returning a response. Hope something in there helps, - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Sam Morrison Sent: Wednesday, January 30, 2013 7:36 PM To: openstack@lists.launchpad.net list Subject: [Openstack] Horizon and open connections We have horizon running based on the Ubuntu Folsom Cloud Archive packages. What I notice is that after a while we have thousands of connections in the CLOSE_WAIT state to keystone and our nova api servers. The host also uses up all it's available memory (2GB) After a restart of apache all the connections are cleaned up and the memory used drops down to about 200MB Just wondering if this is supposed to happen or is there a bug. It seems to me that horizon isn't closing connections or something. Anyone have a similar issue/solution? Cheers, Sam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Poll: H release cycle naming
Also, aren't the release names always *California* cities? Thereby Hillsboro, Oregon isn't a valid choice... - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: Thursday, January 24, 2013 11:52 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Poll: H release cycle naming Adam Young wrote: I think we have overlooked the most obvious answer: [...] To keep the single-choice poll efficient, the Technical Committee preselected 4 finalists from the list of 35 (!) valid options. Sorry your preferred option didn't make it. -- Thierry Carrez (ttx) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Poll: H release cycle naming
I stand corrected! Thanks. ;-) - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Mark T. Voelker Sent: Monday, January 28, 2013 1:18 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Poll: H release cycle naming Also, aren't the release names always *California* cities? Nope. =) http://wiki.openstack.org/ReleaseNaming At Your Service, -- Mark T. Voelker On 1/28/13 3:23 PM, Gabriel Hurley wrote: Also, aren't the release names always *California* cities? Thereby Hillsboro, Oregon isn't a valid choice... - Gabriel -Original Message- From: openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: Thursday, January 24, 2013 11:52 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Poll: H release cycle naming Adam Young wrote: I think we have overlooked the most obvious answer: [...] To keep the single-choice poll efficient, the Technical Committee preselected 4 finalists from the list of 35 (!) valid options. Sorry your preferred option didn't make it. -- Thierry Carrez (ttx) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New to OpenStack - question Swift+Keystone Horizon
Horizon's list of required services includes Nova, Glance and Keystone. At
present no work has been done to make it run with a Swift + Keystone (only)
configuration. That said, it's not impossible. The easiest route would likely
be to unregister all of the Nova and Glance-related panels in the existing
System and Project dashboards (this can be done using Horizon's
customization_module setting, though documentation for it is minimal), and
provide a custom user_home function that directs users to the Containers
(e.g. Swift) panel upon login.
In general as long as you don't ever touch any of the panels that try to make
API calls to Nova or Glance you can avoid having to run those services.
Unfortunately, *a lot* of the panels *do* make calls to those services. The
Swift Containers panel does not, though, so it can be done.
Keystone is absolutely required, though, along with proper Swift + Keystone
auth integration. That part is critical.
All the best,
- Gabriel
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On
Behalf Of Brian Ipsen
Sent: Wednesday, January 16, 2013 1:29 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] New to OpenStack - question Swift+Keystone Horizon
Hi
I have just started to take a look at OpenStack (especially Swift, as this is
what is most needed for a case I am investigating).
So far I have managed to get a Swift node up and running (all-in-one) on
Ubuntu, but for some reasons I have been asked to take at look at the RedHat
preview-implementation of the Folsom release.
Since Nova and the other parts not are needed, I would prefer not to install
those parts... But will Horizon still be able to work - just with Swift and the
underlying identity service based on keystone ?
I have tried the RedHat approach, and Keystone is up and running. I then tried
to install and configure Horizon according to the RedHat instructions (and
installed Swift afterwards). But whenever I log on to the Horizon interface, I
get an internal server error page back.
Sine I don't know whether Horizon will run on such a limited setup (and I have
not been able to locate information about it), I don't know whether it could be
a bug in the RedHat implementation - or it simply is an unsupported setup...
Regards
Brian
PS: The error I get is this (from httpd error log):
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] mod_wsgi (pid=1715):
Exception occurred processing WSGI script
'/usr/share/openstack-dashboard/openstack_dashboard/wsgi/django.wsgi'.
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] Traceback (most recent
call last):
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] File
/usr/lib/python2.6/site-packages/django/core/handlers/wsgi.py, line 241, in
__call__
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] response =
self.get_response(request)
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] File
/usr/lib/python2.6/site-packages/django/core/handlers/base.py, line 179, in
get_response
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] response =
self.handle_uncaught_exception(request, resolver, sys.exc_info())
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] File
/usr/lib/python2.6/site-packages/django/core/handlers/base.py, line 228, in
handle_uncaught_exception
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] return
callback(request, **param_dict)
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] File
/usr/lib/python2.6/site-packages/django/utils/decorators.py, line 91, in
_wrapped_view
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] response =
view_func(request, *args, **kwargs)
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] File
/usr/lib/python2.6/site-packages/django/views/defaults.py, line 33, in
server_error
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] return
http.HttpResponseServerError(t.render(Context({})))
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] File
/usr/lib/python2.6/site-packages/django/template/base.py, line 140, in render
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] return
self._render(context)
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] File
/usr/lib/python2.6/site-packages/django/template/base.py, line 134, in _render
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] return
self.nodelist.render(context)
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] File
/usr/lib/python2.6/site-packages/django/template/base.py, line 823, in render
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] bit =
self.render_node(node, context)
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] File
/usr/lib/python2.6/site-packages/django/template/base.py, line 837, in
render_node
[Wed Jan 16 20:12:40 2013] [error] [client 10.41.43.34] return
Re: [Openstack] Dashboard/horizon PRODUCTION bug
I haven't heard a report like this from anyone else. Looking at your patch it looks like you're having problems with the sub-module imports for some reason, which sounds to me like a Python problem. Is there anything unusual about your version of Python? Any unusual/duplicate packages on your python path that might be causing name conflicts/import errors? - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Sina Sadeghi Sent: Wednesday, January 09, 2013 7:54 PM To: openstack Subject: [Openstack] Dashboard/horizon PRODUCTION bug I just upgraded the openstack-dashboard we are using to the latest version provided by Ubuntu Cloud Archive. There were multiple bugs causing Internal Server Error which I had to patch manually to rectify, I couldn't see anyone reporting the same errors after a brief google search. Can someone examine the patch provided and please confirm whether they have this issue or not? I'm running Ubuntu 12.04 with Folsom installed using the Ubuntu Cloud Archive. # dpkg -l | grep -e 'openstack\|horizon' ii openstack-dashboard 2012.2-0ubuntu2~cloud0 django web interface to Openstack ii openstack-dashboard-ubuntu-theme 2012.2-0ubuntu2~cloud0 Ubuntu theme for the Openstack dashboard ii python-django-horizon2012.2-0ubuntu2~cloud0 Django module providing web based interaction with OpenStack ii python-django-openstack 2012.2-0ubuntu2~cloud0 dummy transitonal package from python-django-openstack to python-django-horizon ii python-openstack-auth1.0.1-0ubuntu6~cloud0A django authentication backend for Openstack I have attached the main patch I had to apply to get dashboard working again, but I also had to patch: /usr/lib/python2.7/dist-packages/horizon/dashboards/settings/project/views.py to change from horizon.api import keystone to from horizon.api import keystoneclient as well. If this is an actual bug I'm happy to file and supply the patch as appropriate. -- -- Sina Sadeghi Lead Cloud Engineer [cid:image001.jpg@01CDEF1D.ABEFEC50] Aptira Pty Ltd 1800 APTIRA aptira.comhttp://www.aptira.com Follow @aptirahttps://twitter.com/#/aptira inline: image001.jpg___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack Dashboard + WebServer
The DevStack and Ubuntu configurations run with the Ubuntu distro's default version of Apache and modWSGI. Personally I'm also a big fan of NginX. Horizon, being a Django/WSGI-compliant application can run behind any webserver that supports the Python WSGI standard. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Andrew Holway Sent: Thursday, December 13, 2012 6:39 AM To: Desta Haileselassie Hagos Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack Dashboard + WebServer Its vanilla apache httpd afaik. On Dec 13, 2012, at 3:31 PM, Desta Haileselassie Hagos wrote: Hey guys, What sort of Web Server is behind OpenStack dashboard (horizon)? Is it some sort of Apache??? Cheers, Desta ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Horizon - OfflineGenerationError
Have you tried doing what it said and running manage.py compress? (make sure you're in the proper Python environment/venv when running that command) That error indicates one of two things: 1. You have your settings set with COMPRESS_ENABLED = True and COMPRESS_OFFLINE = True but you haven't run manage.py compress, or... 2. There was an error while trying to compress the files such as not being able to find a particular file or a permissions problem on an input file or output directory. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of JuanFra Rodriguez Cardoso Sent: Thursday, December 13, 2012 4:37 AM To: Matthias Runge Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Horizon - OfflineGenerationError Hi Matthias: Thanks for replying. Rest of openstack services are working ok. Theses are versions installed of Horizon and Django (from EPEL 6.7) - openstack-dashboard-2012.2-4.el6.noarch. - Django14-1.4.2-2.el6.noarch Do you recommend I install Horizon from github repository? Thanks! 2012/12/13 Matthias Runge mru...@redhat.commailto:mru...@redhat.com On 12/13/2012 12:24 PM, JuanFra Rodriguez Cardoso wrote: Hi all: I'm installing OpenStack Dashboard 2012.2 on CentOS 6.3 and I got next error related to css/js compression: Yes, I bet, it's not related with Dashboard, although the error message tells you so. Which version are you installing from where? Do you see other issues with your openstack-installation? Please note, the minimum required set of OpenStack services running includes the following: + Nova (compute, api, scheduler, network, and volume services) + Glance + Keystone Instead of nova volume, you could also use cinder volume. Did you install there and are they working ok? Matthias File /usr/lib/python2.6/site-packages/django/template/base.py, line 837, in render_node [Thu Dec 13 11:58:37 2012] [error] [client 192.10.1.36] return node.render(context) [Thu Dec 13 11:58:37 2012] [error] [client 192.10.1.36] File /usr/lib/python2.6/site-packages/compressor/templatetags/compress.py, line 147, in render [Thu Dec 13 11:58:37 2012] [error] [client 192.10.1.36] return self.render_compressed(context, self.kind, self.mode, forced=forced) [Thu Dec 13 11:58:37 2012] [error] [client 192.10.1.36] File /usr/lib/python2.6/site-packages/compressor/templatetags/compress.py, line 88, in render_compressed [Thu Dec 13 11:58:37 2012] [error] [client 192.10.1.36] cached_offline = self.render_offline(context, forced=forced) [Thu Dec 13 11:58:37 2012] [error] [client 192.10.1.36] File /usr/lib/python2.6/site-packages/compressor/templatetags/compress.py, line 72, in render_offline [Thu Dec 13 11:58:37 2012] [error] [client 192.10.1.36] 'You may need to run python manage.py compress.' % key) [Thu Dec 13 11:58:37 2012] [error] [client 192.10.1.36] OfflineGenerationError: You have offline compression enabled but key 1056718f92f8d4204721bac759b3871a is missing from offline manifest. You may need to run python manage.py compress. [Thu Dec 13 11:58:37 2012] [error] [client 192.10.1.36] File does not exist: /var/www/html/favicon.ico any idea for solving it? Thanks, JuanFra. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Do we have any schema for keystone v3.0 request/responses
It sounds like you *could* start updating and submitting it, but with the knowledge that you’ll have to continue to tweak it just as the JSON spec is being tweaked during development. So your options are to maintain it as such or wait until it’s declared FINAL and then do the work later on but only once. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Jorge Williams Sent: Wednesday, December 05, 2012 7:04 PM To: heckj; Ali, Haneef Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Do we have any schema for keystone v3.0 request/responses I was waiting for things to stabilize. Give me the go ahead Joe and I'll update and submit. Sent from my Motorola Smartphone on the Now Network from Sprint! -Original message- From: heckj he...@mac.commailto:he...@mac.com To: Ali, Haneef haneef@hp.commailto:haneef@hp.com Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Sent: Wed, Dec 5, 2012 18:32:03 CST Subject: Re: [Openstack] Do we have any schema for keystone v3.0 request/responses Hey Ali, We don't have an XSD for the V3 API sets - we've been holding off finalizing that up as we are making small implementation changes as we're getting it into practice and learning what ideas worked, and which didn't. Jorge (Rackspace) has something and offered to do more, but hasn't submitted it up for review, and I don't know what state it's in. We also have modifications to the /token portion of the API that are pending final implementation (Guang is working on these now) - when that's complete, we'd very much welcome you helping us construct an XSD for ongoing use. -joe On Dec 5, 2012, at 4:16 PM, Ali, Haneef haneef@hp.commailto:haneef@hp.com wrote: Hi, Do we have any XSD file for keystone v3.0 api? All the examples show only json format. I don’t see even a single request/response example using xml. Does keystone v3.0 support xml content-type? If so what is the namespace for the v3.0 schema? Thanks Haneef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [horizon] Select a key pair by default in launch instance?
Agreed. I've been thinking that for a while. I've been thinking keypair should be promoted to the main tab of the Launch workflow, even. Patches welcome. :-) - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Kieran Spear Sent: Monday, December 03, 2012 4:18 PM To: openstack@lists.launchpad.net Subject: [Openstack] [horizon] Select a key pair by default in launch instance? Hi all, I've had a few requests from users who forget to select a key pair when launching an instance through the dashboard. I do this myself quite often. Can we select the first available key pair by default, much like what is done with security groups? Most of our users only have a single key pair anyway. Cheers, Kieran ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Dashboard boot from volume question
Yep, what Vish said. Everything about the current Boot From Volume UI is driven by contraints from Nova which the Nova core team is aware of and is working to fix. I will certainly not argue that the current UX in Horizon around it is any good at all. Look for improvements in the late G or H timeframe. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Vishvananda Ishaya Sent: Tuesday, November 27, 2012 8:24 AM To: Sina Sadeghi Cc: openstack Subject: Re: [Openstack] Dashboard boot from volume question On Nov 26, 2012, at 7:30 PM, Sina Sadeghi s...@aptira.commailto:s...@aptira.com wrote: Hi again list, I am wondering why the dashboard UI around booting from volume is setup the way it is? Currently the user is presented with an Instance source: pulldown menu when they want to launch an instance. Only Image and Snapshot are present in this list. A user must go to the volume tab and specify boot from volume there. However, if the user does not also specify an image or snapshot, then the error Please select an option for the instance source. is presented to the user. Shouldn't the Instance source: pulldown menu have a Volume list item so this error doesn't occur? This would definitely make more sense. Unfortunately image id is still required even when booting from volume. There is some work being done to fix this for grizzly, so hopefully soon that will be an option. There is a bit of additional work needed around the ux of booting from a volume. It would be nice if the ui offered an option to select an image and have it copied to a volume automatically for you at boot time, but there are still a few blockers before that works cleanly. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Essex Dashboard: KeyError at /nova/instances_and_volumes/
That is actually the manifestation of a bug in Nova that was addressed very
late in Folsom. The short version is that Nova inconsistently scoped the
ownership of volumes vs. instances so it was possible for an admin user to view
a mixed set of resources which could lead to the scenario you hit where things
are in one list but not the other. I'm not sure if there's any plans to
backport the fixes from Nova. A patch could probably be worked up for the
stable/essex Horizon branch that would avoid the keyerror (see the state of
that code in Folsom:
https://github.com/openstack/horizon/blob/stable/folsom/horizon/dashboards/nova/volumes/views.py#L68
), but it would be papering over what is inherently a broken situation in Nova.
My advice from back in the Essex days was that you should be wary of using an
admin user in the Project dashboard since the underlying APIs didn't handle
it correctly.
Alternatively, the Folsom Horizon release is actually backwards-compatible to
an Essex stack, so you could try running Folsom Horizon which is less subject
to many issues.
Hope one of these suggestions helps!
- Gabriel
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On
Behalf Of Christian Parpart
Sent: Monday, November 12, 2012 3:37 AM
To: openstack@lists.launchpad.net
Subject: [Openstack] Essex Dashboard: KeyError at /nova/instances_and_volumes/
Hey all,
since quite some weeks I am getting an error page instead of the Instances and
Volumes page in the
Essex Horizon Dashboard with the above title and the below detailed error
output:
Environment:
Request Method: GET
Request URL: http://controller.rz.dawanda.com/nova/instances_and_volumes/
Django Version: 1.3.1
Python Version: 2.7.3
Installed Applications:
['openstack_dashboard',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'django_nose',
'horizon',
'horizon.dashboards.nova',
'horizon.dashboards.syspanel',
'horizon.dashboards.settings']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'openstack_dashboard.middleware.DashboardLogUnhandledExceptionsMiddleware',
'horizon.middleware.HorizonMiddleware',
'django.middleware.doc.XViewMiddleware',
'django.middleware.locale.LocaleMiddleware')
Traceback:
File /usr/lib/python2.7/dist-packages/django/core/handlers/base.py in
get_response
111. response = callback(request, *callback_args,
**callback_kwargs)
File /usr/lib/python2.7/dist-packages/horizon/decorators.py in dec
40. return view_func(request, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/horizon/decorators.py in dec
55. return view_func(request, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/horizon/decorators.py in dec
40. return view_func(request, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/django/views/generic/base.py in view
47. return self.dispatch(request, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/django/views/generic/base.py in dispatch
68. return handler(request, *args, **kwargs)
File /usr/lib/python2.7/dist-packages/horizon/tables/views.py in get
105. handled = self.construct_tables()
File /usr/lib/python2.7/dist-packages/horizon/tables/views.py in
construct_tables
96. handled = self.handle_table(table)
File /usr/lib/python2.7/dist-packages/horizon/tables/views.py in handle_table
68. data = self._get_data_dict()
File /usr/lib/python2.7/dist-packages/horizon/tables/views.py in
_get_data_dict
37. self._data[table._meta.namehttp://meta.name] =
data_func()
File
/usr/lib/python2.7/dist-packages/horizon/dashboards/nova/instances_and_volumes/views.py
in get_volumes_data
74. att['instance'] = instances[att['server_id']]
Exception Type: KeyError at /nova/instances_and_volumes/
Exception Value: u'8aa2989e-85ea-4975-b81b-04d06dbf8013'
now I wonder in how far that is a bug in the software and/or whether I have an
invalid entry in my nova database that
I can fix by hand.
if so, does anyone know how to actually work around this? I do really need this
(now not working) page :-)
Regards,
Christian Parpart.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Horizon] Error in /var/log/apache2/error.log
Your Quantum API route is returning a 404. Whether this is because you have
your route wrong or Quantum is misconfigured or [something else] I could tell
you. I would recommend narrowing down your possibilities by trying to make the
call directly with quantumclient or using curl to make the request directly and
to look at your Quantum logs to see if there's something evidently amiss.
All the best,
- Gabriel
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On
Behalf Of Srikanth Kumar Lingala
Sent: Monday, November 12, 2012 8:00 AM
To: openstack@lists.launchpad.net; openstack-...@lists.openstack.org
Subject: [Openstack] [Horizon] Error in /var/log/apache2/error.log
Hi,
I created a custom page in horizon. Most of the new page is working fine.
But, when I wanted to load some custom 'quantum' DB table data in horizon, I am
getting the following error in '/var/log/apache2/error.log':
Traceback (most recent call last):
[Mon Nov 12 15:52:58 2012] [error] File
/usr/lib/python2.7/dist-packages/horizon/dashboards/nova/services/configs/tabs.py,
line 42, in get_context_data
[Mon Nov 12 15:52:58 2012] [error] config =
api.quantum.dhcp_config_get(self.request, config_id)
[Mon Nov 12 15:52:58 2012] [error] File
/usr/lib/python2.7/dist-packages/horizon/api/quantum.py, line 247, in
dhcp_config_get
[Mon Nov 12 15:52:58 2012] [error] **params).get('config')
[Mon Nov 12 15:52:58 2012] [error] File
/usr/lib/python2.7/dist-packages/quantumclient/v2_0/client.py, line 102, in
with_params
[Mon Nov 12 15:52:58 2012] [error] ret = self.function(instance, *args,
**kwargs)
[Mon Nov 12 15:52:58 2012] [error] File
/usr/lib/python2.7/dist-packages/quantumclient/v2_0/client.py, line 330, in
show_config
[Mon Nov 12 15:52:58 2012] [error] return self.get(self.config_path %
(config), params=_params)
[Mon Nov 12 15:52:58 2012] [error] File
/usr/lib/python2.7/dist-packages/quantumclient/v2_0/client.py, line 620, in
get
[Mon Nov 12 15:52:58 2012] [error] headers=headers, params=params)
[Mon Nov 12 15:52:58 2012] [error] File
/usr/lib/python2.7/dist-packages/quantumclient/v2_0/client.py, line 605, in
retry_request
[Mon Nov 12 15:52:58 2012] [error] headers=headers, params=params)
[Mon Nov 12 15:52:58 2012] [error] File
/usr/lib/python2.7/dist-packages/quantumclient/v2_0/client.py, line 550, in
do_request
[Mon Nov 12 15:52:58 2012] [error] self._handle_fault_response(status_code,
replybody)
[Mon Nov 12 15:52:58 2012] [error] File
/usr/lib/python2.7/dist-packages/quantumclient/v2_0/client.py, line 523, in
_handle_fault_response
[Mon Nov 12 15:52:58 2012] [error] exception_handler_v20(status_code,
des_error_body)
[Mon Nov 12 15:52:58 2012] [error] File
/usr/lib/python2.7/dist-packages/quantumclient/v2_0/client.py, line 82, in
exception_handler_v20
[Mon Nov 12 15:52:58 2012] [error] message=message)
[Mon Nov 12 15:52:58 2012] [error] QuantumClientException: 404 Not Found
[Mon Nov 12 15:52:58 2012] [error]
[Mon Nov 12 15:52:58 2012] [error] The resource could not be found.
Can anybody, please suggest me, what is the error and the fix?
Thanks in advance.
--
Srikanth.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [openstack-dev] [Horizon] tables.DeleteAction not working
For questions like that it would be *very* helpful if you could post your code somewhere (github/gerrit). Debugging them otherwise is basically shooting in the dark. - Gabriel From: Srikanth Kumar Lingala [mailto:srikanthkumar.ling...@gmail.com] Sent: Monday, November 12, 2012 11:51 AM To: openstack@lists.launchpad.net; openstack-...@lists.openstack.org Subject: [openstack-dev] [Horizon] tables.DeleteAction not working Hi, I created a custom table in Quantum DB, and getting rows from that, and show as Table in Horizon. For each row, I put only action 'Delete', and called subsequent class for eg. 'DeleteRow(tables.DeleteAction)'. In this, I wrote 'delete' function, in which I am calling quantum API to delete the row from DB. But, however, If I click DeleteRow button in horizon, 'delete()' function in the class is not triggering. And, as a result, row is not deleting from DB. I am not getting any kind of error logs in nova-api.log, apache error logs ..etc. Can anyone suggest, what went wrong? Thanks in advance. -- Srikanth. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Horizon] Different URLs (hyperlinks) in a table view.
If you're trying to override a link in the actions column you can override get_link_url on any subclass of LinkAction as demonstrated here: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/containers/tables.py#L67 If you're trying to alter the link wrapped around the text in one of the columns, you can pass a callable to the link argument for that Column as here: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/containers/tables.py#L113 Hope that helps, - Gabriel From: Srikanth Kumar Lingala [mailto:srikanthkumar.ling...@gmail.com] Sent: Tuesday, November 06, 2012 5:49 AM To: Gabriel Hurley Cc: openstack@lists.launchpad.net; openstack-...@lists.openstack.org Subject: [Horizon] Different URLs (hyperlinks) in a table view. Hi Gabriel, I want to go to different URL for each row in a table view. For example, in the below table, based on some criteria, first row URL needs to go to 'networks/[NETWORKID]/detail' and second URL needs to go to 'networks/[NETWORKID]/other_detail'. Networks Create Networkhttp://10.232.91.33/horizon/nova/networks/create Delete Networks [ ] Name Subnets Associated Shared Status Admin State Actions [ ] dsdhttp://10.232.91.33/horizon/nova/networks/c15a3917-d7fa-4059-9e5c-38a2124995ef/detail * 1.1.1.1/24http://1.1.1.1/24 No ACTIVE UP Edit Networkhttp://10.232.91.33/horizon/nova/networks/c15a3917-d7fa-4059-9e5c-38a2124995ef/update [ ] vdvxchttp://10.232.91.33/horizon/nova/networks/f0d4201d-ddb8-4365-bd83-ef2bf0d0431c/detail * 10.10.0.0/24http://10.10.0.0/24 No ACTIVE UP Edit Networkhttp://10.232.91.33/horizon/nova/networks/f0d4201d-ddb8-4365-bd83-ef2bf0d0431c/update Displaying 2 items I saw the script 'dashboard/networks/url.py', but it is directing to only one page 'networks/[NETWORKID]/detail' every time. Can I give different URL's dynamically to each network in networks table view, based on some criteria (Eg. based on its name). Please help me. Thanks in advance. -- Srikanth. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Dope'n'Stack (What the F☁☁K is OpenStack) Shirts
Hey all, I just got this from the Dope'n'Stack crew and thought I'd pass it along: --- We know many of you were devastated by not getting a What the F☁☁K is OpenStack shirt down in San Diego... if you still want one there's a signup list available: https://docs.google.com/spreadsheet/viewform?formkey=dFp4S3lVcWJjMUZYblg4NFpONnpUbmc6MQ When there's enough party people signed up we'll send out another run for production. If you have no idea what we're talking about, check out the illest thing in the whole IT industry: http://www.dopenstack.com/ Two guys who like OpenStack, - Terrance Dope Bertram Stack --- Just wanted to spread the word. ;-) - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack] Limiting new roles
With respect to the comments on Horizon, as soon as Keystone implements the policy rollup and exposes it in the v3 API Horizon will fully honor the policies specified by the various projects. That blueprint for Keystone was targeted for Folsom but got bumped to Grizzly. Hopefully it'll make it in this time so we can get that done. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Dolph Mathews Sent: Wednesday, October 31, 2012 3:39 PM To: Guillermo Alvarado Cc: openstack Subject: Re: [Openstack] [OpenStack] Limiting new roles I'm specifically referring to keystone, because you mention ...this role only can create tentants and roles... If you can create tenants and roles in keystone, you also have the power to create new users and grant yourself additional roles in keystone, due to the binary nature of the policy implementation in keystone today (thereby -- and unfortunately -- defeating the rest of your statement: ... but cannnot change quotas or modify images). -Dolph On Wed, Oct 31, 2012 at 5:29 PM, Guillermo Alvarado guillermoalvarad...@gmail.commailto:guillermoalvarad...@gmail.com wrote: I know the implementation is not binay, you can modify the permissions related with nova/glance/swifth of the differents roles. I doubt is if horizon know wich template can view each user... 2012/10/31 Dolph Mathews dolph.math...@gmail.commailto:dolph.math...@gmail.com With regard to keystone, the current policy implementation is entirely binary in that a role may either have total control over keystone or none. The implementation in Grizzly is much more granular. -Dolph On Wed, Oct 31, 2012 at 2:35 PM, Guillermo Alvarado guillermoalvarad...@gmail.commailto:guillermoalvarad...@gmail.com wrote: Hi everyboy, I want to create a new role, named another-admin, so this role only can create tentants and roles but cannnot change quotas or modify images and all other actions that admin role can do. I read about create rules in the policy.json of each service (nova, keystone, glance, swift) but my doubt is: How can I limit the views/templates/urls of Horizon, I mean, I want that the role another-admin can not see templates related to glance and can not see that menu. Thanks in advance, Best Regards. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Quotas in folsom
It's also worth noting that we are now in territory where quotas are controlled by multiple projects: volumes and gigabytes have quotas in both Nova and Cinder; network quotas are in both Nova and Quantum... While I don't think it makes sense to try and centralize these things, I think the projects could coordinate more to understand who should be managing a given quota and to try and make the end-user experience less baffling. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Kevin L. Mitchell Sent: Monday, October 29, 2012 9:28 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Quotas in folsom On Mon, 2012-10-29 at 10:53 -0400, Mitchell Broome wrote: I'm running into quota problems trying to increase the number of security groups and rules within security groups per tenant. Setting quota_security_groups and quota_security_group_rules in nova.conf seem to have no effect. There also doesn't seem to be any way to change the quota limits for security groups through the nova client or horizon. The quotas system checks the database for quotas specific to the tenant, then for quotas for the tenant's quota class (if you're using quota classes). Only if it can't find any such quotas will it go to the values defined in nova.conf. You're right that these particular quotas are not among the quotas recognized by the nova shell command, but you can access them through the pythonic API; I'm guessing that the new quotas were added to nova itself during the folsom release cycle, but nobody remembered to update novaclient to recognize them. Could you log a bug against folsom for that, please? How do I go about changing these quotas or is there a way to disable all quotas all together? Check the database itself for quota records for your tenants; you can revert to defaults (drawn from nova.conf) by deleting any 'quotas' table rows for the resources you're interested in. If it still doesn't take the values you set in nova.conf, then there's likely some other bug that needs to be looked into… -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] Domain Name Spaces
There are various options for how Horizon can handle the UX problems associated with adding additional domains. Making it a part of the URL is one which could be supported, but I'm not inclined to make that the only method. The implementation details can be hashed out when we get there. I am more concerned about the experience for CLI/API users; adding more parameters they have to pass is quite unfriendly. And I have to say that Keystone's track record for handling default options has been quite poor (see default tenant). The mixed support for lookups via ID vs. name is also a mess. There needs to be consistency around what is unique and in what scope (which is where this thread started). So far I haven't heard a concrete answer on that. For example, if tenants uniqueness is scoped to a domain, and lookups via tenant name are possible, and there's a default domain... well haven't you just painted yourself into a corner where tenant names in the default domain must be unique while names in any other domain do not? It's these kinds of issues that need to really be thought through. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Adam Young Sent: Friday, October 26, 2012 4:19 PM To: Henry Nash Cc: OpenStack Development Mailing List; openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: Re: [Openstack] [keystone] Domain Name Spaces On 10/26/2012 07:17 PM, Henry Nash wrote: So to pick up on a couple of the areas of contention: a) Roles. I agree that role names must stay globally unique. One way of thinking about this is that it is not actually keystone that is creating the role name space it is the other services (Nova etc.) by specifying roles in their policy files. Until those services support domain specific segmentation, then role names stay global. b) Will multi-domains make it more complicated in terms of authorisation - e.g. will the users have to input a Domain Name into Horizon the whole time? The first thing I would say is that if the cloud administrator has create multiple domains, then the keystone API should indeed require the domain specification. However, that should not mean it should be laborious for a Horizon user. In the case where a Cloud Provider has created domains to encapsulate each of their customers - then if they want to let those customer use horizon as the UI, then I would think they want to be able to give each customer a unique URL which will point to a Horizon that knows which domain to go to. Yes, I think that this is the solution. It will involve HTTPD virtual hosts, and horizon can then get an additional config parameter keystone_domain as part of the wsgi config. Maybe the url contains the Domain Name or ID in the path, and Horizon pulls this out of its own url (assuming that's possible) and hence the user is never given an option to chose a domain. A Cloud Admin would use a non domain qualified url to get to Horizon (basically as it is now) and hence be able to see the different domains. Likewise, in the case of where the Cloud Provider has not chosen to create any individual domains (and is just running the cloud in the default domain), then the non domain qualified url would be used to a Horizon that only showed one, default domain and hence no choice is required. Henry On 26 Oct 2012, at 17:31, heckj wrote: Bringing conversation for domains in Keystone to the broader mailing lists. On Oct 26, 2012, at 5:18 AM, Dolph Mathews dolph.math...@gmail.commailto:dolph.math...@gmail.com wrote: I think this discussion would be great for both mailing lists. -Dolph On Fri, Oct 26, 2012 at 5:18 AM, Henry Nash henry.n...@mac.commailto:henry.n...@mac.com wrote: Hi Not sure where best to have this discussion - here, as a comment to the v3api doc, or elsewhere - appreciate some guidance and will transfer this to the right place At the Summit we started a discussion on whether things like user name, tenant name etc. should be globally unique or unique within a domain. I'd like to widen that discussion to try and a) agree a direction, b) agree some changes to our current spec. Here's my view as an opening gambit: - When a Keystone instance is first started, there is only one, default, Domain. The Cloud Provider does not need to create any new domains, all projects can exist in this default domain, as will the users etc. There is one, global, name space. Clients using the v2 API will work just fine. +1 Very much what we were thinking for the initial implemenation and rollout to make it backwards compatible with the V2 (non-domain) core API - If the Cloud Provider wants to provide their customers with regions they can administer themselves and be self-contained, then they create a Domain for each customer. It should be possible for users/roles to be scoped to a
Re: [Openstack] Inserting into custom tables from horizon.
Horizon has (thus far) been designed to avoid requiring a persistent storage backend such as a database, so you won't find any code in there to do that. That said, Horizon is built on Django, and Django has a phenomenal ORM which works with most common database backends. Building a Django model for your data and integrating that with your Horizon installation is totally fair game. See Django's documentation for examples there. However I would advise against using the same database as Nova unless you actually need to do JOINs between the tables. Better to keep a clean separation otherwise. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Srikanth Kumar Lingala Sent: Thursday, October 25, 2012 8:48 AM To: openstack@lists.launchpad.net Subject: [Openstack] Inserting into custom tables from horizon. Hi, I want to create a new custom table in nova database and insert data into that table from Openstack Dashboard, by creating some custom fields. I am not able to find any SQL executions in the source code, as it is using django framework, which is similar to MVC architecture. Can anyone point me where can I start doing that? -- Srikanth. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How can I choose my own timezone on Dashboard of Essex?
Full timezone support was added in Folsom; for Essex the best you can do is change the TIME_ZONE setting in your local_settings.py file; however if your timezone there doesn't match the timezone on your server(s) you're gonna end up with an offset between the dashboard and the rest of the stack, which is terribly confusing. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Sébastien Han Sent: Thursday, October 11, 2012 12:36 AM To: Ray Sun Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] How can I choose my own timezone on Dashboard of Essex? Hi, There is a line in /etc/openstack-dashboard/local_settings.py called TIME_ZONE # The timezone of the server. This should correspond with the timezone # of your entire OpenStack installation, and hopefully be in UTC. TIME_ZONE = UTC Change it, restart apache and memcached, that should do the trick. Have you looked at that? Cheers! On Thu, Oct 11, 2012 at 7:38 AM, Ray Sun qsun01...@cienet.com.cnmailto:qsun01...@cienet.com.cn wrote: In the Dashboard of Essex version, seems the datetime is always displayed as UTC time, How can I choose my own timezone? Thanks. - Ray Yours faithfully, Kind regards. CIeNET Technologies (Beijing) Co., Ltd Email: qsun01...@cienet.com.cnmailto:qsun01...@cienet.com.cn Office Phone: +86-01081470088-7079 Mobile Phone: +86-18901118291tel:%2B86-18901118291 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Adding Custom form field in Openstack Dashboard.
That generic error is what happens when there's a 500 error on the server-side while submitting a form via AJAX. Take a look in the Horizon console log to see what really went wrong. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Srikanth Kumar Lingala Sent: Tuesday, October 09, 2012 12:22 AM To: openstack@lists.launchpad.net; openstack-...@lists.openstack.org Subject: [Openstack] Adding Custom form field in Openstack Dashboard. Hi all, I have added my own custom text box field in the form 'Launch Instance' page. For that, I modified the following file: /usr/lib/python2.7/dist-packages/horizon/dashboards/nova/instances/workflows.py Added text box in the above script as follows: sample = forms.CharField(max_length=15, label=_(Sample), required=False) Now, I want to access the posted value of the above field. For that, I am using context['sample'] variable. When I clicked on the 'Launch' button, I am getting a Horizon alert error as the following: There was an error submitting the form. Please try again. Please suggest me to fix the issue. Thanks in advance. -- Srikanth. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Disable Quantum in Horizon Folsom
This QUANTUM_ENABLED setting hasn't existed in a very long time (I'm talking like Diablo timeframe). Everything in Horizon is controlled by Keystone's service catalog. The presence or absence of particular service types (e.g. network for Quantum) is what controls the appearance of those panels in the UI. This paradigm is also true for Swift (object-store service) and Cinder (volume service). So, that said, if you are seeing Quantum in your UI when you aren't using Quantum then that means your Keystone catalog is misconfigured. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of John Garbutt Sent: Monday, October 08, 2012 8:01 AM To: 'Kiall Mac Innes'; Bilel Msekni Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Disable Quantum in Horizon Folsom I think, when I had this issue I modified my keystone configuration. I removed the quantum endpoint and service accounts, and Horizon seemed to correctly detect there is was no quantum in my setup. Having said that, I am surprized the flag did not work. Maybe a capitalization error (try all caps), or missing space between equals sign? I can't remember if that stuff matters. John From: openstack-bounces+john.garbutt=citrix@lists.launchpad.netmailto:openstack-bounces+john.garbutt=citrix@lists.launchpad.net [mailto:openstack-bounces+john.garbutt=citrix@lists.launchpad.net]mailto:[mailto:openstack-bounces+john.garbutt=citrix@lists.launchpad.net] On Behalf Of Kiall Mac Innes Sent: 08 October 2012 11:50 To: Bilel Msekni Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Disable Quantum in Horizon Folsom Quantum is defiantly not needed for Horizon in Folsom. We don't use Quantum, and do use Horizon. The python-quantumclient library needs to be installed, but thats about it. And from your pastebin - I'm pretty sure you already have that installed. Thanks, Kiall On Mon, Oct 8, 2012 at 11:20 AM, Bilel Msekni ski...@hotmail.frmailto:ski...@hotmail.fr wrote: Thank you Kiall for replying, Of course i did :) Yet, after consulting with OpenStack IRC people, it seems that quantum can not be excluded from horizon :) I am going for installing it :) Le 08/10/2012 12:10, Kiall Mac Innes a écrit : Did you restart apache after editing local_settings.py? Thanks, Kiall On Mon, Oct 8, 2012 at 10:57 AM, Bilel Msekni ski...@hotmail.frmailto:ski...@hotmail.fr wrote: Hi, Back with a new bug :) So, i have installed OpenStack Folsom and edited the horizon localsetting.py file to disable Quantum service: (Quantum_Enabled=False) Still now Horizon is giving errors and inhibiting me from starting VMs: I get this when i click on the networks tab in the dashboard page: http://pastebin.com/7766hVwb does anyone have an idea how to disable quantum in Horizon ? ___ Mailing list: https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Horizon Bug 1004412 Details
All of what you said is correct. Those filtering issues (which applied to volumes, keypairs, and security groups at least) were tracked in separate tickets in Nova and all got fixed towards the tail end of Folsom. I don't have the commits handy, sorry. The proper fix was filtering the results returned from Nova correctly on that end; the fix on the ticket you listed was only a defense against the problem on Horizon's end. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Joe Topjian Sent: Saturday, October 06, 2012 11:19 AM To: openstack Subject: [Openstack] Horizon Bug 1004412 Details Hello, I've been aware of Bug 1004412 (https://bugs.launchpad.net/horizon/+bug/1004412) in my Essex deployments for a while and finally had some time to look into it in detail. I believe I have found the cause and wanted to discuss what I found vs how it was fixed in the patch. From what I can see, when an admin requests a list of volumes, all volumes in the cloud are returned. But when an admin requests a list of instances, only instances owned by the admin are returned -- unless an option to return all instances is specified. Because of these two distinct actions, the chances of a KeyError happening when visiting /nova/instances_and_volumes is extremely high once other projects begin working in the OpenStack environment: all volumes from all projects are returned but only admin instances are returned, so any volume attached in another project cannot find its corresponding instance. I see two proper solutions to this issue: either only return volumes owned by the admin or return all instances in all projects by default. I was unable to figure out (without doing too many changes) how to filter volumes, so I decided on the latter solution. In views.py, I modified the call to get a list of instances to be: if self.request.user.is_admin(): self._instances_list = api.server_list(self.request, all_tenants=True) else: self._instances_list = api.server_list(self.request) Without looking at the implementation details, but instead what the implementation is trying to achieve, I do not see this same issue being resolved in the patch (https://github.com/openstack/horizon/commit/155bfb72c1b5f866236928f4ffd0c2567dc556f3). My question is if I have incorrectly assessed the issue or if the patch is taking other things into account that I'm not aware of? Thanks, Joe -- Joe Topjian Systems Administrator Cybera Inc. www.cybera.cahttp://www.cybera.ca Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Packaging Horizon
Now I'm not well-versed in the legalese of all the distros, but that sounds like splitting hairs on the meaning of compiled from source. If I run it through LESS and commit the file to the repo does that make it from source? It'd solve your problem exactly the same. I'd be curious to know the definition here, but that seems like overkill to me. If its what you need I'll do it for Folsom, but... thoughts? - Gabriel On Sep 14, 2012, at 8:25 PM, Thomas Goirand tho...@goirand.fr wrote: On Sat Sep 15 2012 03:55:09 AM CST, Gabriel Hurley gabriel.hur...@nebula.com wrote: Either way works, you just have to compile the file once and ship it in the distro package. For at least Debian, this would make the package non-free. Everything has to be compiled from source. If you can't compile it yourself then you could perhaps use the one from Adam/Ubuntu, or I can do it and send you the final output file. That isn't the way. Thomas -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Adam Gandelman Sent: Friday, September 14, 2012 11:19 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Packaging Horizon On 09/14/2012 05:06 AM, Matthias Runge wrote: Hi, currently, I'm trying to package horizon RC1 for Fedora. Since, Fedora does not have node.js included, and also doesn't have LESS included, it won't work per default. Do you have suggestions for me? Thanks We faced the same issue in Ubuntu [1]. Ended up compiling and compressing the CSS and JS at packaging time, shipping those + the manifest.json with the package and enabling COMPRESS_OFFLINE=True by default. Users who might want to make use of lessc and node later can just install node-less and set COMPRESS_OFFLINE=False. Adam [1] https://bugs.launchpad.net/horizon/+bug/1024326 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Packaging Horizon
Adam beat me to the punch. What he suggested is the least invasive solution (doesn't require changing any template files). The secondary solution which is simpler but less elegant is a simple patch to the stylesheet template file to point to a static pre-compiled copy of the CSS, and then removing/overriding the COMPRESS_PRECOMPILERS setting (making it an empty tuple) . Either way works, you just have to compile the file once and ship it in the distro package. If you can't compile it yourself then you could perhaps use the one from Adam/Ubuntu, or I can do it and send you the final output file. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Adam Gandelman Sent: Friday, September 14, 2012 11:19 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Packaging Horizon On 09/14/2012 05:06 AM, Matthias Runge wrote: Hi, currently, I'm trying to package horizon RC1 for Fedora. Since, Fedora does not have node.js included, and also doesn't have LESS included, it won't work per default. Do you have suggestions for me? Thanks We faced the same issue in Ubuntu [1]. Ended up compiling and compressing the CSS and JS at packaging time, shipping those + the manifest.json with the package and enabling COMPRESS_OFFLINE=True by default. Users who might want to make use of lessc and node later can just install node-less and set COMPRESS_OFFLINE=False. Adam [1] https://bugs.launchpad.net/horizon/+bug/1024326 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Create new Public User
Matt is correct in pointing you to extending Horizon, however I'd take this up a level and suggest that I'd love to see a mashup between the very widely used django-registration app (http://docs.b-list.org/django-registration/0.8/) and the django-openstack-auth backend. Making user accounts self-service should be pretty doable with those two pieces. Definitely an interesting and worthwhile project. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Matt Joyce Sent: Monday, September 10, 2012 11:06 PM To: Jegadeesh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Create new Public User horizon dashboard extensions are probably the way to go. http://docs.openstack.org/developer/horizon/topics/tutorial.html check that out for starters. -Matt On Mon, Sep 10, 2012 at 9:30 PM, Jegadeesh s.jegade...@gmail.commailto:s.jegade...@gmail.com wrote: Hi Guys, I am new for OpenStack. For some testing, i have installed it (Ubuntu 12.04, Essex) and it works fine. Now, i want to customize the dashboard to add some more options like automate the user creation with mail confirmation, send a mail after create/delete instances etc... Can someone give some ideas? Thanks, Jegadeesh S ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] About the Role and User's rights
One additional note on that, however: for legacy reasons many of the projects have hardcoded assumptions about the role named admin. In Grizzly we'll be working to make the role-based access control truly customizable, but for now you're stuck with needing that one. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Dolph Mathews Sent: Friday, August 31, 2012 12:34 AM To: Jack Cc: openstack Subject: Re: [Openstack] About the Role and User's rights Those roles you see in keystone are merely examples, and don't have any meaning by themselves. You create your own roles in keystone (e.g. $ keystone role-create) and define the associated actions specific to each service via each service's own policy.json. For example, here's nova's default policy.json: https://github.com/openstack/nova/blob/master/etc/nova/policy.json -Dolph On Fri, Aug 31, 2012 at 2:21 AM, Jack 545997...@qq.commailto:545997...@qq.com wrote: hi all, openstack uses a rights management system that employs a Role-Based Access Control , Roles control the actions that a user is allowed to perform .there are 5 roles in keystone ,there are admin,KeystoneAdmin,KeystoneServiceAdmin,Member,anotherrole ,but ,how openstack control every role's rights? how openstack lmits the actions of each role? Looking forward ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] About the Role and User's rights
Yes, but because those policy files are not standardized, exposed across projects, etc. you can do that in some projects but not others. The whole thing is inconsistent and I can tell you for a fact that admin is still hard-coded in lots of places. For the Folsom release it is not safe to say you can universally forego the name admin across the entire stack. Part of the v3 Keystone API is rolling up and exposing those policy definitions so that we have a common endpoint for this critical component of RBAC. That didn't happen in Folsom, so we get to do it in Grizzly now. ;-) - Gabriel From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] Sent: Friday, August 31, 2012 1:34 PM To: Gabriel Hurley Cc: Dolph Mathews; Jack; openstack Subject: Re: [Openstack] About the Role and User's rights Nova recently was changed to allow the rolename that gets is_admin privileges specified in context. There is still some work needed to break out the is_admin capabilities into individual policy actions, but at least you can pick a different name for your admin role. from nova's policy.json: context_is_admin: [[role:admin]], On Aug 31, 2012, at 10:11 AM, Gabriel Hurley gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote: One additional note on that, however: for legacy reasons many of the projects have hardcoded assumptions about the role named admin. In Grizzly we'll be working to make the role-based access control truly customizable, but for now you're stuck with needing that one. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.netmailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.netmailto:bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Dolph Mathews Sent: Friday, August 31, 2012 12:34 AM To: Jack Cc: openstack Subject: Re: [Openstack] About the Role and User's rights Those roles you see in keystone are merely examples, and don't have any meaning by themselves. You create your own roles in keystone (e.g. $ keystone role-create) and define the associated actions specific to each service via each service's own policy.json. For example, here's nova's default policy.json: https://github.com/openstack/nova/blob/master/etc/nova/policy.json -Dolph On Fri, Aug 31, 2012 at 2:21 AM, Jack 545997...@qq.commailto:545997...@qq.com wrote: hi all, openstack uses a rights management system that employs a Role-Based Access Control , Roles control the actions that a user is allowed to perform .there are 5 roles in keystone ,there are admin,KeystoneAdmin,KeystoneServiceAdmin,Member,anotherrole ,but ,how openstack control every role's rights? how openstack lmits the actions of each role? Looking forward ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Horizon PTL Candidacy
I hereby officially throw my hat in the ring to be Horizon's PTL. Qualifications: I'm a highly active developer on Horizon, and a member of the Horizon Drivers group. I wrote the initial version of python-keystoneclient, and I'm a member of the Keystone Core group as well. I'm also a core committer for the Django web framework on which Horizon is based. I work hard to understand the workings of the entire stack and the needs of the ecosystem at large so we can work together to make the entirety of OpenStack consistent, stable and amazing. I believe VERY strongly in stability, backwards-compatibility, and consistent, properly-versioned APIs. I also have a strong belief in the importance of translation, internationalization and localization to support our international userbases. Contribution over the last six months: I've been the implementer on the majority of the large Folsom blueprints, most of which had to do with improving the flow and ease-of-use of various complicated workflows. I also re-implemented the keystone authentication in Horizon to be dramatically more robust and secure. I've provided a lot of feedback on API revisions in other projects (e.g. Keystone) since those APIs deeply affect Horizon's ability to deliver on a high quality experience. I guided the community's initiative to nail down a complete set of guidelines for developers around internationalization. I've been largely leading the Horizon project in terms of architecture and code review during the Folsom timeframe despite not being the official PTL. Most critical aspects for Horizon in the next 6 months: Full RBAC support; continued focus on reducing the user frustration in complex workflows and interactions; adding more introspective features to reduce boilerplate; cleaner separation of end-user and admin code flows; making the admin dashboard more useful to admins as opposed to just being the same user dashboard except you can see everything in the system; improved file upload mechanisms; Philosophical ideas regarding being a PTL: The foremost role of the PTL is to maintain and convey the long-term vision of the project through day-to-day work (in code, in architecture, in reviews, in answering questions, etc.). Right behind that it is crucial that the PTLs work to guide the community (in gathering consensus on difficult topics, in supporting community members of all types, in maintaining the principles of our community). A close third is that the PTLs must work with each other to ensure the consistency, compatibility, and commonality of all core projects. I'm more than happy to answer any questions or address any concerns people may have. :-) All the best, - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A plea from an OpenStack user
Well said, Ryan. Agreed 100% on all points, both in the specific examples and the overarching theme of n+1 compatibility. Upgrade paths have got to be clean and well-documented, and deprecations must be done according to responsible, established timelines from here on out. We're verifiably doing better between Essex and Folsom, but we still have a LONG way to go to call our upgrade process anything resembling great. There was talk of trying to set up test infrastructure that would roll out Essex and then upgrade it to Folsom in some automated fashion so we could start learning where it breaks. Was there any forward momentum on that? All the best, - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Ryan Lane Sent: Tuesday, August 28, 2012 2:26 PM To: openstack@lists.launchpad.net Subject: [Openstack] A plea from an OpenStack user Yesterday I spent the day finally upgrading my nova infrastructure from diablo to essex. I've upgraded from bexar to cactus, and cactus to diablo, and now diablo to essex. Every single upgrade is becoming more and more difficult. It's not getting easier, at all. Here's some of the issues I ran into: 1. Glance changed from using image numbers to uuids for images. Nova's reference to these weren't updated. There was no automated way to do so. I had to map the old values to the new values from glance's database then update them in nova. 2. Instance hostnames are changed every single release. In bexar and cactus it was the ec2 style id. In diablo it was changed and hardcoded to instance- ec2-style-id. In essex it is hardcoded to the instance name; the instance's ID is configurable (with a default of instance-ec2-style-id, but it only affects the name used in virsh/the filesystem. I put a hack into diablo (thanks to Vish for that hack) to fix the naming convention as to not break our production deployment, but it only affected the hostnames in the database, instances in virsh and on the filesystem were still named instance-ec2-style- id, so I had to fix all libvirt definitions and rename a ton of files to fix this during this upgrade, since our naming convention is the ec2-style format. The hostname change still affected our deployment, though. It's hardcoded. I decided to simply switch hostnames to the instance name in production, since our hostnames are required to be unique globally; however, that changes how our puppet infrastructure works too, since the certname is by default based on fqdn (I changed this to use the ec2-style id). Small changes like this have giant rippling effects in infrastructures. 3. There used to be global groups in nova. In keystone there are no global groups. This makes performing actions on sets of instances across tenants incredibly difficult; for instance, I did an in-place ubuntu upgrade from lucid to precise on a compute node, and needed to reboot all instances on that host. There's no way to do that without database queries fed into a custom script. Also, I have to have a management user added to every single tenant and every single tenant-role. 4. Keystone's LDAP implementation in stable was broken. It returned no roles, many values were hardcoded, etc. The LDAP implementation in nova worked, and it looks like its code was simply ignored when auth was moved into keystone. My plea is for the developers to think about how their changes are going to affect production deployments when upgrade time comes. It's fine that glance changed its id structure, but the upgrade should have handled that. If a user needs to go into the database in their deployment to fix your change, it's broken. The constant hardcoded hostname changes are totally unacceptable; if you change something like this it *must* be configurable, and there should be a warning that the default is changing. The removal of global groups was a major usability killer for users. The removal of the global groups wasn't necessarily the problem, though. The problem is that there were no alternative management methods added. There's currently no reasonable way to manage the infrastructure. I understand that bugs will crop up when a stable branch is released, but the LDAP implementation in keystone was missing basic functionality. Keystone simply doesn't work without roles. I believe this was likely due to the fact that the LDAP backend has basically no tests and that Keystone light was rushed in for this release. It's imperative that new required services at least handle the functionality they are replacing, when released. That said, excluding the above issues, my upgrade went fairly smoothly and this release is *way* more stable and performs *way* better, so kudos to the community for that. Keep up the good work! - Ryan
Re: [Openstack] Default rules for the 'default' security group
I traced this through the code at one point looking for the same thing. As it stands, right now there is *not* a mechanism for customizing the default security group's rules. It's created programmatically the first time the rules for a project are retrieved with no hook to add or change its characteristics. I'd love to see this be possible, but it's definitely a feature request. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Boris-Michel Deschenes Sent: Thursday, August 23, 2012 7:59 AM To: Yufang Zhang; openstack@lists.launchpad.net Subject: Re: [Openstack] Default rules for the 'default' security group I'm very interested in this, we run essex and have a very bad workaround for this currently, but it would be great to be able to do this (set default rules for the default security group). Boris De : openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.netmailto:openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net [mailto:openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net]mailto:[mailto:openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net] De la part de Yufang Zhang Envoyé : 23 août 2012 08:43 À : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Objet : [Openstack] Default rules for the 'default' security group Hi all, Could I ask how to set the default rules for the 'default' security group for all the users in openstack? Currently, the 'default' security group has no rule by default, thus newly created instances could only be accessed by instances from the same group. Is there any method to set default rules(such as ssh or icmp) for the 'default' security group for all users in openstack, so that I don't have to remind the new users to modify security group setting the fist time they logged into openstack and create instances? I have ever tried HP could which is built on openstack, they permit ssh or ping to the instances in the 'default' security group. Best Regards. Yufang ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Translation, Internationalization and Localization in OpenStack
In conjunction with the PTLs, the Docs team, the Infrastructure team, various community members and more, I'm very happy to say that we are ready to share out a complete set of documentation and processes for translation, internationalization, and localization for OpenStack as a whole. The document lives on the wiki here: http://wiki.openstack.org/Translations The critical infrastructure is already in place, and Nova, Horizon, Keystone and Docs are already up and running with the new processes (and have been successfully for a little while now). Of immediate importance is the fact that we are technically under string freeze right now, so (as Thierry pointed out at the meeting earlier today) any review that alters strings marked for translation should be flagged and requires special consideration and coordination with translators before being merged. The string freeze gives translators a period of time before a release in which translations do not change so they can complete their work properly. Comments and critiques of the process are welcome, but let's keep them on the mailing list before making edits to the wiki page. Obviously we'll continue to refine this over time. Thanks, and happy translating! - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] sort_key and sort_dir for collections based REST APIs
For two summits running I've been advocating the need for a common standard of functionality for all OpenStack APIs (things like sorting, bulk operations, filtering, pagination, etc.). I intend to push on the issue even harder this time around at the Grizzly summit (I'm going to propose an entire working session on it). It's one of those problems that simply *cannot* be solved one project at a time. The community needs to agree, and then the projects need to implement the solutions over time. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Brian Waldon Sent: Monday, August 20, 2012 10:06 AM To: boden Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] sort_key and sort_dir for collections based REST APIs As we can't just add things to our APIs, it's not straight-forward to support them across the board. I think it would make sense to bake these parameters into the next versions of our APIs for collection sorting, but my opinion is definitely biased. Maybe Joe Heck can comment, as he's working on the v2 Identity API. Brian On Aug 20, 2012, at 11:43 AM, boden wrote: All, Is anybody here familiar with the 'sort_key' and 'sort_dir' parameters for collection based APIs? Specifically I'm wondering if there are any plans to add support for these 2 params across the board (all collections based REST APIs including the 'primary compute extensions')? Based on my google-ability it appears they are only on the glance image APIs (http://docs.openstack.org/developer/glance/glanceapi.html ) at the present moment, so looking for more clarity on this topic intermediate to longer term. Thanks much ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] sort_key and sort_dir for collections based REST APIs
Given that the v3 API didn't get implemented in Folsom that gives us a perfect opportunity to talk about this stuff at the Grizzly summit! ;-) - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Monday, August 20, 2012 1:45 PM To: Brian Waldon Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] sort_key and sort_dir for collections based REST APIs In the V3 Keystone API, we asserted that we wanted filter functions, but didn't go to the length of defining a sort_key and sort_direction in the API spec. ref: https://docs.google.com/document/d/1VP-bTBbwsn6q- rDzuS9CEKb2ubE1VjbWRFd4BkkjoOY/edit?pli=1 -joe On Aug 20, 2012, at 10:05 AM, Brian Waldon bcwal...@gmail.com wrote: As we can't just add things to our APIs, it's not straight-forward to support them across the board. I think it would make sense to bake these parameters into the next versions of our APIs for collection sorting, but my opinion is definitely biased. Maybe Joe Heck can comment, as he's working on the v2 Identity API. Brian On Aug 20, 2012, at 11:43 AM, boden wrote: All, Is anybody here familiar with the 'sort_key' and 'sort_dir' parameters for collection based APIs? Specifically I'm wondering if there are any plans to add support for these 2 params across the board (all collections based REST APIs including the 'primary compute extensions')? Based on my google-ability it appears they are only on the glance image APIs (http://docs.openstack.org/developer/glance/glanceapi.html ) at the present moment, so looking for more clarity on this topic intermediate to longer term. Thanks much ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Horizon: controlling table appearance
There are two levels of status control in Horizon: one at the column level and one at the row level, which is an aggregate of the column statuses within that row. Column status is controlled by settings status=True on the column. If you want fine-grained control over which statuses are considered good, bad or unknown you can use the status_choices keyword argument as well. Docs for that are here: http://docs.openstack.org/developer/horizon/ref/tables.html#horizon.tables.Column.status_choices The row status is defined in the tables Meta options by settings status_columns to a list of column names which should be considered. The aggregation is fairly naïve: if all columns are good then the row is good, if any or unknown it's unknown, and if any are bad then it's bad. Hopefully that's helpful to you. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of LifeOn2 Development Sent: Thursday, August 16, 2012 8:46 AM To: openstack@lists.launchpad.net Subject: [Openstack] Horizon: controlling table appearance Hello All, I am currently looking into how the appearance of tables in the Horizon UI is controlled, more specifically the Instances table in Project-Instances Volumes. What I am trying to accomplish is to control for which content combinations of the Status and Task cells a certain row is rendered with the pale yellow background and the spinner animation in the Task cell or not. Reasonably information about row state (including when to show the spinner and yellow or not) is passed in the Ajax data for the row sent from nova. I have looked into the contents of the Ajax data sent, but have not been able to distinguish any data that would seem to control this row appearance. So, if anybody could point me to the mechanism that regulates this aspect of row appearance, it would be super! Many Thanks, Fredric ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Dashboard] Multi-region support in Horizon?
More than happy to discuss it! If we can do things to support it that don't rely on other projects (e.g. Keystone) all the better. Otherwise we should discuss it as a community and work together towards a federated federation solution. ;-) - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Matt Joyce Sent: Tuesday, August 14, 2012 12:18 PM To: Yufang Zhang Cc: j...@ansolabs.com; openstack@lists.launchpad.net Subject: Re: [Openstack] [Dashboard] Multi-region support in Horizon? In the short term you might be able to setup something with a horizon customization module... http://docs.openstack.org/developer/horizon/topics/customizing.html In the long term I think federation should be a concern for grizzly planning in horizon. But maybe I am just being a little too optimistic. -Matt On Tue, Aug 14, 2012 at 3:28 AM, Yufang Zhang yufang521...@gmail.commailto:yufang521...@gmail.com wrote: Hi all, I'd like to use horizon to manage clusters in multiple data centers(regions). Currently, horizon supports multi-region by means of deploying one keystone service for each region. Thus we have to manage multiple keystone services for all the regions(creating users or projects, etc.), which doesn't make sense. Should it be better to allow users to choose service endpoints(nova or glance) according to region name? At least, novaclient works as this way: you can provide region name(via --os_region_name option) as a filter to select nova service endpoint to access, so that we could deploy just one keystone service to manage services on different regions. Or is there any better workaround? Best Regards. Yufang ___ Mailing list: https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [openstack] [horizon] Adding quota information to horizon.usage.base ?
Go for it. I assume this is related to https://bugs.launchpad.net/horizon/+bug/1018560 ? If you need to add stuff feel free. Were you thinking the end result would be to display those bars on the overview screen for the project? - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Matt Joyce Sent: Tuesday, August 14, 2012 12:24 PM To: openstack@lists.launchpad.net Subject: [Openstack] [openstack] [horizon] Adding quota information to horizon.usage.base ? Is anyone opposed to me adding quota information to usage.base. ? I'd like to add the graph bars from _launch_details_help.html to provide a quick heads up on where you are in terms of current allocation of resources against quotas. Maybe later we can provide some graphing of deltas in resource use against quota. In that, I don't know if we even track past quotas anywhere. So I am going to avoid jumping into that any time soon. Maybe that's a job for ceilometer. -Matt ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Why Image upload functionality is not there in Horizon ?
Horizon already has what you just described. You can load images into glance by providing a URI. It's the Create Image button on the Images table. - Gabriel -Original Message- From: Brian Waldon [mailto:bcwal...@gmail.com] Sent: Friday, August 10, 2012 7:35 AM To: Gabriel Hurley Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Why Image upload functionality is not there in Horizon ? Even being able to add images while providing an external location would be useful. You could depend on your user to put it in swift or s3 and just provide a uri that references it. On Aug 9, 2012, at 11:05 AM, Gabriel Hurley wrote: Indeed, uploading large files with the Horizon webserver as an intermediate relay is a nasty business which we want to discourage. We are looking at ways to send files directly from the Horizon client-side UI to swift/glance for large file upload in the future. All the best, - Gabriel -Original Message- From: openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of bounces+Jay Pipes Sent: Thursday, August 09, 2012 10:43 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Why Image upload functionality is not there in Horizon ? On 08/09/2012 02:35 AM, Sajith Kariyawasam wrote: Hi all, After playing around with Openstack Mangement Console, Horizon, I realize that the image upload functionality is not provided there. Is there any special reason for that? Is it because there are no Rest services available at the moment? or else is it felt that providing image upload via the UI is not practically important? Probably because sending 20G Windows image files through a web form interface isn't very efficient ;) It's also not something a regular user of Glance/Nova would do -- and system administrators won't do it very often, and when they do, they'll use the glance CLI tool to do it. Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Why Image upload functionality is not there in Horizon ?
Indeed, uploading large files with the Horizon webserver as an intermediate relay is a nasty business which we want to discourage. We are looking at ways to send files directly from the Horizon client-side UI to swift/glance for large file upload in the future. All the best, - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Jay Pipes Sent: Thursday, August 09, 2012 10:43 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Why Image upload functionality is not there in Horizon ? On 08/09/2012 02:35 AM, Sajith Kariyawasam wrote: Hi all, After playing around with Openstack Mangement Console, Horizon, I realize that the image upload functionality is not provided there. Is there any special reason for that? Is it because there are no Rest services available at the moment? or else is it felt that providing image upload via the UI is not practically important? Probably because sending 20G Windows image files through a web form interface isn't very efficient ;) It's also not something a regular user of Glance/Nova would do -- and system administrators won't do it very often, and when they do, they'll use the glance CLI tool to do it. Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Images API v2 Versioning and Glance
With the stipulation that clients will be able to talk to all versions of the API from here on forward, I am totally in favor of this. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Brian Waldon Sent: Wednesday, August 08, 2012 3:51 PM To: openstack@lists.launchpad.net Subject: [Openstack] Images API v2 Versioning and Glance tl;dr - We're going to use minor versioning for the v2 Images API and take a more iterative approach to API design and implementation Up until this point we have depended on big design up front for the Images API. We spent most of Essex talking about v2 without writing any code. At the beginning of the Folsom release cycle I took it upon myself to start implementing the v2 Images API (which has been rather slow-going). Several people have helped, for which I am grateful, but ultimately we didn't finish what was needed. Not only did we not finish everything, but there are several things in the spec that need to revisit. The (possibly incorrect) assumption I have been working under is that we would release the v2 API and that would be it - just a major version, no minor versioning, no extensions. If we wanted to make changes, we would put them in v3. That won't work. It has taken two releases to get to this point and we still aren't done. The solution as I see it is to use a more iterative design/implementation cycle for our APIs. We can't be designing massive API specs up front - it doesn't always work. We need to have the flexibility to move fast and get to something that works that we are proud of. We are going to use minor versioning for the v2 Images API. This means that the Folsom release will implement a v2.0 spec, with additional (and already identified) features in a v2.1 sometime early in Grizzly. Please voice any and all concerns ASAP since we're on a pretty short timeline. Brian Waldon The People's PTL ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Quantum devstack authentication error
I'm trying to run devstack with quantum enabled so I can test the recent work on re-integrating Quantum into Horizon. I've followed the instructions for what should be in my localrc file here: http://wiki.openstack.org/QuantumDevstack However, devstack fails when trying to create a network during its health checks. The error logged is here: https://gist.github.com/3288861 Any advice? What's missing from that wiki page? Or is this a bug? Thanks, - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Quantum devstack authentication error
Thanks, that got it. Two things, though: 1. Shouldn't that be in the wiki? 2. What do you mean only works in folsom? I'm running the latest devstack with master everything... how much more folsom does it get? - Gabriel From: Aaron Rosen [mailto:aro...@nicira.com] Sent: Tuesday, August 07, 2012 1:33 PM To: Gabriel Hurley Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Quantum devstack authentication error Hi Gabriel, Adding Q_AUTH_STRATEGY=noauth to localrc should fix the issue. The authentication it's trying to use only works in folsom. Thanks, Aaron On Tue, Aug 7, 2012 at 1:04 PM, Gabriel Hurley gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote: I'm trying to run devstack with quantum enabled so I can test the recent work on re-integrating Quantum into Horizon. I've followed the instructions for what should be in my localrc file here: http://wiki.openstack.org/QuantumDevstack However, devstack fails when trying to create a network during its health checks. The error logged is here: https://gist.github.com/3288861 Any advice? What's missing from that wiki page? Or is this a bug? Thanks, - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [glance] legacy client removal and python-glanceclient
As a rule of thumb, we need to start doing proper deprecation on all public interfaces, whether that's a CLI, client method signatures, APIs, etc. It's a little late for this on the old vs. new glance client/CLI (unless Brian feels the work can be reasonably done to make them compatible) but it's something we need to be really mindful of going forward. As a community we've tacitly made an N+1 promise of compatibility, so changes like this would ideally support both code paths in Folsom and raise a DeprecationWarning on the old one, then be completely removed in Grizzly. If we wanted to be even nicer to people relying on these public interfaces we'd move towards an N+2 timeline and start with a PendingDeprecationWarning in Folsom, escalate to a DeprecationWarning in Grizzly, and finish with complete removal in H***. All the best, - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Vishvananda Ishaya Sent: Wednesday, August 01, 2012 10:35 AM To: Brian Waldon Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [glance] legacy client removal and python- glanceclient On Jul 31, 2012, at 10:09 PM, Brian Waldon bcwal...@gmail.com wrote: I do agree that this current upgrade story could be better, but how much better do you expect it to be and in what specific ways? If the command-line interface were backwards-compatibile, would that solve all your problems? I'm fine doing that for the v1.0.0 release as long as we can deprecate all the old behavior out for a v2.0.0 release. Do you expect the legacy python library to get installed with folsom? As a side note, I do want to point out that the python module paths do not conflict. Legacy compatibility would be a huge win if it is feasible. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [glance] legacy client removal and python-glanceclient
Personally I'd recommend using Python's built-in warnings module and the standard DeprecationWarning and PendingDeprecation warning classes: http://docs.python.org/library/warnings.html#warning-categories For an example of this in action (outside OpenStack) check out Django's usage here: https://github.com/django/django/blob/stable/1.4.x/django/core/management/sql.py#L99 - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Kevin L. Mitchell Sent: Wednesday, August 01, 2012 12:19 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] [glance] legacy client removal and python- glanceclient On Wed, 2012-08-01 at 18:37 +, Gabriel Hurley wrote: As a rule of thumb, we need to start doing proper deprecation on all public interfaces, whether that's a CLI, client method signatures, APIs, etc. It's a little late for this on the old vs. new glance client/CLI (unless Brian feels the work can be reasonably done to make them compatible) but it's something we need to be really mindful of going forward. As an example of how it can be done properly, check out https://review.openstack.org/#/c/10577/ (at least, I believe I did it correctly ;) -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] VM can't ping self floating IP after a snapshot is taken
I ran into some similar issues with the _enable_hairpin() call. The call is allowed to fail silently and (in my case) was failing. I couldn't for the life of me figure out why, though, and since I'm really not a networking person I didn't trace it along too far. Just thought I'd share my similar pain. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Sam Su Sent: Thursday, July 19, 2012 11:50 AM To: Brian Haley Cc: openstack Subject: Re: [Openstack] VM can't ping self floating IP after a snapshot is taken Thank you for your support. I checked the file nova/virt/libvirt/connection.py, the sentence self._enable_hairpin(instance) is already added to the function _hard_reboot(). It looks like there are some difference between taking snapshot and reboot instance. I tried to figure out how to fix this bug but failed. It will be much appreciated if anyone can give some hints. Thanks, Sam On Thu, Jul 19, 2012 at 8:37 AM, Brian Haley brian.ha...@hp.commailto:brian.ha...@hp.com wrote: On 07/17/2012 05:56 PM, Sam Su wrote: Hi, Just This always happens in Essex release. After I take a snapshot of my VM ( I tried Ubuntu 12.04 or CentOS 5.8), VM can't ping its self floating IP; before I take a snapshot though, VM can ping its self floating IP. This looks closely related to https://bugs.launchpad.net/nova/+bug/933640, but still a little different. In 933640, it sounds like VM can't ping its self floating IP regardless whether we take a snapshot or not. Any suggestion to make an easy fix? And what is the root cause of the problem? It might be because there's a missing _enable_hairpin() call in the reboot() function. Try something like this... nova/virt/libvirt/connection.py, _hard_reboot(): self._create_new_domain(xml) +self._enable_hairpin(instance) self.firewall_driver.apply_instance_filter(instance, network_info) At least that's what I remember doing myself recently when testing after a reboot, don't know about snapshot. Folsom has changed enough that something different would need to be done there. -Brian ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] No option fro creating and deleting users in openstack dashboard
Without information on how you installed keystone/horizon, I'm going to assume the most common problem: your local_settings.py file for Horizon is misconfigured/out of date. Particularly let me point out this section in the example file: https://github.com/openstack/horizon/blob/master/openstack_dashboard/local/local_settings.py.example#L69 Make sure you have that bit of code in the settings you're running with, as having that omitted (or setting can_edit_user to False) will cause exactly the behavior you describe. Someday we'll be able to query this information from Keystone itself via the API, but for now we have to use a setting. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of sarath zacharia Sent: Saturday, July 14, 2012 11:24 PM To: openstack@lists.launchpad.net Subject: [Openstack] No option fro creating and deleting users in openstack dashboard Hi, We installed the essex openstack for our cloud infrastructure with nova , keystone glance and dashboard . But when we accessing the user tab in the dashboard there is no option for creating new user and deleting user and we can create new project . In keystone there is two roles are Admin and member roles. Is there any other roles in Keystone for getting privilege to create new user through dashboard. and is it possible getting full screen vnc access through web browser ? Thanking You with regards Sarath Zacharia ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] About images list in dashboard
Already happened. https://github.com/openstack/horizon/commit/fec36c45dbbca4f3b446cdb231f53e4ab2f6f507 Since they didn't specify when/how they installed Essex, I'm going to assume they got a version that did not include this backport. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Matt Joyce Sent: Friday, July 13, 2012 5:13 PM To: Christian Parpart Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] About images list in dashboard I agree if someone wants to commit a backported fix. This makes sense to do. It's a pretty significant bug for essex users. -Matt On Fri, Jul 13, 2012 at 3:00 PM, Christian Parpart tra...@gmail.commailto:tra...@gmail.com wrote: On Fri, Jul 13, 2012 at 10:56 PM, John Postlethwait john.postlethw...@nebula.commailto:john.postlethw...@nebula.com wrote: Well, it sounds like this issue only happens in Essex, and is no longer an issue in Folsom, so the bug will just be closed as invalid, as it is now fixed in the newer code... Please backport this bug then. That is, the bug report indeed makes absolutely sense to me. :-) John Postlethwait Nebula, Inc. 206-999-4492tel:206-999-4492 On Friday, July 13, 2012 at 1:36 PM, Sam Su wrote: Thank you for you guys' suggestions. Even so, I'd like to file a bug to track this issue, if someone else have the same problem, they would know what happened and what progressed from the bug trace. Sam On Fri, Jul 13, 2012 at 12:43 PM, Gabriel Hurley gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote: Glance pagination was added in Folsom. Adding a bug for this won't help since it's already been added in the current code. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.netmailto:nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurleymailto:openstack-bounces%2Bgabriel.hurley=nebula@lists.launchpad.netmailto:nebula@lists.launchpad.net] On Behalf Of John Postlethwait Sent: Friday, July 13, 2012 12:05 PM To: Sam Su Cc: openstack Subject: Re: [Openstack] About images list in dashboard Hi Sam, Would you mind filing a bug against Horizon with the details so that we can get it fixed? You can do so here: https://bugs.launchpad.net/horizon/+filebug John Postlethwait Nebula, Inc. 206-999-4492tel:206-999-4492 On Thursday, July 12, 2012 at 3:55 PM, Sam Su wrote: I finally found why this happened. If in one tenant, there are more than 30 images and snapshots so that glance cannot return the images list in one response, some images and snapshots will not be seen in the page Images Snapshots of Horizon. Sam On Thu, Jul 5, 2012 at 1:19 PM, Sam Su susltd...@gmail.commailto:susltd...@gmail.com wrote: Thank you for your suggestion. I can see all images in other tenants from dashboard, so I think the images type should be ok. On Thu, Jul 5, 2012 at 11:54 AM, Gabriel Hurley gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote: The Project Dashboard hides images with an AKI or AMI image type (as they're not launchable and generally shouldn't be edited by normal users). You can see those in the Admin Dashboard if you want to edit them. So my guess is that the kernel and ramdisk images are being hidden correctly and your ubuntu-11.10-server-amd64 and ubuntu-12.04-server-amd64 have the wrong image type set. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.netmailto:nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurleymailto:openstack-bounces%2Bgabriel.hurley=nebula@lists.launchpad.netmailto:nebula@lists.launchpad.net] On Behalf Of Sam Su Sent: Thursday, July 05, 2012 11:20 AM To: openstack Subject: [Openstack] About images list in dashboard Hi, I have an Openstack Essex environment. The nova control services, glance, keystone and dashboard are all deployed in one server. Now I encounter a strange problem. I can only see two images (all images are set is_public=true) in the tenant 'demo' from dashboard, i.e., Horizon, as below: Image Name Type Status Public Container Format Actions CentOS-6.2-x86_64 Image Active YesOVF Launch CentOS-5.8-x86_64 Image Active YesOVF Launch However, when I use 'nova image-list' with the same credential for the same tenant 'demo', I can see many more images (see the following result) # nova image-list +-+--+- --+--+ | ID
Re: [Openstack] About images list in dashboard
Glance pagination was added in Folsom. Adding a bug for this won’t help since it’s already been added in the current code. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of John Postlethwait Sent: Friday, July 13, 2012 12:05 PM To: Sam Su Cc: openstack Subject: Re: [Openstack] About images list in dashboard Hi Sam, Would you mind filing a bug against Horizon with the details so that we can get it fixed? You can do so here: https://bugs.launchpad.net/horizon/+filebug John Postlethwait Nebula, Inc. 206-999-4492 On Thursday, July 12, 2012 at 3:55 PM, Sam Su wrote: I finally found why this happened. If in one tenant, there are more than 30 images and snapshots so that glance cannot return the images list in one response, some images and snapshots will not be seen in the page Images Snapshots of Horizon. Sam On Thu, Jul 5, 2012 at 1:19 PM, Sam Su susltd...@gmail.commailto:susltd...@gmail.com wrote: Thank you for your suggestion. I can see all images in other tenants from dashboard, so I think the images type should be ok. On Thu, Jul 5, 2012 at 11:54 AM, Gabriel Hurley gabriel.hur...@nebula.commailto:gabriel.hur...@nebula.com wrote: The “Project Dashboard” hides images with an AKI or AMI image type (as they’re not launchable and generally shouldn’t be edited by “normal” users). You can see those in the “Admin Dashboard” if you want to edit them. So my guess is that the kernel and ramdisk images are being hidden correctly and your “ubuntu-11.10-server-amd64” and “ubuntu-12.04-server-amd64” have the wrong image type set. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.netmailto:nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurleymailto:openstack-bounces%2Bgabriel.hurley=nebula@lists.launchpad.netmailto:nebula@lists.launchpad.net] On Behalf Of Sam Su Sent: Thursday, July 05, 2012 11:20 AM To: openstack Subject: [Openstack] About images list in dashboard Hi, I have an Openstack Essex environment. The nova control services, glance, keystone and dashboard are all deployed in one server. Now I encounter a strange problem. I can only see two images (all images are set is_public=true) in the tenant 'demo' from dashboard, i.e., Horizon, as below: Image Name Type Status Public Container Format Actions CentOS-6.2-x86_64 Image Active YesOVF Launch CentOS-5.8-x86_64 Image Active YesOVF Launch However, when I use 'nova image-list' with the same credential for the same tenant 'demo', I can see many more images (see the following result) # nova image-list +-+--+- --+--+ | ID| Name | Status | Server | +-+--+--- +--+ | 18b130ce-a815-4671-80e8-9308a7b6fc6d | ubuntu-12.04-server-amd64 | ACTIVE | | | 388d16ce-b80b-4e9e-b8db-db6dce6f4a83 | ubuntu-12.04-server-amd64-kernel | ACTIVE | | | 8d9505ce-0974-431d-a53d-e9ed6dc89033 | CentOS-6.2-x86_64 | ACTIVE | | | 99be14c0-3b15-470b-9e2d-a9d7e2242c7a | CentOS-5.8-x86_64 | ACTIVE | | | a486733f-c011-4fa1-8ce2-553084f9bc0e | ubuntu-11.10-server-amd64 | ACTIVE | | | ec7f9c5d-48b4-40e3-8e36-87fbdd099fee | ubuntu-12.04-server-amd64-ramdisk | ACTIVE | | | fbb3a182-e610-448f-8042-0b1addb90750 | ubuntu-12.04-server-amd64-hostname | ACTIVE | | +-+--+--- +--+ I am wondering how to make all these images seen in my the dashboard? It will be much appreciated if someone can give me some hints about this. Thanks, Sam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
The stated and agreed-upon goal from Essex forward is to make the core OpenStack projects N+1 compatible (e.g. Essex-Folsom, Folsom-Grizzly), and to make the clients capable of talking to every API version forever. Anything standing in the way of that should be considered a release-blocking bug, and should be filed against the appropriate projects. I for one intend to see to that as best I can. That said, there *is* a grey area around migration steps like Nova Volume - Cinder. If the migration path is clear, stable, well-documented, uses the same schemas and same APIs... I'd say that *may* still fall into the category of N+1 compatible. It sounds like that's the idea here, but that we need to thoroughly vet the practicality of that assertion. I don't think we can decide this without proof that the clean transition is 100% possible. Code isn't the only thing of value; constructively and respectfully shaping design decisions is great, testing and filing bugs is also fantastic. Profanity and disrespect are not acceptable. Ever. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of George Reese Sent: Thursday, July 12, 2012 12:15 PM To: Brian Waldon Cc: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom So if Im not coding, I should shut up? I think you answered your own question. Sent from my iPhone On Jul 12, 2012, at 14:10, Brian Waldon brian.wal...@rackspace.commailto:brian.wal...@rackspace.com wrote: What exactly was so offensive about what I said? Communities like OpenStack are built on top of people *doing* things, not *talking* about things. I'm just asking you to contribute code or design help rather than slanderous commentary. Brian Offensive Waldon On Jul 12, 2012, at 11:59 AM, George Reese wrote: You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive. -George On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote: This level of response is unnecessary. That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact. Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle. Cheers Chris Sent from my iPad On Jul 12, 2012, at 2:24 PM, George Reese george.re...@enstratus.commailto:george.re...@enstratus.com wrote: Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo - Essex would be the end of this compatibility bullshit. But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed. So you can kiss my ass. -George On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote: We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace. If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself. Have a great day! Brian Waldon On Jul 12, 2012, at 9:32 AM, George Reese wrote: This community just doesn't give a rat's ass about compatibility, does it? -George On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 --
Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom
I'm normally very much in favor of stable APIs and slow deprecation, but in this case I'm far more concerned about having to support two completely independent codebases. If we pursue option 2 I think the language there needs to be even stronger and we'd have to say that nova-volume is dead/frozen, should not be touched except for release blocking bugs, shouldn't have any new bugs filed against it, etc. Personally I'd like to follow option 1, but... - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Vishvananda Ishaya Sent: Wednesday, July 11, 2012 8:27 AM To: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Compressed image support ?
Filed that bug a month ago: https://bugs.launchpad.net/glance/+bug/1009248 Patches welcome. ;-) - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Christopher B Ferris Sent: Monday, July 09, 2012 7:41 PM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Compressed image support ? John Postlethwait wrote: ... Also, you need to make sure you are linking DIRECTLY to the image itself, as if it is a redirect or any other HTTP response besides the file, Glance will still create an image out of it and it will seem to have worked. Sometimes you can even launch said instances that are totally invalid. (During my testing of this I was able to successfully launch instances that were just the HTTP data from 302 redirects.) Why would the Glance client treat an HTTP 302 redirect as a 2xx? That seems rather odd behavior, and less like a feature and more like a bug, to me, if true. From the looks of the code, a RedirectException should be thrown. Cheers, Christopher Ferris IBM Distinguished Engineer, CTO Industry and Cloud Standards Member, IBM Academy of Technology IBM Software Group, Standards Strategy email: chris...@us.ibm.com Twitter: christo4ferris phone: +1 508 234 2986 -openstack-bounces+chrisfer=us.ibm@lists.launchpad.net wrote: -openstack-bounces+- To: Wang Li fox...@gmail.com From: John Postlethwait Sent by: openstack-bounces+chrisfer=us.ibm@lists.launchpad.net Date: 07/09/2012 03:38PM Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Compressed image support ? Hi Wang, Horizon simply uses the Python interface to Glance and tells it to create the image. Glance supports creating images from remote locations that are in a compressed format. There are examples in the Glance documentation here: https://github.com/openstack/glance/blob/master/doc/source/glance.rst# e xa mples-of-uploading-different-kinds-of-images and in the Glance binary itself here: https://github.com/openstack/glance/blob/master/bin/glance#L190 So this is widely supported and documented in Glance. The caveats are that through Horizon, the file MUST be accessible via the network configuration where Glance resides, if it is not accessible due to network configuration or something else, it will fail but seem to have succeeded. Also, you need to make sure you are linking DIRECTLY to the image itself, as if it is a redirect or any other HTTP response besides the file, Glance will still create an image out of it and it will seem to have worked. Sometimes you can even launch said instances that are totally invalid. (During my testing of this I was able to successfully launch instances that were just the HTTP data from 302 redirects.) I would first confirm that where Horizon is installed is able to communicate to where you are trying to copy the image from, and that the link you are using for the image is, in fact, a valid binary and not some other HTTP response. John Postlethwait Nebula, Inc. On Monday, July 9, 2012 at 1:04 AM, Wang Li wrote: hi, all As to the horizon UI, zip and tar.gz image files are supported. Specify an image to upload to the Image Service. Currently only images available via an HTTP URL are supported. The image location must be accessible to the Image Service. Compressed image binaries are supported (.zip and .tar.gz.) My test environment is as follow: 1. LVM as image backend of vms. 2. running vms on Xen in PV mode But when I upload a tar gzipped raw image file, nova just dd from it to logical volume, thus, nova error logged Boot loader didn't return any data! I grepped the nova and glance source code, found nothing about of gz or zip that related to image. This feature is valuable to our use case, for the raw image file is 4GB, but the compressed version is only 400MB. Did I misunderstand the compressed image support? Regards. Wang Li ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help :
Re: [Openstack] About images list in dashboard
The Project Dashboard hides images with an AKI or AMI image type (as they're not launchable and generally shouldn't be edited by normal users). You can see those in the Admin Dashboard if you want to edit them. So my guess is that the kernel and ramdisk images are being hidden correctly and your ubuntu-11.10-server-amd64 and ubuntu-12.04-server-amd64 have the wrong image type set. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Sam Su Sent: Thursday, July 05, 2012 11:20 AM To: openstack Subject: [Openstack] About images list in dashboard Hi, I have an Openstack Essex environment. The nova control services, glance, keystone and dashboard are all deployed in one server. Now I encounter a strange problem. I can only see two images (all images are set is_public=true) in the tenant 'demo' from dashboard, i.e., Horizon, as below: Image Name Type Status Public Container Format Actions CentOS-6.2-x86_64 Image Active YesOVF Launch CentOS-5.8-x86_64 Image Active YesOVF Launch However, when I use 'nova image-list' with the same credential for the same tenant 'demo', I can see many more images (see the following result) # nova image-list +-+--+- --+--+ | ID| Name | Status | Server | +-+--+--- +--+ | 18b130ce-a815-4671-80e8-9308a7b6fc6d | ubuntu-12.04-server-amd64 | ACTIVE | | | 388d16ce-b80b-4e9e-b8db-db6dce6f4a83 | ubuntu-12.04-server-amd64-kernel | ACTIVE | | | 8d9505ce-0974-431d-a53d-e9ed6dc89033 | CentOS-6.2-x86_64 | ACTIVE | | | 99be14c0-3b15-470b-9e2d-a9d7e2242c7a | CentOS-5.8-x86_64 | ACTIVE | | | a486733f-c011-4fa1-8ce2-553084f9bc0e | ubuntu-11.10-server-amd64 | ACTIVE | | | ec7f9c5d-48b4-40e3-8e36-87fbdd099fee | ubuntu-12.04-server-amd64-ramdisk | ACTIVE | | | fbb3a182-e610-448f-8042-0b1addb90750 | ubuntu-12.04-server-amd64-hostname | ACTIVE | | +-+--+--- +--+ I am wondering how to make all these images seen in my the dashboard? It will be much appreciated if someone can give me some hints about this. Thanks, Sam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] About images list in dashboard
Sorry, that's should've read AKI or ARI. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Gabriel Hurley Sent: Thursday, July 05, 2012 11:54 AM To: Sam Su; openstack Subject: Re: [Openstack] About images list in dashboard The Project Dashboard hides images with an AKI or AMI image type (as they're not launchable and generally shouldn't be edited by normal users). You can see those in the Admin Dashboard if you want to edit them. So my guess is that the kernel and ramdisk images are being hidden correctly and your ubuntu-11.10-server-amd64 and ubuntu-12.04-server-amd64 have the wrong image type set. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.netmailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net]mailto:[mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Sam Su Sent: Thursday, July 05, 2012 11:20 AM To: openstack Subject: [Openstack] About images list in dashboard Hi, I have an Openstack Essex environment. The nova control services, glance, keystone and dashboard are all deployed in one server. Now I encounter a strange problem. I can only see two images (all images are set is_public=true) in the tenant 'demo' from dashboard, i.e., Horizon, as below: Image Name Type Status Public Container Format Actions CentOS-6.2-x86_64 Image Active YesOVF Launch CentOS-5.8-x86_64 Image Active YesOVF Launch However, when I use 'nova image-list' with the same credential for the same tenant 'demo', I can see many more images (see the following result) # nova image-list +-+--+- --+--+ | ID| Name | Status | Server | +-+--+--- +--+ | 18b130ce-a815-4671-80e8-9308a7b6fc6d | ubuntu-12.04-server-amd64 | ACTIVE | | | 388d16ce-b80b-4e9e-b8db-db6dce6f4a83 | ubuntu-12.04-server-amd64-kernel | ACTIVE | | | 8d9505ce-0974-431d-a53d-e9ed6dc89033 | CentOS-6.2-x86_64 | ACTIVE | | | 99be14c0-3b15-470b-9e2d-a9d7e2242c7a | CentOS-5.8-x86_64 | ACTIVE | | | a486733f-c011-4fa1-8ce2-553084f9bc0e | ubuntu-11.10-server-amd64 | ACTIVE | | | ec7f9c5d-48b4-40e3-8e36-87fbdd099fee | ubuntu-12.04-server-amd64-ramdisk | ACTIVE | | | fbb3a182-e610-448f-8042-0b1addb90750 | ubuntu-12.04-server-amd64-hostname | ACTIVE | | +-+--+--- +--+ I am wondering how to make all these images seen in my the dashboard? It will be much appreciated if someone can give me some hints about this. Thanks, Sam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] best practices for merging common into specific projects
Having a team/leader in that arena would definitely help. I'd contribute to common more if I knew what needed contributing, who to talk to about it, etc... Same goes for helping in terms of packaging, etc. to make it a proper common library. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: Wednesday, July 04, 2012 2:57 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] best practices for merging common into specific projects Monty Taylor wrote: However, with a versioned library model, the projects can consume things pinned to specific versions, and then they can submit a change that updates the version depend and the code which needs to be updated to support the version change, and that change can be atomic. So honestly, I'd say the real key is getting us closer to the point where openstack-common is a proper library, because all of the rest of the complexity is stuff we're inventing to make life harder on ourselves, when the standard library with api-contract and a version model of the world works pretty fine without needing coordinated changes across multiple repositories. Yes, that's the end goal. And IMHO we are not very far away. I think the main reason we are not there yet is that while a lot of people enjoy giving their opinions about how openstack-common should be done and consumed by projects, not so many people follow up and actually do the work. Making our multiple projects converge onto consolidated and well-accepted APIs is a bit painful work, but it is a prerequisite to turning openstack- common into a proper library (or set of libraries). I'd say the whole thing suffers from not having a proper team/leader/coordinator dedicated to it: relying on existing, overstretched PTLs to lead that effort might not be the fastest path. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Single global dependency list
So, I understand the rationales, and I think of those three options the one chosen is the most reasonable. I'm gonna just come out and say I hate this whole idea, but let's set this aside for a minute 'cuz I have a genuine question: What will the process be for merging changes to this requirements list? Having yet another roadblock to getting your contribution merged is a huge developer disincentive. We're really making it exceptionally hard for new contributors, and frustrating even for the old hands. So, with the goal of making the coordinated management of the projects possible, what can we do to respect developers? - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Monty Taylor Sent: Tuesday, July 03, 2012 7:54 AM To: Eric Windisch Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Single global dependency list On 07/03/2012 10:09 AM, Eric Windisch wrote: I have to agree with others that copying files around is not ideal, and I can see the maintenance of this getting more involved as Nova becomes more coupled with common. Additionally, we'd make the copy only copy in the versions from openstack-common for package that were already listed in the target project, so that we wouldn't add django to python-swiftclient, for instance. This seems to be a reasonable argument against using git submodules, but I'm afraid we might be losing more than we're gaining here. Just because python-swiftclient depends on openstack-common, and django-using code exists there, doesn't mean that django needs to be installed for python-swiftclient. We might do better to use git submodules and solve the dependency problem, than continuing down this copy-everything path. We're explicitly NOT doing a copy-everything path. That's the whole point. We're only copying the needed depends from the master list. git submodules actually make the problem worse, not better. Alternatively, speed up the movement from incubation to library. Yeah - that's kind of the reason that bcwaldon was saying this shouldn't be in openstack-common. openstack-common wants to be a library, and then we're back at not having an appropriate place for the master list. Monty ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] best practices for merging common into specific projects
The notion that copying code is any protection against APIs that may change is a red herring. It's the exact same effect as pegging a version of a dependency (whether it's a commit hash or a real version number), except now you have code duplication. An unstable upgrade path is an unstable upgrade path, and copying the code into the project doesn't alleviate the pain for the project if the upstream library decides to change its APIs. Also, we're really calling something used by more or less all the core projects incubated? ;-) Seems like it's past the proof-of-concept phase now, at least for many parts of common. Questions of API stability are an issue unto themselves. Anyhow, I'm +1 on turning it into a real library of its own, as a couple people suggested already. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of James E. Blair Sent: Tuesday, July 03, 2012 6:56 AM To: andrewbog...@gmail.com Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] best practices for merging common into specific projects Andrew Bogott abog...@wikimedia.org writes: I. As soon as a patch drops into common, the patch author should submit merge-from-common patches to all affected projects. A. (This should really be done by a bot, but that's not going to happen overnight) Actually, I think with our current level of tooling, we can have Jenkins do this (run by Zuul as a post-merge job on openstack-common). I very much believe that the long-term goal should be to make openstack- common a library -- so nothing I say here should be construed against that. But as long as it's in an incubation phase, if doing something like this would help move things along, we can certainly implement it, and fairly easily. Note that a naive implementation might generate quite a bit of review spam if several small changes land to openstack-common (there would then be changes*projects number of reviews in gerrit). We have some code laying around which might be useful here that looks for an existing open change and amends it; at least that would let us have at most only one open merge- from-common-change per-project. Okay, that's all on that; I don't want to derail the main conversation, and I'd much rather it just be a library if we're close to being ready for that. -Jim ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Single global dependency list
Agreed on all points, and I know you're not evil, Monty. ;-) (mostly) You're totally right that this particular case won't stymie new contributors, but as we've seen for changes to common--and sometimes even to the client libraries or devstack--reviewers are in short supply and getting the change you need in one of the gate projects merged can often add days of impedance to otherwise fruitful work. It's bitten me plenty of times. So the need for balance is critical. Being able to vet the impact of a change on every project consuming it is difficult for either automated systems or human reviewers, so we do our best. Perhaps the simplest answer for now is devising a reasonable set of automated gate tests for this os-requires module that humans can trust, and working to expand the circle of reviewers on these centralized projects that have the power to block everyone yet are so easy to ignore... All the best, - Gabriel -Original Message- From: Monty Taylor [mailto:mord...@inaugust.com] Sent: Tuesday, July 03, 2012 12:49 PM To: Gabriel Hurley Cc: Eric Windisch; openstack@lists.launchpad.net Subject: Re: [Openstack] Single global dependency list It's a good and valid question and I don't really know. In this case, I'm merely the pack-horse who was told global synchronized dependencies lists! (not that I'm not the evil person cooking up schemes) That said - most patches from new contributors don't actually come with new library dependencies. If they are adding a new depend, I think it's reasonable to expect it to be slightly harder to get that landed. I do think that we need an answer to who approves changes to this list. Getting stuff merged to openstack-common is often hard because it's a smaller list of people who work on it. I'd hate to see this be only PTLs. However, things like let's upgrade webob seem to _actually_ need more eyes than it seems like at the time. meh. On 07/03/2012 03:12 PM, Gabriel Hurley wrote: So, I understand the rationales, and I think of those three options the one chosen is the most reasonable. I'm gonna just come out and say I hate this whole idea, but let's set this aside for a minute 'cuz I have a genuine question: What will the process be for merging changes to this requirements list? Having yet another roadblock to getting your contribution merged is a huge developer disincentive. We're really making it exceptionally hard for new contributors, and frustrating even for the old hands. So, with the goal of making the coordinated management of the projects possible, what can we do to respect developers? - Gabriel -Original Message- From: openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Monty Taylor Sent: Tuesday, July 03, 2012 7:54 AM To: Eric Windisch Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Single global dependency list On 07/03/2012 10:09 AM, Eric Windisch wrote: I have to agree with others that copying files around is not ideal, and I can see the maintenance of this getting more involved as Nova becomes more coupled with common. Additionally, we'd make the copy only copy in the versions from openstack-common for package that were already listed in the target project, so that we wouldn't add django to python-swiftclient, for instance. This seems to be a reasonable argument against using git submodules, but I'm afraid we might be losing more than we're gaining here. Just because python-swiftclient depends on openstack-common, and django-using code exists there, doesn't mean that django needs to be installed for python-swiftclient. We might do better to use git submodules and solve the dependency problem, than continuing down this copy-everything path. We're explicitly NOT doing a copy-everything path. That's the whole point.. We're only copying the needed depends from the master list. git submodules actually make the problem worse, not better. Alternatively, speed up the movement from incubation to library. Yeah - that's kind of the reason that bcwaldon was saying this shouldn't be in openstack-common. openstack-common wants to be a library, and then we're back at not having an appropriate place for the master list. Monty ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] best practices for merging common into specific projects
I’m pretty -1 on triggering changes in other projects from common. That’s gonna result in a broken code (whether subtle or obvious) no matter how good your gates are. At least as an external library you can freeze a version requirement until such time as you see fit to properly updated that code and *ensure* compatibility in your project. Or if your project likes ridin’ trunk, then don’t pin a version and you’ve got the same effect as an automatic trigger. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Andrew Bogott Sent: Tuesday, July 03, 2012 3:54 PM To: Eric Windisch; openstack@lists.launchpad.net Subject: Re: [Openstack] best practices for merging common into specific projects On 7/3/12 5:47 PM, Eric Windisch wrote: git submodules don't have to be linked to the head of a branch. Instead of double-commiting (for every commit), we can do a single commit in each project to change the git reference of the submodule. This would not be too far from the existing behavior, except that it would minimize the double commits. Oh, I guess I left out an important part of my vision, which is that there would be a commit hook in common which moves the submodule reference in the parent projects anytime a patch is merged in common. So, in short: once a patch passed review for inclusion in common, that patch would automatically go live in all other project heads simultaneously. -- Eric Windisch On Tuesday, July 3, 2012 at 15:47 PM, Andrew Bogott wrote: On 7/3/12 1:59 PM, Gabriel Hurley wrote: The notion that copying code is any protection against APIs that may change is a red herring. It's the exact same effect as pegging a version of a dependency (whether it's a commit hash or a real version number), except now you have code duplication. An unstable upgrade path is an unstable upgrade path, and copying the code into the project doesn't alleviate the pain for the project if the upstream library decides to change its APIs. Also, we're really calling something used by more or less all the core projects incubated? ;-) Seems like it's past the proof-of-concept phase now, at least for many parts of common. Questions of API stability are an issue unto themselves. Anyhow, I'm +1 on turning it into a real library of its own, as a couple people suggested already. - Gabriel I feel like I should speak up since I started this fight in the first place :) Like most people in this thread, I too long for an end to the weird double-commit process that we're using now. So I'm happy to set aside my original Best Practices proposal until there's some consensus regarding how much longer we're going to use that process. Presumably opinions about how to handle merge-from-common commits will vary in the meantime, but that's something we can live with. In terms of promoting common into a real project, though, I want to raise another option that's guaranteed to be unpopular: We make openstack-common a git-submodule that is automatically checked out within the directory tree of each other project. Then each commit to common would need to be gated by the full set of tests on every project that includes common. I haven't thought deeply about the pros and cons of code submodule vs. python project, but I want to bring up the option because it's the system that I'm the most familiar with, and one that's been discussed a bit off and on. -Andrew ___ Mailing list: https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack G naming poll
+1 on close enough to an arbitrary territory and also a great name. ;-) Also, the Grizzly is the California state animal: http://www.statesymbolsusa.org/California/animal_grizzly_bear.html Food for thought. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Brian Waldon Sent: Tuesday, July 03, 2012 4:50 PM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Cc: Thierry Carrez Subject: Re: [Openstack] OpenStack G naming poll TL;DR - Screw the rules, let's call the next release 'Grizzly' As California is rather lacking in the 'municipality names starting with a G that we should use for an OpenStack release' department, I have had to look *slightly* outside the ruleset to find a suitable 'G' release name - that name being 'Grizzly'. The rules clearly state that a release name must represent a city or county near the corresponding design summit and be comprised of a single word of ten characters or less - the problem here being that 'Grizzly' is actually 'Grizzly Flats.' Having already polled a small subset of the community, I feel like there would be enough support for 'Grizzly' to win if it were on the ballot. As I'm more interested in selecting a suitable name than accurately representing some arbitrary territory, I'd love to either permanently amend the rules to make this acceptable or grant an exception in this one case. As Thierry said, if this reaches critical mass, we will figure out what to do. Otherwise, I'll shut up and deal with 'Gazelle'. Brian On Jul 3, 2012, at 3:20 PM, Thierry Carrez wrote: Yes, it's that time of the year again... time for us to choose the name of the next OpenStack release ! This time, cities and counties in California (San Diego, CA being the location of the G design summit) I set up a poll with the available options (based on our current rules of naming) at: https://launchpad.net/~openstack/+poll/g-release-naming Poll is accessible to all members of ~openstack group in Launchpad, and ends next Tuesday, 21:30 UTC. Please cast your vote! I'm aware that a subversive movement wants to try to amend the rules so that another name option becomes available. Since we can't stop (or modify) the poll now that it's been launched, if that movement reaches critical mass, we may organize a second round of polling :) -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] best practices for merging common into specific projects
On a more fundamental level, did I miss some tremendous reason why we have this merge from common pattern instead of making OpenStack Common a standard python dependency just like anything else? Especially with the work Monty has recently done on versioning and packaging the client libs from Jenkins, I can't see a reason to keep following this update common and merge to everything else pattern at all... - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Andrew Bogott Sent: Monday, July 02, 2012 12:17 PM To: openstack@lists.launchpad.net Subject: [Openstack] best practices for merging common into specific projects Having spent some time last week writing code for openstack-common, and having spent yet more time trying to get those changes into Nova, I think it would be useful to define some best practices when crossing the boundary between common and other openstack projects. Background: The openstack-common project is subject to a standard code-review process (and, soon, will also have Jenkins testing gates.) Sadly, patches that are merged into openstack-common are essentially orphans. Bringing those changes into actual use requires yet another step, a 'merge from common' patch where the code changes in common are copied into a specific project (e.g. nova.) Merge-from-common patches are generated via an automated process. Specific projects express dependencies on specific common components via a config file, e.g. 'nova/openstack-common.conf'. The actual file copy is performed by 'openstack-common/update.py,' and its behavior is governed by the appropriate openstack-common.conf file. Questions: When should changes from common be merged into other projects? What should a 'merge-from-common' patch look like? What code-review standards should core committers observe when reviewing merge-from-common patches? Proposals: I. As soon as a patch drops into common, the patch author should submit merge-from-common patches to all affected projects. A. (This should really be done by a bot, but that's not going to happen overnight) II. In the event that I. is not observed, merge-from-common patches will contain bits from multiple precursor patches. That is not only OK, but encouraged. A. Keeping projects in sync with common is important! B. Asking producers of merge-from-common patches to understand the full diff will discourage the generation of such merges. III.Merge-from-common patches should be the product of a single unedited run of update.py. A. If a merge-from-common patch breaks pep8 or a test in nova, don't fix the patch; fix the code in common. IV.Merge-from-common patches are 'presumed justified'. That means: A. Reviewers of merge-from-common patches should consider test failures and pep8 breakages, and obvious functional problems. B. Reviewers of merge-from-common patches should not consider the usefulness, design, etc. of merge-from-common patches. Such concerns need to be handled within the common review process. C. Merges from common should get reviewed early and approved readily in order to avoid project divergence V. Changes to openstack-common.conf are a special case. A. Patches with openstack-common.conf changes should include the relevant merge-from-common changes. B. Such patches should /not/ include any other merge-from-common changes. C. Such patches should not only include the common merges, but should also include whatever code changes make use of the new merge. D. Such patches require the same justification and scrutiny as any other standard project patch. Please discuss! If we're able to reach general agreement about this process, I will document the process in the openstack-common HACKING guidelines. -Andrew On 7/2/12 11:38 AM, Russell Bryant (Code Review) wrote: I did that before seeing this patch. However, I think I prefer what I pushed since it's individual updates explaining what they update instead of a blanket update everything commit. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Devstack]Keystone authentication problem when installing
I'm seeing this error too. It appears that the environment variables (SERVICE_TOKEN, etc.) aren't getting exported, causing keystoneclient to not find them in the environment and triggering that error. What I can't figure out is what changed in the last couple days to make this suddenly stop working. :-/ I'm still looking into it on my end, but any other ideas would be helpful. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Ke Wu Sent: Thursday, June 28, 2012 10:28 AM To: Vaze, Mandar Cc: openstack mail list Subject: Re: [Openstack] [Devstack]Keystone authentication problem when installing Thanks Mandar, Yet could you please explain it in detail? I am pretty new to devstack and didn't see the relationship between the bugs you mentioned and the error I encountered. Appreciate it! -K On Jun 27, 2012, at 9:27 PM, Vaze, Mandar wrote: May be related to https://bugs.launchpad.net/keystone/+bug/995976 Check last comment at https://bugs.launchpad.net/keystone/+bug/995811 -Mandar From: openstack-bounces+mandar.vaze=nttdata@lists.launchpad.netmailto:openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net [mailto:openstack-bounces+mandar.vaze=nttdata@lists.launchpad.netmailto:nttdata@lists.launchpad.net] On Behalf Of Ke Wu Sent: Thursday, June 28, 2012 7:01 AM To: openstack mail list Subject: [Openstack] [Devstack]Keystone authentication problem when installing Hi, I can't find a mailing list of devstack so I choose to ask here, hope this doesn't spam you guys. I was trying to build Devstack on my VM (Ubuntu 12.04 server) to start a new environment for Horizon development. Everything went well until it hit the point to start Keystone service, the error msg was: Expecting authentication method via either a service token, --token or env[SERVICE_TOKEN], or credentials, --os_username or env[OS_USERNAME]. + NOVA_USER_ID= ++ get_field 1 ++ read data ++ grep ' service ' ++ keystone tenant-list Expecting authentication method via either a service token, --token or env[SERVICE_TOKEN], or credentials, --os_username or env[OS_USERNAME]. + NOVA_TENANT_ID= ++ keystone ec2-credentials-create --user --tenant_id usage: keystone ec2-credentials-create [--user_id user-id] [--tenant_id tenant-id] keystone ec2-credentials-create: error: argument --user_id: expected one argument + CREDS= ++ failed ++ local r=2 ++ set +o xtrace Anybody has an idea why this happened? Thanks! -Ke Wu __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Devstack]Keystone authentication problem when installing
I've found where the problem stems from. It snuck in with the keystone sql backend change: https://github.com/openstack-dev/devstack/commit/3f7c06f5aaff5d3e2ec28931e0fe4ab8376208e6#L1L1944 Previously the arguments to the keystone commands were being passed in directly, now they're not, hence the failure. As per the usual, Jenkins doesn't catch this bug because it doesn't test with swift enabled. That's twice that swift-enabled bugs have snuck into devstack lately. :-/ - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Ke Wu Sent: Wednesday, June 27, 2012 7:35 PM To: Adam Young Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Devstack]Keystone authentication problem when installing Here is my localrc: ENABLED_SERVICES=$ENABLED_SERVICES,swift MYSQL_PASSWORD=password ADMIN_PASSWORD= password RABBIT_PASSWORD= password SERVICE_TOKEN= password SWIFT_HASH= password HOST_IP=10.0.0.0 RECLONE=yes SERVICE_PASSWORD= password By what distribution you mean? I clone the devstack code project from github. Thanks, -K On Jun 27, 2012, at 6:44 PM, Adam Young wrote: Can you post your localrc file? YOu can blank out the passwords. Also, what distribution? On 06/27/2012 09:30 PM, Ke Wu wrote: Hi, I can't find a mailing list of devstack so I choose to ask here, hope this doesn't spam you guys. I was trying to build Devstack on my VM (Ubuntu 12.04 server) to start a new environment for Horizon development. Everything went well until it hit the point to start Keystone service, the error msg was: Expecting authentication method via either a service token, --token or env[SERVICE_TOKEN], or credentials, --os_username or env[OS_USERNAME]. + NOVA_USER_ID= ++ get_field 1 ++ read data ++ grep ' service ' ++ keystone tenant-list Expecting authentication method via either a service token, --token or env[SERVICE_TOKEN], or credentials, --os_username or env[OS_USERNAME]. + NOVA_TENANT_ID= ++ keystone ec2-credentials-create --user --tenant_id usage: keystone ec2-credentials-create [--user_id user-id] [--tenant_id tenant-id] keystone ec2-credentials-create: error: argument --user_id: expected one argument + CREDS= ++ failed ++ local r=2 ++ set +o xtrace Anybody has an idea why this happened? Thanks! -Ke Wu ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Devstack]Keystone authentication problem when installing
This turned out to be a legitimate bug in devstack. bug report: https://bugs.launchpad.net/devstack/+bug/1019056 and review: https://review.openstack.org/#/c/9143/ All the best, - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Dean Troyer Sent: Thursday, June 28, 2012 12:45 PM To: Ke Wu Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Devstack]Keystone authentication problem when installing On Wed, Jun 27, 2012 at 9:34 PM, Ke Wu ke...@ibeca.me wrote: Here is my localrc: ENABLED_SERVICES=$ENABLED_SERVICES,swift MYSQL_PASSWORD=password ADMIN_PASSWORD= password RABBIT_PASSWORD= password SERVICE_TOKEN= password SWIFT_HASH= password Do you have spaces following the '=' as shown above? If so that will put a space as the first character of the value. HOST_IP=10.0.0.0 If you set HOST_IP it should be set to the IP address of your primary interface, not a network address. Could you show us the lines _before_ the error log you posted? Specifically, I'd like to see the group of variable assignments immediately before keystone_data.sh is called. dt -- Dean Troyer dtro...@gmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] horizon install from devstack fails to find glanceclient/versioninfo
I'm seeing a lot of that on the CI gate jobs today, too. Seems to be an problem
installing dependencies with pip. Usually I blame this on transient network
problems, unless somebody's been mucking with the clients themselves...
- Gabriel
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On
Behalf Of Doug Hellmann
Sent: Tuesday, June 26, 2012 1:19 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] horizon install from devstack fails to find
glanceclient/versioninfo
I'm having trouble running devstack today. I'm getting the following error
during the horizon installation. Does anyone have any idea what would be
causing that?
Doug
Downloading/unpacking python-glanceclient (from -r
horizon.egg-info/requires.txt (line 7))
Running setup.py egg_info for package python-glanceclient
Traceback (most recent call last):
File string, line 14, in module
File /opt/stack/horizon/build/python-glanceclient/setup.py, line 22, in
module
version=setup.get_post_version('glanceclient'),
File glanceclient/openstack/common/setup.py, line 329, in
get_post_version
return open(os.path.join(projectname, 'versioninfo'),
'r').read().strip()
IOError: [Errno 2] No such file or directory: 'glanceclient/versioninfo'
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File string, line 14, in module
File /opt/stack/horizon/build/python-glanceclient/setup.py, line 22, in
module
version=setup.get_post_version('glanceclient'),
File glanceclient/openstack/common/setup.py, line 329, in get_post_version
return open(os.path.join(projectname, 'versioninfo'), 'r').read().strip()
IOError: [Errno 2] No such file or directory: 'glanceclient/versioninfo'
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] proposing adding Adam Young (ayoung) to keystone-core
I can get behind that. Despite some vigorous debates he and I have had, I can stand behind his overall knowledge, contributions and quality standards. ;-) +1. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Tuesday, June 26, 2012 2:07 PM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: [Openstack] [keystone] proposing adding Adam Young (ayoung) to keystone-core Given his work in Keystone since the redux, I would like propose Adam Young (ayoung) be added to the group keystone-core. For a process in doing this, I thought we'd generally follow Nova's core- promotion process = lazy consensus over a week, and assuming no -1's and at least two +1's from current core members, it's good to go. -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack Dashboard Error
It sounds like your local_settings.py file is missing any logging configuration. The default config from the local_settings.py.example file is a good place to start. If that’s not the case, then it would be helpful to know how you installed OpenStack/Horizon, what you’ve done to configure it, etc. All the best, - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Trinath Somanchi Sent: Sunday, June 24, 2012 10:03 PM To: openstack@lists.launchpad.net Subject: [Openstack] Openstack Dashboard Error Hi- I'm seeing this error when I access the Openstack Dashboard through my browser. [error] No handlers could be found for logger openstack_dashboard. Please help me resolve this issue. -- Regards, -- Trinath Somanchi, +91 9866 235 130 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack-poc] [Openstack] Thoughts on client library releasing
Big +1 for automated tagging and releasing (sounds like we're managing wildlife...) from Jenkins! - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Monty Taylor Sent: Monday, June 18, 2012 3:00 PM To: Joe Heck Cc: openstack-poc@lists.launchpad.net; openst...@lists.launchpad.net Subject: Re: [Openstack] [Openstack-poc] Thoughts on client library releasing On 06/18/2012 02:26 PM, Joe Heck wrote: Monty - Thierry stated it as an assumption last PPB meeting, but I'd like it to be explicit that we have at least a tag on each client library release that we make so that it's possible to distribute a version of the clients. +1000 I didn't want to get too far into implementation details, but the way I'd really like to see this work for the client libs is that releases are actually trigger via jenkins by tags on the repo - so there would literally be no way to release something _without_ a tag. I've got a POC patch to do the tag-based-versioning here: https://review.openstack.org/#/c/8427/ We need to get (aiui) one thing landed to zuul so that we can appropriately trigger on tag events... but that's the plan in my brain hole. On Jun 18, 2012, at 2:11 PM, Monty Taylor wrote: We're trying to figure out how we release client libraries. We're really close - but there are some sticking points. First of all, things that don't really have dissent (with reasoning) - We should release client libs to PyPI Client libs are for use in other python things, so they should be able to be listed as dependencies. Additionally, proper releases to PyPI will make our cross project depends work more sensibly - They should not necessarily be tied to server releases There could be a whole version of the server which sees no needed changes in the client. Alternately, there could be new upcoming server features which need to go into a released version of the library even before the server is released. - They should not be versioned with the server See above. - Releases of client libs should support all published versions of server APIs An end user wants to talk to his openstack cloud - not necessarily to his Essex cloud or his Folsom cloud. That user may also have accounts on multiple providers, and would like to be able to write one program to interact with all of them - if the user needed the folsom version of the client lib to talk to the folsom cloud and the essex version to talk to the essex cloud, his life is very hard. However, if he can grab the latest client lib and it will talk to both folsom and essex, then he will be happy. There are three major points where there is a lack of clear agreement. Here they are, along with suggestions for what we do about them. - need for official stable branches I would like to defer on this until such a time as we actually need it, rather than doing the engineering for in case we need it. But first, I'd like to define we, and that is that we are OpenStack as an upstream. As a project, we are at the moment probably the single friendliest project for the distros in the history of software. But that's not really our job. Most people out there writing libraries do not have multiple parallel releases of those libraries - they have the stable library, and then they release a new one, and people either upgrade their apps to use the new lib or they don't. One of the reasons this has been brought up as a need is to allow for drastic re-writes of a library. I'll talk about that in a second, but I think that is a thing that needs to have allowances for happening. So the model that keystone-lite used - create an experimental branch for the new work, eventually propose that it becomes the new master - seems like a better fit for the drastic rewrite scenario than copying the stable/* model from the server projects, because I think the most common thing will be that library changes are evolutionary, and having two mildly different branches that both represent something that's actually pretty much stable will just be more confusing than helpful. That being said - at such a time that there is actually a pain-point or a specific need for a stable branch, creating branches is fairly easy ... but I think once we have an actual burning need for such a thing, it will make it easier for us to look at models of how we'll use it. - API or major-rewrite-driven versioning scheme I was wondering why bcwaldon and I were missing each other so strongly in the channel the other day when we were discussing this, and then I realized that it's because we have one word API that's getting overloaded for a couple of different meanings - and also that I was being vague in my usage of
Re: [Openstack] [keystone] Keystone on port 5000 - proposing change default port to 8770
The port change is fine with me since we're trampling on an already-registered port number. However, I'd like to ask again about the admin vs. standard ports in the Keystone v3 API. There was no mention of the differentiation between the two or how they would be used. Especially in a post-RBAC/policy.json world, what is an admin API call? Does Keystone really need two ports (Matt Joyce suggests it does) or could they be one? - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Nguyen, Liem Manh Sent: Thursday, June 21, 2012 10:40 AM To: Joseph Heck; Vaze, Mandar Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [keystone] Keystone on port 5000 - proposing change default port to 8770 +1 for an IANA-registered public port. I wonder why we registered the admin port, but not the public port in the first place. Liem -Original Message- From: openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net [mailto:openstack-bounces+liem_m_nguyen=hp@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Thursday, June 21, 2012 1:28 AM To: Vaze, Mandar Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [keystone] Keystone on port 5000 - proposing change default port to 8770 Honestly the only reason is that I've heard some fairly direct feedback that port 5000 is that MS uPnP port and hence blocked by many corporate entities, so it's just a matter of a PITA and a slight bump in setup for those groups. Thought to honestly register another port with IANA like 35357 and put it in place - wanted to see if anyone screamed first. -joe On Jun 20, 2012, at 8:49 PM, Vaze, Mandar wrote: public_port is configurable via keystone.conf - so if port 5000 is blocked in specific setup, it is trivial to change it to some other port. why make so many changes (REST docs, XML docs, devstack, and the code) for a parameter that can be easily tweaked ? -Mandar -Original Message- From: openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net [mailto:openstack-bounces+mandar.vaze=nttdata@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Thursday, June 21, 2012 4:46 AM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: [Openstack] [keystone] Keystone on port 5000 - proposing change default port to 8770 At the risk of a terrible public tar and feathering... I've learned that port 5000 (which Keystone is using for it's default public- token-auth stuff) is commonly blocked by many firewalls, as it's been registered as a Microsoft uPnP port. I thought I'd go ahead and propose changing the default to 8770. I picked this number because it's close to the Nova ports in common use (8773, 8774, 8775, and 8776). And yes, I'll submit updates to all REST docs, XML docs, devstack, and the code. So... how many people do I need to worry about murdering me for this next design summit? -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Need stable/essex review for Horizon
Argh. I think it interacted with one of the other backports badly. I'll update this today. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Mark McLoughlin Sent: Thursday, June 21, 2012 3:07 PM To: Devin Carlen Cc: openstack Subject: Re: [Openstack] Need stable/essex review for Horizon On Thu, 2012-06-21 at 13:21 -0700, Devin Carlen wrote: Hey all, We've had a number of stable/essex reviews up that were abandoned due to lack of reviews. We have re-enabled them and are hoping to get some eyes on these so we can release 2012.1.1: https://review.openstack.org/#/c/7718/ This one - aka the scary one - has test failures Cheers, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Need stable/essex review for Horizon
Updated the review on gerrit so the test that got added by another backport to work with this patch. Everything should be good there now. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Mark McLoughlin Sent: Thursday, June 21, 2012 3:07 PM To: Devin Carlen Cc: openstack Subject: Re: [Openstack] Need stable/essex review for Horizon On Thu, 2012-06-21 at 13:21 -0700, Devin Carlen wrote: Hey all, We've had a number of stable/essex reviews up that were abandoned due to lack of reviews. We have re-enabled them and are hoping to get some eyes on these so we can release 2012.1.1: https://review.openstack.org/#/c/7718/ This one - aka the scary one - has test failures Cheers, Mark. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Blueprint automatic-secure-key-generation] Automatic SECURE_KEY generation
Sascha, That's all fine; my only reasoning on step 4 was simply that we could provide a more detailed, controlled error message by checking for the key ourselves. I actually don't feel strongly on that point. - Gabriel -Original Message- From: Sascha Peilicke [mailto:sasc...@suse.de] Sent: Wednesday, June 20, 2012 9:05 AM To: Gabriel Hurley; openstack@lists.launchpad.net Cc: Paul McMillan Subject: Re: [Openstack] [Blueprint automatic-secure-key-generation] Automatic SECURE_KEY generation Hi guys, according from your answers, I believe we're still trying to tackle slightly different issues, so I'd like step back a bit and try to sum up our discussion. Please correct me where I am wrong. I think we all agree that the SECRET_KEY should be protected as much as possible, via sensible file permissions, restricted access to the dashboard machine(s)/VM(s), HTTPS and all that jazz. One should also set SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY and CSRF_COOKIE_SECURE appropriately. We also agree that a key has to be generated somehow and no default key should be provided (given the ability to abuse it easily). So the only remaining question is about _when_ to actually set the key. You both seem to want a key generated automatically for development environments (and thus, for run_tests.sh), possible by also asking the user if he wants that or not. That's a worthy thing to do and I'll try to address this in the way Gabriel proposed (see below). So only production deployments are left. There, I see (roughly) two scenarios that may occur in practice: - One dashboard instance on one machine/VM served by one or multiple python interpreters (through Apache+mod_wsgi or whatever) - Multiple dashboard instances, split over multiple machines, where each may use one or more interpreters In both cases, we would have to make sure that all dashboard instances have the _same_ SECRET_KEY available before starting up (to the latest at the time they read their settings.py). Besides letting this be done by the admin manually, there's the option to automate this. Obviously, this may be different depending on how dashboard(s) are deployed: 1. Centralized tools like crowbar/chef/puppet There you can set/generate the key on the central controller / admin node and push to all dashboard nodes and be done (simplified, I know). 2. Packages Generally, you can generate a key upon installation, which would be unique for one machine. Won't work for multiple-machine deployments. 3. Appliance images Similarly, you can generate the key while booting up. You can't use the packaging approach as there is no package installation phase. Again, won't work in the multiple-machine scenario. 4. Deploy from tarballs / git / ... Not a real option, IMHO. So, multiple-machine deployments will only work via centralized mechanisms (this seems to match current practice) whereas single-machine deployments do have some room for further automation. My original idea was to provide an option to simplify 2. and 3. and pretend that the admin does the right thing in case 1. and hopefully 4. (like it is done currently for all cases). BTW, it should also work in case 1. if the PATH in get_from_file(PATH) points to an NFS export, but that's another story ;-) So how about this: Only provide extra convenience / security for the developer (but ask him) and set nothing by default in production, but only document how one could do it in local_settings.py.example. Either way, sorry for the lengthy mail :-) On 06/19/2012 09:45 PM, Gabriel Hurley wrote: That's looking pretty good, Sascha. May I suggest: 1. Instead of using the temporary lockfile, let's actually move slightly back towards your original approach and check for the existence of a known secret key file (added to .gitignore of course) which the get_secret_key function can check for. This is actually how get_secret_key() stil works, the only difference to what you have in mind is that it also generates the key-file if it doesn't exist. The lockfile is used in order to avoid a potential race of multiple Python processes each trying to create the secret key file if it doesn't exist. If the key is already available, this whole thing would not be needed, true. The only thing that is missing are more secure file permissions for the key-file (I would address that). 2. Split the code that generates the secret key into a separate function generate_secret_key which can be used at will. 2. In the run_tests.sh script (meant for developers, really not used in production deployments), have it check for a valid secret key in either the settings file itself or the known secret key file as part of the sanity check for the environment. If a valid secret key is not available, have it ask the user if they'd like to automatically generate a secret key (using
Re: [Openstack] [Blueprint automatic-secure-key-generation] Automatic SECURE_KEY generation
That's looking pretty good, Sascha. May I suggest: 1. Instead of using the temporary lockfile, let's actually move slightly back towards your original approach and check for the existence of a known secret key file (added to .gitignore of course) which the get_secret_key function can check for. 2. Split the code that generates the secret key into a separate function generate_secret_key which can be used at will. 2. In the run_tests.sh script (meant for developers, really not used in production deployments), have it check for a valid secret key in either the settings file itself or the known secret key file as part of the sanity check for the environment. If a valid secret key is not available, have it ask the user if they'd like to automatically generate a secret key (using generate_secret_key). Make sure this also respects the -q/--quiet flag for non-interactive runs like Jenkins. 3. Drop lines 25-29 in the local_settings.py.example in your branch, and uncomment line 31. I liked removing the example SECRET_KEY that exists in the example settings file like in your first patch. Even leaving it in as a comment encourages people to simply uncomment it and use the recycled insecure key. Let's take that back out and just keep your explanatory text, which is spot-on. 4. Modify the get_secret_key function so that if a valid key is not available (e.g. this is production and we didn't use run_tests.sh to install the environment) it dies with a very explanatory error message indicating that a secret key must be set. I know that's a lot to take in, but I think it walks the cleanest line between making it super-easy for developers while making sure everyone is aware of what's going on. If you'll do that and push the review to Gerrit I'll be totally in support of it. Thanks! - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Sascha Peilicke Sent: Tuesday, June 19, 2012 2:04 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] [Blueprint automatic-secure-key-generation] Automatic SECURE_KEY generation On 06/19/2012 04:55 AM, Paul McMillan wrote: Ah, you're thinking of a setup where there are multiple dashboard VMs behind a load-balancer serving requests. Indeed, there the dashboard instances should either share the SECRET_KEY or the load-balancer has to make sure that all requests of a given session are redirected to the same dashboard instance. I'm concerned that anything which automatically generates a secret key will cause further problems down the line for other users. For example, you've clearly experienced what happens when you use more than one worker and generate a per-process key. Imagine trying to debug that same problem on a multi-system cloud (with a load balancer that usually routes people to the same place, but not always). If you aren't forced to learn about this setting during deployment, you are faced with a nearly impossible problem of users just sometimes get logged out. I feel like this patch is merely kicking the can down the road just a little past where your particular project needs it to be, without thinking about the bigger picture. I'm sorry about that, but that was definitely not the intent. Inherently you are right, there are just far to many possible setups to get them all right. Thus it's a valid choice to defer such decisions to the one doing the setup. But trying to ease the process can't be that wrong either. That's the whole point why distributions don't only provide packages that merely include pristine upstream tarballs. We try (and sometimes fail to) provide useful defaults that are at least useful to get started. I'm sure you're not seriously suggesting that a large-scale production deployment of openstack will be served entirely by a single point of failure dashboard server. But shouldn't local_settings.py still take preference over settings.py? Thus the admin could still set a specific SECRET_KEY in local_settings.py regardless of the default (auto-generated) one. So I only would have to fix the patch by not removing the documentation about SECRET_KEY from local_settings.py, right? I agree with Gabriel. Horizon should ship with no secret key (so it won't start until you set one). At most, it should automatically generate a key on a per-process basis, or possibly as part of run_tests, so that getting started with development is easy. Under no circumstances should it attempt to read the mind of an admin doing a production deployment, because it will invariably do the wrong thing more often than the right. As a security issue, it's important that admins READ THE DOCUMENTATION. Preventing the project from starting until they address the issue is one good way. Ok, I've adjusted the patch to reflect
Re: [Openstack] Cinder status update
Nice work.
When you've got the rest of the API bits ironed out (particularly
attach/detach) I'll help work on making sure Horizon is fully functional there.
Note that there's also an F3 Horizon blueprint for splitting volumes into its
own optional panel:
https://blueprints.launchpad.net/horizon/+spec/nova-volume-optional
We should coordinate on these things. ;-)
- Gabriel
-Original Message-
From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net
[mailto:openstack-
bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of John
Griffith
Sent: Tuesday, June 19, 2012 2:10 PM
To: openstack@lists.launchpad.net
Subject: [Openstack] Cinder status update
For those of you that don't know Cinder is the new project intended to
separate block storage out of Nova and provide it via it's own service. The
goal is to have a functional replacement for Nova-Volumes by Folsom 2
(don't worry, you'll be able to select which service to use). So far things
have
gone fairly well, we're at a stage now where we have a beta version that's
ready for use in devstack environments for folks that might be curious or
interested in doing some testing/fixing :)
I haven't done anything fancy like packaging it all up in vagrant, but
depending on the level of interest we can look into that. Currently the
needed patches are in Gerrit as Drafts, so rather than mess with adding a ton
of people who are just a little curious, I've created a github fork that can
be
used just for initial looking around/testing.
In order to get an install up and running all you need to do is clone the
following version of devstack:
https://github.com/j-griffith/devstack.git (you should also be able to just
modify your vagrant attributes file to point to this version of devstack of
course).
The stackrc in the version of devstack on j-griffith is hard coded for the
cinder
service and the special repos in order to make it as easy as possible to check
out the beta.
Run stack.sh and you should be in business...
Please note that this is a hack to get things up and running for folks that
have
expressed interest in testing and seeing where things are at. There are
surely issues/bugs and things that aren't done yet, but this is suitable to
be
called beta.
What to expect:
* Create/List/Delete volumes on the cinder service via:
cinderclient ('cinder'), euca2ools
* Create/List/Delete volume-snapshots on the cinder service via:
cinderclient ('cinder'), euca2ools
* Attach/Detach needs some work but it can be done via euca-attach-
volume
What's in progress:
* Attach/Detach for cinderclient
* Seems to be something not working in horizon any longer, need to
look at this
* Lots of cleanup and unused nova code to strip out of cinder project still
* Tests (unit tests, as well as devstack tests)
Note there are a fixes/changes on a daily basis so it's very much a moving
target. Official repos should all be updated and ready for consumption no
later than the end of this week.
Give it a try, if you find an issue or something missing let me know, or
better
yet fix it up and send me a pull request :)
Thanks,
John
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Dashboard (Ubuntu 12.04/Essex)
It may have to do with the container type set on the images. There is some filtering happening in the Project dashboard that hides the AKI and ARI images that are associated with AMIs. So if you've only got AKI/ARI images those would be hidden. You can see (and manage) those images as an administrator in the Admin dashboard. Without further information that'd be my best guess. You can also try setting the log level to DEBUG in your local_settings.py file to get more information about exactly what is returned from the API. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Lillie Ross-CDSR11 Sent: Monday, June 18, 2012 9:32 AM To: openstack@lists.launchpad.net Subject: [Openstack] Dashboard (Ubuntu 12.04/Essex) All, I've upgraded our cloud, but am stymied on one last configuration issue. From the dashboard, I'm unable to display images and/or snapshots. However, I can display loaded images using the nova and glance command line tools with no problems. For example, 'glance index' displays the following: ID Name Disk Format Container Format Size -- -- f4c861aa-ded5-4cb8-9338-c0551a11a5d5 tty-linux ami ami25165824 bfc26a24-8cd5-4259-a57a-7071d909de8c tty-linux-ramdisk ari ari 5882349 df43feb9-aa30-4a2a-a03e-0357df5d4249 tty-linux-kernel aki aki 4404752 and the corresponding command through the nova-api service, 'nova image-list' displays: +--+---+++ | ID |Name | Status | Server | +--+---+++ | bfc26a24-8cd5-4259-a57a-7071d909de8c | tty-linux-ramdisk | ACTIVE || | df43feb9-aa30-4a2a-a03e-0357df5d4249 | tty-linux-kernel | ACTIVE || | f4c861aa-ded5-4cb8-9338-c0551a11a5d5 | tty-linux | ACTIVE || +--+---+++ However, when accessing the Images Snapshots panel in Horizon, I receive 2 error messages that it's unable to retrieve images and snapshots. Looking at the nova-api.log file, I see the following: 2012-06-18 11:13:30 INFO nova.api.openstack.wsgi [req-65ef5523-b1ff-47a1-8bd6-4a896df47958 1 1] GET http://173.23.181.1:8776/v1/1/snapshots/detail 2012-06-18 11:13:30 DEBUG nova.api.openstack.wsgi [req-65ef5523-b1ff-47a1-8bd6-4a896df47958 1 1] Unrecognized Content-Type provided in request from (pid=9586) get_body /u sr/lib/python2.7/dist-packages/nova/api/openstack/wsgi.py:697 2012-06-18 11:13:30 INFO nova.api.openstack.wsgi [req-65ef5523-b1ff-47a1-8bd6-4a896df47958 1 1] http://173.23.181.1:8776/v1/1/snapshots/detail returned with HTTP 200 which indicates that the request complete OK. From the Apache access logs I see 127.0.0.1:80 173.17.11.184 - - [18/Jun/2012:11:13:24 -0500] GET /nova/images_and_snapshots/ HTTP/1.1 200 49213 http://cloud.dtl.mot-solutions.com/nova/images_and_snaps hots/ Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2 which also seems to indicate that all is well with 49K data returned, however nothing displays in the dashboard. Any suggestions? Thanks to all in advance! Regards, Ross ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone API V3 - draft 2 now available
Hi Joe, I added lots of comments on the google doc. I think most of them reinforce the existing design decisions. That said, there are a few high-level issues I'd like to ask for discussion on: 1. This API features no differentiation between the admin API and the regular API as it exists currently; I assume this is due to the new policy engine. Am I correct, and does that mean that Keystone will no longer be using the admin port (35357)? 2. User roles on domains solves the issue of who has the power to manage tenants, but that then begs the question who has the power to manage domains? The same question applies to services and policies. Anything that is not scoped to the domain still falls into a grey area, and the previous answer of anyone who's got that permission anywhere has that permission everywhere strikes me as massively broken. 3. On an API level, I'd like to see this API be the first to support a parameter on all GET requests that causes that request to not only return the serialization of that single object, but all the related objects as well. For example, the GET /tenant/tenant_id call by default would have a domain_id attribute, but with this flag it would have a domain attribute containing the entire serialized domain object. As for the name of this flag, I don't feel strongly. Django calls this concept select_related, sqlalchemy calls it eagerload. We could pick whatever we like here, but I'll be asking for this in Nova, et. al.'s APIs going forward too. 4. In the you probably don't even want to touch it category: have you given any thought to password reset functionality? Obviously it's backend dependent, but having some general concept of forgot password/forgot username would be important to end users in many cases. There are three cases I can see depending on backend: directly provide a password reset mechanism where possible; provide instructions for password reset (configured by system admin) where there is an external process in place; return Not Implemented when neither previous case is satisfied. I'm not saying this *must* appear in this API spec, but it's worth mentioning. Thanks for all the work on this. It's really looking great! - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Joseph Heck Sent: Sunday, June 17, 2012 3:09 PM To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: [Openstack] Keystone API V3 - draft 2 now available Draft 2 of the V3 Core Keystone API is now available for comment: https://docs.google.com/document/d/1_TkawQIa52eSBfS4pv_nx1SJeoBghIlGVZsRJJynKAM/edit In this revision, I've * updated the token structure a bit - to match the new resources * changed how the associations or user-tenant through a role are enabled (POST instead of PUT) * put in detailed examples of responses to every call The general format of this documentation roughly follows the developer documentation at developer.github.comhttp://developer.github.com, which I thought had a pretty good model of showing how to use the APIs and describing the relevant pieces. There's a lot of cut and paste in there, so if something seems obviously wrong, it probably is ... please make a comment on the google doc and let me know. This document is far more structured and complete, and contains sufficient detail for those excited about WADLs and XSDs and such to create relevant mappings. Feedback needed please, comment away! -joe ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Openstack-poc] Thoughts on client library releasing
Big +1 for automated tagging and releasing (sounds like we're managing wildlife...) from Jenkins! - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Monty Taylor Sent: Monday, June 18, 2012 3:00 PM To: Joe Heck Cc: openstack-...@lists.launchpad.net; openstack@lists.launchpad.net Subject: Re: [Openstack] [Openstack-poc] Thoughts on client library releasing On 06/18/2012 02:26 PM, Joe Heck wrote: Monty - Thierry stated it as an assumption last PPB meeting, but I'd like it to be explicit that we have at least a tag on each client library release that we make so that it's possible to distribute a version of the clients. +1000 I didn't want to get too far into implementation details, but the way I'd really like to see this work for the client libs is that releases are actually trigger via jenkins by tags on the repo - so there would literally be no way to release something _without_ a tag. I've got a POC patch to do the tag-based-versioning here: https://review.openstack.org/#/c/8427/ We need to get (aiui) one thing landed to zuul so that we can appropriately trigger on tag events... but that's the plan in my brain hole. On Jun 18, 2012, at 2:11 PM, Monty Taylor wrote: We're trying to figure out how we release client libraries. We're really close - but there are some sticking points. First of all, things that don't really have dissent (with reasoning) - We should release client libs to PyPI Client libs are for use in other python things, so they should be able to be listed as dependencies. Additionally, proper releases to PyPI will make our cross project depends work more sensibly - They should not necessarily be tied to server releases There could be a whole version of the server which sees no needed changes in the client. Alternately, there could be new upcoming server features which need to go into a released version of the library even before the server is released. - They should not be versioned with the server See above. - Releases of client libs should support all published versions of server APIs An end user wants to talk to his openstack cloud - not necessarily to his Essex cloud or his Folsom cloud. That user may also have accounts on multiple providers, and would like to be able to write one program to interact with all of them - if the user needed the folsom version of the client lib to talk to the folsom cloud and the essex version to talk to the essex cloud, his life is very hard. However, if he can grab the latest client lib and it will talk to both folsom and essex, then he will be happy. There are three major points where there is a lack of clear agreement. Here they are, along with suggestions for what we do about them. - need for official stable branches I would like to defer on this until such a time as we actually need it, rather than doing the engineering for in case we need it. But first, I'd like to define we, and that is that we are OpenStack as an upstream. As a project, we are at the moment probably the single friendliest project for the distros in the history of software. But that's not really our job. Most people out there writing libraries do not have multiple parallel releases of those libraries - they have the stable library, and then they release a new one, and people either upgrade their apps to use the new lib or they don't. One of the reasons this has been brought up as a need is to allow for drastic re-writes of a library. I'll talk about that in a second, but I think that is a thing that needs to have allowances for happening. So the model that keystone-lite used - create an experimental branch for the new work, eventually propose that it becomes the new master - seems like a better fit for the drastic rewrite scenario than copying the stable/* model from the server projects, because I think the most common thing will be that library changes are evolutionary, and having two mildly different branches that both represent something that's actually pretty much stable will just be more confusing than helpful. That being said - at such a time that there is actually a pain-point or a specific need for a stable branch, creating branches is fairly easy ... but I think once we have an actual burning need for such a thing, it will make it easier for us to look at models of how we'll use it. - API or major-rewrite-driven versioning scheme I was wondering why bcwaldon and I were missing each other so strongly in the channel the other day when we were discussing this, and then I realized that it's because we have one word API that's getting overloaded for a couple of different meanings - and also that I was being vague in my usage of
Re: [Openstack] [Blueprint automatic-secure-key-generation] Automatic SECURE_KEY generation
To the points Sascha raised, and in particular in response to the code method suggested here (https://github.com/saschpe/horizon/commit/1414d538d65d2d3deb981db0ab9e888a3c96a149) I think we are largely in agreement except for one point: I have no problem with this approach for development, or even for distro packaging, but I strongly dislike this automatic generation for a production deployment. Particularly there are issues about distributed deployments where the installs need to share a common secret key to allow for shared data signing validation, etc. I would rather not obfuscate these very real and very relevant concerns for productions deployments for the sake of making everything else a little easier. Especially because it will lead to very hard-to-diagnose bugs because people aren't aware of the magic happening behind the scenes. As such, I'd rather have the code you wrote be part of the environment build/run_tests code such that there's an *optional* tool to do this, but it doesn't hide legitimate security and functionality concerns. I'm also cc'ing Paul McMillan, Django's resident security expert, to get his take on this. - Gabriel -Original Message- From: Sascha Peilicke [mailto:sasc...@suse.de] Sent: Friday, June 15, 2012 12:38 AM To: Gabriel Hurley Cc: openstack@lists.launchpad.net Subject: Re: [Blueprint automatic-secure-key-generation] Automatic SECURE_KEY generation Hi Grabriel, let's discuss the blueprint [1] on the list. On 06/14/2012 10:36 PM, Gabriel Hurley wrote: Blueprint changed by Gabriel Hurley: Whiteboard set to: After discussing this with both the Horizon core team and Django's security czar/core committer Paul McMillan, we've decided the best way to proceed with this is as follows: * Remove the default SECRET_KEY so it cannot be shared causing security problems. * For development, add a few lines to auto-generate a SECRET_KEY if one isn't present. Ok, nothing to add, this is what the patch actually does [2]. * For production, document that a SECRET_KEY is required, how to generate one, etc. The question to me is, why this should matter to the admin at all. Security-wise, the only thing that matters is that the SECRET_KEY is unique per dashboard installation and set before the first start. Whether this is done by the admin or by the patch to discuss doesn't really matter. However, even if documented appropriately, setting up a complete OpenStack deployment isn't exactly a piece of cake. Having to remember yet another config value is error-prone IMO and easily forgotten. Actually, Django already does a really good job in documenting this, but we stumbled upon this because all of our internal development clouds had the same (default) SECRET_KEY. Seems like we just forgot ;-) * Work with the distros to make sure they properly generate a unique SECRET_KEY for each install. This is why I started the whole topic, as there are cases where this is just impractical. But let's take it slowly, current OpenStack rpm packages for openSUSE / SLES generate a SECRET_KEY as a %post scriptlet (i.e. just after package installation). This doesn't hurt and is probably what you had in mind. However, this only works if there is actually a package to install. Unfortunately, this isn't the case when the dashboard is deployed from an appliance image. Of course, you could check and set the SECRET_KEY after successfully booting up the appliance image via a script (if it is not a snapshot of an already booted system) or you could just do it when the Django app is actually started. The latter seems more practical to me. And lastly, when it's part of the horizon code-base, the issue could be solved for all deployments. Footnotes: [1] https://blueprints.launchpad.net/horizon/+spec/automatic-secure-key- generation [2] https://github.com/saschpe/horizon/commit/1414d538d65d2d3deb981db0a b9e888a3c96a149 -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] how to achieve i18n in horizon
It generally sounds like you've done the right things... the only thing I can think of offhand might be that if you're running Django through a webserver like Apache, nginx, or gunicorn you'll need to restart your webserver to see the changes take effect. Some information on what version of Horizon you're running, how you installed it, etc. might be helpful as well... - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of yuanke wei Sent: Wednesday, June 13, 2012 3:47 AM To: openstack mail list Subject: [Openstack] how to achieve i18n in horizon hi, the problem is as follows: I changed some translation in horizon/horizon/locale/zh_CN/LC_MESSAGES/django.po, and then compiled with django-admin compilemessages -l zh_CN. the django.mo file was successfully generated. but as I refresh the horizon web page, it seems nothing have changed with the text. can anyone show me what is the problem and how to achieve i18n in horizon. thanks! ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] v3 API draft (update and questions to the community)
I'd love to review it when you're ready for review, or collaborate on it prior to a public offering. My laundry-list of features that an ideal API would contain is ever-growing, though I do try to temper it with reality. We should compare notes sometime. All the best, - Gabriel -Original Message- From: Mark Nottingham [mailto:m...@mnot.net] Sent: Tuesday, June 12, 2012 8:43 PM To: Gabriel Hurley Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the community) On 13/06/2012, at 1:24 PM, Gabriel Hurley wrote: Totally agree with all of Jay's points, and I also couldn't agree more with Mark on the importance of being crystal clear, and not operating on just a common understanding which is quickly misunderstood or forgotten. Ideally I'd like to see an OpenStack API feature contract of some sort... essentially a document describing the FULL list of features, how those parameters are controlled and how they would interact, and what a project should do if they do not implement an API feature (hopefully only for technical reasons such as Keystone paging with LDAP or swift with complex DB-esque operations). This isn't saying we should have a unified API spec, I'm talking solely about a contract for the features all APIs should strive to support. This would be a big project, but everyone would then have a common agreement about what the user experience of interacting with OpenStack should be. The project APIs as they stand are siloed and stunningly inconsistent, and I'd love to work toward fixing that. Absolutely. One of my other projects is to rewrite the API as a proper specification (in a style similar to an Internet-Draft, not that we'd necessarily publish it as one). I should have something to show soon; if you're interested in helping out, that'd be great. Cheers, My two cents, - Gabriel -Original Message- From: openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Mark Nottingham Sent: Tuesday, June 12, 2012 7:20 PM To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the community) On 13/06/2012, at 3:31 AM, Jay Pipes wrote: This isn't necessarily true. Nova's compute layer goes through a number of steps to ensure a semi-transactional nature to certain operations like resizing. Certain times a query needs to indicate that it intends to make a reservation of resources (see quota/reservation system now .. this is the SELECT FOR UPDATE paradigm) and other times, the query doesn't care about such things. In the latter case, there aren't expectations that the list returned is 100% accurate according to the state of the database at a particular timestamp of when the transaction occurred. In this case, filters and optimistic pagination works perfectly fine, IMHO. That might work, but we need to be crystal-clear about the semantics of what we're giving back; having it understood between OpenStack projects isn't good enough. I.e., we're not building the APIs just for Horizon; they're for lots of folks, and subtle semantics -- even when well-documented, much less when they're not -- are often misunderstood. Cheers, -- Mark Nottingham http://www.mnot.net/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Mark Nottingham http://www.mnot.net/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Swift] swift.common.client and swift CLI has moved to its own project python-swiftclient
Big +1 to getting our client release process nailed down! That'll be huge in terms of managing those dependencies. :-) - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Monty Taylor Sent: Wednesday, June 13, 2012 8:28 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] [Swift] swift.common.client and swift CLI has moved to its own project python-swiftclient On 06/13/2012 10:58 AM, Juan J. Martinez wrote: On 13/06/12 15:42, Dan Prince wrote: Okay. It looks like Swift also still depends on swiftclient. Long term it would be nice if we could build and unit test swift without relying on the swiftclient package. Could we: I can't see the reason for that, swiftlclient is a dependency of swift (as webob, greenlet, pastedeploy, etc). I agree. At the moment it's slightly more ugly because we haven't finalized the pypi release process for our client libs... but we should have that in the next week or so, and then it should be perfectly possible to treat it just like anything else. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [keystone] v3 API draft (update and questions to the community)
Mark, Apparently you must have missed my lightning talk at the Essex summit... ;-) (http://gabrielhurley.github.com/slides/openstack/apis_like_orms/index.html) Filtering, pagination, and many other API features are *critical* for a rich dashboard experience. If you want to talk specifics, the entire Horizon team would be happy to have a long chat with you. That said, we have also considered the case you propose where you effectively request everything and handle it on the client-side... however, I see that as a tremendously lazy solution. On the service-provider end you have access to powerful database methods that can do these operations in fractions of the time the client-side can (especially with good indexes, etc.). And if you've ever worked in mobile applications you'll know that minimizing data across the wire is crucial. The only argument I've heard in favor of that is basically it's easier for us not to add API features. To speak on the specific feature of pagination, the problem of 'corruption' by simultaneous writers is no excuse for not implementing it. You think Google, Facebook, Flickr, etc. etc. etc. don't have this problem? If you consume their feeds you'll notice you can fetch offset-based pagination with ease. You'd never expect to see a navigation element at the bottom of Google search results that said take me to results starting with the letter m. None of this is a case of someone might use it. The Horizon team has been loudly asking for these features for 8+ months now. And not just from Keystone but from all the projects. I have a list a mile long of API features we need to really deliver a compelling experience. I was just adding some items to it today, in fact. The rest of your points I have no strong feelings on and generally agree, but when it comes to API features... I feel *very* strongly. All the best, - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Mark Nottingham Sent: Monday, June 11, 2012 10:27 PM To: Joseph Heck Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net) Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the community) On 11/06/2012, at 6:58 AM, Joseph Heck wrote: First - what's the current thought of support for PATCH vs PUT in updating REST resources? Are there any issues with clients being able to use a PATCH verb? It's not something I'm super familiar with, so I'm looking for feedback from the community here. Ideally, I'd like to support the semantics of the PATCH HTTP verb, and possibly just assert no support for the PUT verb to be clear about intended functionality. Is that going to throw anyone for a loop? I answered a question about PATCH before; don't want to repeat myself, but it should be workable. Happy to chat more about it if you have specific questions. Second - filtering/searching for resources. The draft includes a section labelled Query By Name, which is probably mis-labelled, as it's intended to cover the general idea of passing in query parameters to general listing resource endpoints to filter the result set. The API endpoints across all the resources are defined as plurals, with the idea that specificity comes later in the URI (for referencing a single resource), or that we could add on these query parameters to restrict/filter by resource type. I'm in the middle of doing some log analysis and other research about how the APIs are used at Rackspace. It's too early to share results (although I do intend to, in some form, because the idea is to inform future API design), but one of the things that's very noticeable is how (extremely!) little pagination and filtering seem to be used in anger. In fact, if you take a look at the libraries, you'll find that they often don't use or even support filtering or pagination; e.g., libcloud doesn't, AFAICT. So, it's worth having a think about what the use cases actually are; both filtering and pagination are usually ways to save one or more of: a) client-side work b) server-side work c) bandwidth / latency One interesting exercise would be to estimate the largest number of users (or whatever else you'd be listing) that a reasonable deployment would put in a single response, triple it, do a dummy serialisation in JSON, and then gzip it, so that you can estimate the size, see how long it takes to parse on the client, etc. From what I've seen (in OpenStack as well as in other APIs that have nothing to do with Cloud), API designers tend to overestimate the utility of pagination and especially filtering (somebody might use it), but users just ignore them, doing all of the work on the client side, except in extreme circumstances (e.g., VERY large responses / very high latency). Unless you have strong use cases for
Re: [Openstack] [keystone] v3 API draft (update and questions to the community)
Totally agree with all of Jay's points, and I also couldn't agree more with Mark on the importance of being crystal clear, and not operating on just a common understanding which is quickly misunderstood or forgotten. Ideally I'd like to see an OpenStack API feature contract of some sort... essentially a document describing the FULL list of features, how those parameters are controlled and how they would interact, and what a project should do if they do not implement an API feature (hopefully only for technical reasons such as Keystone paging with LDAP or swift with complex DB-esque operations). This isn't saying we should have a unified API spec, I'm talking solely about a contract for the features all APIs should strive to support. This would be a big project, but everyone would then have a common agreement about what the user experience of interacting with OpenStack should be. The project APIs as they stand are siloed and stunningly inconsistent, and I'd love to work toward fixing that. My two cents, - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Mark Nottingham Sent: Tuesday, June 12, 2012 7:20 PM To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [keystone] v3 API draft (update and questions to the community) On 13/06/2012, at 3:31 AM, Jay Pipes wrote: This isn't necessarily true. Nova's compute layer goes through a number of steps to ensure a semi-transactional nature to certain operations like resizing. Certain times a query needs to indicate that it intends to make a reservation of resources (see quota/reservation system now .. this is the SELECT FOR UPDATE paradigm) and other times, the query doesn't care about such things. In the latter case, there aren't expectations that the list returned is 100% accurate according to the state of the database at a particular timestamp of when the transaction occurred. In this case, filters and optimistic pagination works perfectly fine, IMHO. That might work, but we need to be crystal-clear about the semantics of what we're giving back; having it understood between OpenStack projects isn't good enough. I.e., we're not building the APIs just for Horizon; they're for lots of folks, and subtle semantics -- even when well-documented, much less when they're not -- are often misunderstood. Cheers, -- Mark Nottingham http://www.mnot.net/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Glance/Swift integration broken (kills devstack)
I just thought I'd call out that Glance's swift storage module is currently broken, and apparently this escaped the devstack gate even though devstack actually fails to complete if swift is enabled. Are we not testing with swift in the ENABLED_SERVICES list? Bug report here: https://bugs.launchpad.net/devstack/+bug/1011885 All the best, - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Quantum integration with Horizon
The blueprint for adding Quantum support (via a Networks panel) back into the dashboard is still a high priority for both the Horizon and Quantum teams. There was a patch started by one of the Quantum team members, but after a code review that identified many fixes it ended up expiring and doesn't seem to have been touched since. As a secondary concern, the Quantum/Melange merge significantly complicates the featureset that needs to be supported, so there are a number of factors in play around service capability detection, API design, etc. that still have to be settled before support can be restored. All contributions on this front are welcome. - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Gary Kotton Sent: Thursday, June 07, 2012 4:28 AM To: Neelakantam Gaddam Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Quantum integration with Horizon On 06/07/2012 11:39 AM, Neelakantam Gaddam wrote: Hi All, Currently, I don't see any Quantum UI in Horizon in Essex. Does the Horizon support Quantum UI in the current release? If so, please share the configuration steps. If not, When can I expect the Quantum UI integration with Horizon ? This is not supported for Essex. There is a blueprint for Folsom-2 for horizon support (https://blueprints.launchpad.net/quantum/+spec/quantum-horizon). Can you please give me the list of features for the next release of Essex and the timelines.? Please look at https://launchpad.net/quantum/folsom for the release dates of Folsom (this is the version after Essex). We are currently porting back bug fixes from Folsom-1 to the stable Essex version. This may take some time. Thanks Gary -- Thanks Regards Neelakantam Gaddam ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] How to let nova use localtime rather than UTC time?
Stored timestamps should always be in UTC, however efforts should be made to support local timezones as a user-configurable option. Horizon will be working towards this goal since Django has good timezone support, I'd encourage other projects to keep this on their radar as well. - Gabriel -Original Message- From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack- bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Johannes Erdfelt Sent: Wednesday, June 06, 2012 8:35 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] How to let nova use localtime rather than UTC time? On Wed, Jun 06, 2012, livemoon mwjpi...@gmail.com wrote: I found nova use utcnow to get time and write it to db. So the create_time of vm also show utc time rather than localtime. You really don't want to do this. For instance, the database won't store the timezone, so in places where there is daylight savings time, timestamps can be ambiguous. As a best practice, the database should store in UTC and then tools should convert to a local timezone for convenience. JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Change user password (not admin)
I've had this fight with Joe Heck and Termie before. They rejected my attempts to modify the Keystone code to allow a user to change their own password. I believe their grounds were a combination of it being an admin activity, and that adding it to the user API would change the API contract and couldn't be done in until v.next of the API. Feel free to have at it with them again. ;-) - Gabriel From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net [mailto:openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of Guillermo Alvarado Sent: Wednesday, June 06, 2012 9:24 AM To: openstack@lists.launchpad.net Subject: [Openstack] Change user password (not admin) Hi everyone! I am trying to develop a new feature to horizon, I want to users can update their own password. I used this: from horizon import api api.user_update_password( request, request.user.idhttp://request.user.id, form.cleaned_data['new_password'], admin=True ) But the user is logged out because in keystone.py there is this: if not user.is_admin(): raise exceptions.NotAuthorized So, Only the user admin can use that method. How can I be able to use this method with a normal user, or do you recommend to query the database directly to modify the password in the user table. Thanks in advance! ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
