<div dir="ltr">HI Santosh <div><br></div><div>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 </div>
<div><br></div><div>--</div><div>Regards</div><div>Kanika Saklani</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 6, 2013 at 6:06 PM, Santosh Kumar <span dir="ltr"><<a href="mailto:Santosh8.Kumar@aricent.com" target="_blank">Santosh8.Kumar@aricent.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kanika,<br>
<br>
Regarding : Facing issue in creating router in openstack        dashboard  (Kanika Saklani)<br>
<br>
if you are getting error like information not available for router or quota, means issue is with network node in your set up.<br>
<br>
Could you please share exact issue you are facing while creating router in dashboard.<br>
<br>
Regards<br>
Santosh Parihar<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a> [mailto:<a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a>]<br>

Sent: Wednesday, November 06, 2013 5:30 PM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: OpenStack-dev Digest, Vol 19, Issue 10<br>
<br>
Send OpenStack-dev mailing list submissions to<br>
        <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:openstack-dev-owner@lists.openstack.org">openstack-dev-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: [TripleO] Releases of this week (Robert Collins)<br>
   2. Re: [TripleO] Releases of this week (Roman Podoliaka)<br>
   3. Re: [TripleO] Releases of this week (Sergey Lukjanov)<br>
   4. Re: [heat][keystone] APIs, roles, request scope and<br>
      admin-ness (Jamie Lennox)<br>
   5. Re: [Solum] Design Workshop at SFO (Roshan Agrawal)<br>
   6. Bad review patterns (Radomir Dopieralski)<br>
   7. Re: [Neutron] IPv6 sub-team? (Mark McClain)<br>
   8. Re: [TripleO] Releases of this week (Roman Podoliaka)<br>
   9. Re: [qa] Duplicated test effort development (Ken'ichi Ohmichi)<br>
  10. Re: [Neutron] IPv6 sub-team? (Miguel Angel)<br>
  11. Code Review (Jenkins-job-builder, BlameUpstreamCommitters<br>
      plugin support) (Peter Liljenberg)<br>
  12. [Nova] [Climate] Reservation service called Climate<br>
      (Sylvain Bauza)<br>
  13. Facing issue in creating router in openstack      dasboard<br>
      (Kanika Saklani)<br>
  14. [State-Management] Slides from taskflow speaker   session<br>
      (Joshua Harlow)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 6 Nov 2013 17:44:15 +1300<br>
From: Robert Collins <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [TripleO] Releases of this week<br>
Message-ID:<br>
        <<a href="mailto:CAJ3HoZ0CDnJhdYeNMQLoEhW09H4fOqOoHnNrC_oOHBA0CVt7SQ@mail.gmail.com">CAJ3HoZ0CDnJhdYeNMQLoEhW09H4fOqOoHnNrC_oOHBA0CVt7SQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Awesome work - thank you!!!<br>
<br>
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.<br>
<br>
Cheers,<br>
Rob<br>
<br>
On 2 November 2013 04:38, Roman Podoliaka <<a href="mailto:rpodolyaka@mirantis.com">rpodolyaka@mirantis.com</a>> wrote:<br>
> Hi all,<br>
><br>
> This week I've been doing releases of all projects, which belong to<br>
> TripleO program. Here are release notes you might be interested in:<br>
><br>
>     os-collect-config  - 0.1.5 (was 0.1.4):<br>
>         - default polling interval was reduced to 30 seconds<br>
>         - requirements were updated to use the new iso8601 version<br>
> fixing important bugs<br>
><br>
>     diskimage-builder - 0.0.9 (was 0.0.8)<br>
>          - added support for bad Fedora image mirrors (retry the<br>
> request once on 404)<br>
>          - removed dependency on dracut-network from fedora element<br>
>          - fixed the bug with removing of lost+found dir if it's not<br>
> found<br>
><br>
>     tripleo-image-elements  - 0.1.0 (was 0.0.4)<br>
>          - switched to tftpd-hpa on Fedora and Ubuntu<br>
>          - made it possible to disable file injection in Nova<br>
>          - switched seed vm to Neutron native PXE<br>
>          - added Fedora support to apache2 element<br>
>          - fixed processing of routes in init-neutron-ovs<br>
>          - fixed Heat watch server url key name in seed vm metadata<br>
><br>
>     tripleo-heat-templates - 0.1.0 (was 0.0.1)<br>
>          - disabled Nova Baremetal file injection (undercloud)<br>
>          - made LaunchConfiguration resources mergeable<br>
>          - made neutron public interface configurable (overcloud)<br>
>          - made it possible to set public interface IP (overcloud)<br>
>          - allowed making the public interface a VLAN (overcloud)<br>
>          - added a wait condition for signalling that overcloud is ready<br>
>          - added metadata for Nova floating-ip extension<br>
>          - added tuskar API service configuration<br>
>          - hid AdminToken in Heat templates<br>
>          - added Ironic service configuration<br>
><br>
>      tuskar - 0.0.2 (was 0.0.1)<br>
>          - made it possible to pass Glance image id<br>
>          - fixed the bug with duplicated Resource Class names<br>
><br>
>      tuskar-ui - 0.0.2 (was 0.0.1)<br>
>           - resource class creation form no longer ignores the image selection<br>
>           - separated flavors creation step<br>
>           - fail gracefully on node detail page when no overcloud<br>
>           - added validation of MAC addresses and CIDR values<br>
>           - stopped appending Resource Class name to Resource Class flavors<br>
>           - fixed JS warnings when $ is not available<br>
>           - fixed links and naming in Readme<br>
>           - various code and test fixes (pep8, refactoring)<br>
><br>
>       python-tuskarclient - 0.0.2 (was 0.0.1)<br>
>           - fixed processing of 301 response code<br>
><br>
>       os-apply-config and os-refresh-config haven't had new commits<br>
> since the last release<br>
><br>
> This also means that:<br>
> 1. We are now releasing all the projects we have.<br>
> 2. *tuskar* projects have got PyPi entries.<br>
><br>
> Last but not least.<br>
><br>
> I'd like to say a big thank you to Chris Jones who taught me 'Release<br>
> Management 101' and provided patches to openstack/infra-config to make<br>
> all our projects 'releasable'; Robert Collins for his advice on<br>
> version numbering; Clark Boylan and Jeremy Stanley for landing of<br>
> Gerrit ACL patches and debugging PyPi uploads issues; Radomir<br>
> Dopieralski and Tomas Sedovic for landing a quick fix to tuskar-ui.<br>
><br>
> Thank you all guys, you've helped me a lot!<br>
><br>
> Roman<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 6 Nov 2013 07:42:44 +0200<br>
From: Roman Podoliaka <<a href="mailto:rpodolyaka@mirantis.com">rpodolyaka@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [TripleO] Releases of this week<br>
Message-ID:<br>
        <<a href="mailto:CAKA_ueA8Nh3D-tRvb9v3A8q4%2BU8nb-7fRq4SOSTCjinE_bUjZQ@mail.gmail.com">CAKA_ueA8Nh3D-tRvb9v3A8q4+U8nb-7fRq4SOSTCjinE_bUjZQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hey,<br>
<br>
Oh, that's a pity. I didn't know that. Sure I'll update the doc and look<br>
for a way to automize the process.<br>
<br>
Roman<br>
<br>
On Wednesday, November 6, 2013, Robert Collins wrote:<br>
<br>
> Awesome work - thank you!!!<br>
><br>
> Can you please add to your docs though, that we need to go and close<br>
> the bugs in the project (either via a script or by hand) - gerrit<br>
> leaves them as Fix Committed today.<br>
><br>
> Cheers,<br>
> Rob<br>
><br>
> On 2 November 2013 04:38, Roman Podoliaka <<a href="mailto:rpodolyaka@mirantis.com">rpodolyaka@mirantis.com</a><javascript:;>><br>
> wrote:<br>
> > Hi all,<br>
> ><br>
> > This week I've been doing releases of all projects, which belong to<br>
> > TripleO program. Here are release notes you might be interested in:<br>
> ><br>
> >     os-collect-config  - 0.1.5 (was 0.1.4):<br>
> >         - default polling interval was reduced to 30 seconds<br>
> >         - requirements were updated to use the new iso8601 version<br>
> > fixing important bugs<br>
> ><br>
> >     diskimage-builder - 0.0.9 (was 0.0.8)<br>
> >          - added support for bad Fedora image mirrors (retry the<br>
> > request once on 404)<br>
> >          - removed dependency on dracut-network from fedora element<br>
> >          - fixed the bug with removing of lost+found dir if it's not<br>
> found<br>
> ><br>
> >     tripleo-image-elements  - 0.1.0 (was 0.0.4)<br>
> >          - switched to tftpd-hpa on Fedora and Ubuntu<br>
> >          - made it possible to disable file injection in Nova<br>
> >          - switched seed vm to Neutron native PXE<br>
> >          - added Fedora support to apache2 element<br>
> >          - fixed processing of routes in init-neutron-ovs<br>
> >          - fixed Heat watch server url key name in seed vm metadata<br>
> ><br>
> >     tripleo-heat-templates - 0.1.0 (was 0.0.1)<br>
> >          - disabled Nova Baremetal file injection (undercloud)<br>
> >          - made LaunchConfiguration resources mergeable<br>
> >          - made neutron public interface configurable (overcloud)<br>
> >          - made it possible to set public interface IP (overcloud)<br>
> >          - allowed making the public interface a VLAN (overcloud)<br>
> >          - added a wait condition for signalling that overcloud is ready<br>
> >          - added metadata for Nova floating-ip extension<br>
> >          - added tuskar API service configuration<br>
> >          - hid AdminToken in Heat templates<br>
> >          - added Ironic service configuration<br>
> ><br>
> >      tuskar - 0.0.2 (was 0.0.1)<br>
> >          - made it possible to pass Glance image id<br>
> >          - fixed the bug with duplicated Resource Class names<br>
> ><br>
> >      tuskar-ui - 0.0.2 (was 0.0.1)<br>
> >           - resource class creation form no longer ignores the image<br>
> selection<br>
> >           - separated flavors creation step<br>
> >           - fail gracefully on node detail page when no overcloud<br>
> >           - added validation of MAC addresses and CIDR values<br>
> >           - stopped appending Resource Class name to Resource Class<br>
> flavors<br>
> >           - fixed JS warnings when $ is not available<br>
> >           - fixed links and naming in Readme<br>
> >           - various code and test fixes (pep8, refactoring)<br>
> ><br>
> >       python-tuskarclient - 0.0.2 (was 0.0.1)<br>
> >           - fixed processing of 301 response code<br>
> ><br>
> >       os-apply-config and os-refresh-config haven't had new commits<br>
> > since the last release<br>
> ><br>
> > This also means that:<br>
> > 1. We are now releasing all the projects we have.<br>
> > 2. *tuskar* projects have got PyPi entries.<br>
> ><br>
> > Last but not least.<br>
> ><br>
> > I'd like to say a big thank you to Chris Jones who taught me 'Release<br>
> > Management 101' and provided patches to openstack/infra-config to make<br>
> > all our projects 'releasable'; Robert Collins for his advice on<br>
> > version numbering; Clark Boylan and Jeremy Stanley for landing of<br>
> > Gerrit ACL patches and debugging PyPi uploads issues; Radomir<br>
> > Dopieralski and Tomas Sedovic for landing a quick fix to tuskar-ui.<br>
> ><br>
> > Thank you all guys, you've helped me a lot!<br>
> ><br>
> > Roman<br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a> <javascript:;><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> --<br>
> Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a> <javascript:;>><br>
> Distinguished Technologist<br>
> HP Converged Cloud<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a> <javascript:;><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0d4fea7e/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0d4fea7e/attachment-0001.html</a>><br>

<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 6 Nov 2013 14:07:02 +0800<br>
From: Sergey Lukjanov <<a href="mailto:slukjanov@mirantis.com">slukjanov@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [TripleO] Releases of this week<br>
Message-ID: <<a href="mailto:D7AE8049-6442-49E1-875F-151EDD356EB2@mirantis.com">D7AE8049-6442-49E1-875F-151EDD356EB2@mirantis.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Here is the script for processing bug while releasing - <a href="https://github.com/ttx/openstack-releasing/blob/master/process_bugs.py" target="_blank">https://github.com/ttx/openstack-releasing/blob/master/process_bugs.py</a><br>

<br>
Sincerely yours,<br>
Sergey Lukjanov<br>
Savanna Technical Lead<br>
Mirantis Inc.<br>
<br>
On Nov 6, 2013, at 1:42 PM, Roman Podoliaka <<a href="mailto:rpodolyaka@mirantis.com">rpodolyaka@mirantis.com</a>> wrote:<br>
<br>
> Hey,<br>
><br>
> 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.<br>
><br>
> Roman<br>
><br>
> On Wednesday, November 6, 2013, Robert Collins wrote:<br>
> Awesome work - thank you!!!<br>
><br>
> Can you please add to your docs though, that we need to go and close<br>
> the bugs in the project (either via a script or by hand) - gerrit<br>
> leaves them as Fix Committed today.<br>
><br>
> Cheers,<br>
> Rob<br>
><br>
> On 2 November 2013 04:38, Roman Podoliaka <<a href="mailto:rpodolyaka@mirantis.com">rpodolyaka@mirantis.com</a>> wrote:<br>
> > Hi all,<br>
> ><br>
> > This week I've been doing releases of all projects, which belong to<br>
> > TripleO program. Here are release notes you might be interested in:<br>
> ><br>
> >     os-collect-config  - 0.1.5 (was 0.1.4):<br>
> >         - default polling interval was reduced to 30 seconds<br>
> >         - requirements were updated to use the new iso8601 version<br>
> > fixing important bugs<br>
> ><br>
> >     diskimage-builder - 0.0.9 (was 0.0.8)<br>
> >          - added support for bad Fedora image mirrors (retry the<br>
> > request once on 404)<br>
> >          - removed dependency on dracut-network from fedora element<br>
> >          - fixed the bug with removing of lost+found dir if it's not found<br>
> ><br>
> >     tripleo-image-elements  - 0.1.0 (was 0.0.4)<br>
> >          - switched to tftpd-hpa on Fedora and Ubuntu<br>
> >          - made it possible to disable file injection in Nova<br>
> >          - switched seed vm to Neutron native PXE<br>
> >          - added Fedora support to apache2 element<br>
> >          - fixed processing of routes in init-neutron-ovs<br>
> >          - fixed Heat watch server url key name in seed vm metadata<br>
> ><br>
> >     tripleo-heat-templates - 0.1.0 (was 0.0.1)<br>
> >          - disabled Nova Baremetal file injection (undercloud)<br>
> >          - made LaunchConfiguration resources mergeable<br>
> >          - made neutron public interface configurable (overcloud)<br>
> >          - made it possible to set public interface IP (overcloud)<br>
> >          - allowed making the public interface a VLAN (overcloud)<br>
> >          - added a wait condition for signalling that overcloud is ready<br>
> >          - added metadata for Nova floating-ip extension<br>
> >          - added tuskar API service configuration<br>
> >          - hid AdminToken in Heat templates<br>
> >          - added Ironic service configuration<br>
> ><br>
> >      tuskar - 0.0.2 (was 0.0.1)<br>
> >          - made it possible to pass Glance image id<br>
> >          - fixed the bug with duplicated Resource Class names<br>
> ><br>
> >      tuskar-ui - 0.0.2 (was 0.0.1)<br>
> >           - resource class creation form no longer ignores the image selection<br>
> >           - separated flavors creation step<br>
> >           - fail gracefully on node detail page when no overcloud<br>
> >           - added validation of MAC addresses and CIDR values<br>
> >           - stopped appending Resource Class name to Resource Class flavors<br>
> >           - fixed JS warnings when $ is not available<br>
> >           - fixed links and naming in Readme<br>
> >           - various code and test fixes (pep8, refactoring)<br>
> ><br>
> >       python-tuskarclient - 0.0.2 (was 0.0.1)<br>
> >           - fixed processing of 301 response code<br>
> ><br>
> >       os-apply-config and os-refresh-config haven't had new commits<br>
> > since the last release<br>
> ><br>
> > This also means that:<br>
> > 1. We are now releasing all the projects we have.<br>
> > 2. *tuskar* projects have got PyPi entries.<br>
> ><br>
> > Last but not least.<br>
> ><br>
> > I'd like to say a big thank you to Chris Jones who taught me 'Release<br>
> > Management 101' and provided patches to openstack/infra-config to make<br>
> > all our projects 'releasable'; Robert Collins for his advice on<br>
> > version numbering; Clark Boylan and Jeremy Stanley for landing of<br>
> > Gerrit ACL patches and debugging PyPi uploads issues; Radomir<br>
> > Dopieralski and Tomas Sedovic for landing a quick fix to tuskar-ui.<br>
> ><br>
> > Thank you all guys, you've helped me a lot!<br>
> ><br>
> > Roman<br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> --<br>
> Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
> Distinguished Technologist<br>
> HP Converged Cloud<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/af4480be/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/af4480be/attachment-0001.html</a>><br>

<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 06 Nov 2013 17:56:13 +1000<br>
From: Jamie Lennox <<a href="mailto:jamielennox@redhat.com">jamielennox@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [heat][keystone] APIs, roles, request<br>
        scope and admin-ness<br>
Message-ID: <<a href="mailto:1383724573.2359.3.camel@dhcp-40-102.bne.redhat.com">1383724573.2359.3.camel@dhcp-40-102.bne.redhat.com</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
On Wed, 2013-11-06 at 06:16 +0800, Clint Byrum wrote:<br>
> Excerpts from Steven Hardy's message of 2013-11-03 00:06:39 +0800:<br>
> > Hi all,<br>
> ><br>
> > Looking to start a wider discussion, prompted by:<br>
> > <a href="https://review.openstack.org/#/c/54651/" target="_blank">https://review.openstack.org/#/c/54651/</a><br>
> > <a href="https://blueprints.launchpad.net/heat/+spec/management-api" target="_blank">https://blueprints.launchpad.net/heat/+spec/management-api</a><br>
> > <a href="https://etherpad.openstack.org/p/heat-management-api" target="_blank">https://etherpad.openstack.org/p/heat-management-api</a><br>
> ><br>
> > Summary - it has been proposed to add a management API to Heat, similar in<br>
> > concept to the admin/public API topology used in keystone.<br>
> ><br>
> > I'm concerned that this may not be a pattern we want to propagate throughout<br>
> > OpenStack, and that for most services, we should have one API to access data,<br>
> > with the scope of the data returned/accessible defined by the roles held by<br>
> > the user (ie making proper use of the RBAC facilities afforded to us via<br>
> > keystone).<br>
<br>
I feel that i can speak for the keystone developers when i say avoid<br>
this at all costs! Currently in the implementation of keystone what is<br>
exposed on the admin port is the same as the public port with the<br>
intention that we can hopefully remove adminURL altogether.<br>
<br>
> > In the current PoC patch, a users admin-ness is derived from the fact that<br>
> > they are accessing a specific endpoint, and that policy did not deny them<br>
> > access to that endpoint.  I think this is wrong, and we should use keystone<br>
> > roles to decide the scope of the request.<br>
> ><br>
> > The proposal seems to consider tenants as the top-level of abstraction, with<br>
> > the next level up being a global service provider admin, but this does not<br>
> > consider the keystone v3 concept of domains [1], or that you may wish to<br>
> > provide some of these admin-ish features to domain-admin users (who will<br>
> > adminster data accross multiple tenants, just like has been proposed), via the<br>
> > public-facing API.<br>
> ><br>
> > It seems like we need a way of scoping the request (via data in the context),<br>
> > based on a heirarchy of admin-ness, like:<br>
> ><br>
> > 1. Normal user<br>
> > 2. Tenant Admin (has admin role in a tenant)<br>
> > 3. Domain Admin (has admin role in all tenants in the domain)<br>
> > 4. Service Admin (has admin role everywhere, like admin_token for keystone)<br>
> ><br>
> > The current "is_admin" flag which is being used in the PoC patch won't allow<br>
> > this granularity of administrative boundaries to be represented, and splitting<br>
> > admin actions into a separate API will prevent us providing tenant and domain<br>
> > level admin functionality to customers in a public cloud environment.<br>
> ><br>
> > It has been mentioned that in keystone, if you have admin in one tenant, you<br>
> > are admin everywhere, which is a pattern I think we should not follow -<br>
> > keystone folks, what are your thoughts in terms of roadmap to make role<br>
> > assignment (at the request level) scoped to tenants rather than globally<br>
> > applied?  E.g what data can we add to move from X-Roles in auth_token, to<br>
> > expressing roles in multiple tenants and domains?<br>
> ><br>
><br>
> Right, roles should be tenant and domain scoped, and the roles that we<br>
> consume in our policy definitions should not need to know anything about<br>
> the hierarchy. It seems very broken to me that there would be no way to<br>
> make a user who can only create more users in their tenant in Keystone.<br>
> Likewise, I would consider Heat broken if I had to use a special API<br>
> for doing things with a role I already have that is just scoped more<br>
> broadly than a single tenant or domain.<br>
<br>
This is possible with the v3 api.<br>
<br>
> > Basically, I'm very concerned that we discuss this, get a clear roadmap which<br>
> > will work with future keystone admin/role models, and is not a short-term hack<br>
> > which we won't want to maintain long-term.<br>
> ><br>
> > What are peoples thoughts on this?<br>
><br>
> Let's try and find a keystone dev or two in the hallway at the summit<br>
> and get some clarity on the way Keystone is intended to work, which may<br>
> help us decide if we want to follow their admin-specific-API paradigm or<br>
> not.<br>
<br>
There are a number of us at summit (myself included). Our sessions tend<br>
to be in the afternoon so you can probably find at least 1 dev in the<br>
dev lounge at the other times.<br>
<br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Wed, 6 Nov 2013 08:25:25 +0000<br>
From: Roshan Agrawal <<a href="mailto:roshan.agrawal@RACKSPACE.COM">roshan.agrawal@RACKSPACE.COM</a>><br>
To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Solum] Design Workshop at SFO<br>
Message-ID:<br>
        <9C1B7917DE16F44D855E72328D666ED1231BC961@ORD1EXD03.RACKSPACE.CORP><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Re-sending details for the upcoming Solum workshop at SFO on popular demand<br>
