Re: [openstack-dev] [heat][keystone] APIs, roles, request scope and admin-ness
On Wed, 2013-11-06 at 06:16 +0800, Clint Byrum wrote: Excerpts from Steven Hardy's message of 2013-11-03 00:06:39 +0800: Hi all, Looking to start a wider discussion, prompted by: https://review.openstack.org/#/c/54651/ https://blueprints.launchpad.net/heat/+spec/management-api https://etherpad.openstack.org/p/heat-management-api Summary - it has been proposed to add a management API to Heat, similar in concept to the admin/public API topology used in keystone. I'm concerned that this may not be a pattern we want to propagate throughout OpenStack, and that for most services, we should have one API to access data, with the scope of the data returned/accessible defined by the roles held by the user (ie making proper use of the RBAC facilities afforded to us via keystone). I feel that i can speak for the keystone developers when i say avoid this at all costs! Currently in the implementation of keystone what is exposed on the admin port is the same as the public port with the intention that we can hopefully remove adminURL altogether. In the current PoC patch, a users admin-ness is derived from the fact that they are accessing a specific endpoint, and that policy did not deny them access to that endpoint. I think this is wrong, and we should use keystone roles to decide the scope of the request. The proposal seems to consider tenants as the top-level of abstraction, with the next level up being a global service provider admin, but this does not consider the keystone v3 concept of domains [1], or that you may wish to provide some of these admin-ish features to domain-admin users (who will adminster data accross multiple tenants, just like has been proposed), via the public-facing API. It seems like we need a way of scoping the request (via data in the context), based on a heirarchy of admin-ness, like: 1. Normal user 2. Tenant Admin (has admin role in a tenant) 3. Domain Admin (has admin role in all tenants in the domain) 4. Service Admin (has admin role everywhere, like admin_token for keystone) The current is_admin flag which is being used in the PoC patch won't allow this granularity of administrative boundaries to be represented, and splitting admin actions into a separate API will prevent us providing tenant and domain level admin functionality to customers in a public cloud environment. It has been mentioned that in keystone, if you have admin in one tenant, you are admin everywhere, which is a pattern I think we should not follow - keystone folks, what are your thoughts in terms of roadmap to make role assignment (at the request level) scoped to tenants rather than globally applied? E.g what data can we add to move from X-Roles in auth_token, to expressing roles in multiple tenants and domains? Right, roles should be tenant and domain scoped, and the roles that we consume in our policy definitions should not need to know anything about the hierarchy. It seems very broken to me that there would be no way to make a user who can only create more users in their tenant in Keystone. Likewise, I would consider Heat broken if I had to use a special API for doing things with a role I already have that is just scoped more broadly than a single tenant or domain. This is possible with the v3 api. Basically, I'm very concerned that we discuss this, get a clear roadmap which will work with future keystone admin/role models, and is not a short-term hack which we won't want to maintain long-term. What are peoples thoughts on this? Let's try and find a keystone dev or two in the hallway at the summit and get some clarity on the way Keystone is intended to work, which may help us decide if we want to follow their admin-specific-API paradigm or not. There are a number of us at summit (myself included). Our sessions tend to be in the afternoon so you can probably find at least 1 dev in the dev lounge at the other times. ___ 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] [Solum] Design Workshop at SFO
Re-sending details for the upcoming Solum workshop at SFO on popular demand We will also have an events section on Solum.io for this kind of communication in the next week or so. Please confirm your attendance by visiting the eventbrite page: https://www.eventbrite.com/event/9130831563 . This is important so we get an accurate count of attendees. From: Roshan Agrawal Sent: Friday, November 01, 2013 3:17 PM To: openstack-dev@lists.openstack.org Subject: [Solum] Design Workshop at SFO Hello, we are locked down on the plan to hold design workshops on Solum at SFO! It it now time to confirm your participation, and make travel arrangements. Please confirm your attendance by visiting the eventbrite page: https://www.eventbrite.com/event/9130831563 . This is important so we get an accurate count of attendees. Workshop dates: Nov 19, 20 Location: Rackspace SFO office (620 Folsom St, San Francisco, CA 94107) Purpose: working sessions for Solum contributors to discuss design/blueprints. Meeting Structure Nov 19 Tuesday 9:00 am - 5 pm 9:00 - 9:30: check-in 9:30 - 10:00: introductions, agenda 10:00 - 5:00: Roundtable workshop, whiteboarding 5:30 - 7:00: Happy hour (3rd floor at the Rackspace SFO office) Nov 20 Wednesday 9:30 am - 3:00 pm : Continue workshops Workshop Concludes 3 pm Wednesday Please refer to the etherpad page below for the latest info on the event, and to provide input on discussion topics for the workshop. https://etherpad.openstack.org/p/SolumSFOCommunityWorkshop Thanks, and look forward to seeing you all at the event. Thanks! Roshan Agrawal ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Bad review patterns
Hello, I'm quite new in the OpenStack project, but I love it already. What is especially nifty is the automated review system -- I'm really impressed. I'm coming from a project in which we also did reviews of every change -- although it was mostly manual, and just one review was enough to merge -- and at some point in that project I noticed that it is very easy to give reviews that are unhelpful, frustrating and just get in the way of the actual work. I started paying attention to how I am reviewing code, and I managed to come up with several patterns that are bad. Once I know the patterns, it's easier to recognize when I'm doing something wrong and rethink the review. I would like to share the patterns that I noticed. Not sure if that works... = You see some suspicious piece of code, and you are not sure if it is correct or not. So you point it out in the review and -1 it, demanding that the author rechecks it and/or prove that it indeed works. It's your job as a reviewer to check such things, don't put all the effort on the author. They probably already checked that this code works, and possibly have even written tests for it. If you are not familiar with the technology enough to tell whether it's good or not, and have no means of testig it yourself, you shouldn't be reviewing it. If you do have the means to test it or can find the piece of documentation that says that it shouldn't be done -- do it as a part of the review. You ain't gonna need it. The code contains some parts that are potentially reusable later or in different areas, so you -1 it and tell the author to move them into reusable functions. The fact that you think something is reusable doesn't necessarily mean it is, and overly general code is harder to maintain. Let something repeat a couple of times just to be sure it actually is reusable. Once you find a repeating pattern, you can refactor the code to use a generalized function in its place -- in a separate change. There is an old bug here. = While you review the submitted code, you notice something wrong in the code not immediately related to the change you are reviewing. You -1 the change and tell the author to fix that bug, or formatting issue, or typo, or whatever. That fix has nothing to do with the change you are reviewing. The correct thing to do is to make a mental note of it, and fix it in a separate change -- possibly even finding more instances of it or coming up with a much better fix after seeing more code. Guess what I mean. == You notice a pep8 violation, or pep257 violation, or awkward wording of a comment or docstring, or a clumsy piece of code. You -1 the change and just tell author to fix it. It's not so easy to guess what you mean, and in case of a clumsy piece of code, not even that certain that better code can be used instead. So always provide an example of what you would rather want to see. So instead of pointing to indentation rules, just show properly indented code. Instead of talking about grammar or spelling, just type the corrected comment or docstring. Finally, instead of saying use list comprehension here or don't use has_key, just type your proposal of how the code should look like. Then we have something concrete to talk about. Of course, you can also say why you think this is better, but an example is very important. If you are not sure how the improved code would look like, just let it go, chances are it would look even worse. Not a complete fix. === The code fixes some problems (for example, fixes formatting and enables some flake8 checks), but leaves some other, related problems still not fixed. You -1 it and demand that the author adds fixes for the related problem. Don't live your coding career through the authors. If their fix is good and correct and improves the code, let it in, even if you see more opportunities to improve it. You can add those additional fixes yourself in a separate change. Or, if you don't have time or skill to do that, report a bug about the remaining problems and someone else will do it, but don't hold the author hostage with your review because you think he didn't do enough. Leaving a mark. === You review a change and see that it is mostly fine, but you feel that since you did so much work reviewing it, you should at least find *something* wrong. So you find some nitpick and -1 the change just so that they know you reviewed it. This is quite obvious. Just don't do it. It's OK to spend an hour reviewing something, and then leaving no comments on it, because it's simply fine, or because we had to means to test someting (see the first pattern). Those are the things I'm careful about myself. I'm sure that not everyone of you will agree that all of those patterns are bad in all situations -- in fact, I'm pretty sure that some of them are sometimes warranted -- but they are always
Re: [openstack-dev] [Neutron] IPv6 sub-team?
I definitely think this should be a standing Neutron sub team. mark On Nov 6, 2013, at 7:50 AM, Collins, Sean (Contractor) sean_colli...@cable.comcast.com wrote: Hi, Is there any interest in organizing a IPv6 sub-team, similar to how there are sub-teams for FwaaS, VPNaas, ML2, etc? -- Sean M. Collins AIM: seanwdp ___ 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] [TripleO] Releases of this week
Hey, Cool! Thanks for sharing this! Roman On Wednesday, November 6, 2013, Sergey Lukjanov wrote: Here is the script for processing bug while releasing - https://github.com/ttx/openstack-releasing/blob/master/process_bugs.py Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. On Nov 6, 2013, at 1:42 PM, Roman Podoliaka rpodoly...@mirantis.com wrote: Hey, Oh, that's a pity. I didn't know that. Sure I'll update the doc and look for a way to automize the process. Roman On Wednesday, November 6, 2013, Robert Collins wrote: Awesome work - thank you!!! Can you please add to your docs though, that we need to go and close the bugs in the project (either via a script or by hand) - gerrit leaves them as Fix Committed today. Cheers, Rob On 2 November 2013 04:38, Roman Podoliaka rpodoly...@mirantis.com wrote: Hi all, This week I've been doing releases of all projects, which belong to TripleO program. Here are release notes you might be interested in: os-collect-config - 0.1.5 (was 0.1.4): - default polling interval was reduced to 30 seconds - requirements were updated to use the new iso8601 version fixing important bugs diskimage-builder - 0.0.9 (was 0.0.8) - added support for bad Fedora image mirrors (retry the request once on 404) - removed dependency on dracut-network from fedora element - fixed the bug with removing of lost+found dir if it's not found tripleo-image-elements - 0.1.0 (was 0.0.4) - switched to tftpd-hpa on Fedora and Ubuntu - made it possible to disable file injection in Nova - switched seed vm to Neutron native PXE - added Fedora support to apache2 element - fixed processing of routes in init-neutron-ovs - fixed Heat watch server url key name in seed vm metadata tripleo-heat-templates - 0.1.0 (was 0.0.1) - disabled Nova Baremetal file injection (undercloud) - made LaunchConfiguration resources mergeable - made neutron public interface configurable (overcloud) - made it possible to set public interface IP (overcloud) - allowed making the public interface a VLAN (overcloud) - added a wait condition for signalling that overcloud is ready - added metadata for Nova floating-ip extension - added tuskar API service configuration - hid AdminToken in Heat templates - added Ironic service configuration tuskar - 0.0.2 (was 0.0.1) - made it possible to pass Glance image id - fixed the bug with duplicated Resource Class names tuskar-ui - 0.0.2 (was 0.0.1) - resource class creation form no longer ignores the image selection - separated flavors creation step - fail gracefully on node detail page when no overcloud - added validation of MAC addresses and CIDR values - stopped appending Resource Class name to Resource Class flavors - fixed JS warnings when $ is not available - fixed links and naming in Readme - various code and test fixes (pep8, refactoring) python-tuskarclient - 0.0.2 (was 0.0.1) - fixed processing of 301 response code os-apply-config and os-refresh-config haven't had new commits since the last release This also means that: 1. We are now releasing all the projects we have. 2. *tuskar* projects have got PyPi entries. Last but not least. I'd like to say a big thank you to Chris Jones who taught me 'Release Management 101' and provided patches to openstack/infra-config to make all our projects 'releasable'; Robert Collins for his advice on version numbering; Clark Boylan and Jeremy Stanley for landing of Gerrit ACL patches and debugging PyPi uploads issues; Radomir Dopieralski and Tomas Sedovic for landing a quick fix to tuskar-ui. Thank you all guys, you've helped me a lot! Roman ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com Distinguished Technologist ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] Duplicated test effort development
Hi, 2013/10/30 Christopher Yeoh cbky...@gmail.com: Hi, It looks like we have lots of people writing tests at the moment which is great, but the downside is we're starting to see people accidentally writing tests for the same APIs at the same time. There is a google spreadsheet which covers the Nova v2 API where we can reserve what tests we're working on but I don't think we have an easily editable list for the other APIs. I don't think blueprints/bugs work so well at this, and I don't think we have anything else setup at the moment, so as a temporary measure I've created an etherpad here: https://etherpad.openstack.org/p/TempestTestDevelopment which links to the Nova v2 API spreadsheet and to a new etherpad for glance apis (this would ideally be a spreadsheet as well but in the meantime would work as a tool to avoid duplicated effort). Add new links if you're working on new tests for other APIs. I think it'd be a really good idea if we all checked these lists and add what we're about to work on before starting to write new tests to avoid the situation where we have almost identical changesets in the review queue from different people. Thanks for preparing this etherpad page. To avoid the duplicated works of Tempest, I also have added some contents about separation negative tests from positive test files. To separate negative tests, some patches have been queued already in Gerrit. I wrote these patches' URLs on the etherpad. I'm glad if developers check this contents before starting this work. Thanks Ken'ichi Ohmichi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 sub-team?
+1 from me! (I think it's my first message on the list, so Hi! ;) Miguel Angel Ajo Pelayo +34 636 52 25 69 skype: ajoajoajo 2013/11/6 Mark McClain mark.mccl...@dreamhost.com I definitely think this should be a standing Neutron sub team. mark On Nov 6, 2013, at 7:50 AM, Collins, Sean (Contractor) sean_colli...@cable.comcast.com wrote: Hi, Is there any interest in organizing a IPv6 sub-team, similar to how there are sub-teams for FwaaS, VPNaas, ML2, etc? -- Sean M. Collins AIM: seanwdp ___ 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] [Climate] Reservation service called Climate
Hi, During the Design session https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API we discussed the fact that this is not the role of Nova for doing atomic reservations in order to ensure the user needs will be met. I raised the point (and sorry for my bad accent, was stressy) that we're already trying to provide a reservation system for Openstack, called Climate (a Stackforge project). I would really like to discuss with you all, Nova community, about the reservation system and ensure that we, at Climate, are on the good path. Climate is planning to reserve both virtual instances and physical hosts, but for the discussion we had, only physical hosts usecase is relevant. We had an unconference session today at 2pm, I can share you the slides : https://docs.google.com/presentation/d/1BJGmtzGees6tg_Np7JuKFtuLGiCaguVYD8hYJ2eVKAc/edit#slide=id.p (please focus on slides 11-14, they're talking on the design for host reservations) All the code is located on Stackforge, but please note the most important part of physical host reservations is still under review there : https://review.openstack.org/#/q/project:+stackforge/climate+status:open,n,z (We're missing reviewers, by the way !) I'm open to discuss and waiting your thoughts, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Code Review (Jenkins-job-builder, BlameUpstreamCommitters plugin support)
Hi, Could someone review this please: https://review.openstack.org/#/c/54085/ Regards, Peter ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [State-Management] Slides from taskflow speaker session
Thanks all for showing up! http://www.slideshare.net/harlowja/taskflow-27820295 Not sure if there is an official page for this, anyway link is above (likely video link somewhere also). Questions, comments, feedback welcome! Thxs all for making this possible :-) -josh Sent from my really tiny device... ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OpenStack-dev Digest, Vol 19, Issue 10
thank you to Chris Jones who taught me 'Release Management 101' and provided patches to openstack/infra-config to make all our projects 'releasable'; Robert Collins for his advice on version numbering; Clark Boylan and Jeremy Stanley for landing of Gerrit ACL patches and debugging PyPi uploads issues; Radomir Dopieralski and Tomas Sedovic for landing a quick fix to tuskar-ui. Thank you all guys, you've helped me a lot! Roman ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Robert Collins rbtcoll...@hp.com javascript:; Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0d4fea7e/attachment-0001.html -- Message: 3 Date: Wed, 6 Nov 2013 14:07:02 +0800 From: Sergey Lukjanov slukja...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [TripleO] Releases of this week Message-ID: d7ae8049-6442-49e1-875f-151edd356...@mirantis.com Content-Type: text/plain; charset=iso-8859-1 Here is the script for processing bug while releasing - https://github.com/ttx/openstack-releasing/blob/master/process_bugs.py Sincerely yours, Sergey Lukjanov Savanna Technical Lead Mirantis Inc. On Nov 6, 2013, at 1:42 PM, Roman Podoliaka rpodoly...@mirantis.com wrote: Hey, Oh, that's a pity. I didn't know that. Sure I'll update the doc and look for a way to automize the process. Roman On Wednesday, November 6, 2013, Robert Collins wrote: Awesome work - thank you!!! Can you please add to your docs though, that we need to go and close the bugs in the project (either via a script or by hand) - gerrit leaves them as Fix Committed today. Cheers, Rob On 2 November 2013 04:38, Roman Podoliaka rpodoly...@mirantis.com wrote: Hi all, This week I've been doing releases of all projects, which belong to TripleO program. Here are release notes you might be interested in: os-collect-config - 0.1.5 (was 0.1.4): - default polling interval was reduced to 30 seconds - requirements were updated to use the new iso8601 version fixing important bugs diskimage-builder - 0.0.9 (was 0.0.8) - added support for bad Fedora image mirrors (retry the request once on 404) - removed dependency on dracut-network from fedora element - fixed the bug with removing of lost+found dir if it's not found tripleo-image-elements - 0.1.0 (was 0.0.4) - switched to tftpd-hpa on Fedora and Ubuntu - made it possible to disable file injection in Nova - switched seed vm to Neutron native PXE - added Fedora support to apache2 element - fixed processing of routes in init-neutron-ovs - fixed Heat watch server url key name in seed vm metadata tripleo-heat-templates - 0.1.0 (was 0.0.1) - disabled Nova Baremetal file injection (undercloud) - made LaunchConfiguration resources mergeable - made neutron public interface configurable (overcloud) - made it possible to set public interface IP (overcloud) - allowed making the public interface a VLAN (overcloud) - added a wait condition for signalling that overcloud is ready - added metadata for Nova floating-ip extension - added tuskar API service configuration - hid AdminToken in Heat templates - added Ironic service configuration tuskar - 0.0.2 (was 0.0.1) - made it possible to pass Glance image id - fixed the bug with duplicated Resource Class names tuskar-ui - 0.0.2 (was 0.0.1) - resource class creation form no longer ignores the image selection - separated flavors creation step - fail gracefully on node detail page when no overcloud - added validation of MAC addresses and CIDR values - stopped appending Resource Class name to Resource Class flavors - fixed JS warnings when $ is not available - fixed links and naming in Readme - various code and test fixes (pep8, refactoring) python-tuskarclient - 0.0.2 (was 0.0.1) - fixed processing of 301 response code os-apply-config and os-refresh-config haven't had new commits since the last release This also means that: 1. We are now releasing all the projects we have. 2. *tuskar* projects have got PyPi
Re: [openstack-dev] Bad review patterns
+1 Regards -Harshad On Nov 6, 2013, at 12:36 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: Hello, I'm quite new in the OpenStack project, but I love it already. What is especially nifty is the automated review system -- I'm really impressed. I'm coming from a project in which we also did reviews of every change -- although it was mostly manual, and just one review was enough to merge -- and at some point in that project I noticed that it is very easy to give reviews that are unhelpful, frustrating and just get in the way of the actual work. I started paying attention to how I am reviewing code, and I managed to come up with several patterns that are bad. Once I know the patterns, it's easier to recognize when I'm doing something wrong and rethink the review. I would like to share the patterns that I noticed. Not sure if that works... = You see some suspicious piece of code, and you are not sure if it is correct or not. So you point it out in the review and -1 it, demanding that the author rechecks it and/or prove that it indeed works. It's your job as a reviewer to check such things, don't put all the effort on the author. They probably already checked that this code works, and possibly have even written tests for it. If you are not familiar with the technology enough to tell whether it's good or not, and have no means of testig it yourself, you shouldn't be reviewing it. If you do have the means to test it or can find the piece of documentation that says that it shouldn't be done -- do it as a part of the review. You ain't gonna need it. The code contains some parts that are potentially reusable later or in different areas, so you -1 it and tell the author to move them into reusable functions. The fact that you think something is reusable doesn't necessarily mean it is, and overly general code is harder to maintain. Let something repeat a couple of times just to be sure it actually is reusable. Once you find a repeating pattern, you can refactor the code to use a generalized function in its place -- in a separate change. There is an old bug here. = While you review the submitted code, you notice something wrong in the code not immediately related to the change you are reviewing. You -1 the change and tell the author to fix that bug, or formatting issue, or typo, or whatever. That fix has nothing to do with the change you are reviewing. The correct thing to do is to make a mental note of it, and fix it in a separate change -- possibly even finding more instances of it or coming up with a much better fix after seeing more code. Guess what I mean. == You notice a pep8 violation, or pep257 violation, or awkward wording of a comment or docstring, or a clumsy piece of code. You -1 the change and just tell author to fix it. It's not so easy to guess what you mean, and in case of a clumsy piece of code, not even that certain that better code can be used instead. So always provide an example of what you would rather want to see. So instead of pointing to indentation rules, just show properly indented code. Instead of talking about grammar or spelling, just type the corrected comment or docstring. Finally, instead of saying use list comprehension here or don't use has_key, just type your proposal of how the code should look like. Then we have something concrete to talk about. Of course, you can also say why you think this is better, but an example is very important. If you are not sure how the improved code would look like, just let it go, chances are it would look even worse. Not a complete fix. === The code fixes some problems (for example, fixes formatting and enables some flake8 checks), but leaves some other, related problems still not fixed. You -1 it and demand that the author adds fixes for the related problem. Don't live your coding career through the authors. If their fix is good and correct and improves the code, let it in, even if you see more opportunities to improve it. You can add those additional fixes yourself in a separate change. Or, if you don't have time or skill to do that, report a bug about the remaining problems and someone else will do it, but don't hold the author hostage with your review because you think he didn't do enough. Leaving a mark. === You review a change and see that it is mostly fine, but you feel that since you did so much work reviewing it, you should at least find *something* wrong. So you find some nitpick and -1 the change just so that they know you reviewed it. This is quite obvious. Just don't do it. It's OK to spend an hour reviewing something, and then leaving no comments on it, because it's simply fine, or because we had to means to test someting (see the first pattern). Those are the things I'm careful about myself. I'm
[openstack-dev] [swift] what does swift do if the auditor find that all 3 replicas are corrupt?
Hi, I have a question about swift: what does swift do if the auditor find that all 3 replicas are corrupt? will it notify the owner of the object(email to the account owner)? what will happen if the GET request to the corrupted object? will it return a special error telling that all the replicas are corrupted? Or will it just say that the object is not exist? Or it just return one of the corrupted replica? Or something else? Thanks very much for your help. -Daniel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Swift multinode installation add repository
Dear all, I am trying to install Swift in a distributed multinode environment consisiting of 1 Proxy node and 5 Storage nodes. I am following the tutorial: http://docs.openstack.org/developer/swift/howto_installmultinode.html I have a problem adding the swift-core repository: add-apt-repository ppa:swift-core/release Error: can't find signing_key_fingerprint at https://launchpad.net/api/1.0/~swift-core/+archive/release and then I cannot install Swift because it does not find the repository. How can I solve this problem? Thank you very much. Best regards, Gerard Marin ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] How to add a comment to a change review?
Can someone enlighten me as to how I can add a comment to one of my own changes on review.openstack.org. I suppose it's mind numbingly obvious but here for examplehttps://review.openstack.org/#/c/51263/11I just cannot see how to add a comment. It says here: https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures Leave a comment on the review referencing the bug causing the transient failure (not the bug you're attempting to fix with your patch): To re-run the check jobs (before a change has been approved), leave a comment with the form recheck bug . To re-run the gate jobs (after a change has been approved), leave a comment with the form reverify bug . It must be so obvious ... Thanks in advance, Mike. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to add a comment to a change review?
You just click the review button under the change list on Gerrit. It should then take you to a screen where you can see inline comments waiting to be added and enter an overall comment as well. The comment system in Gerrit really should be a bit more intuitive. Best Regards, Solly Ross - Original Message - From: Michael Bright mjbrigh...@gmail.com To: openstack-dev@lists.openstack.org Sent: Wednesday, November 6, 2013 11:34:27 AM Subject: [openstack-dev] How to add a comment to a change review? Can someone enlighten me as to how I can add a comment to one of my own changes on review.openstack.org . I suppose it's mind numbingly obvious but here for example I just cannot see how to add a comment. It says here: https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures Leave a comment on the review referencing the bug causing the transient failure (not the bug you're attempting to fix with your patch): To re-run the check jobs (before a change has been approved), leave a comment with the form recheck bug . To re-run the gate jobs (after a change has been approved), leave a comment with the form reverify bug . It must be so obvious ... Thanks in advance, Mike. ___ 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] How to add a comment to a change review?
Thanks Solly! On 6 November 2013 17:42, Solly Ross sr...@redhat.com wrote: You just click the review button under the change list on Gerrit. It should then take you to a screen where you can see inline comments waiting to be added and enter an overall comment as well. The comment system in Gerrit really should be a bit more intuitive. Best Regards, Solly Ross - Original Message - From: Michael Bright mjbrigh...@gmail.com To: openstack-dev@lists.openstack.org Sent: Wednesday, November 6, 2013 11:34:27 AM Subject: [openstack-dev] How to add a comment to a change review? Can someone enlighten me as to how I can add a comment to one of my own changes on review.openstack.org . I suppose it's mind numbingly obvious but here for example I just cannot see how to add a comment. It says here: https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures Leave a comment on the review referencing the bug causing the transient failure (not the bug you're attempting to fix with your patch): To re-run the check jobs (before a change has been approved), leave a comment with the form recheck bug . To re-run the gate jobs (after a change has been approved), leave a comment with the form reverify bug . It must be so obvious ... Thanks in advance, Mike. ___ 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] [Openstack] [Neutron] Security groups issue when running latest libvirt?
Answering myself as I investigated a little further and cross-posting to
openstack-dev because I'd like to get feedback from Nova/Neutron devs.
Users running Havana should configure
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver.
This driver is still available in the Havana release although
deprecated. AFAIU, this is the only option if you want effective
security groups with KVM OVS.
For people using the master branch of nova, sorry but security groups
are currently broken because LibvirtHybridOVSBridgeDriver is gone ([0]).
Joe Gordon asked the Neutron devs about it few weeks ago [1] but no
answer and in another review [2], the conclusion was that the Tempest
tests passed with Neutron. However I don't see anywhere in the tests
([3], [4]) that we check if the security rules allow/block traffic.
It would be nice if core devs could confirm or refute.
Regards,
Simon
[0] https://review.openstack.org/#/c/49660/
[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-October/016886.html
[2] https://review.openstack.org/#/c/44349
[3]
https://github.com/openstack/tempest/blob/master/tempest/api/network/test_security_groups.py
[4]
https://github.com/openstack/tempest/blob/master/tempest/api/network/test_security_groups_negative.py
Le 05/11/2013 14:57, Simon Pasquier a écrit :
Hi all,
I'm struggling with security groups on Havana with Neutron and OVS
plugin (GRE tunnels). No problem to create/delete security group rules
but even though iptables configuration is updated, traffic to my
instances is never filtered [0].
I'm running DevStack on 2 nodes (1 controller + 1 compute):
- OS: Ubuntu 12.04.3 (LTS) with the Havana cloud archive repository.
- Open vSwitch package version: 1.10.2-0ubuntu2~cloud0
- libvirt package version: 1.1.1-0ubuntu8~cloud2
- localrc, nova.conf, neutron.conf and ovs_neutron_plugin.ini files
pasted at [1] (I didn't modify any of these files after the DevStack run)
According to [2], [3] and [4], iptables is not compatible with TAP
devices connectd directly to Open vSwitch ports, this is why there used
to be the additional veth + bridge interfaces [5]. But in my setup, this
is not the case anymore as shown in [6] ('ovs-vsctl show' +
'iptables-save' ouptut). I've also pasted the libvirt XML configuration
[7] that shows that the instance is directly connected to the Open vSwitch.
Are the security groups supposed to work when the instance is directly
connected to OVS? If yes, what am I doing wrong?
Regards,
[0] http://paste.openstack.org/show/50490/
[1] http://paste.openstack.org/show/50448/
[2] http://www.spinics.net/linux/fedora/libvirt-users/msg05384.html
[3] http://openvswitch.org/pipermail/discuss/2013-October/011461.html
[4]
http://docs.openstack.org/havana/config-reference/content/under_the_hood_openvswitch.html
[5]
http://docs.openstack.org/havana/config-reference/content/figures/7/a/a/common/figures/under-the-hood-scenario-2-ovs-compute.png
[6] http://paste.openstack.org/show/50486/
[7] http://paste.openstack.org/show/50487/
--
Simon Pasquier
Software Engineer
Bull, Architect of an Open World
Phone: + 33 4 76 29 71 49
http://www.bull.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Bad review patterns
On Wed, Nov 6, 2013 at 2:34 AM, Radomir Dopieralski openst...@sheep.art.plwrote: Hello, I'm quite new in the OpenStack project, but I love it already. What is especially nifty is the automated review system -- I'm really impressed. I'm coming from a project in which we also did reviews of every change -- although it was mostly manual, and just one review was enough to merge -- and at some point in that project I noticed that it is very easy to give reviews that are unhelpful, frustrating and just get in the way of the actual work. I started paying attention to how I am reviewing code, and I managed to come up with several patterns that are bad. Once I know the patterns, it's easier to recognize when I'm doing something wrong and rethink the review. I would like to share the patterns that I noticed. Agreed on all points. I think Gerrit is nice in that it automates a lot of stuff, but unfortunately the workflow has not encouraged the best behavior for reviewers. This is a good list to follow -- but how can we be sure people will? This mailing list thread will only be seen by a small number of reviewers over the life of the project, I'm sure. -- IRC: radix Christopher Armstrong Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to skip certain unit tests?
On Wed, Oct 30, 2013 at 7:02 PM, Vijay B os.v...@gmail.com wrote: Hi, How can we skip certain unit tests when running run_tests.sh? I'm looking at the Openstack unit test page If it's not too late you may skip tests with testr/run_tests.sh. List all tests using testr store in a file, exclude the tests and feed the file that has tests to execute to run_tests.sh script. Something in these lines, assuming you use venv ... . .venv/bin/activate testr list-tests | egrep -v 'exclude_test1|exclude_test2' execute-tests deactivate ./run_tests.sh -- --load-list=execute-tests -- Regards, Bhuvan Arumugam www.livecipher.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Bad review patterns
All the points sound quite reasonable. I agree with Chris, the more reviewers read this, the better will be our review quality. Do we have some kind of reviewing guide?, if we don't this could be an start. -- irc: ajo / mangelajo Miguel Angel Ajo Pelayo +34 636 52 25 69 skype: ajoajoajo 2013/11/6 Christopher Armstrong chris.armstr...@rackspace.com On Wed, Nov 6, 2013 at 2:34 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: Hello, I'm quite new in the OpenStack project, but I love it already. What is especially nifty is the automated review system -- I'm really impressed. I'm coming from a project in which we also did reviews of every change -- although it was mostly manual, and just one review was enough to merge -- and at some point in that project I noticed that it is very easy to give reviews that are unhelpful, frustrating and just get in the way of the actual work. I started paying attention to how I am reviewing code, and I managed to come up with several patterns that are bad. Once I know the patterns, it's easier to recognize when I'm doing something wrong and rethink the review. I would like to share the patterns that I noticed. Agreed on all points. I think Gerrit is nice in that it automates a lot of stuff, but unfortunately the workflow has not encouraged the best behavior for reviewers. This is a good list to follow -- but how can we be sure people will? This mailing list thread will only be seen by a small number of reviewers over the life of the project, I'm sure. -- IRC: radix Christopher Armstrong Rackspace ___ 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] Review please
Hi all, Could someone review https://review.openstack.org/53538, please? It has already timed out once due to a -1 (addressed in comments, but the comment author never responded or removed it). It's a trivial bugfix and it about to be auto-abandoned again in two days. Regards, Stanisław Pitucha Cloud Services Hewlett Packard 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] [Neutron] IPv6 sub-team?
+1 we are in process of designing/implementing this and want to be part of the community effort. On Nov 5, 2013, at 3:50 PM, Collins, Sean (Contractor) sean_colli...@cable.comcast.com wrote: Hi, Is there any interest in organizing a IPv6 sub-team, similar to how there are sub-teams for FwaaS, VPNaas, ML2, etc? -- Sean M. Collins AIM: seanwdp ___ 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] [swift] what does swift do if the auditor find that all 3 replicas are corrupt?
On 11/6/13 7:12 AM, Daniel Li wrote: Hi, I have a question about swift: what does swift do if the auditor find that all 3 replicas are corrupt? will it notify the owner of the object(email to the account owner)? what will happen if the GET request to the corrupted object? will it return a special error telling that all the replicas are corrupted? Or will it just say that the object is not exist? Or it just return one of the corrupted replica? Or something else? If all 3 (or N) replicas are corrupt, then the auditors will eventually quarantine all of them, and subsequent GET requests will receive 404 responses. No notifications are sent, nor is it really feasible to start sending them. The auditor is not a single process; there is one Swift auditor process running on each node in a cluster. Therefore, when an object is quarantined, there's no way for its auditor to know if the other copies are okay or not. Note that this is highly unlikely to ever happen, at least with the default of 3 replicas. When an auditor finds a corrupt object, it quarantines it (moves it to a quarantines directory). Then, since that object is missing, the replication processes will recreate the object by copying it from a node with a good copy. You'd need to have all replicas become corrupt within a very short timespan so that the replicators don't get a chance to replace the damaged ones. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Bad review patterns
This definitely should be somewhere in wiki or blog and in the bookmarks. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Bad review patterns
How about putting it on a wiki and linking it from the top bar of gerrit itself? (call it review guidelines for example) That way, even people who didn't look for it explicitly could find it. Regards, Stanisław Pitucha Cloud Services Hewlett Packard -Original Message- From: Sergey Skripnick [mailto:sskripn...@mirantis.com] Sent: Wednesday, November 06, 2013 6:50 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Bad review patterns This definitely should be somewhere in wiki or blog and in the bookmarks. ___ 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] Bad review patterns
Great thread and very insightful. Yes; please make this more accessible to other reviewers. Adding this to the wiki is a great start. Andrew Mirantis On Wed, Nov 6, 2013 at 11:05 AM, Pitucha, Stanislaw Izaak stanislaw.pitu...@hp.com wrote: How about putting it on a wiki and linking it from the top bar of gerrit itself? (call it review guidelines for example) That way, even people who didn't look for it explicitly could find it. Regards, Stanisław Pitucha Cloud Services Hewlett Packard -Original Message- From: Sergey Skripnick [mailto:sskripn...@mirantis.com] Sent: Wednesday, November 06, 2013 6:50 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Bad review patterns This definitely should be somewhere in wiki or blog and in the bookmarks. ___ 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 -- If google has done it, Google did it right! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Bad review patterns
Well said. This will encourage new developers. On Wed, Nov 6, 2013 at 11:26 AM, Andrew Woodward xar...@gmail.com wrote: Great thread and very insightful. Yes; please make this more accessible to other reviewers. Adding this to the wiki is a great start. Andrew Mirantis On Wed, Nov 6, 2013 at 11:05 AM, Pitucha, Stanislaw Izaak stanislaw.pitu...@hp.com wrote: How about putting it on a wiki and linking it from the top bar of gerrit itself? (call it review guidelines for example) That way, even people who didn't look for it explicitly could find it. Regards, Stanisław Pitucha Cloud Services Hewlett Packard -Original Message- From: Sergey Skripnick [mailto:sskripn...@mirantis.com] Sent: Wednesday, November 06, 2013 6:50 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Bad review patterns This definitely should be somewhere in wiki or blog and in the bookmarks. ___ 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 -- If google has done it, Google did it right! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ravi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] What key strings can we set in scheduler_hints param when boot an instance?
Hi all, I am using the nova python api and recently i need to use the filter schedule hint when i boot up an instance. In the novaclient.v1_1.client.Client.servers.create() method, there is a :param scheduler_hints: (optional extension) arbitrary key-value pairs specified by the client to help boot an instance which we can specify the key-value pairs to help boot an instance. However, i don't know what key string can I specify in my key-values pairs. I search online but did not get any information about that? Is there any document that list all the keystrings we can specify in the scheduler_hints? I would like to have a list of all the keys that we can specify in the scheduler_hints. Thanks a lot xin ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Bad review patterns
Hi!
I would like do disagree with some of the points.
First of all, '-1' mark may have a wrong perception especially among new
contributors.
-1 doesn't mean reviewers don't want your code (which is -2), it means they
either not sure it is good enough or they see how you could make it better.
Not sure if that works
If you as a reviewer have a gut feeling ('not sure') that it may not work -
put a -1.
Let submitter explain it to you. You can change your score later without
requiring to change the patch.
Also, there are plenty of cases when the code could not be tested because
it requires specific environment to run.
I think it's ok to put -1 in case of uncertainty. The only thing you should
care about is that such -1 is not 'finished' because you don't require
submitter to change anything, so you need to check if your concerns were
addressed and potentially change the score.
On point #2:
Let something repeat a couple of times just to be sure it actually is
reusable.
I think code repetition is not desirable in most of the cases and only
occasionally repeating code gets merged. That happens especially when
someone didn't put reusable code in a common place so others unaware of its
existance. Instead of doing refactoring later on (who will do this?) just
rely on reviewer's opinion and check if generalization could be done.
And this can grow as a snowball (oh, he has copy-pasted his stuff, why
shouldn't I do the same?) so the earlier it is caught - the better.
On other points: the patch is required to be self-consistent. It needs to
solve something that is stated in the bug/commit message and no more (and
hopefully not less) than that. So the scope really matters. I haven't see
much comments from reviewers requesting to make occasional fixes. Although
sometimes it make sense to ask for such, especially if they are related,
reasonable and the patch is going to be improved anyways (due to some other
issues). It also may happen that submitter has missed certain things that
also fall in the scope of the work he is doing.
Having said that, I believe that it's not very difficult to get through a
review where you get -1 for code style issues.
When you have your code, IDE, git and gerrit at your hands it is a matter
of minutes (hours rarely) to resolve those and resubmit.
The real issue with the review process is that reviewers should back up his
mark once they has put it and they not usually do that for various reasons.
The worst thing to do is to put -1 and go away without leaving a chance for
submitter to explain what he meant and wanted.
So once a reviewer started a review (put a mark) - it is his responsibility
to work further on this review.
Persistent -1 should indicate that reviewer and submitter could not agree
on fundamentals of the patch (design, workflow, etc), which, in turn,
means, that a discussion should be held within a community before the work
on the patch is continued.
Thanks,
Eugene.
On Wed, Nov 6, 2013 at 11:26 PM, Andrew Woodward xar...@gmail.com wrote:
Great thread and very insightful. Yes; please make this more
accessible to other reviewers. Adding this to the wiki is a great
start.
Andrew
Mirantis
On Wed, Nov 6, 2013 at 11:05 AM, Pitucha, Stanislaw Izaak
stanislaw.pitu...@hp.com wrote:
How about putting it on a wiki and linking it from the top bar of gerrit
itself? (call it review guidelines for example)
That way, even people who didn't look for it explicitly could find it.
Regards,
Stanisław Pitucha
Cloud Services
Hewlett Packard
-Original Message-
From: Sergey Skripnick [mailto:sskripn...@mirantis.com]
Sent: Wednesday, November 06, 2013 6:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Bad review patterns
This definitely should be somewhere in wiki or blog and in the bookmarks.
___
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
--
If google has done it, Google did it right!
___
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] Bad review patterns
On 6 November 2013 21:34, Radomir Dopieralski openst...@sheep.art.pl wrote: Hello, I'm quite new in the OpenStack project, but I love it already. What is especially nifty is the automated review system -- I'm really impressed. I'm coming from a project in which we also did reviews of every change -- although it was mostly manual, and just one review was enough to merge -- and at some point in that project I noticed that it is very easy to give reviews that are unhelpful, frustrating and just get in the way of the actual work. I started paying attention to how I am reviewing code, and I managed to come up with several patterns that are bad. Once I know the patterns, it's easier to recognize when I'm doing something wrong and rethink the review. I would like to share the patterns that I noticed. Thank you for this, very cool. I have two nits ;). Firstly, things like code duplication is a sliding scale, and I think it's ok for a reviewer to say 'these look similar, give it a go please'. If the reviewee tries, and it's no good - thats fine. But saying 'hey, I won't even try' - thats not so good. Many times we get drive-by patches and no follow up, so there is a learnt response to require full satisfaction with each patch that comes in. Regular contributors get more leeway here I think. Secondly, this: Leaving a mark. === You review a change and see that it is mostly fine, but you feel that since you did so much work reviewing it, you should at least find *something* wrong. So you find some nitpick and -1 the change just so that they know you reviewed it. Thats indeed not cool. Perhaps a 0 with the nitpick. On the other hand, perhaps the nitpick actually matters. If it's a nitpick it's going to be what - a couple minutes to fix and push ? ... I think the real concern is that by pushing it up again you go to the back of the queue for reviews, so maybe we should talk about that instead. We don't want backpressure on folk polishing a patch on request because of review latency. This is quite obvious. Just don't do it. It's OK to spend an hour reviewing something, and then leaving no comments on it, because it's simply fine, or because we had to means to test someting (see the first pattern). Core reviewers look for the /comments/ from people, not just the votes. A +1 from someone that isn't core is meaningless unless they are known to be a thoughtful code reviewer. A -1 with no comment is also bad, because it doesn't help the reviewee get whatever the issue is fixed. It's very much not OK to spend an hour reviewing something and then +1 with no comment: if I, and I think any +2er across the project see a patch that needs an hour of review, with a commentless +1, we'll likely discount the +1 as being meaningful. -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] [Solum]: Welcome to the community site for Solum !!
Brent, Thank you for putting together such a clear and thoughtful post. Your article was quoted and included on the Solum.io community site, and has inspired other new contributors as well. Viewpoints like yours help illustrate that this effort is really about working together to address common needs that we agree on and care about. We are proud to have you as part of our community and look forward to working closely with you. Adrian On Nov 6, 2013, at 2:26 AM, Brent Smithurst bre...@activestate.commailto:bre...@activestate.com wrote: This is great! I was waiting for the site to go live so I'd have a nice place to link our Why Would ActiveState Join Project Solum? blog post: http://www.activestate.com/blog/2013/11/why-would-activestate-join-openstacks-project-solum We're looking forward to this as it gains momentum. Brent On Mon, Nov 4, 2013 at 5:25 PM, Roshan Agrawal roshan.agra...@rackspace.commailto:roshan.agra...@rackspace.com wrote: The community site for Solum has gone live! www.Solum.iohttp://www.solum.io/ - this is a landing page for all things Solum related. Also check out the blog section on the site. The logo: is a placeholder for now. We are working on a cool new logo - but the placeholder right now isn't too bad either, is it? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] A Tool for Making OpenStack Log Reading a Bit Easier
First, very cool tool, nice work! I wonder if it's reasonable (or interesting) to take these approaches and bring them into os-loganalyze. That would mean there was common parsing routines, and then we would just call out to different functions if were were trying to do HTML or ANSI coloring. I personally live so often off the weblogs that I honestly hadn't thought about the local case, which would be definitely interesting. It would also be really great if adding semantics to one use did it for the other as well, so people would see the same output when they were looking at test failures as when they were doing local development. If you are interested in trying to join efforts there, let me know. On Wed, Nov 6, 2013 at 9:36 AM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Nov 6, 2013 at 9:10 AM, Clint Byrum cl...@fewbar.com wrote: I often use ccze to look at logs. It has some built in things like coloring the words warn or warning yellow and error red. It would be great to have this filter added as another ccze plugin. Sean Dague, wrote a really slick tool for logs.openstack.org that is similar: http://git.openstack.org/cgit/openstack-infra/os-loganalyze/tree/README.rst http://logs.openstack.org/98/54198/7/check/check-tempest-devstack-vm-neutron/a153156/logs/screen-q-svc.txt.gz?level=TRACE Excerpts from Solly Ross's message of 2013-11-06 05:58:02 +0800: Hello All, The other day, I was reading through a debug-level OpenStack log, and came to the realization that reading OpenStack debug-level logs was difficult, to say the least -- they can be very busy, and it is hard to quickly filter out relevant information. Thus, I wrote a little Perl script to make reading dense debug-level logs a bit easier: https://github.com/DirectXMan12/os_log_prettifier. I figured that I'd share it with other people. Basically, the script highlights certain key details using color and bolding (via ANSI control codes), and can filter lines based on subject (in the form of 'x.y.z') or message type, using regular expressions. I hope people find it useful! Best Regards, Solly Ross ___ 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 -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Code Review (Jenkins-job-builder, BlameUpstreamCommitters plugin support)
Hi Peter, Could you explain more about the scenario this plugin fits in existing openstack jenkins jobs? I haven't seen any jobs with upstream , except devstack-gate related slave usage status transition jobs, which are already superseded by nodepool. IRC channel openstack-infra and mailing list openstack-infra are also better way to get infra core reviewers' attention, but you probably have to wait since most of them are in the summit right now. On Wed, Nov 6, 2013 at 1:47 AM, Peter Liljenberg pliljenb...@gmail.comwrote: Hi, Could someone review this please: https://review.openstack.org/#/c/54085/ Regards, Peter ___ 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] RFC: reverse the default Gerrit sort order
I've been thinking about review queues recently (since here at the summit everyone is talking about reviews! :)). One thing that struck me today was that Gerrit makes it easier to review the newest changes first, rather than the changes that have been in the queue longest, or the changes that started going through the review process first. So... is it possible to change the default sort order for Gerrit? How hard is it to do - could we do an experiment on that and see if it nudges the dial for reviewstats (just make the change, not ask anyone to change their behaviour)? As for what sort order to choose, I'd be happy just getting data on a different default sort order - it seems like the easiest thing would be to reverse the current order, vs doing something more sophisticated. If folk are about to jump up and say 'hey, reviewday' or 'hey next-review' : I specifically want to see what the effect on changing the Gerrit web UI is, because my sense is that that is the default place folk do reviews, and I want to change the default-experience folk have, not the optional experience folk can opt into. -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] Bad review patterns
-Original Message- From: Robert Collins [mailto:robe...@robertcollins.net] Sent: 06 November 2013 22:08 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Bad review patterns On 6 November 2013 21:34, Radomir Dopieralski openst...@sheep.art.pl wrote: Hello, Secondly, this: Leaving a mark. === You review a change and see that it is mostly fine, but you feel that since you did so much work reviewing it, you should at least find *something* wrong. So you find some nitpick and -1 the change just so that they know you reviewed it. Thats indeed not cool. Perhaps a 0 with the nitpick. On the other hand, perhaps the nitpick actually matters. If it's a nitpick it's going to be what - a couple minutes to fix and push ? ... I think the real concern is that by pushing it up again you go to the back of the queue for reviews, so maybe we should talk about that instead. We don't want backpressure on folk polishing a patch on request because of review latency. This is quite obvious. Just don't do it. It's OK to spend an hour reviewing something, and then leaving no comments on it, because it's simply fine, or because we had to means to test someting (see the first pattern). Core reviewers look for the /comments/ from people, not just the votes. A +1 from someone that isn't core is meaningless unless they are known to be a thoughtful code reviewer. A -1 with no comment is also bad, because it doesn't help the reviewee get whatever the issue is fixed. It's very much not OK to spend an hour reviewing something and then +1 with no comment: if I, and I think any +2er across the project see a patch that needs an hour of review, with a commentless +1, we'll likely discount the +1 as being meaningful. I don't really get what you're saying here Rob. It seems to me an almost inevitable part of the review process that useful comments are going to be mostly negative. If someone has invested that amount of effort because the patch is complex, or It took then a while to work their way back into that part of the systems, etc, but having given the code careful consideration they decide it's good - do you want comments in there saying I really like your code, Well done on fixing such a complex problem or some such ? I just don't see how you can use a lack or presence of positive feedback in a +1 as any sort of indication on the quality of that +1. Unless you start asking reviewers to précis the change in their own words to show that they understood it I don't really see how additional positive comments help in most cases. Perhaps if you have some specific examples of this it would help to clarify Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Nova SSL Apache2 Question
Hello, I am trying to front all of the Grizzly OpenStack services with Apache2 in order to enable SSL. I've got Horizon and Keystone working but am struggling with Nova. The only documentation I have been able to find is at URL http://www.rackspace.com/blog/enabling-ssl-for-the-openstack-api/ However, the Nova sample osapi.wsgi and osapi files are not working with Grizzly. Does anyone have a set of these files for Nova? Thanks, Mark Miller ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Nova SSL Apache2 Question
Hi Mark, try this and let us know. http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/installing-openstack-dashboard.html Anne Gentle Content Stacker a...@openstack.org On Nov 7, 2013, at 8:20 AM, Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.com wrote: Hello, I am trying to front all of the Grizzly OpenStack services with Apache2 in order to enable SSL. I've got Horizon and Keystone working but am struggling with Nova. The only documentation I have been able to find is at URL http://www.rackspace.com/blog/enabling-ssl-for-the-openstack-api/ However, the Nova sample osapi.wsgi and osapi files are not working with Grizzly. Does anyone have a set of these files for Nova? Thanks, Mark Miller ___ 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] [Openstack] [Neutron] Security groups issue when running latest libvirt?
That is true... Back to LibvirtHybridOVSBridgeDriver, Security Groups is
working again...
On 6 November 2013 15:03, Simon Pasquier simon.pasqu...@bull.net wrote:
Answering myself as I investigated a little further and cross-posting to
openstack-dev because I'd like to get feedback from Nova/Neutron devs.
Users running Havana should configure libvirt_vif_driver=nova.virt.
libvirt.vif.LibvirtHybridOVSBridgeDriver.
This driver is still available in the Havana release although deprecated.
AFAIU, this is the only option if you want effective security groups with
KVM OVS.
For people using the master branch of nova, sorry but security groups are
currently broken because LibvirtHybridOVSBridgeDriver is gone ([0]). Joe
Gordon asked the Neutron devs about it few weeks ago [1] but no answer and
in another review [2], the conclusion was that the Tempest tests passed
with Neutron. However I don't see anywhere in the tests ([3], [4]) that we
check if the security rules allow/block traffic.
It would be nice if core devs could confirm or refute.
Regards,
Simon
[0] https://review.openstack.org/#/c/49660/
[1] http://lists.openstack.org/pipermail/openstack-dev/2013-
October/016886.html
[2] https://review.openstack.org/#/c/44349
[3] https://github.com/openstack/tempest/blob/master/tempest/
api/network/test_security_groups.py
[4] https://github.com/openstack/tempest/blob/master/tempest/
api/network/test_security_groups_negative.py
Le 05/11/2013 14:57, Simon Pasquier a écrit :
Hi all,
I'm struggling with security groups on Havana with Neutron and OVS
plugin (GRE tunnels). No problem to create/delete security group rules
but even though iptables configuration is updated, traffic to my
instances is never filtered [0].
I'm running DevStack on 2 nodes (1 controller + 1 compute):
- OS: Ubuntu 12.04.3 (LTS) with the Havana cloud archive repository.
- Open vSwitch package version: 1.10.2-0ubuntu2~cloud0
- libvirt package version: 1.1.1-0ubuntu8~cloud2
- localrc, nova.conf, neutron.conf and ovs_neutron_plugin.ini files
pasted at [1] (I didn't modify any of these files after the DevStack run)
According to [2], [3] and [4], iptables is not compatible with TAP
devices connectd directly to Open vSwitch ports, this is why there used
to be the additional veth + bridge interfaces [5]. But in my setup, this
is not the case anymore as shown in [6] ('ovs-vsctl show' +
'iptables-save' ouptut). I've also pasted the libvirt XML configuration
[7] that shows that the instance is directly connected to the Open
vSwitch.
Are the security groups supposed to work when the instance is directly
connected to OVS? If yes, what am I doing wrong?
Regards,
[0] http://paste.openstack.org/show/50490/
[1] http://paste.openstack.org/show/50448/
[2] http://www.spinics.net/linux/fedora/libvirt-users/msg05384.html
[3] http://openvswitch.org/pipermail/discuss/2013-October/011461.html
[4]
http://docs.openstack.org/havana/config-reference/content/under_the_hood_
openvswitch.html
[5]
http://docs.openstack.org/havana/config-reference/
content/figures/7/a/a/common/figures/under-the-hood-
scenario-2-ovs-compute.png
[6] http://paste.openstack.org/show/50486/
[7] http://paste.openstack.org/show/50487/
--
Simon Pasquier
Software Engineer
Bull, Architect of an Open World
Phone: + 33 4 76 29 71 49
http://www.bull.com
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
openstack
Post to : openst...@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
openstack
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Nova SSL Apache2 Question
Hi Anne, Thanks for the pointer but I am looking for directions for Nova running on a different node than the rest of OpenStack so it needs to be standalone. Mark -Original Message- From: Anne Gentle [mailto:annegen...@justwriteclick.com] Sent: Wednesday, November 06, 2013 4:41 PM To: OpenStack Development Mailing List (not for usage questions) Cc: OpenStack Development Mailing List; openstack...@lists.openstack.org Subject: Re: [openstack-dev] Nova SSL Apache2 Question Hi Mark, try this and let us know. http://docs.openstack.org/grizzly/openstack- compute/install/yum/content/installing-openstack-dashboard.html Anne Gentle Content Stacker a...@openstack.org On Nov 7, 2013, at 8:20 AM, Miller, Mark M (EB SW Cloud - RD - Corvallis) mark.m.mil...@hp.com wrote: Hello, I am trying to front all of the Grizzly OpenStack services with Apache2 in order to enable SSL. I've got Horizon and Keystone working but am struggling with Nova. The only documentation I have been able to find is at URL http://www.rackspace.com/blog/enabling-ssl-for-the-openstack-api/ However, the Nova sample osapi.wsgi and osapi files are not working with Grizzly. Does anyone have a set of these files for Nova? Thanks, Mark Miller ___ 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] [Solum]: Workshop dates at SFO
Folks, some of us indicated they cannot make Nov 19,20, so I created a doodle poll to finalize a date that works for most of us. Please take a moment to indicate your preference on the doodle link below - http://www.doodle.com/6yey9nfgfapzv4f8 Please get this done by EOD if you can. Thanks, Roshan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Bad review patterns
On Wed, Nov 6, 2013 at 7:21 PM, Day, Phil philip@hp.com wrote: Leaving a mark. === You review a change and see that it is mostly fine, but you feel that since you did so much work reviewing it, you should at least find *something* wrong. So you find some nitpick and -1 the change just so that they know you reviewed it. This is quite obvious. Just don't do it. It's OK to spend an hour reviewing something, and then leaving no comments on it, because it's simply fine, or because we had to means to test someting (see the first pattern). Another one that comes into this category is adding a -1 which just says I agree with the other -1's in here. If you have some additional perspective and can expand on it then that's fine - otherwise it adds very little and is just review count chasing. It's an unfortunate consequence of counting and publishing review stats that having such a measure will inevitable also drive behavour. I agree that having no comment with a +1 is OK. If I think the code looks good I'll +1 it. If I think the code could be better I'll -1 it and leave comments. I don't think that leaving a -1 with a 'what they said' comment is a bad thing. As the developer writing the patch it's helpful to know there is a consensus and it's not just one person requesting a change. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek www: http://dstanek.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum]: Workshop dates at SFO
Some of us have already booked travel? On Nov 7, 2013, at 10:46 AM, Roshan Agrawal roshan.agra...@rackspace.com wrote: Folks, some of us indicated they cannot make Nov 19,20, so I created a doodle poll to finalize a date that works for most of us. Please take a moment to indicate your preference on the doodle link below - http://www.doodle.com/6yey9nfgfapzv4f8 Please get this done by EOD if you can. Thanks, Roshan ___ 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] RE : [Nova] [Climate] Reservation service called Climate
Being at my first summit, I haven't noticed there were Nova unconference timeslots for discussing various stuff. My bad. I proposed tomorrow 1.50pm to discuss around the reservation service itself and how we plan to use host aggregates (or pclouds) for our needs. -Sylvain De : Sylvain Bauza [sylvain.ba...@bull.net] Date d'envoi : mercredi 6 novembre 2013 10:47 À : openstack-dev@lists.openstack.org Objet : [openstack-dev] [Nova] [Climate] Reservation service called Climate Hi, During the Design session https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API we discussed the fact that this is not the role of Nova for doing atomic reservations in order to ensure the user needs will be met. I raised the point (and sorry for my bad accent, was stressy) that we're already trying to provide a reservation system for Openstack, called Climate (a Stackforge project). I would really like to discuss with you all, Nova community, about the reservation system and ensure that we, at Climate, are on the good path. Climate is planning to reserve both virtual instances and physical hosts, but for the discussion we had, only physical hosts usecase is relevant. We had an unconference session today at 2pm, I can share you the slides : https://docs.google.com/presentation/d/1BJGmtzGees6tg_Np7JuKFtuLGiCaguVYD8hYJ2eVKAc/edit#slide=id.p (please focus on slides 11-14, they're talking on the design for host reservations) All the code is located on Stackforge, but please note the most important part of physical host reservations is still under review there : https://review.openstack.org/#/q/project:+stackforge/climate+status:open,n,z (We're missing reviewers, by the way !) I'm open to discuss and waiting your thoughts, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] RE : [Nova] [Climate] Reservation service called Climate
I think that's some kind of typo in https://etherpad.openstack.org/p/NovaIcehouseSummitUnconference - there is 1:30 PM time there for the Friday. On Thu, Nov 7, 2013 at 12:13 PM, Sylvain Bauza sylvain.ba...@bull.netwrote: Being at my first summit, I haven't noticed there were Nova unconference timeslots for discussing various stuff. My bad. I proposed tomorrow 1.50pm to discuss around the reservation service itself and how we plan to use host aggregates (or pclouds) for our needs. -Sylvain -- *De :* Sylvain Bauza [sylvain.ba...@bull.net] *Date d'envoi :* mercredi 6 novembre 2013 10:47 *À :* openstack-dev@lists.openstack.org *Objet :* [openstack-dev] [Nova] [Climate] Reservation service called Climate Hi, During the Design session https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API we discussed the fact that this is not the role of Nova for doing atomic reservations in order to ensure the user needs will be met. I raised the point (and sorry for my bad accent, was stressy) that we're already trying to provide a reservation system for Openstack, called Climate (a Stackforge project). I would really like to discuss with you all, Nova community, about the reservation system and ensure that we, at Climate, are on the good path. Climate is planning to reserve both virtual instances and physical hosts, but for the discussion we had, only physical hosts usecase is relevant. We had an unconference session today at 2pm, I can share you the slides : https://docs.google.com/presentation/d/1BJGmtzGees6tg_Np7JuKFtuLGiCaguVYD8hYJ2eVKAc/edit#slide=id.p (please focus on slides 11-14, they're talking on the design for host reservations) All the code is located on Stackforge, but please note the most important part of physical host reservations is still under review there : https://review.openstack.org/#/q/project:+stackforge/climate+status:open,n,z (We're missing reviewers, by the way !) I'm open to discuss and waiting your thoughts, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] RE : [Nova] [Climate] Reservation service called Climate
I mean not in the ether pad, but in your letter :) It's 1:30, not 1:50 PM. On Thu, Nov 7, 2013 at 1:04 PM, Dina Belova dbel...@mirantis.com wrote: I think that's some kind of typo in https://etherpad.openstack.org/p/NovaIcehouseSummitUnconference - there is 1:30 PM time there for the Friday. On Thu, Nov 7, 2013 at 12:13 PM, Sylvain Bauza sylvain.ba...@bull.netwrote: Being at my first summit, I haven't noticed there were Nova unconference timeslots for discussing various stuff. My bad. I proposed tomorrow 1.50pm to discuss around the reservation service itself and how we plan to use host aggregates (or pclouds) for our needs. -Sylvain -- *De :* Sylvain Bauza [sylvain.ba...@bull.net] *Date d'envoi :* mercredi 6 novembre 2013 10:47 *À :* openstack-dev@lists.openstack.org *Objet :* [openstack-dev] [Nova] [Climate] Reservation service called Climate Hi, During the Design session https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API we discussed the fact that this is not the role of Nova for doing atomic reservations in order to ensure the user needs will be met. I raised the point (and sorry for my bad accent, was stressy) that we're already trying to provide a reservation system for Openstack, called Climate (a Stackforge project). I would really like to discuss with you all, Nova community, about the reservation system and ensure that we, at Climate, are on the good path. Climate is planning to reserve both virtual instances and physical hosts, but for the discussion we had, only physical hosts usecase is relevant. We had an unconference session today at 2pm, I can share you the slides : https://docs.google.com/presentation/d/1BJGmtzGees6tg_Np7JuKFtuLGiCaguVYD8hYJ2eVKAc/edit#slide=id.p (please focus on slides 11-14, they're talking on the design for host reservations) All the code is located on Stackforge, but please note the most important part of physical host reservations is still under review there : https://review.openstack.org/#/q/project:+stackforge/climate+status:open,n,z (We're missing reviewers, by the way !) I'm open to discuss and waiting your thoughts, -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Dina Belova Software Engineer Mirantis Inc. -- Best regards, Dina Belova Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum]: Workshop dates at SFO
Clayton, correct. We may end up sticking to the original dates; I wanted to arrive at the decision based on collective input. From: Clayton Coleman [ccole...@redhat.com] Sent: Wednesday, November 06, 2013 9:14 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum]: Workshop dates at SFO Some of us have already booked travel? On Nov 7, 2013, at 10:46 AM, Roshan Agrawal roshan.agra...@rackspace.com wrote: Folks, some of us indicated they cannot make Nov 19,20, so I created a doodle poll to finalize a date that works for most of us. Please take a moment to indicate your preference on the doodle link below - http://www.doodle.com/6yey9nfgfapzv4f8 Please get this done by EOD if you can. Thanks, Roshan ___ 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] [Mistral] Unconference track slides
Hi, A lot of people here in Hong Kong keep asking me to share the slides that I presented within Unconference track so here they are: http://www.slideshare.net/RenatAkhmerov/mistral-hong-kong-unconference-track Just in case if you just got familiar with Mistral here’s the project Launchpad page: launchpad.net/Mistral Please let us know if you’re interested in some particular things about Mistral, I’ll be happy to tell you everything. Thanks, Renat Akhmerov @ Mirantis Inc.___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Bad review patterns
On Thu, 2013-11-07 at 00:21 +, Day, Phil wrote: Leaving a mark. === You review a change and see that it is mostly fine, but you feel that since you did so much work reviewing it, you should at least find *something* wrong. So you find some nitpick and -1 the change just so that they know you reviewed it. This is quite obvious. Just don't do it. It's OK to spend an hour reviewing something, and then leaving no comments on it, because it's simply fine, or because we had to means to test someting (see the first pattern). Another one that comes into this category is adding a -1 which just says I agree with the other -1's in here. If you have some additional perspective and can expand on it then that's fine - otherwise it adds very little and is just review count chasing. It's an unfortunate consequence of counting and publishing review stats that having such a measure will inevitable also drive behavour. Perhaps a source of the problem is early voting. Feeling pressure to add a +/-1 (or even 2) without fully asking what's going on in the code leads to premature adjudication. For instance, I have to do a lot of reviews in SCSI; I'm a subject matter expert, so I do recognise some bad coding patterns and ask for them to be changed unconditionally, but a lot of the time I don't necessarily understand why the code was done in the way it was, so I ask. Before I get the answer I'm not really qualified to judge the merits. James ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Jenkins randomly fails?
Hi all, Please have a look at these two changes: https://review.openstack.org/#/c/55370/ https://review.openstack.org/#/c/55221/ The only change is to remove 4 duplicate definitions. I'm sure this will not cause any new problems, but it seems like the tests are randomly failing in jenkins. Could anyone tell me how to handle this? Thanks, Siming ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Bad review patterns
On Thu, Nov 07, 2013 at 12:21:38AM +, Day, Phil wrote: Leaving a mark. === You review a change and see that it is mostly fine, but you feel that since you did so much work reviewing it, you should at least find *something* wrong. So you find some nitpick and -1 the change just so that they know you reviewed it. This is quite obvious. Just don't do it. It's OK to spend an hour reviewing something, and then leaving no comments on it, because it's simply fine, or because we had to means to test someting (see the first pattern). Another one that comes into this category is adding a -1 which just says I agree with the other -1's in here. If you have some additional perspective and can expand on it then that's fine - otherwise it adds very little and is just review count chasing. I don't think that it is valueless as you describe. If I multiple people add '-1' with a same comments as name, then as a core reviewer I will consider that initial -1 to be a much stronger nack, than if only one person had added the -1. So I welcome people adding I agree with blah to any review. It's an unfortunate consequence of counting and publishing review stats that having such a measure will inevitable also drive behavour. IMHO what this shows is not people trying to game the stats, but rather the inadequacy of gerrit. We don't have any way to distinguish a -1 minor nice to have nitpick from a -1 serious code issue that is a must-fix. Adding a -2 is really too heavyweight because it is sticky, and implies do not ever merge this. It would be nice to be able to use '-2' for serious must-fix issue without it being sticky, and have a separate way for core reviewers to put an review into a block from being merged indefinitely state - perhaps a new state would be more useful eg a Blocked state, to add to New, Open, Merged, Abadoned. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] iso8601 filling up nova logs
My nova logs are full of this - is it ok if I make a change to the default log
level to set iso8601 to WARN?
2:39:54.683 DEBUG iso8601.iso8601 [-] Parsed 2013-11-06T06:38:00Z into
{'tz_sign': None, 'second_fraction': None, 'hour': u'06', 'tz_hour': None,
'month': u'11', 'timezone': u'Z', 'second': u'00', 'tz_minute': None, 'year':
u'2013', 'separator': u'T', 'day': u'06', 'minute': u'38'} with default
timezone iso8601.iso8601.Utc object at 0x2adcc90 from (pid=14941) parse_date
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:166
2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'2013' for 'year' with
default None from (pid=14941) to_int
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'11' for 'month' with
default None from (pid=14941) to_int
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'06' for 'day' with
default None from (pid=14941) to_int
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'06' for 'hour' with
default None from (pid=14941) to_int
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'38' for 'minute' with
default None from (pid=14941) to_int
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'00' for 'second' with
default None from (pid=14941) to_int
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.686 DEBUG iso8601.iso8601 [-] Parsed 2013-11-0
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Jenkins randomly fails?
Hi Siming, Yes there are some intermittent test failures which may be due to infrastructure and/or bugs. Here's my suggestion from recent experiences as a Noob. The e-mail you got from Jenkins includes this line, with a link telling you what to do: Build failed. For information on how to proceed, see https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures In your case, at least for https://review.openstack.org/#/c/55370/ it seems that the build system recognized the failure as likely being due to a known bug #1239637. You should check the failing log file, which you can access via the link given in the e-mail or on the above 55370 change page: - check-tempest-devstack-vm-neutron-pghttp://logs.openstack.org/70/55370/1/check/check-tempest-devstack-vm-neutron-pg/6d4cc81 FAILURE in 18m 27s to verify that this is indeed the same bug which has caused your build to fail. If this is the case, you can click on the Review button (for your patch set) and set Code to 0, add a comment (Cover Message): Recheck bug #x that's Recheck bug #1239637 in your case (the bug number suggested by the Elastic recheck). Hopefully that will pass. I hope this helps, I'm learning too ... Regards, Mike. On 7 November 2013 08:09, Siming Yin sael...@gmail.com wrote: Hi all, Please have a look at these two changes: https://review.openstack.org/#/c/55370/ https://review.openstack.org/#/c/55221/ The only change is to remove 4 duplicate definitions. I'm sure this will not cause any new problems, but it seems like the tests are randomly failing in jenkins. Could anyone tell me how to handle this? Thanks, Siming ___ 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
