Re: [openstack-dev] [nova] 2 weeks in the bug tracker
I think we are limited by the statuses available in launchpad, which doesn't have a stale status. [1] 1. https://help.launchpad.net/Bugs/Statuses On Sat, Sep 20, 2014 at 7:25 PM, Preston L. Bannister pres...@bannister.us wrote: This is great. On the point of: If an Incomplete bug has no response after 30 days it's fair game to close (Invalid, Opinion, Won't Fix). How about Stale ... since that is where it is. (How hard to add a state?) On Fri, Sep 19, 2014 at 6:13 AM, Sean Dague s...@dague.net wrote: I've spent the better part of the last 2 weeks in the Nova bug tracker to try to turn it into something that doesn't cause people to run away screaming. I don't remember exactly where we started at open bug count 2 weeks ago (it was north of 1400, with 200 bugs in new, but it might have been north of 1600), but as of this email we're at 1000 open bugs (I'm counting Fix Committed as closed, even though LP does not), and ~0 new bugs (depending on the time of the day). == Philosophy in Triaging == I'm going to lay out the philosophy of triaging I've had, because this may also set the tone going forward. A bug tracker is a tool to help us make a better release. It does not exist for it's own good, it exists to help. Which means when evaluating what stays in and what leaves we need to evaluate if any particular artifact will help us make a better release. But also more importantly realize that there is a cost for carrying every artifact in the tracker. Resolving duplicates gets non linearly harder as the number of artifacts go up. Triaging gets non-linearly hard as the number of artifacts go up. With this I was being somewhat pragmatic about closing bugs. An old bug that is just a stacktrace is typically not useful. An old bug that is a vague sentence that we should refactor a particular module (with no specifics on the details) is not useful. A bug reported against a very old version of OpenStack where the code has changed a lot in the relevant area, and there aren't responses from the author, is not useful. Not useful bugs just add debt, and we should get rid of them. That makes the chance of pulling a random bug off the tracker something that you could actually look at fixing, instead of mostly just stalling out. So I closed a lot of stuff as Invalid / Opinion that fell into those camps. == Keeping New Bugs at close to 0 == After driving the bugs in the New state down to zero last week, I found it's actually pretty easy to keep it at 0. We get 10 - 20 new bugs a day in Nova (during a weekday). Of those ~20% aren't actually a bug, and can be closed immediately. ~30% look like a bug, but don't have anywhere near enough information in them, and flipping them to incomplete with questions quickly means we have a real chance of getting the right info. ~10% are fixable in 30 minutes worth of work. And the rest are real bugs, that seem to have enough to dive into it, and can be triaged into Confirmed, set a priority, and add the appropriate tags for the area. But, more importantly, this means we can filter bug quality on the way in. And we can also encourage bug reporters that are giving us good stuff, or even easy stuff, as we respond quickly. Recommendation #1: we adopt a 0 new bugs policy to keep this from getting away from us in the future. == Our worse bug reporters are often core reviewers == I'm going to pick on Dan Prince here, mostly because I have a recent concrete example, however in triaging the bug queue much of the core team is to blame (including myself). https://bugs.launchpad.net/nova/+bug/1368773 is a terrible bug. Also, it was set incomplete and no response. I'm almost 100% sure it's a dupe of the multiprocess bug we've been tracking down but it's so terse that you can't get to the bottom of it. There were a ton of 2012 nova bugs that were basically post it notes. Oh, we should refactor this function. Full stop. While those are fine for personal tracking, their value goes to zero probably 3 months after they are files, especially if the reporter stops working on the issue at hand. Nova has plenty of wouldn't it be great if we... ideas. I'm not convinced using bugs for those is useful unless we go and close them out aggressively if they stall. Also, if Nova core can't file a good bug, it's hard to set the example for others in our community. Recommendation #2: hey, Nova core, lets be better about filing the kinds of bugs we want to see! mkay! Recommendation #3: Let's create a tag for personal work items or something for these class of TODOs people are leaving themselves that make them a ton easier to cull later when they stall and no one else has enough context to pick them up. == Tags == The aggressive tagging that Tracy brought into the project has been awesome. It definitely helps slice out into better functional areas. Here is the top of our current official tag list (and bug count): 95
Re: [openstack-dev] [Manila] ./run_tests issue
Dep MySQL-python is already in test-requirements.txt file. As Andreas
said, second one mysql-devel is C lib and can not be installed via pip.
So, project itself, as all projects in OpenStack, can not install it.
C lib deps are handled by Devstack, if it is used. See:
https://github.com/openstack-dev/devstack/tree/master/files/rpms
https://github.com/openstack-dev/devstack/blob/2f27a0ed3c609bfcd6344a55c121e56d5569afc9/functions-common#L895
Yes, Manila could have its files in the same way in
https://github.com/openstack/manila/tree/master/contrib/devstack , but this
lib is already exist in deps for other projects. So, I guess you used
Manila run_tests.sh file on host without devstack installation, in that
case all other projects would fail in the same way.
On Sun, Sep 21, 2014 at 2:54 AM, Alex Leonhardt aleonhardt...@gmail.com
wrote:
And yet it's a dependency so I'm with Deepak and it should at least be
mentioned in the prerequisites on a webpage somewhere .. :) I might even
try and update/add that myself as it caught me out a few times too..
Alex
On 20 Sep 2014 12:44, Andreas Jaeger a...@suse.com wrote:
On 09/20/2014 09:34 AM, Deepak Shetty wrote:
thanks , that worked.
Any idea why it doesn't install it automatically and/or it isn't present
in requirements.txt ?
I thought that was the purpose of requirements.txt ?
AFAIU requirements.txt has only python dependencies while
mysql-devel is a C development package,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
___
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
--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Requirements freeze exception: urllib3
Hi, Please see this: https://review.openstack.org/122993 Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][vmware] Juno update
Hi, Below is a short update of the current status of the driver in Juno. We managed to complete the following specs: * Integration with oslo.vmware (https://github.com/openstack/nova-specs/blob/master/specs/juno/use-oslo-vmware.rst) * Hot plug interface (https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-hot-plug.rst) * Span refactor (https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-spawn-refactor.rst) The following specs were implemented but did not manage to land: * Ephemeral disk support (https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-ephemeral-disk-support.rst) * Storage based policies (https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-spbm-support.rst) The following specs were partially implemented - they need to be rebased after the spawn refactor: * Spawning an OVA image (https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-driver-ova-support.rst) * VSAN support (https://github.com/openstack/nova-specs/blob/master/specs/juno/vmware-vsan-support.rst) In addition to this the ESX driver is no longer supported. In addition to this we have a number of critical bugs that are in review: * Update to latest oslo.vmware (https://review.openstack.org/#/c/121614/) * VMware: Convert file_size to int (https://review.openstack.org/#/c/120309/) * VMware: fix exception when multiple compute nodes are running (https://review.openstack.org/#/c/108225) * VMware: fix regression for 'TaskInProgress' (https://review.openstack.org/#/c/121479/) * VMware: prevent race condition with VNC port allocation (https://review.openstack.org/#/c/114548/) * VMware: fix VM rescue problem with VNC console (https://review.openstack.org/#/c/113908/) * VMware: support inventory folders (https://review.openstack.org/#/c/122017/) * vc driver breaks instances.hypervisor_hostname value (https://review.openstack.org/#/c/99623/) Hopefully we can get the above patches in (some may require a rebase ...) Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Please do *NOT* use vendorized versions of anything (here: glanceclient using requests.packages.urllib3)
Hi Ian and Donald, I've read the full thread, and couldn't help to reply to it still, even though I previously thought I shouldn't, as what I care is OpenStack, not really requests, and more largely, the topic of the wrong reasons why upstream are embedding foreign library code copies. I completely agree with someone else who wrote that this thread is nearly uninteresting for OpenStack itself. However, it is IMO my role, as a package maintainer, to let you know about my view on your argumentation. If you ignore my argumentation, then at least I'll have tried! :) On 09/18/2014 03:42 AM, Ian Cordasco wrote: Circling back to the issue of vendoring though: it’s a conscious decision to do this, and in the last two years there have been 2 CVEs reported for requests. There have been none for urllib3 and none for chardet. (Frankly I don’t think either urllib3 or chardet have had any CVEs reported against them, but let’s ignore that for now.) While security is typically the chief concern with vendoring, none of the libraries we use have had security issues rendering it a moot point in my opinion. The benefits of vendoring for us as a team have been numerous and we will likely continue to do it until it stops benefiting us and our users. Could you please list the benefits *for end users*? I'm really saying users, as in, not developers. Because I don't see any benefit at all for the end users. I don't think any of them would like to see many version of the same thing on their system. Also, the issue is not only security. Let me give you an example. Simply do this in a Debian sid machine: apt-file search six.py | grep -v python3 | grep -v pyshared | wc -l We have in Debian, about 50 versions of six.py around, embedded in packages. And this doesn't even counts those where only bits of six are just embedded in a file which isn't called six.py. Of course, we (in Debian) would like them to be removed. Why? Because it's a useless complexity, with so many different version, some with embedded bugs which have been fixed upstream, and the like. That's not even about security at this point (I hardly would see how six.py would have security issue). There is also a waste of server resources (install time, size of packages in the Debian archive, increased download time, RAM footprint of everything, etc.). We don't need to install (and compile as .pyc at install time) 50 versions of six.py, a single one is enough. We're trying to address this as much as we can, and you'll see lots of packages were we did, but it's not always easy for various reasons, like upstream code not up-to-date with latest version, or lack of time from the Debian package maintainer. Also, consider the fact that six is small: a quite small single file. It's still unacceptable from a Unix distribution stand point, but this makes the vendorizing less of an absurdity. Now, for urllib3, it's a WAY bigger. There's about 25 Python files. So multiply the resulting waste and issues... This was a simple example for six. Now just generalize to all. There's numerous upstream authors who also think that it's ok, and they can be one of the few exception. But really, every upstream who does this think that he's special. That's not the case. Requests isn't more special than any other Python module. On 09/18/2014 04:31 AM, Ian Cordasco wrote: Isn’t the whole point of distributing a library to let people use it as they see fit? The point of a library, is that it is shared among multiple consumers. Oh, maybe not if you're using Windows, but that's maybe out of the scope of this debate. Maintaining a coherent distribution with a single version of every library, is what distributions do as much as possible. It is unfortunately not always possible, but we do it as much as we can. On 09/18/2014 04:31 AM, Ian Cordasco wrote: Project X pins a version of requests. Alice doesn’t know anything about requests and does pip install X. Until Alice takes a more active role in the development of Project X and looks into requests, she will never know she’s installed software that has exposures in it. In all likelihood, any person who just uses something that pins requests will never check for it. If they just use pip and Project X never updates, it’s not our responsibility for anything that happens to the user. This is exactly why we should, at all costs, avoid using pinning. This is very dangerous, and leads to all sorts of issues. We should make sure that we stay current with absolutely all libraries, and when possible, support both the old and the new version of some incompatible API when possible. On 09/18/2014 04:31 AM, Ian Cordasco wrote: I think more applications bundle it than you realize. You’re likely using one daily that does it. It's not because stupidity is wide spread that it becomes smartness. (nothing personal, just making a general statement...) On 09/18/2014 04:31 AM, Ian Cordasco wrote: The reality is that by vendoring its
Re: [openstack-dev] Please do *NOT* use vendorized versions of anything (here: glanceclient using requests.packages.urllib3)
On 09/18/2014 05:22 AM, Dean Troyer wrote: On Wed, Sep 17, 2014 at 3:53 PM, Robert Collins robe...@robertcollins.net mailto:robe...@robertcollins.net wrote: On 18 September 2014 08:01, Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com wrote: Interestingly enough, the distros are doing exactly what they don't want us to do, ie, rebuilding things to use 'their' tested version of dependencies rather than the included one... We don't use our tested version, we use upstream's, and a single version of it. Indeed - but the distros are solving for two specific issues: No argument, just observing the recursive nature of this... Also, if we pin to a version, is the downstream consequence different? IIRC Thomas has had to do this with Django (1.7?) and Horizon, probably with others too. Correct. And there's still some open issues with it, though mostly it has been dealt with. There was also SQLAlchemy 0.8 then 0.9 a year ago as well. Though since Mike Bayer works on OpenStack support now, I'm sure I wont have to deal with any SQLA issue again. It's a common mistake to think that we just need to pin. Pinning (the upper bound) doesn't solve any issue, apart from having the tests pass the gate. This is sometimes urgent to fix the gate, so I understand why this is done. The reality is that packages in a distribution share common dependency, and OpenStack isn't alone in the distro. Lucky, (almost?) everyone in the OpenStack community understand this, and so far, I've received *a lot* of help from everyone. You have no idea how much this is important to me. Kudos to everyone who do help or who is at least gives moral support! :) As a provider of an app package directly to users, dealing with the front-line consequences of changing dependencies falls on me. And its one reason with this hat on I want static linking, or a Python equivalent of it (bundling/vendoring) at the app level. Since a few days, the Debian policy manual explicitly forbids static linking. I fully agree with the decision to make it explicit. Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Please do *NOT* use vendorized versions of anything (here: glanceclient using requests.packages.urllib3)
Hi Thomas, Several people, many of whom are core contributors to other projects, have asked that this discussion not be continued in this venue. Discussion of the decisions of the core-developers of requests are not appropriate for this list. All three of us have email addresses that you can retrieve from anywhere you please. There’s a mailing list for request, albeit very lightly trafficked, and there’s twitter. Further, I’m disappointed that you felt it appropriate or necessary to result to personal attacks on this list. At the very least you could have contained those to Twitter like others in this thread have done. I expected a more civil response on the openstack-dev mailing list. Cheers, Ian On 9/21/14, 7:21 AM, Thomas Goirand z...@debian.org wrote: Hi Ian and Donald, I've read the full thread, and couldn't help to reply to it still, even though I previously thought I shouldn't, as what I care is OpenStack, not really requests, and more largely, the topic of the wrong reasons why upstream are embedding foreign library code copies. I completely agree with someone else who wrote that this thread is nearly uninteresting for OpenStack itself. However, it is IMO my role, as a package maintainer, to let you know about my view on your argumentation. If you ignore my argumentation, then at least I'll have tried! :) On 09/18/2014 03:42 AM, Ian Cordasco wrote: Circling back to the issue of vendoring though: it’s a conscious decision to do this, and in the last two years there have been 2 CVEs reported for requests. There have been none for urllib3 and none for chardet. (Frankly I don’t think either urllib3 or chardet have had any CVEs reported against them, but let’s ignore that for now.) While security is typically the chief concern with vendoring, none of the libraries we use have had security issues rendering it a moot point in my opinion. The benefits of vendoring for us as a team have been numerous and we will likely continue to do it until it stops benefiting us and our users. Could you please list the benefits *for end users*? I'm really saying users, as in, not developers. Because I don't see any benefit at all for the end users. I don't think any of them would like to see many version of the same thing on their system. Also, the issue is not only security. Let me give you an example. Simply do this in a Debian sid machine: apt-file search six.py | grep -v python3 | grep -v pyshared | wc -l We have in Debian, about 50 versions of six.py around, embedded in packages. And this doesn't even counts those where only bits of six are just embedded in a file which isn't called six.py. Of course, we (in Debian) would like them to be removed. Why? Because it's a useless complexity, with so many different version, some with embedded bugs which have been fixed upstream, and the like. That's not even about security at this point (I hardly would see how six.py would have security issue). There is also a waste of server resources (install time, size of packages in the Debian archive, increased download time, RAM footprint of everything, etc.). We don't need to install (and compile as .pyc at install time) 50 versions of six.py, a single one is enough. We're trying to address this as much as we can, and you'll see lots of packages were we did, but it's not always easy for various reasons, like upstream code not up-to-date with latest version, or lack of time from the Debian package maintainer. Also, consider the fact that six is small: a quite small single file. It's still unacceptable from a Unix distribution stand point, but this makes the vendorizing less of an absurdity. Now, for urllib3, it's a WAY bigger. There's about 25 Python files. So multiply the resulting waste and issues... This was a simple example for six. Now just generalize to all. There's numerous upstream authors who also think that it's ok, and they can be one of the few exception. But really, every upstream who does this think that he's special. That's not the case. Requests isn't more special than any other Python module. On 09/18/2014 04:31 AM, Ian Cordasco wrote: Isn’t the whole point of distributing a library to let people use it as they see fit? The point of a library, is that it is shared among multiple consumers. Oh, maybe not if you're using Windows, but that's maybe out of the scope of this debate. Maintaining a coherent distribution with a single version of every library, is what distributions do as much as possible. It is unfortunately not always possible, but we do it as much as we can. On 09/18/2014 04:31 AM, Ian Cordasco wrote: Project X pins a version of requests. Alice doesn’t know anything about requests and does pip install X. Until Alice takes a more active role in the development of Project X and looks into requests, she will never know she’s installed software that has exposures in it. In all likelihood, any person who just uses something that pins requests will never check for it. If they
Re: [openstack-dev] Please do *NOT* use vendorized versions of anything (here: glanceclient using requests.packages.urllib3)
On 09/21/2014 11:30 AM, Ian Cordasco wrote: Hi Thomas, Several people, many of whom are core contributors to other projects, have asked that this discussion not be continued in this venue. Discussion of the decisions of the core-developers of requests are not appropriate for this list. All three of us have email addresses that you can retrieve from anywhere you please. There’s a mailing list for request, albeit very lightly trafficked, and there’s twitter. Further, I’m disappointed that you felt it appropriate or necessary to result to personal attacks on this list. At the very least you could have contained those to Twitter like others in this thread have done. I expected a more civil response on the openstack-dev mailing list. For those of us interested in this conversation, I ask that whatever decisions (if any) that come out of those discussions, that somebody please do post to the openstack-dev ML a summary of those decisions or actions. Thanks much in advance, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?
Querying keystone for tenant names is certainly fair game. Keystone should be considered the only source of truth for tenant names though, as they are mutable and not globally unique on their own, so other services should not stash any names from keystone into long term persistence (users, projects, domains, groups, etc-- roles might be an odd outlier worth a separate conversation if anyone is interested). Store IDs where necessary, and use IDs on the wire where possible though, as they are immutable. On Sat, Sep 20, 2014 at 7:46 PM, Kevin Benton blak...@gmail.com wrote: Hello all, A patch has come up to query keystone for tenant names in the IBM plugin.[1] As I understand it, this was one of the reasons another mechanism driver was reverted.[2] Can we get some clarity on the level of integration with Keystone that is permitted? Thanks 1. https://review.openstack.org/#/c/122382 2. https://review.openstack.org/#/c/118456 -- Kevin Benton ___ 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] [Neutron] - what integration with Keystone is allowed?
So based on those guidelines there would be a problem with the IBM patch because it's storing the tenant name in a backend controller, right? On Sep 21, 2014 12:18 PM, Dolph Mathews dolph.math...@gmail.com wrote: Querying keystone for tenant names is certainly fair game. Keystone should be considered the only source of truth for tenant names though, as they are mutable and not globally unique on their own, so other services should not stash any names from keystone into long term persistence (users, projects, domains, groups, etc-- roles might be an odd outlier worth a separate conversation if anyone is interested). Store IDs where necessary, and use IDs on the wire where possible though, as they are immutable. On Sat, Sep 20, 2014 at 7:46 PM, Kevin Benton blak...@gmail.com wrote: Hello all, A patch has come up to query keystone for tenant names in the IBM plugin.[1] As I understand it, this was one of the reasons another mechanism driver was reverted.[2] Can we get some clarity on the level of integration with Keystone that is permitted? Thanks 1. https://review.openstack.org/#/c/122382 2. https://review.openstack.org/#/c/118456 -- Kevin Benton ___ 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] devstack - horizon dashboard issues
Hi guys,
trying to get a devstack up and running, on a VM, but I keep getting this:
Error during template rendering
In template
/opt/stack/horizon/openstack_dashboard/templates/context_selection/_project_list.html,
error at line *7*
Reverse for ''switch_tenants'' with arguments
'(u'ca0fd29936a649e59850d7bb8c17e44c',)' and keyword arguments '{}' not
found.
Any pointers ?
Alex
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] naming of provider template for docs
Thanks for the suggestions, I'll give that patch another crack. -Angus On Sat, Sep 20, 2014 at 10:11 AM, Qiming Teng teng...@linux.vnet.ibm.com wrote: On Fri, Sep 19, 2014 at 11:20:43AM +0200, Thomas Spatzier wrote: From: Mike Spreitzer mspre...@us.ibm.com To: OpenStack Development Mailing List \(not for usage questions\) openstack-dev@lists.openstack.org Date: 19/09/2014 07:15 Subject: Re: [openstack-dev] [Heat] naming of provider template for docs Angus Salkeld asalk...@mirantis.com wrote on 09/18/2014 09:33:56 PM: Hi I am trying to add some docs to openstack-manuals hot_guide about using provider templates : https://review.openstack.org/#/c/121741/ Mike has suggested we use a different term, he thinks provider is confusing. I agree that at the minimum, it is not very descriptive. Mike has suggested nested stack, I personally think this means something a bit more general to many of us (it includes the concept of aws stacks) and may I suggest template resource - note this is even the class name for this exact functionality. Thoughts? Option 1) stay as is provider templates Option 2) nested stack Option 3) template resource Out of those 3 I like #3 the most, even though not perfect as Mike discussed below. Thanks for rising to the documentation challenge and trying to get good terminology. I think your intent is to describe a category of resources, so your option 3 is superior to option 1 --- the thing being described is not a template, it is a resource (made from a template). I think Option 4) custom resource That one sound too generic to me, since also custom python based resource plugins are custom resources. +1. 'Custom resource' may cause more confusion. would be even better. My problem with template resource is that, to someone who does not already know what it means, this looks like it might be a kind of resource that is a template (e.g., for consumption by some other resource that does something with a template), rather than itself being something made from a template. If you want to follow this direction to something perfectly clear, you might try templated resource (which is a little better) or template-based resource (which I think is pretty clear but a bit wordy) --- but an AWS::CloudFormation::Stack is also based on a template. I think that if you try for a name that really says all of the critical parts of the idea, you will get something that is too wordy and/or awkward. It is true that custom resource begs the question of how the user accomplishes her customization, but at least now we have the reader asking the right question instead of being misled. I think template-based resource really captures the concept best. And it is not too wordy IMO. If it helps to explain the concept intuitively, I would be in favor of it. Agreed. If it sounds too wordy, just use 'template resource' would be okay. Regards, Thomas ___ 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] [Heat] Announcing my candidacy for PTL
I would like to announce my candidacy for the position of Orchestration PTL. After contributing to Heat since it was created, I feel like I know what Heat is and can do. We have some really big challenges ahead to ensure that Heat is scalable and stays relevant. The big issues for Heat that I want to focus on are: The TripleO project have used Heat extensively and found it to be lacking in a number of areas, I believe that this is great feedback that we need to respond to very quickly. We are starting some of this (the convergence work) but I'd like to get more involved with this to make sure we can get to a solution in a timely manner. How do other projects that have been working hard in the orchestration area (TOSCA, Murano and Mistral) fit into OpenStack, and in particular, how they integrate with Heat and the Orchestration program. There is obviously lots of talk in this area (tent sizes), but I think we need to start looking forward to understand how these projects could fit together to form a cohesive product for OpenStack. How do we integrate better with existing OpenSource orchestration tools that users are familiar with using. Hopefully OpenStack orchestration does not begin and end with a CloudFormation based solution. I look forward to some fun discussions in this area;) In conclusion these are exciting times for OpenStack and in particular Orchestration. I'd love the opportunity to face these challenges head on with our great community. Regards Angus Salkeld ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] 2 weeks in the bug tracker
On 9/19/2014 8:13 AM, Sean Dague wrote: I've spent the better part of the last 2 weeks in the Nova bug tracker to try to turn it into something that doesn't cause people to run away screaming. I don't remember exactly where we started at open bug count 2 weeks ago (it was north of 1400, with 200 bugs in new, but it might have been north of 1600), but as of this email we're at 1000 open bugs (I'm counting Fix Committed as closed, even though LP does not), and ~0 new bugs (depending on the time of the day). == Philosophy in Triaging == I'm going to lay out the philosophy of triaging I've had, because this may also set the tone going forward. A bug tracker is a tool to help us make a better release. It does not exist for it's own good, it exists to help. Which means when evaluating what stays in and what leaves we need to evaluate if any particular artifact will help us make a better release. But also more importantly realize that there is a cost for carrying every artifact in the tracker. Resolving duplicates gets non linearly harder as the number of artifacts go up. Triaging gets non-linearly hard as the number of artifacts go up. With this I was being somewhat pragmatic about closing bugs. An old bug that is just a stacktrace is typically not useful. An old bug that is a vague sentence that we should refactor a particular module (with no specifics on the details) is not useful. A bug reported against a very old version of OpenStack where the code has changed a lot in the relevant area, and there aren't responses from the author, is not useful. Not useful bugs just add debt, and we should get rid of them. That makes the chance of pulling a random bug off the tracker something that you could actually look at fixing, instead of mostly just stalling out. So I closed a lot of stuff as Invalid / Opinion that fell into those camps. == Keeping New Bugs at close to 0 == After driving the bugs in the New state down to zero last week, I found it's actually pretty easy to keep it at 0. We get 10 - 20 new bugs a day in Nova (during a weekday). Of those ~20% aren't actually a bug, and can be closed immediately. ~30% look like a bug, but don't have anywhere near enough information in them, and flipping them to incomplete with questions quickly means we have a real chance of getting the right info. ~10% are fixable in 30 minutes worth of work. And the rest are real bugs, that seem to have enough to dive into it, and can be triaged into Confirmed, set a priority, and add the appropriate tags for the area. But, more importantly, this means we can filter bug quality on the way in. And we can also encourage bug reporters that are giving us good stuff, or even easy stuff, as we respond quickly. Recommendation #1: we adopt a 0 new bugs policy to keep this from getting away from us in the future. == Our worse bug reporters are often core reviewers == I'm going to pick on Dan Prince here, mostly because I have a recent concrete example, however in triaging the bug queue much of the core team is to blame (including myself). https://bugs.launchpad.net/nova/+bug/1368773 is a terrible bug. Also, it was set incomplete and no response. I'm almost 100% sure it's a dupe of the multiprocess bug we've been tracking down but it's so terse that you can't get to the bottom of it. There were a ton of 2012 nova bugs that were basically post it notes. Oh, we should refactor this function. Full stop. While those are fine for personal tracking, their value goes to zero probably 3 months after they are files, especially if the reporter stops working on the issue at hand. Nova has plenty of wouldn't it be great if we... ideas. I'm not convinced using bugs for those is useful unless we go and close them out aggressively if they stall. Also, if Nova core can't file a good bug, it's hard to set the example for others in our community. Recommendation #2: hey, Nova core, lets be better about filing the kinds of bugs we want to see! mkay! Recommendation #3: Let's create a tag for personal work items or something for these class of TODOs people are leaving themselves that make them a ton easier to cull later when they stall and no one else has enough context to pick them up. == Tags == The aggressive tagging that Tracy brought into the project has been awesome. It definitely helps slice out into better functional areas. Here is the top of our current official tag list (and bug count): 95 compute 83 libvirt 74 api 68 vmware 67 network 41 db 40 testing 40 volumes 36 ec2 35 icehouse-backport-potential 32 low-hanging-fruit 31 xenserver 25 ironic 23 hyper-v 16 cells 14 scheduler 12 baremetal 9 ceph 9 security 8 oslo ... So, good stuff. However I think we probably want to take a further step and attempt to get champions for tags. So that tag owners would ensure their bug list looks sane, and actually spend some time fixing them. It's pretty clear, for instance, that the ec2 bugs are just piling up, and very few fixes coming in.
Re: [openstack-dev] [nova] expected behaviour of _report_state() on rabbitmq failover
On 9/10/2014 3:33 PM, Chris Friesen wrote: On 09/10/2014 02:13 PM, Chris Friesen wrote: As it stands, it seems that waiting for the RPC call to time out blocks _report_state() from running again in report_interval seconds, which delays the service update until the RPC timeout period expires. Just noticed something... In the case of _report_state(), does it really make sense to wait 60 seconds for RPC timeout when we're going to send a new service update in 10 seconds anyway? More generally, the RPC timeout on the service_update() call should be less than or equal to service.report_interval for the service. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Maybe completely unrelated, but FYI while you're looking at this code path: https://bugs.launchpad.net/neutron/+bug/1357055 -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] expected behaviour of _report_state() on rabbitmq failover
On 9/21/2014 7:56 PM, Matt Riedemann wrote: On 9/10/2014 3:33 PM, Chris Friesen wrote: On 09/10/2014 02:13 PM, Chris Friesen wrote: As it stands, it seems that waiting for the RPC call to time out blocks _report_state() from running again in report_interval seconds, which delays the service update until the RPC timeout period expires. Just noticed something... In the case of _report_state(), does it really make sense to wait 60 seconds for RPC timeout when we're going to send a new service update in 10 seconds anyway? More generally, the RPC timeout on the service_update() call should be less than or equal to service.report_interval for the service. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Maybe completely unrelated, but FYI while you're looking at this code path: https://bugs.launchpad.net/neutron/+bug/1357055 Oops, completely wrong bug. Here is the correct one: https://bugs.launchpad.net/nova/+bug/1331537 -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Announcing my candidacy for PTL
confirmed On 21/09/14 08:15 PM, Angus Salkeld wrote: I would like to announce my candidacy for the position of Orchestration PTL. After contributing to Heat since it was created, I feel like I know what Heat is and can do. We have some really big challenges ahead to ensure that Heat is scalable and stays relevant. The big issues for Heat that I want to focus on are: The TripleO project have used Heat extensively and found it to be lacking in a number of areas, I believe that this is great feedback that we need to respond to very quickly. We are starting some of this (the convergence work) but I'd like to get more involved with this to make sure we can get to a solution in a timely manner. How do other projects that have been working hard in the orchestration area (TOSCA, Murano and Mistral) fit into OpenStack, and in particular, how they integrate with Heat and the Orchestration program. There is obviously lots of talk in this area (tent sizes), but I think we need to start looking forward to understand how these projects could fit together to form a cohesive product for OpenStack. How do we integrate better with existing OpenSource orchestration tools that users are familiar with using. Hopefully OpenStack orchestration does not begin and end with a CloudFormation based solution. I look forward to some fun discussions in this area;) In conclusion these are exciting times for OpenStack and in particular Orchestration. I'd love the opportunity to face these challenges head on with our great community. Regards Angus Salkeld ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Federation and Policy
On 09/19/2014 01:43 PM, Doug Hellmann wrote: On Sep 19, 2014, at 6:56 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 18/09/2014 22:14, Doug Hellmann wrote: On Sep 18, 2014, at 4:34 PM, David Chadwick d.w.chadw...@kent.ac.uk wrote: On 18/09/2014 21:04, Doug Hellmann wrote: On Sep 18, 2014, at 12:36 PM, David Chadwick d.w.chadw...@kent.ac.uk wrote: Our recent work on federation suggests we need an improvement to the way the policy engine works. My understanding is that most functions are protected by the policy engine, but some are not. The latter functions are publicly accessible. But there is no way in the policy engine to specify public access to a function and there ought to be. This will allow an administrator to configure the policy for a function to range from very lax (publicly accessible) to very strict (admin only). A policy of means that any authenticated user can access the function. But there is no way in the policy to specify that an unauthenticated user (i.e. public) has access to a function. We have already identified one function (get trusted IdPs identity:list_identity_providers) that needs to be publicly accessible in order for users to choose which IdP to use for federated login. However some organisations may not wish to make this API call publicly accessible, whilst others may wish to restrict it to Horizon only etc. This indicates that that the policy needs to be set by the administrator, and not by changes to the code (i.e. to either call the policy engine or not, or to have two different API calls). I don’t know what list_identity_providers does. it lists the IDPs that Keystone trusts to authenticate users Can you give a little more detail about why some providers would want to make it not public I am not convinced that many cloud services will want to keep this list secret. Today if you do federated login, the public web page of the service provider typically lists the logos or names of its trusted IDPs (usually Facebook and Google). Also all academic federations publish their full lists of IdPs. But it has been suggested that some commercial cloud providers may not wish to publicise this list and instead require the end users to know which IDP they are going to use for federated login. In which case the list should not be public. if we plan to make it public by default? If we think there’s a security issue, shouldn’t we just protect it? Its more a commercial in confidence issue (I dont want the world to know who I have agreements with) rather than a security issue, since the IDPs are typically already well known and already protect themselves against attacks from hackers on the Internet. OK. The weak “someone might want to” requirement aside, and again showing my ignorance of implementation details, do we truly have to add a new feature to disable the policy check? Is there no way to have an “always allow” policy using the current syntax? You tell me. If there is, then problem solved. If not, then my request still stands From looking at the code, it appears that something like True:”True” (or possibly True:True) would always pass, but I haven’t tested that. Nope; it errors out before it ever gets to the policy check, when it unpacks the token. Doug regards David Doug regards David If we can invent some policy syntax that indicates public access, e.g. reserved keyword of public, then Keystone can always call the policy file for every function and there would be no need to differentiate between protected APIs and non-protected APIs as all would be protected to a greater or lesser extent according to the administrator's policy. Comments please It seems reasonable to have a way to mark a function as fully public, if we expect to really have those kinds of functions. Doug regards 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 ___ 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] About the question Switch firewall_driver control from Neutron to Nova
Dear OpenStack-dev, I've posted a question on https://ask.openstack.org/en/question/47819/switch-firewall_driver-control-f rom-neutron-to-nova/ It's suggested that I should forward this question to OpenStack-dev mailing list for discussion. Any feedback/answer would be very appreciated. Thanks and regards Trung ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] pycharm license?
Hi, Does anyone has pycharm license for openstack project development? Thanks. Regards Kanagaraj M ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO][elections] Not running as PTL this cycle
I'm not running as PTL for the TripleO program this cycle. There are a couple of reasons for this. Firstly, I think its good for intense multi-year efforts like we're all involved in here to have leadership spread around: for the folk wearing the leadership hat, its hard work keeping everything paged in all the time, and folk can easily burn out. I don't like burning out :). For projects, having folk that have different views avoids us getting stuck in a rut and increases experimentation and learning, IME. Secondly, I joined OpenStack to help it move forward as a whole, but I've done relatively little other than deployment - and we've consistently hit limitations and issues outside of the deployment code - in all sorts of areas - testing, performance, other APIs and so on. I personally feel a need to correct this - I'm currently running into the risk of myopia, solving things just in the deployment context, and I need to do better than that :). I look forward to other TripleO folk putting their hat into the ring - I'll support whoever wins in anyway I can, and I'm still going to be here hacking on TripleO and reviewing what folk are working on:) -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?
Thanks Kevin for bring it up in the ML, I was looking for a guideline or any document to clarify issues on this subject. I was told, even using keystone API in neutron is not permitted. Thanks, Nader. On Sun, Sep 21, 2014 at 12:58 PM, Kevin Benton blak...@gmail.com wrote: So based on those guidelines there would be a problem with the IBM patch because it's storing the tenant name in a backend controller, right? On Sep 21, 2014 12:18 PM, Dolph Mathews dolph.math...@gmail.com wrote: Querying keystone for tenant names is certainly fair game. Keystone should be considered the only source of truth for tenant names though, as they are mutable and not globally unique on their own, so other services should not stash any names from keystone into long term persistence (users, projects, domains, groups, etc-- roles might be an odd outlier worth a separate conversation if anyone is interested). Store IDs where necessary, and use IDs on the wire where possible though, as they are immutable. On Sat, Sep 20, 2014 at 7:46 PM, Kevin Benton blak...@gmail.com wrote: Hello all, A patch has come up to query keystone for tenant names in the IBM plugin.[1] As I understand it, this was one of the reasons another mechanism driver was reverted.[2] Can we get some clarity on the level of integration with Keystone that is permitted? Thanks 1. https://review.openstack.org/#/c/122382 2. https://review.openstack.org/#/c/118456 -- Kevin Benton ___ 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