<br>
We will also have an "events" section on Solum.io for this kind of communication in the next week or so.<br>
<br>
Please confirm your attendance by visiting the eventbrite page: <a href="https://www.eventbrite.com/event/9130831563" target="_blank">https://www.eventbrite.com/event/9130831563</a> . This is important so we get an accurate count of attendees.<br>

________________________________________<br>
From: Roshan Agrawal<br>
Sent: Friday, November 01, 2013 3:17 PM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [Solum] Design Workshop at SFO<br>
<br>
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.<br>
<br>
Please confirm your attendance by visiting the eventbrite page: <a href="https://www.eventbrite.com/event/9130831563" target="_blank">https://www.eventbrite.com/event/9130831563</a> . This is important so we get an accurate count of attendees.<br>

<br>
Workshop dates: Nov 19, 20<br>
Location: Rackspace SFO office (620 Folsom St, San Francisco, CA 94107)<br>
Purpose: working sessions for Solum contributors to discuss design/blueprints.<br>
<br>
Meeting Structure<br>
Nov 19 Tuesday 9:00 am - 5 pm<br>
  9:00 - 9:30: check-in<br>
  9:30 - 10:00: introductions, agenda<br>
  10:00 - 5:00: Roundtable workshop, whiteboarding<br>
  5:30 - 7:00: Happy hour (3rd floor at the Rackspace SFO office)<br>
