Re: [openstack-dev] [nova] nova default quotas
Hi Sergio, On 28 May 2014 23:28, Cazzolato, Sergio J sergio.j.cazzol...@intel.com wrote: Hi Kieran, What do you think about the approach proposed in https://review.openstack.org/#/c/94519/ ? What we are trying to do is to simplify the way to manage default quotas through an API and keeping backward compatibility. So doing this is not needed to restart any service once a default quota is changed, something that could be painful when there are many services running in parallel. If the current spec is implemented as-is, when we upgrade to Juno our default quotas will be wrong. Like Joe mentioned, the table wasn't dropped in Icehouse (and the underlying default quotas still work), so my only concern at this point is that users don't have to do *anything* in order to ensure that default quotas are maintained during an Icehouse - Juno upgrade. Whether this should happen as part of your spec, or another spec designed to address just this issue, I don't know. Cheers, Kieran From: Kieran Spear [mailto:kisp...@gmail.com] Sent: Wednesday, May 28, 2014 2:05 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] nova default quotas Hi Joe, On 28/05/2014, at 11:21 AM, Joe Gordon joe.gord...@gmail.com wrote: On Tue, May 27, 2014 at 1:30 PM, Kieran Spear kisp...@gmail.com wrote: On 28/05/2014, at 6:11 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: Phil, You are correct and this seems to be an error. I don't think in the earlier ML thread[1] that anyone remembered that the quota classes were being used for default quotas. IMO we need to revert this removal as we (accidentally) removed a Havana feature with no notification to the community. I've reactivated a bug[2] and marked it critical. +1. We rely on this to set the default quotas in our cloud. Hi Kieran, Can you elaborate on this point. Do you actually use the full quota-class functionality that allows for quota classes, if so what provides the quota classes? If you only use this for setting the default quotas, why do you prefer the API and not setting the config file? We just need the defaults. My comment was more to indicate that yes, this is being used by people. I'm sure we could switch to using the config file, and generally I prefer to keep configuration in code, but finding out about this half way through a release cycle isn't ideal. I notice that only the API has been removed in Icehouse, so I'm assuming the impact is limited to *changing* the defaults, which we don't do often. I was initially worried that after upgrading to Icehouse we'd be left with either no quotas or whatever the config file defaults are, but it looks like this isn't the case. Unfortunately the API removal in Nova was followed by similar changes in novaclient and Horizon, so fixing Icehouse at this point is probably going to be difficult. Cheers, Kieran Kieran Vish [1] http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html [2] https://bugs.launchpad.net/nova/+bug/1299517 On May 27, 2014, at 12:19 PM, Day, Phil philip@hp.com wrote: Hi Vish, I think quota classes have been removed from Nova now. Phil Sent from Samsung Mobile Original message From: Vishvananda Ishaya Date:27/05/2014 19:24 (GMT+00:00) To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] nova default quotas Are you aware that there is already a way to do this through the cli using quota-class-update? http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html (near the bottom) Are you suggesting that we also add the ability to use just regular quota-update? I'm not sure i see the need for both. Vish On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J sergio.j.cazzol...@intel.com wrote: I would to hear your thoughts about an idea to add a way to manage the default quota values through the API. The idea is to use the current quota api, but sending ''default' instead of the tenant_id. This change would apply to quota-show and quota-update methods. This approach will help to simplify the implementation of another blueprint named per-flavor-quotas Feedback? Suggestions? Sergio Juan Cazzolato Intel Software Argentina ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list
Re: [openstack-dev] [nova] nova default quotas
On 28/05/2014, at 6:11 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: Phil, You are correct and this seems to be an error. I don’t think in the earlier ML thread[1] that anyone remembered that the quota classes were being used for default quotas. IMO we need to revert this removal as we (accidentally) removed a Havana feature with no notification to the community. I’ve reactivated a bug[2] and marked it critical. +1. We rely on this to set the default quotas in our cloud. Kieran Vish [1] http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html [2] https://bugs.launchpad.net/nova/+bug/1299517 On May 27, 2014, at 12:19 PM, Day, Phil philip@hp.com wrote: Hi Vish, I think quota classes have been removed from Nova now. Phil Sent from Samsung Mobile Original message From: Vishvananda Ishaya Date:27/05/2014 19:24 (GMT+00:00) To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] nova default quotas Are you aware that there is already a way to do this through the cli using quota-class-update? http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html (near the bottom) Are you suggesting that we also add the ability to use just regular quota-update? I’m not sure i see the need for both. Vish On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J sergio.j.cazzol...@intel.com wrote: I would to hear your thoughts about an idea to add a way to manage the default quota values through the API. The idea is to use the current quota api, but sending ''default' instead of the tenant_id. This change would apply to quota-show and quota-update methods. This approach will help to simplify the implementation of another blueprint named per-flavor-quotas Feedback? Suggestions? Sergio Juan Cazzolato Intel Software Argentina ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] nova default quotas
Hi Joe, On 28/05/2014, at 11:21 AM, Joe Gordon joe.gord...@gmail.com wrote: On Tue, May 27, 2014 at 1:30 PM, Kieran Spear kisp...@gmail.com wrote: On 28/05/2014, at 6:11 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: Phil, You are correct and this seems to be an error. I don’t think in the earlier ML thread[1] that anyone remembered that the quota classes were being used for default quotas. IMO we need to revert this removal as we (accidentally) removed a Havana feature with no notification to the community. I’ve reactivated a bug[2] and marked it critical. +1. We rely on this to set the default quotas in our cloud. Hi Kieran, Can you elaborate on this point. Do you actually use the full quota-class functionality that allows for quota classes, if so what provides the quota classes? If you only use this for setting the default quotas, why do you prefer the API and not setting the config file? We just need the defaults. My comment was more to indicate that yes, this is being used by people. I'm sure we could switch to using the config file, and generally I prefer to keep configuration in code, but finding out about this half way through a release cycle isn't ideal. I notice that only the API has been removed in Icehouse, so I'm assuming the impact is limited to *changing* the defaults, which we don't do often. I was initially worried that after upgrading to Icehouse we'd be left with either no quotas or whatever the config file defaults are, but it looks like this isn't the case. Unfortunately the API removal in Nova was followed by similar changes in novaclient and Horizon, so fixing Icehouse at this point is probably going to be difficult. Cheers, Kieran Kieran Vish [1] http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html [2] https://bugs.launchpad.net/nova/+bug/1299517 On May 27, 2014, at 12:19 PM, Day, Phil philip@hp.com wrote: Hi Vish, I think quota classes have been removed from Nova now. Phil Sent from Samsung Mobile Original message From: Vishvananda Ishaya Date:27/05/2014 19:24 (GMT+00:00) To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] nova default quotas Are you aware that there is already a way to do this through the cli using quota-class-update? http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html (near the bottom) Are you suggesting that we also add the ability to use just regular quota-update? I’m not sure i see the need for both. Vish On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J sergio.j.cazzol...@intel.com wrote: I would to hear your thoughts about an idea to add a way to manage the default quota values through the API. The idea is to use the current quota api, but sending ''default' instead of the tenant_id. This change would apply to quota-show and quota-update methods. This approach will help to simplify the implementation of another blueprint named per-flavor-quotas Feedback? Suggestions? Sergio Juan Cazzolato Intel Software Argentina ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Selenium test fixes
No failures in the last 24 hours. \o/ On 26 May 2014 23:44, Kieran Spear kisp...@gmail.com wrote: Hi peeps, Could I ask reviewers to prioritise the following: https://review.openstack.org/#/c/95392/ It should eliminate our selenium gate failures, which seem to be happening many times per day now. Cheers, Kieran ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Selenium test fixes
Hi peeps, Could I ask reviewers to prioritise the following: https://review.openstack.org/#/c/95392/ It should eliminate our selenium gate failures, which seem to be happening many times per day now. Cheers, Kieran ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] No templated service catalog for V3?
Great, thanks for working on it. I'll test it out asap. Cheers, Kieran On 23 May 2014 23:18, Brant Knudson b...@acm.org wrote: On Thu, May 22, 2014 at 7:32 PM, Kieran Spear kisp...@gmail.com wrote: Hi, I notice that the templated catalog doesn't support the V3 API*. This is a blocker for us, particularly for Heat since it uses V3 internally. We could switch to the SQL backend, but I'm sure others are affected by this too. Is it hard to fix? Cheers, Kieran * https://bugs.launchpad.net/keystone/+bug/1313458 I posted an initial change for it in https://review.openstack.org/#/c/70630/ but then got distracted. I'll take another look at it today. - Brant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone] No templated service catalog for V3?
Hi, I notice that the templated catalog doesn't support the V3 API*. This is a blocker for us, particularly for Heat since it uses V3 internally. We could switch to the SQL backend, but I'm sure others are affected by this too. Is it hard to fix? Cheers, Kieran * https://bugs.launchpad.net/keystone/+bug/1313458 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Nominating Radomir Dopieralski to Horizon Core
Belated +1. Thanks Radomir. It's great to see all the new contributors in this cycle. On 6 March 2014 09:36, Lyle, David david.l...@hp.com wrote: I'd like to nominate Radomir Dopieralski to Horizon Core. I find his reviews very insightful and more importantly have come to rely on their quality. He has contributed to several areas in Horizon and he understands the code base well. Radomir is also very active in tuskar-ui both contributing and reviewing. David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] User Signup
On 15 February 2014 16:52, Soren Hansen so...@linux2go.dk wrote: Den 15/02/2014 00.19 skrev Adam Young ayo...@redhat.com: Could you please spend 5 minutes on the blueprint https://blueprints.launchpad.net/horizon/+spec/user-registration and add your suggestions in the white board. Does it make sense for this to be in Keystone first, and then Horizon just consumes it? I would think that user-registration-request would be a reasonable Keystone extension. Then, you would add a role user-approver for a specific domain to approve a user, which would trigger the create event. This makes perfect sense to me. +1. It certainly is Keystone's domain, so an API extension sounds like the right way to go. Kieran /Soren ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] User Signup
Hi Soren, On 10 February 2014 08:27, Soren Hansen so...@linux2go.dk wrote: I've just taken a look at the feedback in the whiteboard. If it's ok, I'd like to take this discussion back to the mailing list. I find the whiteboards somewhat clumsy for discussions. Akihiro Motoki points out that all services should work without the dashboard. Keystone already exposes an API to create new users, so that requirement is already fulfilled, whether there's an intermediate service or not, so I don't really understand this objection. Kieran Spear argues in favour of a separate registration service that Horizon talks to over some sort of RPC interface. He argues that putting Keystone admin credentials on public facing webserver is a security risk. I agree that putting admin credentials on a public web server is a security risk, but I'm not sure why a set of restricted admin credentials that only allow you to create users and tenants is a bigger problem than the credentials for separate registration service that performs the exact same operations? The third (and most dangerous) operation here is the role grant. I don't think any Keystone policy could be specific enough to prevent arbitrary member role assignment in this case. How do you express the following as a set of policies in Keystone? Allow a user to create a new user and a new project and grant the member role for only that user on only that project. There may be other ways around this particular case, but in these situations I accept that mistakes are inevitable, and another layer of isolation helps to reduce the impact when things go wrong. Cheers, Kieran Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ 2014-02-01 18:24 GMT+01:00 Saju M sajup...@gmail.com: Hi folks, Could you please spend 5 minutes on the blueprint https://blueprints.launchpad.net/horizon/+spec/user-registration and add your suggestions in the white board. Thanks, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon and Tuskar-UI codebase merge
Another +1 for separate repos. Horizon's core focus should remain on the integrated projects, but we also need to prepare better for when incubated projects graduate, so their inclusion is less disruptive. I also like Gabriel's suggestion of a non-gating CI job to catch any integration issues between TuskarUI and Horizon. Kieran On 20 December 2013 03:29, Lyle, David david.l...@hp.com wrote: So after a lot of consideration, my opinion is the two code bases should stay in separate repos under the Horizon Program, for a few reasons: -Adding a large chunk of code for an incubated project is likely going to cause the Horizon delivery some grief due to dependencies and packaging issues at the distro level. -The code in Tuskar-UI is currently in a large state of flux/rework. The Tuskar-UI code needs to be able to move quickly and at times drastically, this could be detrimental to the stability of Horizon. And conversely, the stability needs of Horizon and be detrimental to the speed at which Tuskar-UI can change. -Horizon Core can review changes in the Tuskar-UI code base and provide feedback without the code needing to be integrated in Horizon proper. Obviously, with an eye to the code bases merging in the long run. As far as core group organization, I think the current Tuskar-UI core should maintain their +2 for only Tuskar-UI. Individuals who make significant review contributions to Horizon will certainly be considered for Horizon core in time. I agree with Gabriel's suggestion of adding Horizon Core to tuskar-UI core. The idea being that Horizon core is looking for compatibility with Horizon initially and working toward a deeper understanding of the Tuskar-UI code base. This will help insure the integration process goes as smoothly as possible when Tuskar/TripleO comes out of incubation. I look forward to being able to merge the two code bases, but I don't think the time is right yet and Horizon should stick to only integrating code into OpenStack Dashboard that is out of incubation. We've made exceptions in the past, and they tend to have unfortunate consequences. -David -Original Message- From: Jiri Tomasek [mailto:jtoma...@redhat.com] Sent: Thursday, December 19, 2013 4:40 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Horizon and Tuskar-UI codebase merge On 12/19/2013 08:58 AM, Matthias Runge wrote: On 12/18/2013 10:33 PM, Gabriel Hurley wrote: Adding developers to Horizon Core just for the purpose of reviewing an incubated umbrella project is not the right way to do things at all. If my proposal of two separate groups having the +2 power in Gerrit isn't technically feasible then a new group should be created for management of umbrella projects. Yes, I totally agree. Having two separate projects with separate cores should be possible under the umbrella of a program. Tuskar differs somewhat from other projects to be included in horizon, because other projects contributed a view on their specific feature. Tuskar provides an additional dashboard and is talking with several apis below. It's a something like a separate dashboard to be merged here. When having both under the horizon program umbrella, my concern is, that both projects wouldn't be coupled so tight, as I would like it. Esp. I'd love to see an automatic merge of horizon commits to a (combined) tuskar and horizon repository, thus making sure, tuskar will work in a fresh (updated) horizon environment. Please correct me if I am wrong, but I think this is not an issue. Currently Tuskar-UI is run from Horizon fork. In local Horizon fork we create symlink to tuskar-ui local clone and to run Horizon with Tuskar-UI we simply start Horizon server. This means that Tuskar-UI runs on latest version of Horizon. (If you pull regularly of course). Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Jirka ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Nominations to Horizon Core
+1 for Tatiana and the clean-up. On 11 December 2013 07:24, Lyle, David david.l...@hp.com wrote: I would like to nominate Tatiana Mazur to Horizon Core. Tatiana has been a significant code contributor in the last two releases, understands the code base well and has been doing a significant number of reviews for the last to milestones. Additionally, I'd like to remove some inactive members of Horizon-core who have been inactive since the early Grizzly release at the latest. Devin Carlen Jake Dahn Jesse Andrews Joe Heck John Postlethwait Paul McMillan Todd Willey Tres Henry paul-tashima sleepsonthefloor Please respond with a +1/-1 by this Friday. -David Lyle ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Horizon Issue
Hi,
On 13 November 2013 12:54, K S khyat...@gmail.com wrote:
Hi I'm a newbie to horizon and I'm working on a trove related issue.
My use case is that on successful execution of the workflow in
trove, I need to redirect the workflow to a view. Additionally I want
to pass a couple of parameters from the workflow to the chained view.
I have tried the following approaches till now :
- set the success_url in workflow. This redirects me to the view,
however I am unable to pass parameters.
You can define a get_success_url() method on your workflow and return
the URL you want. There's an example here:
https://github.com/openstack/horizon/blob/7a51bc7ddd57b39f4389e84ac77bd2dc98c9a3cd/openstack_dashboard/dashboards/project/networks/subnets/workflows.py#L69-L71
class CreateSubnet(network_workflows.CreateNetwork):
snip
def get_success_url(self):
return reverse(horizon:project:networks:detail,
args=(self.context.get('network_id'),))
Hope that helps,
Kieran
- 'return redirect() ' in the handle method of the workflow. This
does not help as expected output of the handle method is a boolean.
Please help me if I am missing some concepts here. Or if this is a
limitation of the workflow. Can I redirect a workflow (passing
parameters) to a view? I know we can easily achieve this behavior with
forms but not sure if this is possible with workflows in horizon.
Your help will be highly appreciated.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cantrip for syncing all the OpenStack repos locally
On 28 October 2013 05:46, Monty Taylor mord...@inaugust.com wrote: Hey all! We still don't have grokmirror running, which I'd like to do to help local syncing of the bazillion git repos. (I frequently like to do that before getting on a plane) However - turns out there is a simple shell-script snippet you can run to get the job done well. It assumes you have an ssh host setup called review which points to review.openstack.org:29418. This will clone or update every repo in gerrit: for repo in `ssh review gerrit ls-projects` ; do mkdir -p $(dirname $repo) if [ ! -d $repo ] ; then echo Cloning $repo git clone git://git.openstack.org/$repo $repo (cd $repo; git review -s) else echo Updating $repo (cd $repo; git remote update) fi done mr looks useful for this type of thing. I haven't got into the habit of using it yet though. http://myrepos.branchable.com/ If you run mr update inside a repository, it'll only act on that repository. In general, any mr command runs recursively over any repository located somewhere in or under the current directory. Cheers, Kieran ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Thanks for fixing my patch
On 14 October 2013 09:58, Jeremy Stanley fu...@yuggoth.org wrote: On 2013-10-14 09:45:38 +1100 (+1100), Angus Salkeld wrote: Note the commit will authored by the original poster, so perhaps if you modify a patch we should add a Modified-by: line to indicate that it was dual authored. We encourage the use of Co-Authored-By: name n...@example.com in commit messages to indicate people who worked on a particular patch. It's a convention for recognizing multiple authors, and our projects would encourage the stats tools to observe it when collecting statistics. https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references That said, if the work I'm doing is trivial fixup to someone else's change and I'm not substantially contributing to the overall idea/implementation, I don't bother to add one... only if it's a significant departure from/improvement on the original author's work. While we're talking about attribution - it's polite to reassign the bug to the original author when it finally merges, since launchpad automatically assigns you whenever you push a new patchset. Kieran -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] ./run_tests.sh issues on Ubuntu 12.04 LTS
Hi Neil, On 26 September 2013 11:13, Neil Zhao neilch...@gmail.com wrote: Hi, All, I'm new to openstack, and I followed the Quick Start at : http://docs.openstack.org/developer/horizon/quickstart.html I thought the Horizon ./run_tests.sh should run successfully since I'm using the popular Ubuntu. And after the script finished, I'll have a out-of-box env to run Horizon, but I was wrong. I found issues, and have to fix them manually with: sudo apt-get install xxx. I've noted some of them as following, I think somebody should test the script more, :) 1) I think the following dependencies should be added/checked in the script: python2.7-dev libxml2-dev libxslt1-dev 2) And the script should be ran as root/sudoers? As it'll do something in my /usr/lib/python2.7/ directory. The script creates a virtualenv in .venv and installs all the python dependencies there. They're not available system-wide. Running anything as root is out of scope for run_tests.sh, but we should definitely list the required C libraries somewhere in the documentation like Nova does: http://docs.openstack.org/developer/nova/devref/development.environment.html#linux-systems BTW, should I file some bug for these? And how? Please do: https://bugs.launchpad.net/horizon/+filebug ...you're welcome to fix it too :) https://wiki.openstack.org/wiki/How_To_Contribute Cheers, Kieran Thank you, Neil Zhao ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Pagination
On 15/08/2013, at 3:02 AM, Jay Pipes jaypi...@gmail.com wrote: On 08/14/2013 12:25 PM, Mac Innes, Kiall wrote: So, Are we saying that UIs built on OpenStack APIs shouldn't be able to show traditional pagination controls? Or am I missing how this should work with marker/limit? No, not quite what I'm saying. The operation to get the total number of pages -- or more explicitly, the operation to get the *exact* number of pages in a list result -- is expensive, and in order to be reasonably efficient, some level of caching is almost always needed. However, being able to page forwards and backwards is absolutely possible with limit/marker solutions. It simply requires the paging client (in this case, Horizon), to store the list of previously seen page links returned in listing results (there is a next and prev link in the returned list images results, for example). Is there a prev link? It's optional in Compute v2 and Images v1 and Nova/Glance don't seem to be returning it. I suspect Nova v3 isn't either but I haven't tested it. There's no mention of it in Images v2 at all and no prev returned there either. If there is a next and prev link in the returned results then Horizon wouldn't need to store anything - the links can be rendered straight into the page. Anyway, you're right, this is all secondary to the need for decent filtering. e.g. for 11 pages of content, something like: 1 2 3 .. 10 11 Yeah, that's not an efficient operation unless you have some sort of caching in place. You can use things like MySQL's SQL_CALC_FOUND_ROWS, but that is not efficient since instead of stopping the query after LIMIT rows, you end up executing the entire query to determine the number of rows that *would* have been returned if no LIMIT was applied. In order to make such a thing efficient, you'd want to cache the value of SQL_CALC_FOUND_ROWS in the session and use that to calculate the number of pages. It's something that can be done, but isn't, IMHO, worth it to get the traditional UI you describe. Instead, a good filter/search UI would be better, with just next/prev links. Best, -jay Thanks, Kiall On 13/08/13 22:45, Jay Pipes wrote: On 08/13/2013 05:04 PM, Gabriel Hurley wrote: I have been one of the earliest, loudest, and most consistent PITA's about pagination, so I probably oughta speak up. I would like to state three facts: 1. Marker + limit (e.g. forward-only) pagination is horrific for building a user interface. 2. Pagination doesn't scale. 3. OpenStack's APIs have historically had useless filtering capabilities. In a world where pagination is a must-have feature we need to have page number + limit pagination in order to build a reasonable UI. Ironically though, I'm in favor of ditching pagination altogether. It's the lowest-common denominator, used because we as a community haven't buckled down and built meaningful ways for our users to get to the data they really want. Filtering is great, but it's only 1/3 of the solution. Let me break it down with problems and high level solutions: Problem 1: I know what I want and I need to find it. Solution: filtering/search systems. This is a good place to start. Glance has excellent filtering/search capabilities -- built in to the API from early on in the Essex timeframe, and only expanded over the last few releases. Pagination solutions should build on a solid filtering/search functionality in the API, where there is a consistent sort key and direction (either hard-coded or user-determined, doesn't matter). Limit/offset pagination solutions (forward and backwards paging, random skip-to-a-page) are inefficient from a SQL query perspective and should be a last resort, IMO, compared to limit/marker. With some smart session-storage of a page's markers, backwards paging with limit/marker APIs is certainly possible -- just store the previous page's marker. Problem 2: I don't know what I want, and it may or may not exist. Solution: tailored discovery mechanisms. This should not be a use case that we spend much time on. Frankly, this use case can be summarized as the window shopper scenario. Providing a quality search/filtering mechanism, including the *API* itself providing REST-ful discovery of the filters and search criteria the API supports, is way more important... Problem 3: I need to know something about *all* the data in my system. Solution: reporting systems. Sure, no disagreement there. We've got the better part of none of that. I disagree. Some of the APIs have support for a good bit of search/filtering. We just need to bring all the projects up to search speed, Captain. Best, -jay p.s. I very often go to the second and third pages of Google searches. :) But I never skip to the 127th page of results. But I'd like to solve these issues. I have lots of thoughts on all of those, and I think the UX and design
Re: [openstack-dev] [keystone] Pagination
On 14/08/2013, at 7:40 AM, Jay Pipes jaypi...@gmail.com wrote: On 08/13/2013 05:04 PM, Gabriel Hurley wrote: I have been one of the earliest, loudest, and most consistent PITA's about pagination, so I probably oughta speak up. I would like to state three facts: 1. Marker + limit (e.g. forward-only) pagination is horrific for building a user interface. 2. Pagination doesn't scale. 3. OpenStack's APIs have historically had useless filtering capabilities. In a world where pagination is a must-have feature we need to have page number + limit pagination in order to build a reasonable UI. Ironically though, I'm in favor of ditching pagination altogether. It's the lowest-common denominator, used because we as a community haven't buckled down and built meaningful ways for our users to get to the data they really want. Filtering is great, but it's only 1/3 of the solution. Let me break it down with problems and high level solutions: Problem 1: I know what I want and I need to find it. Solution: filtering/search systems. This is a good place to start. Glance has excellent filtering/search capabilities -- built in to the API from early on in the Essex timeframe, and only expanded over the last few releases. Pagination solutions should build on a solid filtering/search functionality in the API, where there is a consistent sort key and direction (either hard-coded or user-determined, doesn't matter). Limit/offset pagination solutions (forward and backwards paging, random skip-to-a-page) are inefficient from a SQL query perspective and should be a last resort, IMO, compared to limit/marker. With some smart session-storage of a page's markers, backwards paging with limit/marker APIs is certainly possible -- just store the previous page's marker. Not just the previous page's marker, but the marker of every previous page since we would like to be able to click the previous button more than once. Any previous markers we store are also likely to become stale pretty quickly. And all this is based on the assumption that the user's session even started at the first 'page' - it could be they followed a link from elsewhere in Horizon or the greater internet. I completely agree with Dolph that this is something the client shouldn't need to care about at all. The next/prev links returned with each page of results should hide all of this. next/prev links also make it trivial for the client to discover whether there's even a next page at all, since we don't want to make a user click a link to go to an empty page. Having said that, I think we can improve the current marker/limit system without hurting performance if we split the marker into 'before' and 'after' parameters. That way all the information needed to go forward or backwards is included in the results for the current page. Supporting 'before' should be as simple as reversing the sort order and then flipping the order of the results. Kieran Problem 2: I don't know what I want, and it may or may not exist. Solution: tailored discovery mechanisms. This should not be a use case that we spend much time on. Frankly, this use case can be summarized as the window shopper scenario. Providing a quality search/filtering mechanism, including the *API* itself providing REST-ful discovery of the filters and search criteria the API supports, is way more important... Problem 3: I need to know something about *all* the data in my system. Solution: reporting systems. Sure, no disagreement there. We've got the better part of none of that. I disagree. Some of the APIs have support for a good bit of search/filtering. We just need to bring all the projects up to search speed, Captain. Best, -jay p.s. I very often go to the second and third pages of Google searches. :) But I never skip to the 127th page of results. But I'd like to solve these issues. I have lots of thoughts on all of those, and I think the UX and design communities can offer a lot in terms of the usability of the solutions we come up with. Even more, I think this would be an awesome working group session at the next summit to talk about nothing other than how can we get rid of pagination? As a parting thought, what percentage of the time do you click to the second page of results in Google? All the best, - Gabriel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Cells and quota reservation expiry
Hi all, We're having some issues with quota reservations not being deleted. I understand this can happen in certain cases and that's why they have an expiry time? But I've also noticed that reservations never expire in our system either. Looking at the code, I think this is because the periodic task to handle deleting expired reservations lives in nova-scheduler while the reservations themselves are stored in the top-cell db. Is this a bug? Where's a good place to move the task to? The cells manager? ps. What's a sane low value for the reservation expiry time? Cheers, Kieran ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] Memcache user token index and PKI tokens
On 16/07/2013, at 1:10 AM, Adam Young ayo...@redhat.com wrote: On 07/15/2013 04:06 AM, Kieran Spear wrote: Hi all, I want to backport the fix for the Token List in Memcache can consume an entire memcache page bug[1] to Grizzly, but I had a couple of questions: 1. Why do we need to store the entire token data in the usertoken-userid key? This data always seems to be hashed before indexing into the 'token-tokenid' keys anyway. The size of the memcache data for a user's token list currently grows by 4k every time a new PKI token is created. It doesn't take long to hit 1MB at this rate even with the above fix. Yep. The reason, though, is that we either take a memory/storage hit (store the whole token) or a performance hit (reproduce the token data) and we've gone for the storage hit. In this case it looks like we're taking a hit from both, since the PKI token id from the user token index is retrieved, then hashed and then that key is used to retrieve the token from the tokens-%s page anyway. 2. Every time it creates a new token, Keystone loads each token from the user's token list with a separate memcache call so it can throw it away if it's expired. This seems excessive. Is it anything to worry about? If it just checked the first two tokens you'd get the same effect on a longer time scale. I guess part of the answer is to decrease our token expiry time, which should mitigate both issues. Failing that we'd consider moving to the SQL backend. HOw about doing both? But if you move to the sql backend, rememeber to periodically clean up the token table, or you will have storage issues there as well. No silver bullet, I am afraid. I think we're going to stick with memcache for now (the devil we know :)). With (1) and (2) fixed and the token expiration time tweaked I think memcache will do okay. Kieran Cheers, Kieran [1] https://bugs.launchpad.net/keystone/+bug/1171985 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] Memcache user token index and PKI tokens
On 17/07/2013, at 12:26 AM, Morgan Fainberg m...@metacloud.com wrote: On Tue, Jul 16, 2013 at 4:01 AM, Kieran Spear kisp...@gmail.com wrote: On 16/07/2013, at 1:10 AM, Adam Young ayo...@redhat.com wrote: On 07/15/2013 04:06 AM, Kieran Spear wrote: Hi all, I want to backport the fix for the Token List in Memcache can consume an entire memcache page bug[1] to Grizzly, but I had a couple of questions: 1. Why do we need to store the entire token data in the usertoken-userid key? This data always seems to be hashed before indexing into the 'token-tokenid' keys anyway. The size of the memcache data for a user's token list currently grows by 4k every time a new PKI token is created. It doesn't take long to hit 1MB at this rate even with the above fix. Yep. The reason, though, is that we either take a memory/storage hit (store the whole token) or a performance hit (reproduce the token data) and we've gone for the storage hit. In this case it looks like we're taking a hit from both, since the PKI token id from the user token index is retrieved, then hashed and then that key is used to retrieve the token from the tokens-%s page anyway. 2. Every time it creates a new token, Keystone loads each token from the user's token list with a separate memcache call so it can throw it away if it's expired. This seems excessive. Is it anything to worry about? If it just checked the first two tokens you'd get the same effect on a longer time scale. I guess part of the answer is to decrease our token expiry time, which should mitigate both issues. Failing that we'd consider moving to the SQL backend. HOw about doing both? But if you move to the sql backend, rememeber to periodically clean up the token table, or you will have storage issues there as well. No silver bullet, I am afraid. I think we're going to stick with memcache for now (the devil we know :)). With (1) and (2) fixed and the token expiration time tweaked I think memcache will do okay. Kieran Cheers, Kieran [1] https://bugs.launchpad.net/keystone/+bug/1171985 Hi Kieran, I've looked into the potential bug you described and it appears that there has been a change in the master branch to support the idea of pluggable token providers (much better implementation than the driver being responsible for the token itself). This change modified how the memcache driver stored the IDs, and performed the CMS hashing function when the manager returned the token_id to the driver, instead of in-line within the driver. The original fix should have been correct in hashing the PKI token to the short-form ID. Your fix to simply hash the tokens is the correct one and more closely mirrors how the original fix was implemented. If you are interested in the reviews that implement the new pluggable provider(s): https://review.openstack.org/#/c/33858/ (V3) and https://review.openstack.org/#/c/34421/ (V2.0). Going with the shorter TTL on the Tokens is a good idea for various reasons depending on the token driver. I know that the SQL driver (provided you cleanup expired tokens) has worked well for my company, but I want to move to the memcache driver soon. Thanks for the info. Good to know this is fixed on master. Spotted one possible upgrade issue in the V3 patch which I've submitted a bug for: https://bugs.launchpad.net/keystone/+bug/1202050 And a bug for getting my one-line fix into stable/grizzly: https://bugs.launchpad.net/keystone/+bug/1202053 Cheers, Kieran Cheers, Morgan Fainberg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] Memcache user token index and PKI tokens
Hi all, I want to backport the fix for the Token List in Memcache can consume an entire memcache page bug[1] to Grizzly, but I had a couple of questions: 1. Why do we need to store the entire token data in the usertoken-userid key? This data always seems to be hashed before indexing into the 'token-tokenid' keys anyway. The size of the memcache data for a user's token list currently grows by 4k every time a new PKI token is created. It doesn't take long to hit 1MB at this rate even with the above fix. 2. Every time it creates a new token, Keystone loads each token from the user's token list with a separate memcache call so it can throw it away if it's expired. This seems excessive. Is it anything to worry about? If it just checked the first two tokens you'd get the same effect on a longer time scale. I guess part of the answer is to decrease our token expiry time, which should mitigate both issues. Failing that we'd consider moving to the SQL backend. Cheers, Kieran [1] https://bugs.launchpad.net/keystone/+bug/1171985 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] HACKING and new-style relative imports
Hi all, There's a review up to make Horizon pass H304 (no relative imports): https://review.openstack.org/#/c/35664/ Old-style relative imports are dangerous, but I can't think of a good enough reason to forbid new-style imports, e.g.: from .views import IndexView instead of from openstack_dashboard.dashboards.project.images_and_snapshots.views \ import IndexView particularly in Horizon where nesting is deep and you otherwise end up with many imports that won't fit into 80 characters. I think if we're going to make the change above the benefits would need to outweigh the effect on readability. There's some discussion on the review already, but I'd like to hear from a more general audience. Thoughts? Cheers, Kieran ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] HACKING and new-style relative imports
On 10 July 2013 00:55, Joe Gordon joe.gord...@gmail.com wrote: On Tue, Jul 9, 2013 at 1:28 PM, Kieran Spear kisp...@gmail.com wrote: Hi all, There's a review up to make Horizon pass H304 (no relative imports): https://review.openstack.org/#/c/35664/ Old-style relative imports are dangerous, but I can't think of a good enough reason to forbid new-style imports, e.g.: from .views import IndexView instead of from openstack_dashboard.dashboards.project.images_and_snapshots.views \ import IndexView particularly in Horizon where nesting is deep and you otherwise end up with many imports that won't fit into 80 characters. I think if we're going to make the change above the benefits would need to outweigh the effect on readability. There's some discussion on the review already, but I'd like to hear from a more general audience. Thoughts? http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Imports Do not use relative names in imports. Even if the module is in the same package, use the full package name. This helps prevent unintentionally importing a package twice. Thanks. My understanding is that a module can only be imported twice if there are two different paths to it in your python path. This can happen with both relative and absolute imports, so I don't think H304 prevents that one. Cheers, Kieran ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] HACKING and new-style relative imports
On 10 July 2013 02:31, Monty Taylor mord...@inaugust.com wrote: On 07/09/2013 10:55 AM, Joe Gordon wrote: On Tue, Jul 9, 2013 at 1:28 PM, Kieran Spear kisp...@gmail.com mailto:kisp...@gmail.com wrote: Hi all, There's a review up to make Horizon pass H304 (no relative imports): https://review.openstack.org/#/c/35664/ Old-style relative imports are dangerous, but I can't think of a good enough reason to forbid new-style imports, e.g.: from .views import IndexView instead of from openstack_dashboard.dashboards.project.images_and_snapshots.views \ import IndexView particularly in Horizon where nesting is deep and you otherwise end up with many imports that won't fit into 80 characters. I think if we're going to make the change above the benefits would need to outweigh the effect on readability. There's some discussion on the review already, but I'd like to hear from a more general audience. Thoughts? http://google-styleguide.googlecode.com/svn/trunk/pyguide.html#Imports Do not use relative names in imports. Even if the module is in the same package, use the full package name. This helps prevent unintentionally importing a package twice. From pep8: Relative imports for intra-package imports are highly discouraged. Always use the absolute package path for all imports. Even now that PEP 328 is fully implemented in Python 2.5, its style of explicit relative imports is actively discouraged; absolute imports are more portable and usually more readable. In Horizon I think it's obvious that relative imports are more readable (and type-able) than the alternative. If portable is referring to moving code around, I think each style has portability benefits for both inter- and intra-package module moves, and there's a lot of overlap. It sounds like this particular paragraph has been updated to account for PEP328 without considering why new-style imports should be discouraged. There was a thread on python-dev a few years ago about the same issue: http://mail.python.org/pipermail/python-dev/2010-October/104476.html On 10/5/2010 2:21 PM, Guido van Rossum wrote: On Tue, Oct 5, 2010 at 11:17 AM, Darren Daledsdale24 at gmail.com wrote: The issue is implementing a PEP with nice support for relative imports, and then documenting that it should never be used. Isn't this mostly historical? Until the new relative-import syntax was implemented there were various problems with relative imports. The short-term solution was to recommend not using them. The long-term solution was to implement an unambiguous syntax. Now it is time to withdraw the anti-recommendation. Of course, without going overboard -- I still find them an acquired taste; but they have their place. But nothing ever came of the bug: http://bugs.python.org/issue10031 Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
