Hi Kanika, Regarding : Facing issue in creating router in openstack dashboard (Kanika Saklani)
if you are getting error like information not available for router or quota, means issue is with network node in your set up. Could you please share exact issue you are facing while creating router in dashboard. Regards Santosh Parihar -----Original Message----- From: openstack-dev-requ...@lists.openstack.org [mailto:openstack-dev-requ...@lists.openstack.org] Sent: Wednesday, November 06, 2013 5:30 PM To: openstack-dev@lists.openstack.org Subject: OpenStack-dev Digest, Vol 19, Issue 10 Send OpenStack-dev mailing list submissions to openstack-dev@lists.openstack.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev or, via email, send a message with subject or body 'help' to openstack-dev-requ...@lists.openstack.org You can reach the person managing the list at openstack-dev-ow...@lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenStack-dev digest..." Today's Topics: 1. Re: [TripleO] Releases of this week (Robert Collins) 2. Re: [TripleO] Releases of this week (Roman Podoliaka) 3. Re: [TripleO] Releases of this week (Sergey Lukjanov) 4. Re: [heat][keystone] APIs, roles, request scope and admin-ness (Jamie Lennox) 5. Re: [Solum] Design Workshop at SFO (Roshan Agrawal) 6. Bad review patterns (Radomir Dopieralski) 7. Re: [Neutron] IPv6 sub-team? (Mark McClain) 8. Re: [TripleO] Releases of this week (Roman Podoliaka) 9. Re: [qa] Duplicated test effort development (Ken'ichi Ohmichi) 10. Re: [Neutron] IPv6 sub-team? (Miguel Angel) 11. Code Review (Jenkins-job-builder, BlameUpstreamCommitters plugin support) (Peter Liljenberg) 12. [Nova] [Climate] Reservation service called Climate (Sylvain Bauza) 13. Facing issue in creating router in openstack dasboard (Kanika Saklani) 14. [State-Management] Slides from taskflow speaker session (Joshua Harlow) ---------------------------------------------------------------------- Message: 1 Date: Wed, 6 Nov 2013 17:44:15 +1300 From: Robert Collins <robe...@robertcollins.net> 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: <caj3hoz0cdnjhdyenmqloehw09h4foqoohnnrc_oohba0cvt...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 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 HP Converged Cloud ------------------------------ Message: 2 Date: Wed, 6 Nov 2013 07:42:44 +0200 From: Roman Podoliaka <rpodoly...@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: <caka_uea8nh3d-trvb9v3a8q4+u8nb-7frq4sostcjine_bu...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" 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<javascript:;>> > 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 <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 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 > HP Converged Cloud > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/af4480be/attachment-0001.html> ------------------------------ Message: 4 Date: Wed, 06 Nov 2013 17:56:13 +1000 From: Jamie Lennox <jamielen...@redhat.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [heat][keystone] APIs, roles, request scope and admin-ness Message-ID: <1383724573.2359.3.ca...@dhcp-40-102.bne.redhat.com> Content-Type: text/plain; charset="UTF-8" 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 ------------------------------ Message: 5 Date: Wed, 6 Nov 2013 08:25:25 +0000 From: Roshan Agrawal <roshan.agra...@rackspace.com> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Solum] Design Workshop at SFO Message-ID: <9c1b7917de16f44d855e72328d666ed1231bc...@ord1exd03.rackspace.corp> Content-Type: text/plain; charset="us-ascii" 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 ------------------------------ Message: 6 Date: Wed, 06 Nov 2013 09:34:38 +0100 From: Radomir Dopieralski <openst...@sheep.art.pl> To: openstack-dev@lists.openstack.org Subject: [openstack-dev] Bad review patterns Message-ID: <5279ff1e.4030...@sheep.art.pl> Content-Type: text/plain; charset=ISO-8859-1 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 suspicious, and when I find myself falling into one of them, I always rethink what I'm doing. Maybe you have some more bad patterns that you would like to share? Reviewing code is a difficult skill and it's always good to improve it by using experience of others. -- Radomir Dopieralski ------------------------------ Message: 7 Date: Wed, 6 Nov 2013 16:56:16 +0800 From: Mark McClain <mark.mccl...@dreamhost.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Neutron] IPv6 sub-team? Message-ID: <d434a639-4c47-44f3-b094-9042b710e...@dreamhost.com> Content-Type: text/plain; charset=us-ascii 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 ------------------------------ Message: 8 Date: Wed, 6 Nov 2013 11:02:45 +0200 From: Roman Podoliaka <rpodoly...@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: <caka_ueb07rlanpfzcb8vgamtddkabucnwtj5km_gstuq3bz...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" 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< > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/19038b5e/attachment-0001.html> ------------------------------ Message: 9 Date: Wed, 6 Nov 2013 17:29:54 +0800 From: "Ken'ichi Ohmichi" <ken1ohmi...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [qa] Duplicated test effort development Message-ID: <caa393vi3skrmknf1kqymtscgzvacdcb0acie0ylbisde-cb...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 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 ------------------------------ Message: 10 Date: Wed, 6 Nov 2013 10:41:36 +0100 From: Miguel Angel <miguelan...@ajo.es> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Neutron] IPv6 sub-team? Message-ID: <cadsdy2jjahdtiw-cv4r4bstdonmp7x9bted-9ukjntohcdp...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" +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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/1108d2c3/attachment-0001.html> ------------------------------ Message: 11 Date: Wed, 6 Nov 2013 10:47:28 +0100 From: Peter Liljenberg <pliljenb...@gmail.com> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org> Subject: [openstack-dev] Code Review (Jenkins-job-builder, BlameUpstreamCommitters plugin support) Message-ID: <cabftcnuyzw3pa_u6doywdctswtkfyufluecb-bveduymjg6...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi, Could someone review this please: https://review.openstack.org/#/c/54085/ Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/f55de7e4/attachment-0001.html> ------------------------------ Message: 12 Date: Wed, 6 Nov 2013 09:47:26 +0000 From: Sylvain Bauza <sylvain.ba...@bull.net> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org> Subject: [openstack-dev] [Nova] [Climate] Reservation service called Climate Message-ID: <b898bd2833502846b0ec7caf416f8f4750ddf...@bumsg2wm.fr.ad.bull.net> Content-Type: text/plain; charset="iso-8859-1" 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/4a2a2c47/attachment-0001.html> ------------------------------ Message: 13 Date: Wed, 6 Nov 2013 16:14:59 +0530 From: Kanika Saklani <kanika.saklan...@gmail.com> To: openstack-dev@lists.openstack.org Subject: [openstack-dev] Facing issue in creating router in openstack dasboard Message-ID: <CADreVOssjgVa9U9rZg=oew_acucpqds_-jxtuczm6netm+n...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi All, i am new to openstack. i installed the openstack in x86 for that i do the following step to download and install the grizzly as follows:- - $ wget https://github.com/openstack-dev/devstack/archive/stable/grizzly.zip - $unzip grizzly.zip - $cd devstack-stable-grizzly in this directory devstack-stable-grizzly i made a localrc where i did the following configuration:- - $ vim localrc *disable_service n-net enable_service q-svc enable_service q-dhcp enable_service neutron enable_service bigswitch_floodlight Q_PLUGIN=bigswitch_floodlight Q_USE_NAMESPACE=False NOVA_USE_NEUTRON_API=v2 SCHEDULER=nova.scheduler.simple.SimpleScheduler MYSQL_PASSWORD=<password> RABBIT_PASSWORD=<password> ADMIN_PASSWORD=<password> SERVICE_PASSWORD=<password> SERVICE_TOKEN=tokentoken DEST=/opt/stack SCREEN_LOGDIR=$DEST/logs/screen SYSLOG=True #IP:Port for the BSN controller #if more than one, separate with commas BS_FL_CONTROLLERS_PORT=<ip_address:port> BS_FL_CONTROLLER_TIMEOUT=10* Then after that i run the openvswitch-1.11.0 by this command:- - $ cd openvswitch-1.11.0/utilitie - $./ovs-ctl start After that i run the following command in the directory devstack-stable-grizzly - $ ./stack.sh then i get this message:- *Horizon is now available at http://192.168.6.122/ <http://192.168.6.122/> * *Keystone is serving at http://192.168.6.122:5000/v2.0/ <http://192.168.6.122:5000/v2.0/>* *Examples on using novaclient command line is in exercise.sh* *The default users are: admin and demo * *The password: kanika * *This is your host ip: 192.168.6.122 stack.sh completed in 490 seconds.* i also get a login window of open stack then i login with admin & password kanika. As i see the demo of grizzly in youtube the link are (https://www.youtube.com/watch?v=p4eW78gHfCg ) they are doing the following steps:- step1:- they have created the volume first of 5GB space i also did the same. i have attaching the screen shot for this Step2:- then they have done the router configuration, here i got stucked, I am unable to create router I am attaching the screen shot for this as well can you please look into my issue as suggest me how can i get out of this. looking forward for your positive reply. -- Regards Kanika -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0af69113/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: volume_create.png Type: image/png Size: 54354 bytes Desc: not available URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0af69113/attachment-0002.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: router_create.png Type: image/png Size: 52440 bytes Desc: not available URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0af69113/attachment-0003.png> ------------------------------ Message: 14 Date: Wed, 6 Nov 2013 11:15:08 +0000 From: Joshua Harlow <harlo...@yahoo-inc.com> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org> Subject: [openstack-dev] [State-Management] Slides from taskflow speaker session Message-ID: <86c4f964-42ce-4d55-a2c1-65bf8c40e...@yahoo-inc.com> Content-Type: text/plain; charset="us-ascii" 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 End of OpenStack-dev Digest, Vol 19, Issue 10 ********************************************* =============================================================================== Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. =============================================================================== _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