<br>
Nov 20 Wednesday 9:30 am - 3:00 pm : Continue workshops<br>
Workshop Concludes 3 pm Wednesday<br>
<br>
Please refer to the etherpad page below for the latest info on the event, and to provide input on discussion topics for the workshop.<br>
<a href="https://etherpad.openstack.org/p/SolumSFOCommunityWorkshop" target="_blank">https://etherpad.openstack.org/p/SolumSFOCommunityWorkshop</a><br>
<br>
Thanks, and look forward to seeing you all at the event.<br>
<br>
Thanks!<br>
Roshan Agrawal<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Wed, 06 Nov 2013 09:34:38 +0100<br>
From: Radomir Dopieralski <<a href="mailto:openstack@sheep.art.pl">openstack@sheep.art.pl</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] Bad review patterns<br>
Message-ID: <<a href="mailto:5279FF1E.4030702@sheep.art.pl">5279FF1E.4030702@sheep.art.pl</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hello,<br>
<br>
I'm quite new in the OpenStack project, but I love it already. What is<br>
especially nifty is the automated review system -- I'm really impressed.<br>
I'm coming from a project in which we also did reviews of every change<br>
-- although it was mostly manual, and just one review was enough to<br>
merge -- and at some point in that project I noticed that it is very<br>
easy to give reviews that are unhelpful, frustrating and just get in the<br>
way of the actual work. I started paying attention to how I am reviewing<br>
code, and I managed to come up with several patterns that are bad. Once<br>
I know the patterns, it's easier to recognize when I'm doing something<br>
wrong and rethink the review. I would like to share the patterns that I<br>
noticed.<br>
<br>
<br>
Not sure if that works...<br>
=========================<br>
<br>
You see some suspicious piece of code, and you are not sure if it is<br>
correct or not. So you point it out in the review and -1 it, demanding<br>
that the author rechecks it and/or prove that it indeed works.<br>
<br>
It's your job as a reviewer to check such things, don't put all the<br>
effort on the author. They probably already checked that this code<br>
works, and possibly have even written tests for it. If you are not<br>
familiar with the technology enough to tell whether it's good or not,<br>
and have no means of testig it yourself, you shouldn't be reviewing it.<br>
If you do have the means to test it or can find the piece of<br>
documentation that says that it shouldn't be done -- do it as a part of<br>
the review.<br>
<br>
<br>
You ain't gonna need it.<br>
========================<br>
<br>
The code contains some parts that are potentially reusable later or in<br>
different areas, so you -1 it and tell the author to move them into<br>
reusable functions.<br>
<br>
The fact that you think something is reusable doesn't necessarily mean<br>
it is, and overly general code is harder to maintain. Let something<br>
repeat a couple of times just to be sure it actually is reusable. Once<br>
you find a repeating pattern, you can refactor the code to use a<br>
generalized function in its place -- in a separate change.<br>
<br>
<br>
There is an old bug here.<br>
=========================<br>
<br>
While you review the submitted code, you notice something wrong in the<br>
code not immediately related to the change you are reviewing. You -1 the<br>
change and tell the author to fix that bug, or formatting issue, or<br>
typo, or whatever.<br>
<br>
That fix has nothing to do with the change you are reviewing. The<br>
correct thing to do is to make a mental note of it, and fix it in a<br>
separate change -- possibly even finding more instances of it or coming<br>
up with a much better fix after seeing more code.<br>
<br>
<br>
Guess what I mean.<br>
==================<br>
<br>
You notice a pep8 violation, or pep257 violation, or awkward wording of<br>
a comment or docstring, or a clumsy piece of code. You -1 the change and<br>
just tell author to "fix it".<br>
<br>
It's not so easy to guess what you mean, and in case of a clumsy piece<br>
of code, not even that certain that better code can be used instead. So<br>
always provide an example of what you would rather want to see. So<br>
instead of pointing to indentation rules, just show properly indented<br>
code. Instead of talking about grammar or spelling, just type the<br>
corrected comment or docstring. Finally, instead of saying "use list<br>
comprehension here" or "don't use has_key", just type your proposal of<br>
how the code should look like. Then we have something concrete to talk<br>
about. Of course, you can also say why you think this is better, but an<br>
example is very important. If you are not sure how the improved code<br>
would look like, just let it go, chances are it would look even worse.<br>
<br>
<br>
Not a complete fix.<br>
===================<br>
<br>
The code fixes some problems (for example, fixes formatting and enables<br>
some flake8 checks), but leaves some other, related problems still not<br>
fixed. You -1 it and demand that the author adds fixes for the related<br>
problem.<br>
<br>
Don't live your coding career through the authors. If their fix is good<br>
and correct and improves the code, let it in, even if you see more<br>
opportunities to improve it. You can add those additional fixes yourself<br>
in a separate change. Or, if you don't have time or skill to do that,<br>
report a bug about the remaining problems and someone else will do it,<br>
but don't hold the author hostage with your review because you think he<br>
didn't do enough.<br>
<br>
<br>
Leaving a mark.<br>
===============<br>
<br>
You review a change and see that it is mostly fine, but you feel that<br>
since you did so much work reviewing it, you should at least find<br>
*something* wrong. So you find some nitpick and -1 the change just so<br>
that they know you reviewed it.<br>
<br>
This is quite obvious. Just don't do it. It's OK to spend an hour<br>
reviewing something, and then leaving no comments on it, because it's<br>
simply fine, or because we had to means to test someting (see the first<br>
pattern).<br>
<br>
<br>
<br>
Those are the things I'm careful about myself. I'm sure that not<br>
everyone of you will agree that all of those patterns are bad in all<br>
situations -- in fact, I'm pretty sure that some of them are sometimes<br>
warranted -- but they are always suspicious, and when I find myself<br>
falling into one of them, I always rethink what I'm doing. Maybe you<br>
have some more bad patterns that you would like to share? Reviewing code<br>
is a difficult skill and it's always good to improve it by using<br>
experience of others.<br>
<br>
--<br>
Radomir Dopieralski<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Wed, 6 Nov 2013 16:56:16 +0800<br>
From: Mark McClain <<a href="mailto:mark.mcclain@dreamhost.com">mark.mcclain@dreamhost.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Neutron] IPv6 sub-team?<br>
Message-ID: <<a href="mailto:D434A639-4C47-44F3-B094-9042B710E326@dreamhost.com">D434A639-4C47-44F3-B094-9042B710E326@dreamhost.com</a>><br>
Content-Type: text/plain;       charset=us-ascii<br>
<br>
I definitely think this should be a standing Neutron sub team.<br>
<br>
mark<br>
<br>
> On Nov 6, 2013, at 7:50 AM, "Collins, Sean (Contractor)" <<a href="mailto:Sean_Collins2@cable.comcast.com">Sean_Collins2@cable.comcast.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> Is there any interest in organizing a IPv6 sub-team, similar to how<br>
> there are sub-teams for FwaaS, VPNaas, ML2, etc?<br>
><br>
> --<br>
> Sean M. Collins<br>
> AIM: seanwdp<br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Wed, 6 Nov 2013 11:02:45 +0200<br>
From: Roman Podoliaka <<a href="mailto:rpodolyaka@mirantis.com">rpodolyaka@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [TripleO] Releases of this week<br>
Message-ID:<br>
        <<a href="mailto:CAKA_ueB07RLAnPFZCB8vgAmTdDKABUCnwTJ5km_gsTuQ3BzdhQ@mail.gmail.com">CAKA_ueB07RLAnPFZCB8vgAmTdDKABUCnwTJ5km_gsTuQ3BzdhQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hey,<br>
