[openstack-dev] OpenStack-dev Digest, Vol 19, Issue 10
Santosh Kumar
Santosh8.Kumar at aricent.com
Wed Nov 6 12:36:49 UTC 2013
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-request at lists.openstack.org [mailto:openstack-dev-request at lists.openstack.org]
Sent: Wednesday, November 06, 2013 5:30 PM
To: openstack-dev at lists.openstack.org
Subject: OpenStack-dev Digest, Vol 19, Issue 10
Send OpenStack-dev mailing list submissions to
openstack-dev at 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-request at lists.openstack.org
You can reach the person managing the list at
openstack-dev-owner at 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 <robertc at robertcollins.net>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [TripleO] Releases of this week
Message-ID:
<CAJ3HoZ0CDnJhdYeNMQLoEhW09H4fOqOoHnNrC_oOHBA0CVt7SQ at 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 <rpodolyaka at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud
------------------------------
Message: 2
Date: Wed, 6 Nov 2013 07:42:44 +0200
From: Roman Podoliaka <rpodolyaka at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [TripleO] Releases of this week
Message-ID:
<CAKA_ueA8Nh3D-tRvb9v3A8q4+U8nb-7fRq4SOSTCjinE_bUjZQ at 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 <rpodolyaka at 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 at lists.openstack.org <javascript:;>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Robert Collins <rbtcollins at hp.com <javascript:;>>
> Distinguished Technologist
> HP Converged Cloud
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at 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 <slukjanov at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [TripleO] Releases of this week
Message-ID: <D7AE8049-6442-49E1-875F-151EDD356EB2 at 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 <rpodolyaka at 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 <rpodolyaka at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at 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 <jamielennox at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [heat][keystone] APIs, roles, request
scope and admin-ness
Message-ID: <1383724573.2359.3.camel at 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 at 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.agrawal at RACKSPACE.COM>
To: "openstack-dev at lists.openstack.org"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Solum] Design Workshop at SFO
Message-ID:
<9C1B7917DE16F44D855E72328D666ED1231BC961 at 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 at 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 <openstack at sheep.art.pl>
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] Bad review patterns
Message-ID: <5279FF1E.4030702 at 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.mcclain at dreamhost.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] IPv6 sub-team?
Message-ID: <D434A639-4C47-44F3-B094-9042B710E326 at 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_Collins2 at 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 at 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 <rpodolyaka at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [TripleO] Releases of this week
Message-ID:
<CAKA_ueB07RLAnPFZCB8vgAmTdDKABUCnwTJ5km_gsTuQ3BzdhQ at 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 <rpodolyaka at 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 <rpodolyaka at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Robert Collins <rbtcollins at 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" <ken1ohmichi at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [qa] Duplicated test effort development
Message-ID:
<CAA393vi3SkrmknF1kqymtscGZVacdCB0aCiE0yLbisdE-CbCgQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
2013/10/30 Christopher Yeoh <cbkyeoh at 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 <miguelangel at ajo.es>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] IPv6 sub-team?
Message-ID:
<CADSDy2jjahdtiW-Cv4r4bstDoNmP7X9BTeD-9uKJNtohcDpVoA at 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.mcclain at 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_Collins2 at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at 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 <pliljenberg at gmail.com>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] Code Review (Jenkins-job-builder,
BlameUpstreamCommitters plugin support)
Message-ID:
<CABFTCnUyZw3Pa_U6doYWDcTswtkfYUFLUecB-BVedUYMJg6nfg at 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.Bauza at bull.net>
To: "openstack-dev at lists.openstack.org"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Nova] [Climate] Reservation service called
Climate
Message-ID:
<B898BD2833502846B0EC7CAF416F8F4750DDFDED at 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.saklani11 at gmail.com>
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] Facing issue in creating router in openstack
dasboard
Message-ID:
<CADreVOssjgVa9U9rZg=OeW_AcucPqdS_-JXTUczm6nEtM+n5Cw at 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 <harlowja at yahoo-inc.com>
To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [State-Management] Slides from taskflow
speaker session
Message-ID: <86C4F964-42CE-4D55-A2C1-65BF8C40E68B at 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 at 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.
===============================================================================
More information about the OpenStack-dev
mailing list
