Re: [openstack-dev] [hacking] rules for removal
On Sat, 2014-06-21 at 07:36 -0700, Clint Byrum wrote: Excerpts from Sean Dague's message of 2014-06-21 05:08:01 -0700: Pedantic reviewers that are reviewing for this kind of thing only should be scorned. I realistically like the idea markmc came up with - https://twitter.com/markmc_/status/480073387600269312 I also agree it is really fun to think about shaming those annoying actions. It is also not fun _at all_ to be publicly shamed. In fact I'd say it is at least an order of magnitude less fun. There is an old saying, praise in public, punish in private. It is one reason the -1 comments I give always include praise for whatever is right for new contributors. Not everyone is a grizzled veteran. It is far more interesting to me to solve the grouping problem in a way that works for us long term (python 2 and 3) than it is to develop a culture that builds any of its core activities on negative emotional feedback. That's not to say we can't say hey you're doing it wrong. I mean to say that direct feedback like that belongs in private IRC messages or email, not in public everyone can see that reviews. Give people a chance to save face. Meanwhile, the less we have to have one on one negative feedback, the easier the job of reviewers is. The last thing we want to do is have more reasons for people to NOT do reviews. You're right that something like I suggested could easily lead to more negative energy in the project, not less. What I had in mind was that we could laugh at ourselves about this. Assuming that the reviewers called out would be fully on-board and willing to laugh along at being the most pedantic nerd of the week. Yeah, that's probably wishful thinking. Maybe it could be anonymous. Maybe instead it could be a weekly mailing list discussion so that we could all discuss as a community whether that kind of feedback on a review is appropriate. The main point is that this is something worth addressing as a wider community rather than in individual reviews with a limited audience. And that doing it with a bit of humor might help take the sting out of it. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] PTL and core team members
On 20/06/14 07:29 +0100, Mark McLoughlin wrote: On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote: Dolph, I appreciate the suggestion. In the mean time how does the review process work without core developers to approve gerrit submissions? If you're just getting started, have a small number (possibly just 1 to begin with) of developers collaborate closely, with the minimum possible process and then use that list of developers as your core review team when you gradually start adopting some process. Aim to get from zero to bootstrapped with that core team in a small number of weeks at most. Minimum possible process could mean a git repo anywhere that those initial developers have direct push access to. You could use stackforge from the beginning and the developers just approve their own changes, but that's a bit annoying. +1 this is how we did it in Marconi (except for the repo with push access). At the beginning, we kept a core team of 2 developers despite there being at least 4 ppl working on the project. This allowed the team to have better discussions on what got in the repo and what not. One benefit of using stackforge is that you get a great CI system to test your project with but the development will slow down for sure. We started on stackforge right away, then had a 2 days hackathon on a github fork which was not a good idea because we had to submit al those patches for review after the hackathon. :( Flavio -- @flaper87 Flavio Percoco pgp3yPPKqEift.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches
On 06/21/2014 05:41 PM, Doug Hellmann wrote: On Sat, Jun 21, 2014 at 2:27 PM, Morgan Fainberg morgan.fainb...@gmail.com mailto:morgan.fainb...@gmail.com wrote: The issue with the login page simply refreshing was due to a change in Keystone that updated the type of Token issued by default from PKI to PKIZ (compressed PKI/ASN1). The update to the django auth module was intended to correct that specific issue with Keystone and Horizon (Juno). The bug fix (not sure if another review is to blame with the django_openstack_auth module tha t is currently happening) that addressed your specific issue is: https://bugs.launchpad.net/horizon/+bug/1331406 I have proposed a fix for Keystone that would revert the PKIZ default: https://review.openstack.org/#/c/101714/ Depending on the fixes upcoming for the django_openstack_auth module, it may make sense to temporarily revert the PKIZ provider default until we can solve the issues with the django auth module and horizon when PKIZ is enabled. If this review is not needed based on how the horizon issues are corrected, it will be abandoned. I think this is also showing some gaps in our testing, notably that the django_openstack_auth module isn't being exercised on the integration tests. I'll aim to hit up Horizon team and work with them and the QA folks to make sure we cover this gap in the future. We may also want to consider adding it to the list of libraries we have in the cross-project unit test matrix (https://review.openstack.org/#/c/95885/). This is actually just the same issue we've got with the python clients. The changes were moving through to actually do the right thing here (https://review.openstack.org/#/c/79881/) however, that's got to be backported to stable devstack branches as well. Also we need https://review.openstack.org/101749 I just approved https://review.openstack.org/#/c/101734/ (havana pin) Once that passes and merges, if someone rechecks the icehouse pin (Approved, but it won't pass tests until the havana version lands) https://review.openstack.org/#/c/101727/, it should pass and let patches flow again. Next week we need a proper unwind with the horizon team to get django_openstack_auth working with stable/* again, get the testing working again. I'm mostly away from computers today, however 101727 should be in a state where all it needs is a recheck bug 1331406 in about an hour or two, which anyone can do. -Sean Doug --Morgan On Saturday, June 21, 2014, Mike Spreitzer mspre...@us.ibm.com mailto:mspre...@us.ibm.com wrote: Since Friday I have been getting this misbehavior: enter username and password, hit login, and it shows you the login page again. Sean Dague --- [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches --- From: Sean Dague s...@dague.net Toopenstack-dev openstack-dev@lists.openstack.org Date: Sat, Jun 21, 2014 12:54 Subject [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches Horizon in icehouse is now 100% failing [Sat Jun 21 16:17:35 2014] [error] Internal Server Error: / [Sat Jun 21 16:17:35 2014] [error] Traceback (most recent call last): [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py, line 112, in get_response [Sat Jun 21 16:17:35 2014] [error] response = wrapped_callback(request, *callback_args, **callback_kwargs) [Sat Jun 21 16:17:35 2014] [error] File /usr/local/lib/python2.7/dist-packages/django/views/decorators/vary.py, line 36, in inner_func [Sat Jun 21 16:17:35 2014] [error] response = func(*args, **kwargs) [Sat Jun 21 16:17:35 2014] [error] File /opt/stack/old/horizon/openstack_dashboard/wsgi/../../openstack_dashboard/views.py, line 35, in splash [Sat Jun 21 16:17:35 2014] [error] form = views.Login(request) [Sat Jun 21 16:17:35 2014] [error] AttributeError: 'module' object has no attribute 'Login' This suspiciously times with django_openstack_auth 1.1.6 being released. http://logstash.openstack.org/#eyJzZWFyY2giOiJcIkF0dHJpYnV0ZUVycm9yOiAnbW9kdWxlJyBvYmplY3QgaGFzIG5vIGF0dHJpYnV0ZSAnTG9naW4nXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MDMzNjk0MjQ4NjR9 Because this breaks smoke tests on icehouse, it means that any project with upgrade testing fails. Would be
Re: [openstack-dev] [hacking] rules for removal
In addition to making changes to the hacking rules, why don't we mandate also that perceived problems in the commit message shall not be an acceptable reason to -1 a change. Would this improve the situation? -amrith -- Amrith Kumar, CTO Tesora (www.tesora.com) Twitter: @amrithkumar IRC: amrith @freenode | -Original Message- | From: Sean Dague [mailto:s...@dague.net] | Sent: Friday, June 20, 2014 2:08 PM | To: OpenStack Development Mailing List (not for usage questions) | Subject: [openstack-dev] [hacking] rules for removal | | After seeing a bunch of code changes to enforce new hacking rules, I'd | like to propose dropping some of the rules we have. The overall patch | series is here - | https://review.openstack.org/#/q/status:open+project:openstack- | dev/hacking+branch:master+topic:be_less_silly,n,z | | H402 - 1 line doc strings should end in punctuation. The real statement is | this should be a summary sentence. A sentence is not just a set of words | that end in a period. Squirel fast bob. It's something deeper. | This rule thus isn't really semantically useful, especially when you are | talking about at 69 character maximum (79 - 4 space indent - 6 quote | characters). | | H803 - First line of a commit message must *not* end in a period. This was | mostly a response to an unreasonable core reviewer that was -1ing people | for not having periods. I think any core reviewer that -1s for this either | way should be thrown off the island, or at least made fun of, a lot. | Again, the clarity of a commit message is not made or lost by the lack or | existence of a period at the end of the first line. | | H305 - Enforcement of libraries fitting correctly into stdlib, 3rdparty, | our tree. This biggest issue here is it's built in a world where there was | only 1 viable python version, 2.7. Python's stdlib is actually pretty | dynamic and grows over time. As we embrace more python 3, and as distros | start to make python3 be front and center, what does this even mean? The | current enforcement can't pass on both python2 and python3 at the same | time in many cases because of that. | | We have to remember we're all humans, and it's ok to have grey space. | Like in 305, you *should* group the libraries if you can, but stuff like | that should be labeled as 'nit' in the review, and only ask the author to | respin it if there are other more serious issues to be handled. | | Let's optimize a little more for fun, and stop throwing -1s for silly | things. :) | | -Sean | | -- | Sean Dague | http://dague.net smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] PTL and core team members
I'm thinking we are going to need more than 2 on the core team at first but it is hard to tell exactly how many people will be contributing code at first. I know we've got a lot of interested parties and the possibility that some 10+ people are actively contributing. Of course, these things can only be predicted and will be unknown until it is actually known. Also, we really need to have a good plan of action. Once we get a consensus on the design we should start breaking the implementation up into umbrella blueprint specs (or epic blueprint specs) with each one detailing the bigger picture and breaking up the bigger picture into smaller tasks/stories that can be accomplished. Then people can start choosing which they would like to implement. Sounds good in theory, but actually executing it will be the tough part. Thanks, Brandon On Sun, 2014-06-22 at 13:42 +0200, Flavio Percoco wrote: On 20/06/14 07:29 +0100, Mark McLoughlin wrote: On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote: Dolph, I appreciate the suggestion. In the mean time how does the review process work without core developers to approve gerrit submissions? If you're just getting started, have a small number (possibly just 1 to begin with) of developers collaborate closely, with the minimum possible process and then use that list of developers as your core review team when you gradually start adopting some process. Aim to get from zero to bootstrapped with that core team in a small number of weeks at most. Minimum possible process could mean a git repo anywhere that those initial developers have direct push access to. You could use stackforge from the beginning and the developers just approve their own changes, but that's a bit annoying. +1 this is how we did it in Marconi (except for the repo with push access). At the beginning, we kept a core team of 2 developers despite there being at least 4 ppl working on the project. This allowed the team to have better discussions on what got in the repo and what not. One benefit of using stackforge is that you get a great CI system to test your project with but the development will slow down for sure. We started on stackforge right away, then had a 2 days hackathon on a github fork which was not a good idea because we had to submit al those patches for review after the hackathon. :( Flavio ___ 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] rules for removal
On 06/20/2014 02:07 PM, Sean Dague wrote: After seeing a bunch of code changes to enforce new hacking rules, I'd like to propose dropping some of the rules we have. The overall patch series is here - https://review.openstack.org/#/q/status:open+project:openstack-dev/hacking+branch:master+topic:be_less_silly,n,z H402 - 1 line doc strings should end in punctuation. The real statement is this should be a summary sentence. A sentence is not just a set of words that end in a period. Squirel fast bob. It's something deeper. This rule thus isn't really semantically useful, especially when you are talking about at 69 character maximum (79 - 4 space indent - 6 quote characters). ++ This was always a silly rule, IMO Sorry, forgot to add a period. There. Better. H803 - First line of a commit message must *not* end in a period. This was mostly a response to an unreasonable core reviewer that was -1ing people for not having periods. I think any core reviewer that -1s for this either way should be thrown off the island, or at least made fun of, a lot. Again, the clarity of a commit message is not made or lost by the lack or existence of a period at the end of the first line. +10 Sorry, I meant +10. Period. H305 - Enforcement of libraries fitting correctly into stdlib, 3rdparty, our tree. This biggest issue here is it's built in a world where there was only 1 viable python version, 2.7. Python's stdlib is actually pretty dynamic and grows over time. As we embrace more python 3, and as distros start to make python3 be front and center, what does this even mean? The current enforcement can't pass on both python2 and python3 at the same time in many cases because of that. +0 on this one... I find it useful to group the libs together in this way, as it makes it relatively easy to identify quickly at a glance the third party libs that are in use in the module. We have to remember we're all humans, and it's ok to have grey space. Like in 305, you *should* group the libraries if you can, but stuff like that should be labeled as 'nit' in the review, and only ask the author to respin it if there are other more serious issues to be handled. Ya, no real disagreement on that. Let's optimize a little more for fun, and stop throwing -1s for silly things. :) ++ I would also love to get rid of H404, otherwise known as the dumb rule that says if you have a multiline docstring, that there must be a summary line, then a blank line, then a detailed description. It makes things like this illegal, which, IMHO, is stupid: def do_something(self, thing): We do something with the supplied thing, so that something else is also done with this other thing. Make sure the other thing is of type something. pass Likewise, I'd love to be able to have a newline start the docstring, like so: def do_something(self, thing): We do something with the supplied thing, so that something else is also done with this other thing. Make sure the other thing is of type something. pass But there's a rule that prevents that as well... To be clear, I don't think all hacking rules are silly. To the contrary, there are many that are reasonable and useful. However, I'd prefer to focus on things that make the code more readable, not less readable, and rules that enforce Pythonic idioms, not some random hacker's idea of good style. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [hacking] rules for removal
On 06/22/2014 09:41 AM, Amrith Kumar wrote: In addition to making changes to the hacking rules, why don't we mandate also that perceived problems in the commit message shall not be an acceptable reason to -1 a change. Would this improve the situation? I actually *do* think a very poor commit message for a substantial patch deserves a -1. The git commit message is our history for the patch, and it is important in its own right. Now, nits like a single misspelled word or the commit summary being 60 characters instead of 50 are not what I'm talking about, of course. I'm speaking only about when a commit message blatantly disregards the best practices of commit message writing [1] and doesn't offer anything of value to the reviewer. Best, -jay [1] https://wiki.openstack.org/wiki/GitCommitMessages ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] PTL and core team members
Hi Brandon, Yep, that sounds like a good way to approach this. And FWIW, this week I'm planning on moving several of the designs I've presented to the group into blueprints / gerrit specs for the project and otherwise start working on a roadmap to actually get the thing built. In the mean time, there's still a ton that needs to be done on the Neutron LBaaS side of things to make sure we get feature improvements and cleaner Neutron API interfaces in before the Juno freeze. So I don't think there's a reason anyone should be idle working on these two projects, eh. Stephen On Sun, Jun 22, 2014 at 11:38 AM, Brandon Logan brandon.lo...@rackspace.com wrote: I'm thinking we are going to need more than 2 on the core team at first but it is hard to tell exactly how many people will be contributing code at first. I know we've got a lot of interested parties and the possibility that some 10+ people are actively contributing. Of course, these things can only be predicted and will be unknown until it is actually known. Also, we really need to have a good plan of action. Once we get a consensus on the design we should start breaking the implementation up into umbrella blueprint specs (or epic blueprint specs) with each one detailing the bigger picture and breaking up the bigger picture into smaller tasks/stories that can be accomplished. Then people can start choosing which they would like to implement. Sounds good in theory, but actually executing it will be the tough part. Thanks, Brandon On Sun, 2014-06-22 at 13:42 +0200, Flavio Percoco wrote: On 20/06/14 07:29 +0100, Mark McLoughlin wrote: On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote: Dolph, I appreciate the suggestion. In the mean time how does the review process work without core developers to approve gerrit submissions? If you're just getting started, have a small number (possibly just 1 to begin with) of developers collaborate closely, with the minimum possible process and then use that list of developers as your core review team when you gradually start adopting some process. Aim to get from zero to bootstrapped with that core team in a small number of weeks at most. Minimum possible process could mean a git repo anywhere that those initial developers have direct push access to. You could use stackforge from the beginning and the developers just approve their own changes, but that's a bit annoying. +1 this is how we did it in Marconi (except for the repo with push access). At the beginning, we kept a core team of 2 developers despite there being at least 4 ppl working on the project. This allowed the team to have better discussions on what got in the repo and what not. One benefit of using stackforge is that you get a great CI system to test your project with but the development will slow down for sure. We started on stackforge right away, then had a 2 days hackathon on a github fork which was not a good idea because we had to submit al those patches for review after the hackathon. :( Flavio ___ 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 -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Infra] [infra] Nominations for jenkins-job-builder core
On 2014-06-20 14:01:01 -0700 (-0700), James E. Blair wrote: The Jenkins Job Builder project [...] core reviewers [...] I would like to add Darragh Bailey [...] and Marc Abramowitz [...] I'm very much in favor of both Darragh and Marc as additions to the openstack-infra/jenkins-job-builder project core reviewer team. Their knowledge of the project internals and support of its existing core reviewers has been invaluable. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Periodic Security Checks
Adding openstack-security to the thread. In case folks on OSSG don't monitor this list. - Original Message - From: Alexandr Naumchev anaumc...@gmail.com To: openstack-dev@lists.openstack.org Cc: Amey Ghadigaonkar gamoholic...@gmail.com, Vasiliy Artemev vas...@gmail.com, David Yuan david.yuanh...@gmail.com Sent: Sunday, June 22, 2014 4:33:35 AM Subject: [openstack-dev] Periodic Security Checks Hello! We have blueprints here: https://blueprints.launchpad.net/horizon/+spec/periodic-security-checks and here: https://blueprints.launchpad.net/nova/+spec/periodic-security-checks/ And we already have some code. Is it necessary to approve the blueprint before contributing the code? In any case, could someone review the aforementioned blueprints? 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
Re: [openstack-dev] [hacking] rules for removal
I agree Duncan. I think the commit message is one of the most important parts of a commit. If the message is not useful, the code shouldn't go in. Jay Bryant On Jun 22, 2014 1:51 PM, Duncan Thomas duncan.tho...@gmail.com wrote: On 22 June 2014 14:41, Amrith Kumar amr...@tesora.com wrote: In addition to making changes to the hacking rules, why don't we mandate also that perceived problems in the commit message shall not be an acceptable reason to -1 a change. -1. There are some /really/ bad commit messages out there, and some of us try to use the commit messages to usefully sort through the changes (i.e. I often -1 in cinder a change only affects one driver and that isn't clear from the summary). If the perceived problem is grammatical, I'm a bit more on board with it not a reason to rev a patch, but core reviewers can +2/A over the top of a -1 anyway... Would this improve the situation? Writing better commit messages in the first place would improve the situation? ___ 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] [Oslo] Translating log and exception messages in Oslo libraries
+1 To translating oslo logs. There is quite a bit of logging that comes out of the libraries. It should be logged for consistency using delayed translation. Jay On Jun 20, 2014 8:22 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: On Fri, Jun 20, 2014 at 8:40 AM, Mark McLoughlin mar...@redhat.com wrote: Hi I'm not sure we've ever discussed this before, but I had previously figured that we shouldn't translate log and exception messages in oslo.messaging. My thinking is: - it seems like an odd thing for a library to do, I don't know of examples of other libraries doing this .. but I haven't gone looking - it involves a dependency on oslo.i18n - more than just marking strings for translation and using gettextutils, you also need to set up the infrastructure for pushing the .pot files to transifex, pulling the .po files from .transifex and installing the .mo files at install time I don't feel terribly strongly about this except that unless someone is willing to see this through and do the transifex and install-time work, we shouldn't be doing the use-oslo.i18n and mark-strings-for-translation work. I had thought we would do all of the oslo libraries, since so many of the log messages actually come from library code. I think Andreas has already set up most of the infrastructure needed to make the translation jobs work. We haven't done a great job of communicating the plan on log translations, and I'm currently looking for someone from the i18n team to step forward to be the point of contact on that work. Doug Mark. ___ 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] rules for removal
On Mon, Jun 23, 2014 at 4:43 AM, Jay Pipes jaypi...@gmail.com wrote: On 06/22/2014 09:41 AM, Amrith Kumar wrote: In addition to making changes to the hacking rules, why don't we mandate also that perceived problems in the commit message shall not be an acceptable reason to -1 a change. Would this improve the situation? I actually *do* think a very poor commit message for a substantial patch deserves a -1. The git commit message is our history for the patch, and it is important in its own right. Now, nits like a single misspelled word or the commit summary being 60 characters instead of 50 are not what I'm talking about, of course. I'm speaking only about when a commit message blatantly disregards the best practices of commit message writing [1] and doesn't offer anything of value to the reviewer. +1. Minor typos and grammatical errors I don't care about (but will put in suggested fixes if the patch needs to be updated anyway). However, commit messages are very important for future debugging. One or two line vague commit messages can make life a lot harder for others in the future when writing a short description is not what I'd consider an excessive burden. And there should be no assumption that the person reading the commit message will have easy access to the bug database. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] default security group rules in neutron
Greetings We use neutron as network functionality implementation in nova, and as you know, there is a feature called 'os-security-group-default-rules' in nova extension[1], a hook mechanism to add customized rules when creating default security groups, which is a very useful feature to the administrators or operators (at least useful to us in our deployment). But I found this feature is valid only when using nova-network. So, for the functionality parity between nova-network and neutron and for our use case, I registered a blueprint[2] about default security group rules in Neutron days ago and related neutron spec[3], and I want it to be involved in Juno, so we can upgrade our deployment that time for this feature. I'm ready for the code implementation[3]. But I still want to see what's the community's thought about including this feature in neutron, any of your feedback and comments are appreciated! [1] https://blueprints.launchpad.net/nova/+spec/default-rules-for-default-security-group [2] https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group [3] https://review.openstack.org/98966 [4] https://review.openstack.org/99320 -- Regards! --- Lingxian Kong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Swift] Swift 2.0 release candidate
Through extensive work from the entirety of the Swift dev team over the past year, storage policies have landed in Swift. Last Friday, we merged commit 1feaf6e2 which brings storage polices into master. I especially would like to publicly thank Paul Luse (Intel), Clay Gerrard (SwiftStack), and Sam Merritt (SwiftStack) for providing such tremendous focus, dedication, awesome ideas, and leadership to getting this feature designed, written, and merged. For those that don't know, storage policies are a way to take the global footprint of your Swift cluster and choose what subset of hardware to store the data on and how to store it across that subset of hardware. For example, a single Swift cluster can now have data segmented by geographic region or performance tier. Additionally, each policy can have a different replication factor, which enables high replication for local access (e.g. one copy in every PoP) or low replication for some data (e.g. image thumbnails or transcoded video). Storage policies is the necessary building block to allow non-replicated storage (i.e. erasure codes) in Swift, a feature that we are continuing to develop. Full documentation, including design, usage, and upgrade notes, can be found at http://swift.openstack.org/overview_policies.html. With this commit landing, we have tagged Swift 2.0.0.rc1. We are now having a two week QA period to allow community members to play with it in their labs. At the end of the RC period, we'll formally release Swift 2.0. The current target for this is Thursday July 3 (although I realize that discovered issues and the US holiday may put this at risk). In addition to participating in the OpenStack integrated release cycle, Swift makes semantically-versioned releases throughout the year. Because of the scope of the storage policies changes and because you cannot safely downgrade your cluster after configuring a second policy (i.e. you'd lose access to that data if you go to a pre-storage-policies release), we have chosen to bump the major version number to 2. Note that deployers can still upgrade to this version with no client downtime and still safely downgrade until multiple policies are configured. The full CHANGELOG for the 2.0 release is at https://github.com/openstack/swift/blob/master/CHANGELOG. If you are using Swift, please read over the docs, download the tarball from http://tarballs.openstack.org/swift/swift-2.0.0.rc1.tar.gz, and let us know what you find. --John signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