<br>
Cool! Thanks for sharing this!<br>
<br>
Roman<br>
<br>
On Wednesday, November 6, 2013, Sergey Lukjanov wrote:<br>
<br>
> Here is the script for processing bug while releasing -<br>
> <a href="https://github.com/ttx/openstack-releasing/blob/master/process_bugs.py" target="_blank">https://github.com/ttx/openstack-releasing/blob/master/process_bugs.py</a><br>
><br>
> Sincerely yours,<br>
> Sergey Lukjanov<br>
> Savanna Technical Lead<br>
> Mirantis Inc.<br>
><br>
> On Nov 6, 2013, at 1:42 PM, Roman Podoliaka <<a href="mailto:rpodolyaka@mirantis.com">rpodolyaka@mirantis.com</a>><br>
> wrote:<br>
><br>
> Hey,<br>
><br>
> Oh, that's a pity. I didn't know that. Sure I'll update the doc and look<br>
> for a way to automize the process.<br>
><br>
> Roman<br>
><br>
> On Wednesday, November 6, 2013, Robert Collins wrote:<br>
><br>
> Awesome work - thank you!!!<br>
><br>
> Can you please add to your docs though, that we need to go and close<br>
> the bugs in the project (either via a script or by hand) - gerrit<br>
> leaves them as Fix Committed today.<br>
><br>
> Cheers,<br>
> Rob<br>
><br>
> On 2 November 2013 04:38, Roman Podoliaka <<a href="mailto:rpodolyaka@mirantis.com">rpodolyaka@mirantis.com</a>> wrote:<br>
> > Hi all,<br>
> ><br>
> > This week I've been doing releases of all projects, which belong to<br>
> > TripleO program. Here are release notes you might be interested in:<br>
> ><br>
> >     os-collect-config  - 0.1.5 (was 0.1.4):<br>
> >         - default polling interval was reduced to 30 seconds<br>
> >         - requirements were updated to use the new iso8601 version<br>
> > fixing important bugs<br>
> ><br>
> >     diskimage-builder - 0.0.9 (was 0.0.8)<br>
> >          - added support for bad Fedora image mirrors (retry the<br>
> > request once on 404)<br>
> >          - removed dependency on dracut-network from fedora element<br>
> >          - fixed the bug with removing of lost+found dir if it's not<br>
> found<br>
> ><br>
> >     tripleo-image-elements  - 0.1.0 (was 0.0.4)<br>
> >          - switched to tftpd-hpa on Fedora and Ubuntu<br>
> >          - made it possible to disable file injection in Nova<br>
> >          - switched seed vm to Neutron native PXE<br>
> >          - added Fedora support to apache2 element<br>
> >          - fixed processing of routes in init-neutron-ovs<br>
> >          - fixed Heat watch server url key name in seed vm metadata<br>
> ><br>
> >     tripleo-heat-templates - 0.1.0 (was 0.0.1)<br>
> >          - disabled Nova Baremetal file injection (undercloud)<br>
> >          - made LaunchConfiguration resources mergeable<br>
> >          - made neutron public interface configurable (overcloud)<br>
> >          - made it possible to set public interface IP (overcloud)<br>
> >          - allowed making the public interface a VLAN (overcloud)<br>
> >          - added a wait condition for signalling that overcloud is ready<br>
> >          - added metadata for Nova floating-ip extension<br>
> >          - added tuskar API service configuration<br>
> >          - hid AdminToken in Heat templates<br>
> >          - added Ironic service configuration<br>
> ><br>
> >      tuskar - 0.0.2 (was 0.0.1)<br>
> >          - made it possible to pass Glance image id<br>
> >          - fixed the bug with duplicated Resource Class names<br>
> ><br>
> >      tuskar-ui - 0.0.2 (was 0.0.1)<br>
> >           - resource class creation form no longer ignores the image<br>
> selection<br>
> >           - separated flavors creation step<br>
> >           - fail gracefully on node detail page when no overcloud<br>
> >           - added validation of MAC addresses and CIDR values<br>
> >           - stopped appending Resource Class name to Resource Class<br>
> flavors<br>
> >           - fixed JS warnings when $ is not available<br>
> >           - fixed links and naming in Readme<br>
> >           - various code and test fixes (pep8, refactoring)<br>
> ><br>
> >       python-tuskarclient - 0.0.2 (was 0.0.1)<br>
> >           - fixed processing of 301 response code<br>
> ><br>
> >       os-apply-config and os-refresh-config haven't had new commits<br>
> > since the last release<br>
> ><br>
> > This also means that:<br>
> > 1. We are now releasing all the projects we have.<br>
> > 2. *tuskar* projects have got PyPi entries.<br>
> ><br>
> > Last but not least.<br>
> ><br>
> > I'd like to say a big thank you to Chris Jones who taught me 'Release<br>
> > Management 101' and provided patches to openstack/infra-config to make<br>
> > all our projects 'releasable'; Robert Collins for his advice on<br>
> > version numbering; Clark Boylan and Jeremy Stanley for landing of<br>
> > Gerrit ACL patches and debugging PyPi uploads issues; Radomir<br>
> > Dopieralski and Tomas Sedovic for landing a quick fix to tuskar-ui.<br>
> ><br>
> > Thank you all guys, you've helped me a lot!<br>
> ><br>
> > Roman<br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> --<br>
> Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
> Distinguished Technologist<<br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/19038b5e/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/19038b5e/attachment-0001.html</a>><br>

