[openstack-dev] OpenStack-dev Digest, Vol 19, Issue 10
Kanika Saklani
kanika.saklani11 at gmail.com
Wed Nov 6 12:57:05 UTC 2013
HI Santosh
Thanks much for the quick reply.. I have attached error's screen shot in
the previous mail. We are only getting message "Failed to create router
"new router" " . We are not able to figure our more than this.. Please help
us in resolving the issue.. I am again attaching the error's screen shot..
Please find the attachment
--
Regards
Kanika Saklani
On Wed, Nov 6, 2013 at 6:06 PM, Santosh Kumar <Santosh8.Kumar at aricent.com>wrote:
> 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.
>
> ===============================================================================
>
> _______________________________________________
> 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/8bad1dbb/attachment.html>
-------------- 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/8bad1dbb/attachment.png>
More information about the OpenStack-dev
mailing list