<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Wed, 6 Nov 2013 17:29:54 +0800<br>
From: "Ken'ichi Ohmichi" <<a href="mailto:ken1ohmichi@gmail.com">ken1ohmichi@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [qa] Duplicated test effort development<br>
Message-ID:<br>
        <<a href="mailto:CAA393vi3SkrmknF1kqymtscGZVacdCB0aCiE0yLbisdE-CbCgQ@mail.gmail.com">CAA393vi3SkrmknF1kqymtscGZVacdCB0aCiE0yLbisdE-CbCgQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Hi,<br>
<br>
2013/10/30 Christopher Yeoh <<a href="mailto:cbkyeoh@gmail.com">cbkyeoh@gmail.com</a>>:<br>
> Hi,<br>
><br>
> It looks like we have lots of people writing tests at the moment which is<br>
> great, but the downside is we're starting to see people accidentally writing<br>
> tests for the same APIs at the same time.<br>
><br>
> There is a google spreadsheet which covers the Nova v2 API where we can<br>
> reserve what tests we're working on but I don't think we have an easily<br>
> editable list for the other APIs. I don't think blueprints/bugs work so well<br>
> at this, and I don't think we have anything else setup at the moment, so as<br>
> a temporary measure I've created an etherpad here:<br>
><br>
> <a href="https://etherpad.openstack.org/p/TempestTestDevelopment" target="_blank">https://etherpad.openstack.org/p/TempestTestDevelopment</a><br>
><br>
> which links to the Nova v2 API spreadsheet and to a new etherpad for glance<br>
> apis (this would ideally be a spreadsheet as well but in the meantime would<br>
> work as a tool to avoid duplicated effort). Add new links if you're working<br>
> on new tests for other APIs.<br>
><br>
> I think it'd be a really good idea if we all checked these lists and add<br>
> what we're about to work on before starting to write new tests to avoid the<br>
> situation where we have almost identical changesets in the review queue from<br>
> different people.<br>
<br>
Thanks for preparing this etherpad page.<br>
<br>
To avoid the duplicated works of Tempest, I also have added some contents about<br>
separation negative tests from positive test files.<br>
To separate negative tests, some patches have been queued already in Gerrit.<br>
I wrote these patches' URLs on the etherpad.<br>
I'm glad if developers check this contents before starting this work.<br>
<br>
<br>
Thanks<br>
Ken'ichi Ohmichi<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Wed, 6 Nov 2013 10:41:36 +0100<br>
From: Miguel Angel <<a href="mailto:miguelangel@ajo.es">miguelangel@ajo.es</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Neutron] IPv6 sub-team?<br>
Message-ID:<br>
        <<a href="mailto:CADSDy2jjahdtiW-Cv4r4bstDoNmP7X9BTeD-9uKJNtohcDpVoA@mail.gmail.com">CADSDy2jjahdtiW-Cv4r4bstDoNmP7X9BTeD-9uKJNtohcDpVoA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
+1 from me!<br>
<br>
(I think it's my first message on the list, so Hi! ;)<br>
<br>
Miguel Angel Ajo Pelayo<br>
+34 636 52 25 69<br>
skype: ajoajoajo<br>
<br>
<br>
2013/11/6 Mark McClain <<a href="mailto:mark.mcclain@dreamhost.com">mark.mcclain@dreamhost.com</a>><br>
<br>
> I definitely think this should be a standing Neutron sub team.<br>
><br>
> mark<br>
><br>
> > On Nov 6, 2013, at 7:50 AM, "Collins, Sean (Contractor)" <<br>
> <a href="mailto:Sean_Collins2@cable.comcast.com">Sean_Collins2@cable.comcast.com</a>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > Is there any interest in organizing a IPv6 sub-team, similar to how<br>
> > there are sub-teams for FwaaS, VPNaas, ML2, etc?<br>
> ><br>
> > --<br>
> > Sean M. Collins<br>
> > AIM: seanwdp<br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/1108d2c3/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/1108d2c3/attachment-0001.html</a>><br>

<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Wed, 6 Nov 2013 10:47:28 +0100<br>
From: Peter Liljenberg <<a href="mailto:pliljenberg@gmail.com">pliljenberg@gmail.com</a>><br>
To: OpenStack Development Mailing List<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] Code Review (Jenkins-job-builder,<br>
        BlameUpstreamCommitters plugin support)<br>
Message-ID:<br>
        <<a href="mailto:CABFTCnUyZw3Pa_U6doYWDcTswtkfYUFLUecB-BVedUYMJg6nfg@mail.gmail.com">CABFTCnUyZw3Pa_U6doYWDcTswtkfYUFLUecB-BVedUYMJg6nfg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
Could someone review this please:<br>
<br>
<a href="https://review.openstack.org/#/c/54085/" target="_blank">https://review.openstack.org/#/c/54085/</a><br>
<br>
Regards,<br>
Peter<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/f55de7e4/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/f55de7e4/attachment-0001.html</a>><br>

<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Wed, 6 Nov 2013 09:47:26 +0000<br>
From: Sylvain Bauza <<a href="mailto:Sylvain.Bauza@bull.net">Sylvain.Bauza@bull.net</a>><br>
To: "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Nova] [Climate] Reservation service called<br>
        Climate<br>
Message-ID:<br>
        <<a href="mailto:B898BD2833502846B0EC7CAF416F8F4750DDFDED@BUMSG2WM.fr.ad.bull.net">B898BD2833502846B0EC7CAF416F8F4750DDFDED@BUMSG2WM.fr.ad.bull.net</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi,<br>
<br>
During the Design session <a href="https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API" target="_blank">https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API</a> 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.<br>

<br>
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).<br>
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.<br>
<br>
Climate is planning to reserve both virtual instances and physical hosts, but for the discussion we had, only physical hosts usecase is relevant.<br>
<br>
We had an unconference session today at 2pm, I can share you the slides :<br>
<br>
<a href="https://docs.google.com/presentation/d/1BJGmtzGees6tg_Np7JuKFtuLGiCaguVYD8hYJ2eVKAc/edit#slide=id.p" target="_blank">https://docs.google.com/presentation/d/1BJGmtzGees6tg_Np7JuKFtuLGiCaguVYD8hYJ2eVKAc/edit#slide=id.p</a><br>

<br>
(please focus on slides 11-14, they're talking on the design for host reservations)<br>
<br>
All the code is located on Stackforge, but please note the most important part of physical host reservations is still under review there :<br>
<a href="https://review.openstack.org/#/q/project:+stackforge/climate+status:open,n,z" target="_blank">https://review.openstack.org/#/q/project:+stackforge/climate+status:open,n,z</a><br>
<br>
(We're missing reviewers, by the way !)<br>
<br>
<br>
I'm open to discuss and waiting your thoughts,<br>
-Sylvain<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/4a2a2c47/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/4a2a2c47/attachment-0001.html</a>><br>

<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Wed, 6 Nov 2013 16:14:59 +0530<br>
From: Kanika Saklani <<a href="mailto:kanika.saklani11@gmail.com">kanika.saklani11@gmail.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] Facing issue in creating router in openstack<br>
        dasboard<br>
Message-ID:<br>
        <CADreVOssjgVa9U9rZg=<a href="mailto:OeW_AcucPqdS_-JXTUczm6nEtM%2Bn5Cw@mail.gmail.com">OeW_AcucPqdS_-JXTUczm6nEtM+n5Cw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi All,<br>
<br>
i am new to openstack. i installed the openstack in x86 for that  i do the<br>
following step to download and  install the grizzly as follows:-<br>
<br>
   -  $ wget<br>
   <a href="https://github.com/openstack-dev/devstack/archive/stable/grizzly.zip" target="_blank">https://github.com/openstack-dev/devstack/archive/stable/grizzly.zip</a><br>
   -  $unzip grizzly.zip<br>
   -  $cd devstack-stable-grizzly<br>
<br>
in this directory devstack-stable-grizzly i made a localrc where i did the<br>
following configuration:-<br>
<br>
   -  $ vim localrc<br>
<br>
*disable_service n-net<br>
enable_service q-svc<br>
enable_service q-dhcp<br>
enable_service neutron<br>
enable_service bigswitch_floodlight<br>
Q_PLUGIN=bigswitch_floodlight<br>
Q_USE_NAMESPACE=False<br>
NOVA_USE_NEUTRON_API=v2<br>
SCHEDULER=nova.scheduler.simple.SimpleScheduler<br>
MYSQL_PASSWORD=<password><br>
RABBIT_PASSWORD=<password><br>
ADMIN_PASSWORD=<password><br>
SERVICE_PASSWORD=<password><br>
SERVICE_TOKEN=tokentoken<br>
DEST=/opt/stack<br>
SCREEN_LOGDIR=$DEST/logs/screen<br>
SYSLOG=True<br>
#IP:Port for the BSN controller<br>
#if more than one, separate with commas<br>
BS_FL_CONTROLLERS_PORT=<ip_address:port><br>
BS_FL_CONTROLLER_TIMEOUT=10*<br>
<br>
<br>
Then after that i run the openvswitch-1.11.0 by this command:-<br>
<br>
<br>
   -  $ cd openvswitch-1.11.0/utilitie<br>
   -  $./ovs-ctl start<br>
<br>
After that i run the following command in the directory devstack-stable-grizzly<br>
<br>
   - $ ./stack.sh<br>
<br>
then i get this message:-<br>
<br>
*Horizon is now available at <a href="http://192.168.6.122/" target="_blank">http://192.168.6.122/</a> <<a href="http://192.168.6.122/" target="_blank">http://192.168.6.122/</a>> *<br>
*Keystone is serving at <a href="http://192.168.6.122:5000/v2.0/" target="_blank">http://192.168.6.122:5000/v2.0/</a><br>
<<a href="http://192.168.6.122:5000/v2.0/" target="_blank">http://192.168.6.122:5000/v2.0/</a>>*<br>
*Examples on using novaclient command line is in exercise.sh*<br>
*The default users are: admin and demo *<br>
*The password: kanika *<br>
*This is your host ip: 192.168.6.122 stack.sh completed in 490 seconds.*<br>
<br>
<br>
i also get a login window of open stack then i login with admin &<br>
password kanika.<br>
<br>
<br>
As i see the demo of grizzly in youtube the link are<br>
(<a href="https://www.youtube.com/watch?v=p4eW78gHfCg" target="_blank">https://www.youtube.com/watch?v=p4eW78gHfCg</a> ) they are doing the<br>
following steps:-<br>
<br>
<br>
step1:- they have created the volume first of 5GB space i also did the same.<br>
<br>
 i have attaching the screen shot for this<br>
<br>
<br>
Step2:- then they have done the router configuration, here i got<br>
stucked, I am unable to create router<br>
<br>
I am attaching the screen shot for this as well<br>
<br>
<br>
can you please look into my issue as suggest me how can i get out of this.<br>
<br>
looking forward for your positive reply.<br>
<br>
<br>
--<br>
Regards<br>
Kanika<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0af69113/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0af69113/attachment-0001.html</a>><br>

-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: volume_create.png<br>
Type: image/png<br>
Size: 54354 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0af69113/attachment-0002.png" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0af69113/attachment-0002.png</a>><br>

-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: router_create.png<br>
Type: image/png<br>
Size: 52440 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0af69113/attachment-0003.png" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0af69113/attachment-0003.png</a>><br>

<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Wed, 6 Nov 2013 11:15:08 +0000<br>
From: Joshua Harlow <<a href="mailto:harlowja@yahoo-inc.com">harlowja@yahoo-inc.com</a>><br>
To: OpenStack Development Mailing List<br>
        <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [State-Management] Slides from taskflow<br>
        speaker session<br>
Message-ID: <<a href="mailto:86C4F964-42CE-4D55-A2C1-65BF8C40E68B@yahoo-inc.com">86C4F964-42CE-4D55-A2C1-65BF8C40E68B@yahoo-inc.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Thanks all for showing up!<br>
<br>
<a href="http://www.slideshare.net/harlowja/taskflow-27820295" target="_blank">http://www.slideshare.net/harlowja/taskflow-27820295</a><br>
<br>
Not sure if there is an official page for this, anyway link is above (likely video link somewhere also).<br>
<br>
Questions, comments, feedback welcome! Thxs all for making this possible :-)<br>
<br>
-josh<br>
<br>
Sent from my really tiny device...<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
End of OpenStack-dev Digest, Vol 19, Issue 10<br>
*********************************************<br>
<br>
<br>
<br>
<br>
===============================================================================<br>
Please refer to <a href="http://www.aricent.com/legal/email_disclaimer.html" target="_blank">http://www.aricent.com/legal/email_disclaimer.html</a><br>
for important disclosures regarding this electronic communication.<br>
===============================================================================<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>