Re: [openstack-dev] [Neutron] Jenkins randomly fails?

[Michael Bright]

Hi Siming,

Yes there are some intermittent test failures which may be due to
infrastructure and/or bugs.

Here's my suggestion from recent experiences as a Noob.

The e-mail you got from Jenkins includes this line, with a link telling you
what to do:
Build failed.  For information on how to proceed, see
https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures

In your case, at least for https://review.openstack.org/#/c/55370/ it seems
that the build system recognized the
failure as likely being due to a known bug #1239637.
You should check the failing log file, which you can access via the link
given in the e-mail or on the above 55370 change page:

   - 
check-tempest-devstack-vm-neutron-pg
FAILURE in 18m 27s

to verify that this is indeed the same bug which has caused your build to
fail.

If this is the case, you can click on the "Review" button (for your patch
set) and set Code to 0, add a comment ("Cover Message"):
Recheck bug #x
that's
Recheck bug #1239637
in your case (the bug number suggested by the "Elastic recheck").

Hopefully that will pass.

I hope this helps, I'm learning too ...
Regards,
Mike.



On 7 November 2013 08:09, Siming Yin  wrote:

> Hi all,
>
> Please have a look at these two changes:
>
> https://review.openstack.org/#/c/55370/
> https://review.openstack.org/#/c/55221/
>
> The only change is to remove 4 duplicate definitions.  I'm sure this will
> not cause any new problems, but it seems like the tests are randomly
> failing in jenkins.
>
> Could anyone tell me how to handle this?
>
> Thanks,
>
> Siming
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] iso8601 filling up nova logs

[Tracy Jones]

My nova logs are full of this - is it ok if I make a change to the default log 
level to set iso8601 to WARN?

2:39:54.683 DEBUG iso8601.iso8601 [-] Parsed 2013-11-06T06:38:00Z into 
{'tz_sign': None, 'second_fraction': None, 'hour': u'06', 'tz_hour': None, 
'month': u'11', 'timezone': u'Z', 'second': u'00', 'tz_minute': None, 'year': 
u'2013', 'separator': u'T', 'day': u'06', 'minute': u'38'} with default 
timezone  from (pid=14941) parse_date 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:166
2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'2013' for 'year' with 
default None from (pid=14941) to_int 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'11' for 'month' with 
default None from (pid=14941) to_int 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.684 DEBUG iso8601.iso8601 [-] Got u'06' for 'day' with 
default None from (pid=14941) to_int 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'06' for 'hour' with 
default None from (pid=14941) to_int 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'38' for 'minute' with 
default None from (pid=14941) to_int 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.685 DEBUG iso8601.iso8601 [-] Got u'00' for 'second' with 
default None from (pid=14941) to_int 
/usr/local/lib/python2.7/dist-packages/iso8601/iso8601.py:124
2013-11-05 22:39:54.686 DEBUG iso8601.iso8601 [-] Parsed 2013-11-0

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[Daniel P. Berrange]

On Thu, Nov 07, 2013 at 12:21:38AM +, Day, Phil wrote:
> > 
> > Leaving a mark.
> > ===
> > 
> > You review a change and see that it is mostly fine, but you feel that since 
> > you
> > did so much work reviewing it, you should at least find
> > *something* wrong. So you find some nitpick and -1 the change just so that
> > they know you reviewed it.
> > 
> > This is quite obvious. Just don't do it. It's OK to spend an hour reviewing
> > something, and then leaving no comments on it, because it's simply fine, or
> > because we had to means to test someting (see the first pattern).
> > 
> > 
> 
> Another one that comes into this category is adding a -1 which just says "I 
> agree with
> the other -1's in here".   If you have some additional perspective and can 
> expand on
> it then that's fine - otherwise it adds very little and is just review count 
> chasing.

I don't think that it is valueless as you describe. If I multiple people
add '-1' with a "same comments as ", then as a core reviewer I will
consider that initial -1 to be a much stronger nack, than if only one person
had added the -1. So I welcome people adding "I agree with " to any
review.

> It's an unfortunate consequence of counting and publishing review stats that 
> having
> such a measure will inevitable also drive behavour.

IMHO what this shows is not people trying to game the stats, but rather the
inadequacy of gerrit. We don't have any way to distinguish a "-1 minor nice
to have nitpick" from a "-1 serious code issue that is a must-fix". Adding
a -2 is really too heavyweight because it is sticky, and implies "do not
ever merge this".

It would be nice to be able to use '-2' for "serious must-fix issue" without
it being sticky, and have a separate way for core reviewers to put an review
into a "block from being merged indefinitely" state - perhaps a new state
would be more useful eg a "Blocked" state, to add to New, Open, Merged,
Abadoned.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Jenkins randomly fails?

[Siming Yin]

Hi all,

Please have a look at these two changes:

https://review.openstack.org/#/c/55370/
https://review.openstack.org/#/c/55221/

The only change is to remove 4 duplicate definitions.  I'm sure this will
not cause any new problems, but it seems like the tests are randomly
failing in jenkins.

Could anyone tell me how to handle this?

Thanks,

Siming
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Mistral] Unconference track slides

[Renat Akhmerov]

Hi,

A lot of people here in Hong Kong keep asking me to share the slides that I 
presented within Unconference track so here they are:

http://www.slideshare.net/RenatAkhmerov/mistral-hong-kong-unconference-track

Just in case if you just got familiar with Mistral here’s the project Launchpad 
page: launchpad.net/Mistral

Please let us know if you’re interested in some particular things about 
Mistral, I’ll be happy to tell you everything.


Thanks,
Renat Akhmerov
@ Mirantis Inc.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[James Bottomley]

On Thu, 2013-11-07 at 00:21 +, Day, Phil wrote:
> > 
> > Leaving a mark.
> > ===
> > 
> > You review a change and see that it is mostly fine, but you feel that since 
> > you
> > did so much work reviewing it, you should at least find
> > *something* wrong. So you find some nitpick and -1 the change just so that
> > they know you reviewed it.
> > 
> > This is quite obvious. Just don't do it. It's OK to spend an hour reviewing
> > something, and then leaving no comments on it, because it's simply fine, or
> > because we had to means to test someting (see the first pattern).
> > 
> > 
> 
> Another one that comes into this category is adding a -1 which just says "I 
> agree with
> the other -1's in here".   If you have some additional perspective and can 
> expand on
> it then that's fine - otherwise it adds very little and is just review count 
> chasing.
> 
> It's an unfortunate consequence of counting and publishing review stats that 
> having
> such a measure will inevitable also drive behavour.

Perhaps a source of the problem is early voting.  Feeling pressure to
add a +/-1 (or even 2) without fully asking what's going on in the code
leads to premature adjudication.

For instance, I have to do a lot of reviews in SCSI; I'm a subject
matter expert, so I do recognise some bad coding patterns and ask for
them to be changed unconditionally, but a lot of the time I don't
necessarily understand why the code was done in the way it was, so I
ask.  Before I get the answer I'm not really qualified to judge the
merits.

James



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum]: Workshop dates at SFO

[Roshan Agrawal]

Clayton, correct. We may end up sticking to the original dates; I wanted to 
arrive at the decision based on collective input. 

From: Clayton Coleman [ccole...@redhat.com]
Sent: Wednesday, November 06, 2013 9:14 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Solum]: Workshop dates at SFO

Some of us have already booked travel?

> On Nov 7, 2013, at 10:46 AM, Roshan Agrawal  
> wrote:
>
> Folks, some of us indicated they cannot make Nov 19,20, so I created a doodle 
> poll to finalize a date that works for most of us. Please take a moment to 
> indicate your preference on the doodle link below -
>
> http://www.doodle.com/6yey9nfgfapzv4f8
>
> Please get this done by EOD if you can.
>
> Thanks,
> Roshan
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] RE : [Nova] [Climate] Reservation service called Climate

[Dina Belova]

I mean not in the ether pad, but in your letter :) It's 1:30, not 1:50 PM.


On Thu, Nov 7, 2013 at 1:04 PM, Dina Belova  wrote:

> I think that's some kind of typo in
> https://etherpad.openstack.org/p/NovaIcehouseSummitUnconference - there
> is 1:30 PM time there for the Friday.
>
>
> On Thu, Nov 7, 2013 at 12:13 PM, Sylvain Bauza wrote:
>
>>  Being at my first summit, I haven't noticed there were Nova
>> unconference timeslots for discussing various stuff. My bad.
>>
>> I proposed tomorrow 1.50pm to discuss around the reservation service
>> itself and how we plan to use host aggregates (or pclouds) for our needs.
>>
>> -Sylvain
>>
>>  --
>> *De :* Sylvain Bauza [sylvain.ba...@bull.net]
>> *Date d'envoi :* mercredi 6 novembre 2013 10:47
>> *À :* openstack-dev@lists.openstack.org
>> *Objet :* [openstack-dev] [Nova] [Climate] Reservation service called
>> Climate
>>
>>   Hi,
>>
>> During the Design session
>> https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API we
>> discussed the fact that this is not the role of Nova for doing atomic
>> reservations in order to ensure the user needs will be met.
>>
>> I raised the point (and sorry for my bad accent, was stressy) that we're
>> already trying to provide a reservation system for Openstack, called
>> Climate (a Stackforge project).
>> I would really like to discuss with you all, Nova community, about the
>> reservation system and ensure that we, at Climate, are on the good path.
>>
>> Climate is planning to reserve both virtual instances and physical hosts,
>> but for the discussion we had, only physical hosts usecase is relevant.
>>
>> We had an unconference session today at 2pm, I can share you the slides :
>>
>>
>> https://docs.google.com/presentation/d/1BJGmtzGees6tg_Np7JuKFtuLGiCaguVYD8hYJ2eVKAc/edit#slide=id.p
>>
>> (please focus on slides 11-14, they're talking on the design for host
>> reservations)
>>
>> All the code is located on Stackforge, but please note the most important
>> part of physical host reservations is still under review there :
>>
>> https://review.openstack.org/#/q/project:+stackforge/climate+status:open,n,z
>>
>> (We're missing reviewers, by the way !)
>>
>>
>> I'm open to discuss and waiting your thoughts,
>> -Sylvain
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> Best regards,
>
> Dina Belova
>
> Software Engineer
>
> Mirantis Inc.
>



-- 

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] RE : [Nova] [Climate] Reservation service called Climate

[Dina Belova]

I think that's some kind of typo in
https://etherpad.openstack.org/p/NovaIcehouseSummitUnconference - there is
1:30 PM time there for the Friday.


On Thu, Nov 7, 2013 at 12:13 PM, Sylvain Bauza wrote:

>  Being at my first summit, I haven't noticed there were Nova unconference
> timeslots for discussing various stuff. My bad.
>
> I proposed tomorrow 1.50pm to discuss around the reservation service
> itself and how we plan to use host aggregates (or pclouds) for our needs.
>
> -Sylvain
>
>  --
> *De :* Sylvain Bauza [sylvain.ba...@bull.net]
> *Date d'envoi :* mercredi 6 novembre 2013 10:47
> *À :* openstack-dev@lists.openstack.org
> *Objet :* [openstack-dev] [Nova] [Climate] Reservation service called
> Climate
>
>   Hi,
>
> During the Design session
> https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API we
> discussed the fact that this is not the role of Nova for doing atomic
> reservations in order to ensure the user needs will be met.
>
> I raised the point (and sorry for my bad accent, was stressy) that we're
> already trying to provide a reservation system for Openstack, called
> Climate (a Stackforge project).
> I would really like to discuss with you all, Nova community, about the
> reservation system and ensure that we, at Climate, are on the good path.
>
> Climate is planning to reserve both virtual instances and physical hosts,
> but for the discussion we had, only physical hosts usecase is relevant.
>
> We had an unconference session today at 2pm, I can share you the slides :
>
>
> https://docs.google.com/presentation/d/1BJGmtzGees6tg_Np7JuKFtuLGiCaguVYD8hYJ2eVKAc/edit#slide=id.p
>
> (please focus on slides 11-14, they're talking on the design for host
> reservations)
>
> All the code is located on Stackforge, but please note the most important
> part of physical host reservations is still under review there :
>
> https://review.openstack.org/#/q/project:+stackforge/climate+status:open,n,z
>
> (We're missing reviewers, by the way !)
>
>
> I'm open to discuss and waiting your thoughts,
> -Sylvain
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Best regards,

Dina Belova

Software Engineer

Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] RE : [Nova] [Climate] Reservation service called Climate

[Sylvain Bauza]

Being at my first summit, I haven't noticed there were Nova unconference 
timeslots for discussing various stuff. My bad.

I proposed tomorrow 1.50pm to discuss around the reservation service itself and 
how we plan to use host aggregates (or pclouds) for our needs.

-Sylvain


De : Sylvain Bauza [sylvain.ba...@bull.net]
Date d'envoi : mercredi 6 novembre 2013 10:47
À : openstack-dev@lists.openstack.org
Objet : [openstack-dev] [Nova] [Climate] Reservation service called Climate

Hi,

During the Design session 
https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API we discussed 
the fact that this is not the role of Nova for doing atomic reservations in 
order to ensure the user needs will be met.

I raised the point (and sorry for my bad accent, was stressy) that we're 
already trying to provide a reservation system for Openstack, called Climate (a 
Stackforge project).
I would really like to discuss with you all, Nova community, about the 
reservation system and ensure that we, at Climate, are on the good path.

Climate is planning to reserve both virtual instances and physical hosts, but 
for the discussion we had, only physical hosts usecase is relevant.

We had an unconference session today at 2pm, I can share you the slides :

https://docs.google.com/presentation/d/1BJGmtzGees6tg_Np7JuKFtuLGiCaguVYD8hYJ2eVKAc/edit#slide=id.p

(please focus on slides 11-14, they're talking on the design for host 
reservations)

All the code is located on Stackforge, but please note the most important part 
of physical host reservations is still under review there :
https://review.openstack.org/#/q/project:+stackforge/climate+status:open,n,z

(We're missing reviewers, by the way !)


I'm open to discuss and waiting your thoughts,
-Sylvain

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum]: Workshop dates at SFO

[Clayton Coleman]

Some of us have already booked travel?

> On Nov 7, 2013, at 10:46 AM, Roshan Agrawal  
> wrote:
> 
> Folks, some of us indicated they cannot make Nov 19,20, so I created a doodle 
> poll to finalize a date that works for most of us. Please take a moment to 
> indicate your preference on the doodle link below -
> 
> http://www.doodle.com/6yey9nfgfapzv4f8
> 
> Please get this done by EOD if you can.
> 
> Thanks,
> Roshan
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[David Stanek]

On Wed, Nov 6, 2013 at 7:21 PM, Day, Phil  wrote:

> >
> > Leaving a mark.
> > ===
> >
> > You review a change and see that it is mostly fine, but you feel that
> since you
> > did so much work reviewing it, you should at least find
> > *something* wrong. So you find some nitpick and -1 the change just so
> that
> > they know you reviewed it.
> >
> > This is quite obvious. Just don't do it. It's OK to spend an hour
> reviewing
> > something, and then leaving no comments on it, because it's simply fine,
> or
> > because we had to means to test someting (see the first pattern).
> >
> >
>
> Another one that comes into this category is adding a -1 which just says
> "I agree with
> the other -1's in here".   If you have some additional perspective and can
> expand on
> it then that's fine - otherwise it adds very little and is just review
> count chasing.
>
> It's an unfortunate consequence of counting and publishing review stats
> that having
> such a measure will inevitable also drive behavour.


I agree that having no comment with a +1 is OK.  If I think the code looks
good I'll +1 it.  If I think the code could be better I'll -1 it and leave
comments.

I don't think that leaving a -1 with a 'what they said' comment is a bad
thing.  As the developer writing the patch it's helpful to know there is a
consensus and it's not just one person requesting a change.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Solum]: Workshop dates at SFO

[Roshan Agrawal]

Folks, some of us indicated they cannot make Nov 19,20, so I created a doodle 
poll to finalize a date that works for most of us. Please take a moment to 
indicate your preference on the doodle link below -

http://www.doodle.com/6yey9nfgfapzv4f8

Please get this done by EOD if you can.

Thanks,
Roshan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Nova SSL Apache2 Question

[Miller, Mark M (EB SW Cloud - R&D - Corvallis)]

Hi Anne,

Thanks for the pointer but I am looking for directions for Nova running on a 
different node than the rest of OpenStack so it needs to be standalone.

Mark

> -Original Message-
> From: Anne Gentle [mailto:annegen...@justwriteclick.com]
> Sent: Wednesday, November 06, 2013 4:41 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: OpenStack Development Mailing List; openstack...@lists.openstack.org
> Subject: Re: [openstack-dev] Nova SSL Apache2 Question
> 
> Hi Mark, try this and let us know.
> 
> http://docs.openstack.org/grizzly/openstack-
> compute/install/yum/content/installing-openstack-dashboard.html
> 
> Anne Gentle
> Content Stacker
> a...@openstack.org
> 
> 
> > On Nov 7, 2013, at 8:20 AM, "Miller, Mark M (EB SW Cloud - R&D -
> Corvallis)"  wrote:
> >
> > Hello,
> >
> > I am trying to front all of the Grizzly OpenStack services with Apache2 in
> order to enable SSL. I've got Horizon and Keystone working but am struggling
> with Nova. The only documentation I have been able to find is at URL
> http://www.rackspace.com/blog/enabling-ssl-for-the-openstack-api/
> >
> > However, the Nova sample "osapi.wsgi" and "osapi" files are not working
> with Grizzly. Does anyone have a set of these files for Nova?
> >
> > Thanks,
> >
> > Mark Miller
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] [Neutron] Security groups issue when running latest libvirt?

[Martinx - ジェームズ]

That is true... Back to "LibvirtHybridOVSBridgeDriver", Security Groups is
working again...


On 6 November 2013 15:03, Simon Pasquier  wrote:

> Answering myself as I investigated a little further and cross-posting to
> openstack-dev because I'd like to get feedback from Nova/Neutron devs.
>
> Users running Havana should configure libvirt_vif_driver=nova.virt.
> libvirt.vif.LibvirtHybridOVSBridgeDriver.
> This driver is still available in the Havana release although deprecated.
> AFAIU, this is the only option if you want effective security groups with
> KVM & OVS.
>
> For people using the master branch of nova, sorry but security groups are
> currently broken because LibvirtHybridOVSBridgeDriver is gone ([0]). Joe
> Gordon asked the Neutron devs about it few weeks ago [1] but no answer and
> in another review [2], the conclusion was that the Tempest tests passed
> with Neutron. However I don't see anywhere in the tests ([3], [4]) that we
> check if the security rules allow/block traffic.
>
> It would be nice if core devs could confirm or refute.
>
> Regards,
>
> Simon
>
> [0] https://review.openstack.org/#/c/49660/
> [1] http://lists.openstack.org/pipermail/openstack-dev/2013-
> October/016886.html
> [2] https://review.openstack.org/#/c/44349
> [3] https://github.com/openstack/tempest/blob/master/tempest/
> api/network/test_security_groups.py
> [4] https://github.com/openstack/tempest/blob/master/tempest/
> api/network/test_security_groups_negative.py
>
> Le 05/11/2013 14:57, Simon Pasquier a écrit :
>
>  Hi all,
>>
>> I'm struggling with security groups on Havana with Neutron and OVS
>> plugin (GRE tunnels). No problem to create/delete security group rules
>> but even though iptables configuration is updated, traffic to my
>> instances is never filtered [0].
>>
>> I'm running DevStack on 2 nodes (1 controller + 1 compute):
>> - OS: Ubuntu 12.04.3 (LTS) with the Havana cloud archive repository.
>> - Open vSwitch package version: 1.10.2-0ubuntu2~cloud0
>> - libvirt package version: 1.1.1-0ubuntu8~cloud2
>> - localrc, nova.conf, neutron.conf and ovs_neutron_plugin.ini files
>> pasted at [1] (I didn't modify any of these files after the DevStack run)
>>
>> According to [2], [3] and [4], iptables is not compatible with TAP
>> devices connectd directly to Open vSwitch ports, this is why there used
>> to be the additional veth + bridge interfaces [5]. But in my setup, this
>> is not the case anymore as shown in [6] ('ovs-vsctl show' +
>> 'iptables-save' ouptut). I've also pasted the libvirt XML configuration
>> [7] that shows that the instance is directly connected to the Open
>> vSwitch.
>>
>> Are the security groups supposed to work when the instance is directly
>> connected to OVS? If yes, what am I doing wrong?
>>
>> Regards,
>>
>> [0] http://paste.openstack.org/show/50490/
>> [1] http://paste.openstack.org/show/50448/
>> [2] http://www.spinics.net/linux/fedora/libvirt-users/msg05384.html
>> [3] http://openvswitch.org/pipermail/discuss/2013-October/011461.html
>> [4]
>> http://docs.openstack.org/havana/config-reference/content/under_the_hood_
>> openvswitch.html
>>
>> [5]
>> http://docs.openstack.org/havana/config-reference/
>> content/figures/7/a/a/common/figures/under-the-hood-
>> scenario-2-ovs-compute.png
>>
>> [6] http://paste.openstack.org/show/50486/
>> [7] http://paste.openstack.org/show/50487/
>>
>
>
> --
> Simon Pasquier
> Software Engineer
> Bull, Architect of an Open World
> Phone: + 33 4 76 29 71 49
> http://www.bull.com
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Nova SSL Apache2 Question

[Anne Gentle]

Hi Mark, try this and let us know.

http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/installing-openstack-dashboard.html

Anne Gentle
Content Stacker
a...@openstack.org


> On Nov 7, 2013, at 8:20 AM, "Miller, Mark M (EB SW Cloud - R&D - Corvallis)" 
>  wrote:
> 
> Hello,
> 
> I am trying to front all of the Grizzly OpenStack services with Apache2 in 
> order to enable SSL. I've got Horizon and Keystone working but am struggling 
> with Nova. The only documentation I have been able to find is at URL 
> http://www.rackspace.com/blog/enabling-ssl-for-the-openstack-api/
> 
> However, the Nova sample "osapi.wsgi" and "osapi" files are not working with 
> Grizzly. Does anyone have a set of these files for Nova?
> 
> Thanks,
> 
> Mark Miller
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[Day, Phil]

> 
> Leaving a mark.
> ===
> 
> You review a change and see that it is mostly fine, but you feel that since 
> you
> did so much work reviewing it, you should at least find
> *something* wrong. So you find some nitpick and -1 the change just so that
> they know you reviewed it.
> 
> This is quite obvious. Just don't do it. It's OK to spend an hour reviewing
> something, and then leaving no comments on it, because it's simply fine, or
> because we had to means to test someting (see the first pattern).
> 
> 

Another one that comes into this category is adding a -1 which just says "I 
agree with
the other -1's in here".   If you have some additional perspective and can 
expand on
it then that's fine - otherwise it adds very little and is just review count 
chasing.

It's an unfortunate consequence of counting and publishing review stats that 
having
such a measure will inevitable also drive behavour.

Phil

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Nova SSL Apache2 Question

[Miller, Mark M (EB SW Cloud - R&D - Corvallis)]

Hello,

I am trying to front all of the Grizzly OpenStack services with Apache2 in 
order to enable SSL. I've got Horizon and Keystone working but am struggling 
with Nova. The only documentation I have been able to find is at URL 
http://www.rackspace.com/blog/enabling-ssl-for-the-openstack-api/

However, the Nova sample "osapi.wsgi" and "osapi" files are not working with 
Grizzly. Does anyone have a set of these files for Nova?

Thanks,

Mark Miller

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[Day, Phil]

> -Original Message-
> From: Robert Collins [mailto:robe...@robertcollins.net]
> Sent: 06 November 2013 22:08
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Bad review patterns
> 
> On 6 November 2013 21:34, Radomir Dopieralski 
> wrote:
> > Hello,
> 
> Secondly, this:
> 
> >
> > Leaving a mark.
> > ===
> >
> > You review a change and see that it is mostly fine, but you feel that
> > since you did so much work reviewing it, you should at least find
> > *something* wrong. So you find some nitpick and -1 the change just so
> > that they know you reviewed it.
> 
> Thats indeed not cool. Perhaps a 0 with the nitpick. On the other hand,
> perhaps the nitpick actually matters. If it's a nitpick it's going to be what 
> - a
> couple minutes to fix and push ?
> 
> ... I think the real concern is that by pushing it up again you go to the 
> back of
> the queue for reviews, so maybe we should talk about that instead. We
> don't want backpressure on folk polishing a patch on request because of
> review latency.
> 
> > This is quite obvious. Just don't do it. It's OK to spend an hour
> > reviewing something, and then leaving no comments on it, because it's
> > simply fine, or because we had to means to test someting (see the
> > first pattern).
> 
> Core reviewers look for the /comments/ from people, not just the votes. A
> +1 from someone that isn't core is meaningless unless they are known to be
> a thoughtful code reviewer. A -1 with no comment is also bad, because it
> doesn't help the reviewee get whatever the issue is fixed.
> 
> It's very much not OK to spend an hour reviewing something and then +1
> with no comment: if I, and I think any +2er across the project see a patch 
> that
> needs an hour of review, with a commentless +1, we'll likely discount the +1
> as being meaningful.
> 

I don't really get what you're saying here Rob.   It seems to me an almost 
inevitable
part of the review process that useful comments are going to be mostly negative.
If someone has invested that amount of effort because the patch is complex, or
It took then a while to work their way back into that part of the systems, etc, 
but 
having given the code careful consideration they decide it's good - do you want
comments in there saying "I really like your code", "Well done on fixing such a 
 
complex problem" or some such ?

I just don't see how you can use a lack or presence of positive feedback in a 
+1 as 
any sort of indication on the quality of that +1.   Unless you start asking 
reviewers
to précis the change in their own words to show that they understood it I don't 
really see how additional positive comments help in most cases.   Perhaps if you
have some specific examples of this it would help to clarify

Phil


 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] RFC: reverse the default Gerrit sort order

[Robert Collins]

I've been thinking about review queues recently (since here at the
summit everyone is talking about reviews! :)).

One thing that struck me today was that Gerrit makes it easier to
review the newest changes first, rather than the changes that have
been in the queue longest, or the changes that started going through
the review process first.

So... is it possible to change the default sort order for Gerrit? How
hard is it to do - could we do an experiment on that and see if it
nudges the dial for reviewstats (just make the change, not ask anyone
to change their behaviour)?

As for what sort order to choose, I'd be happy just getting data on a
different default sort order - it seems like the easiest thing would
be to reverse the current order, vs doing something more
sophisticated.

If folk are about to jump up and say 'hey, reviewday' or 'hey
next-review' : I specifically want to see what the effect on changing
the Gerrit web UI is, because my sense is that that is the default
place folk do reviews, and I want to change the default-experience
folk have, not the optional experience folk can opt into.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Code Review (Jenkins-job-builder, BlameUpstreamCommitters plugin support)

[XINYU ZHAO]

Hi Peter,
Could you explain more about the scenario this plugin fits in existing
openstack jenkins jobs? I haven't seen any jobs with upstream , except
devstack-gate related slave usage status transition jobs, which are already
superseded by nodepool.

IRC channel openstack-infra and mailing list openstack-infra are also
better way to get infra core reviewers' attention, but you probably have to
wait since most of them are in the summit right now.



On Wed, Nov 6, 2013 at 1:47 AM, Peter Liljenberg wrote:

> Hi,
>
> Could someone review this please:
>
> https://review.openstack.org/#/c/54085/
>
> Regards,
> Peter
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] A Tool for Making OpenStack Log Reading a Bit Easier

[Sean Dague]

First, very cool tool, nice work!

I wonder if it's reasonable (or interesting) to take these approaches
and bring them into os-loganalyze. That would mean there was common
parsing routines, and then we would just call out to different
functions if were were trying to do HTML or ANSI coloring. I
personally live so often off the weblogs that I honestly hadn't
thought about the local case, which would be definitely interesting.
It would also be really great if adding semantics to one use did it
for the other as well, so people would see the same output when they
were looking at test failures as when they were doing local
development.

If you are interested in trying to join efforts there, let me know.

On Wed, Nov 6, 2013 at 9:36 AM, Joe Gordon  wrote:
>
>
>
> On Wed, Nov 6, 2013 at 9:10 AM, Clint Byrum  wrote:
>>
>> I often use ccze to look at logs. It has some built in things like
>> coloring the words "warn" or "warning" yellow and "error" red. It would
>> be great to have this filter added as another ccze plugin.
>>
>
> Sean Dague, wrote a really slick tool for logs.openstack.org that is
> similar:
>
> http://git.openstack.org/cgit/openstack-infra/os-loganalyze/tree/README.rst
>
> http://logs.openstack.org/98/54198/7/check/check-tempest-devstack-vm-neutron/a153156/logs/screen-q-svc.txt.gz?level=TRACE
>
>>
>> Excerpts from Solly Ross's message of 2013-11-06 05:58:02 +0800:
>> > Hello All,
>> > The other day, I was reading through a debug-level OpenStack log, and
>> > came to the realization that reading OpenStack debug-level logs was
>> > difficult, to say the least -- they can be very busy, and it is hard to
>> > quickly filter out relevant information.  Thus, I wrote a little Perl 
>> > script
>> > to make reading dense debug-level logs a bit easier:
>> > https://github.com/DirectXMan12/os_log_prettifier.  I figured that I'd 
>> > share
>> > it with other people.  Basically, the script highlights certain key details
>> > using color and bolding (via ANSI control codes), and can filter lines 
>> > based
>> > on subject (in the form of 'x.y.z') or message type, using regular
>> > expressions.  I hope people find it useful!
>> >
>> > Best Regards,
>> > Solly Ross
>> >
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum]: Welcome to the community site for Solum !!

[Adrian Otto]

Brent,

Thank you for putting together such a clear and thoughtful post. Your article 
was quoted and included on the Solum.io community site, and has inspired other 
new contributors as well.  Viewpoints like yours help illustrate that this 
effort is really about working together to address common needs that we agree 
on and care about. We are proud to have you as part of our community and look 
forward to working closely with you.

Adrian

On Nov 6, 2013, at 2:26 AM, Brent Smithurst 
mailto:bre...@activestate.com>> wrote:

This is great! I was waiting for the site to go live so I'd have a nice place 
to link our "Why Would ActiveState Join Project Solum?" blog post:

http://www.activestate.com/blog/2013/11/why-would-activestate-join-openstacks-project-solum

We're looking forward to this as it gains momentum.

Brent


On Mon, Nov 4, 2013 at 5:25 PM, Roshan Agrawal 
mailto:roshan.agra...@rackspace.com>> wrote:
The community site for Solum has gone live! www.Solum.io  
- this is a landing page for all things Solum related.

Also check out the blog section on the site.

The logo: is a placeholder for now. We are working on a cool new logo - but the 
placeholder right now isn't too bad either, is it?



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[Robert Collins]

On 6 November 2013 21:34, Radomir Dopieralski  wrote:
> Hello,
>
> I'm quite new in the OpenStack project, but I love it already. What is
> especially nifty is the automated review system -- I'm really impressed.
> I'm coming from a project in which we also did reviews of every change
> -- although it was mostly manual, and just one review was enough to
> merge -- and at some point in that project I noticed that it is very
> easy to give reviews that are unhelpful, frustrating and just get in the
> way of the actual work. I started paying attention to how I am reviewing
> code, and I managed to come up with several patterns that are bad. Once
> I know the patterns, it's easier to recognize when I'm doing something
> wrong and rethink the review. I would like to share the patterns that I
> noticed.

Thank you for this, very cool. I have two nits ;). Firstly, things
like code duplication is a sliding scale, and I think it's ok for a
reviewer to say 'these look similar, give it a go please'. If the
reviewee tries, and it's no good - thats fine. But saying 'hey, I
won't even try' - thats not so good. Many times we get drive-by
patches and no follow up, so there is a learnt response to require
full satisfaction with each patch that comes in. Regular contributors
get more leeway here I think.

Secondly, this:

>
> Leaving a mark.
> ===
>
> You review a change and see that it is mostly fine, but you feel that
> since you did so much work reviewing it, you should at least find
> *something* wrong. So you find some nitpick and -1 the change just so
> that they know you reviewed it.

Thats indeed not cool. Perhaps a 0 with the nitpick. On the other
hand, perhaps the nitpick actually matters. If it's a nitpick it's
going to be what - a couple minutes to fix and push ?

... I think the real concern is that by pushing it up again you go to
the back of the queue for reviews, so maybe we should talk about that
instead. We don't want backpressure on folk polishing a patch on
request because of review latency.

> This is quite obvious. Just don't do it. It's OK to spend an hour
> reviewing something, and then leaving no comments on it, because it's
> simply fine, or because we had to means to test someting (see the first
> pattern).

Core reviewers look for the /comments/ from people, not just the
votes. A +1 from someone that isn't core is meaningless unless they
are known to be a thoughtful code reviewer. A -1 with no comment is
also bad, because it doesn't help the reviewee get whatever the issue
is fixed.

It's very much not OK to spend an hour reviewing something and then +1
with no comment: if I, and I think any +2er across the project see a
patch that needs an hour of review, with a commentless +1, we'll
likely discount the +1 as being meaningful.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Facing issue in creating router in openstack dasboard

[Ben Nemec]

 

Is there a reason you're using a very old version of devstack? I would
be more than a little surprised if that worked (especially since the
quantum->neutron change didn't happen until Havana, which is probably
the issue here). 

-Ben 

On 2013-11-06 04:44, Kanika Saklani wrote: 

> 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 
> [3]
> * $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=
> RABBIT_PASSWORD=
> ADMIN_PASSWORD=
> SERVICE_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=
> 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/ [4]  
> KEYSTONE IS SERVING AT HTTP://192.168.6.122:5000/V2.0/ [5] 
> 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 [1] ) 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 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [2]

 

Links:
--
[1] https://www.youtube.com/watch?v=p4eW78gHfCg
[2] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[3] https://github.com/openstack-dev/devstack/archive/stable/grizzly.zip
[4] http://192.168.6.122/
[5] http://192.168.6.122:5000/v2.0/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[Eugene Nikanorov]

Hi!

I would like do disagree with some of the points.
First of all, '-1' mark may have a wrong perception especially among new
contributors.
-1 doesn't mean reviewers don't want your code (which is -2), it means they
either not sure it is good enough or they see how you could make it better.

> Not sure if that works
If you as a reviewer have a gut feeling ('not sure') that it may not work -
put a -1.
Let submitter explain it to you. You can change your score later without
requiring to change the patch.
Also, there are plenty of cases when the code could not be tested because
it requires specific environment to run.
I think it's ok to put -1 in case of uncertainty. The only thing you should
care about is that such -1 is not 'finished' because you don't require
submitter to change anything, so you need to check if your concerns were
addressed and potentially change the score.

On point #2:
>  Let something repeat a couple of times just to be sure it actually is
reusable.
I think code repetition is not desirable in most of the cases and only
occasionally repeating code gets merged. That happens especially when
someone didn't put reusable code in a common place so others unaware of its
existance. Instead of doing refactoring later on (who will do this?) just
rely on reviewer's opinion and check if generalization could be done.
And this can grow as a snowball (oh, he has copy-pasted his stuff, why
shouldn't I do the same?) so the earlier it is caught - the better.

On other points: the patch is required to be self-consistent. It needs to
solve something that is stated in the bug/commit message and no more (and
hopefully not less) than that. So the scope really matters. I haven't see
much comments from reviewers requesting to make occasional fixes. Although
sometimes it make sense to ask for such, especially if they are related,
reasonable and the patch is going to be improved anyways (due to some other
issues). It also may happen that submitter has missed certain things that
also fall in the scope of the work he is doing.

Having said that, I believe that it's not very difficult to get through a
review where you get -1 for code & style issues.
When you have your code, IDE, git and gerrit at your hands it is a matter
of minutes (hours rarely) to resolve those and resubmit.

The real issue with the review process is that reviewers should back up his
mark once they has put it and they not usually do that for various reasons.
The worst thing to do is to put -1 and go away without leaving a chance for
submitter to explain what he meant and wanted.
So once a reviewer started a review (put a mark) - it is his responsibility
to work further on this review.
Persistent -1 should indicate that reviewer and submitter could not agree
on fundamentals of the patch (design, workflow, etc), which, in turn,
means, that a discussion should be held within a community before the work
on the patch is continued.

Thanks,
Eugene.




On Wed, Nov 6, 2013 at 11:26 PM, Andrew Woodward  wrote:

> Great thread and very insightful. Yes; please make this more
> accessible to other reviewers. Adding this to the wiki is a great
> start.
>
> Andrew
> Mirantis
>
> On Wed, Nov 6, 2013 at 11:05 AM, Pitucha, Stanislaw Izaak
>  wrote:
> > How about putting it on a wiki and linking it from the top bar of gerrit
> itself? (call it "review guidelines" for example)
> > That way, even people who didn't look for it explicitly could find it.
> >
> > Regards,
> > Stanisław Pitucha
> > Cloud Services
> > Hewlett Packard
> >
> > -Original Message-
> > From: Sergey Skripnick [mailto:sskripn...@mirantis.com]
> > Sent: Wednesday, November 06, 2013 6:50 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] Bad review patterns
> >
> >
> > This definitely should be somewhere in wiki or blog and in the bookmarks.
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> If google has done it, Google did it right!
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] What key strings can we set in "scheduler_hints" param when boot an instance?

[openstack learner]

Hi all,

I am using the nova python api and recently i need to use the filter
schedule hint when i boot up an instance.  In the
novaclient.v1_1.client.Client.servers.create() method, there is a
:param scheduler_hints: (optional extension) arbitrary key-value pairs
  specified by the client to help boot an instance


which we can specify the key-value pairs to help boot an instance.

However, i don't know what "key string" can I specify in my key-values
pairs. I search online but did not get any information about that?  Is
there any document that list all the keystrings we can specify in the
scheduler_hints?  I would like to have a list of all the "keys" that we can
specify in the scheduler_hints.

Thanks a lot

xin
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[Ravi Chunduru]

Well said. This will encourage new developers.


On Wed, Nov 6, 2013 at 11:26 AM, Andrew Woodward  wrote:

> Great thread and very insightful. Yes; please make this more
> accessible to other reviewers. Adding this to the wiki is a great
> start.
>
> Andrew
> Mirantis
>
> On Wed, Nov 6, 2013 at 11:05 AM, Pitucha, Stanislaw Izaak
>  wrote:
> > How about putting it on a wiki and linking it from the top bar of gerrit
> itself? (call it "review guidelines" for example)
> > That way, even people who didn't look for it explicitly could find it.
> >
> > Regards,
> > Stanisław Pitucha
> > Cloud Services
> > Hewlett Packard
> >
> > -Original Message-
> > From: Sergey Skripnick [mailto:sskripn...@mirantis.com]
> > Sent: Wednesday, November 06, 2013 6:50 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] Bad review patterns
> >
> >
> > This definitely should be somewhere in wiki or blog and in the bookmarks.
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> If google has done it, Google did it right!
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[Andrew Woodward]

Great thread and very insightful. Yes; please make this more
accessible to other reviewers. Adding this to the wiki is a great
start.

Andrew
Mirantis

On Wed, Nov 6, 2013 at 11:05 AM, Pitucha, Stanislaw Izaak
 wrote:
> How about putting it on a wiki and linking it from the top bar of gerrit 
> itself? (call it "review guidelines" for example)
> That way, even people who didn't look for it explicitly could find it.
>
> Regards,
> Stanisław Pitucha
> Cloud Services
> Hewlett Packard
>
> -Original Message-
> From: Sergey Skripnick [mailto:sskripn...@mirantis.com]
> Sent: Wednesday, November 06, 2013 6:50 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Bad review patterns
>
>
> This definitely should be somewhere in wiki or blog and in the bookmarks.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
If google has done it, Google did it right!

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[Pitucha, Stanislaw Izaak]

How about putting it on a wiki and linking it from the top bar of gerrit 
itself? (call it "review guidelines" for example)
That way, even people who didn't look for it explicitly could find it.

Regards,
Stanisław Pitucha
Cloud Services
Hewlett Packard

-Original Message-
From: Sergey Skripnick [mailto:sskripn...@mirantis.com]
Sent: Wednesday, November 06, 2013 6:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Bad review patterns


This definitely should be somewhere in wiki or blog and in the bookmarks.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[Sergey Skripnick]

This definitely should be somewhere in wiki or blog and in the bookmarks.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [swift] what does swift do if the auditor find that all 3 replicas are corrupt?

[Samuel Merritt]

On 11/6/13 7:12 AM, Daniel Li wrote:

Hi,
 I have a question about swift:  what does swift do if the auditor
find that all 3 replicas are corrupt?
will it notify the owner of the object(email to the account owner)?
what will happen if the GET request to the corrupted object?
will it return a special error telling that all the replicas are corrupted?
  Or will it just say that the object is not exist?
  Or it just return one of the corrupted replica?
  Or something else?


If all 3 (or N) replicas are corrupt, then the auditors will eventually 
quarantine all of them, and subsequent GET requests will receive 404 
responses.


No notifications are sent, nor is it really feasible to start sending 
them. "The auditor" is not a single process; there is one Swift auditor 
process running on each node in a cluster. Therefore, when an object is 
quarantined, there's no way for its auditor to know if the other copies 
are okay or not.


Note that this is highly unlikely to ever happen, at least with the 
default of 3 replicas. When an auditor finds a corrupt object, it 
quarantines it (moves it to a "quarantines" directory). Then, since that 
object is missing, the replication processes will recreate the object by 
copying it from a node with a good copy. You'd need to have all replicas 
become corrupt within a very short timespan so that the replicators 
don't get a chance to replace the damaged ones.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 sub-team?

[Hampapur Ajay]

+1
we are in process of designing/implementing this and want to be part of the 
community effort. 

On Nov 5, 2013, at 3:50 PM, "Collins, Sean (Contractor)" 
 wrote:

> Hi,
> 
> Is there any interest in organizing a IPv6 sub-team, similar to how
> there are sub-teams for FwaaS, VPNaas, ML2, etc?
> 
> -- 
> Sean M. Collins
> AIM: seanwdp
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Review please

[Pitucha, Stanislaw Izaak]

Hi all,
Could someone review https://review.openstack.org/53538, please?
It has already timed out once due to a -1 (addressed in comments, but the
comment author never responded or removed it).
It's a trivial bugfix and it about to be auto-abandoned again in two days.

Regards,
Stanisław Pitucha
Cloud Services 
Hewlett Packard



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[Miguel Angel]

All the points sound quite reasonable. I agree with Chris, the more
reviewers read this, the better will be our review quality.

Do we have some kind of reviewing guide?, if we don't this could be an
start.

--
irc: ajo  / mangelajo
Miguel Angel Ajo Pelayo
+34 636 52 25 69
skype: ajoajoajo


2013/11/6 Christopher Armstrong 

> On Wed, Nov 6, 2013 at 2:34 AM, Radomir Dopieralski <
> openst...@sheep.art.pl> wrote:
>
>> Hello,
>>
>> I'm quite new in the OpenStack project, but I love it already. What is
>> especially nifty is the automated review system -- I'm really impressed.
>> I'm coming from a project in which we also did reviews of every change
>> -- although it was mostly manual, and just one review was enough to
>> merge -- and at some point in that project I noticed that it is very
>> easy to give reviews that are unhelpful, frustrating and just get in the
>> way of the actual work. I started paying attention to how I am reviewing
>> code, and I managed to come up with several patterns that are bad. Once
>> I know the patterns, it's easier to recognize when I'm doing something
>> wrong and rethink the review. I would like to share the patterns that I
>> noticed.
>>
>>
>
> Agreed on all points. I think Gerrit is nice in that it automates a lot of
> stuff, but unfortunately the workflow has not encouraged the best behavior
> for reviewers. This is a good list to follow -- but how can we be sure
> people will? This mailing list thread will only be seen by a small number
> of reviewers over the life of the project, I'm sure.
>
>
> --
> IRC: radix
> Christopher Armstrong
> Rackspace
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How to skip certain unit tests?

[Bhuvan Arumugam]

On Wed, Oct 30, 2013 at 7:02 PM, Vijay B  wrote:

> Hi,
>
> How can we skip certain unit tests when running run_tests.sh? I'm looking
> at the Openstack unit test page
>

If it's not too late you may skip tests with testr/run_tests.sh. List all
tests using testr & store in a file, exclude the tests and feed the file
that has tests to execute to run_tests.sh script. Something in these lines,
assuming you use venv ...

. .venv/bin/activate && testr list-tests | egrep -v
'exclude_test1|exclude_test2' > execute-tests && deactivate
./run_tests.sh -- --load-list=execute-tests

-- 
Regards,
Bhuvan Arumugam
www.livecipher.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[Christopher Armstrong]

On Wed, Nov 6, 2013 at 2:34 AM, Radomir Dopieralski
wrote:

> Hello,
>
> I'm quite new in the OpenStack project, but I love it already. What is
> especially nifty is the automated review system -- I'm really impressed.
> I'm coming from a project in which we also did reviews of every change
> -- although it was mostly manual, and just one review was enough to
> merge -- and at some point in that project I noticed that it is very
> easy to give reviews that are unhelpful, frustrating and just get in the
> way of the actual work. I started paying attention to how I am reviewing
> code, and I managed to come up with several patterns that are bad. Once
> I know the patterns, it's easier to recognize when I'm doing something
> wrong and rethink the review. I would like to share the patterns that I
> noticed.
>
>

Agreed on all points. I think Gerrit is nice in that it automates a lot of
stuff, but unfortunately the workflow has not encouraged the best behavior
for reviewers. This is a good list to follow -- but how can we be sure
people will? This mailing list thread will only be seen by a small number
of reviewers over the life of the project, I'm sure.


-- 
IRC: radix
Christopher Armstrong
Rackspace
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] [Neutron] Security groups issue when running latest libvirt?

[Simon Pasquier]

Answering myself as I investigated a little further and cross-posting to 
openstack-dev because I'd like to get feedback from Nova/Neutron devs.


Users running Havana should configure 
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver.
This driver is still available in the Havana release although 
deprecated. AFAIU, this is the only option if you want effective 
security groups with KVM & OVS.


For people using the master branch of nova, sorry but security groups 
are currently broken because LibvirtHybridOVSBridgeDriver is gone ([0]). 
Joe Gordon asked the Neutron devs about it few weeks ago [1] but no 
answer and in another review [2], the conclusion was that the Tempest 
tests passed with Neutron. However I don't see anywhere in the tests 
([3], [4]) that we check if the security rules allow/block traffic.


It would be nice if core devs could confirm or refute.

Regards,

Simon

[0] https://review.openstack.org/#/c/49660/
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2013-October/016886.html

[2] https://review.openstack.org/#/c/44349
[3] 
https://github.com/openstack/tempest/blob/master/tempest/api/network/test_security_groups.py
[4] 
https://github.com/openstack/tempest/blob/master/tempest/api/network/test_security_groups_negative.py


Le 05/11/2013 14:57, Simon Pasquier a écrit :

Hi all,

I'm struggling with security groups on Havana with Neutron and OVS
plugin (GRE tunnels). No problem to create/delete security group rules
but even though iptables configuration is updated, traffic to my
instances is never filtered [0].

I'm running DevStack on 2 nodes (1 controller + 1 compute):
- OS: Ubuntu 12.04.3 (LTS) with the Havana cloud archive repository.
- Open vSwitch package version: 1.10.2-0ubuntu2~cloud0
- libvirt package version: 1.1.1-0ubuntu8~cloud2
- localrc, nova.conf, neutron.conf and ovs_neutron_plugin.ini files
pasted at [1] (I didn't modify any of these files after the DevStack run)

According to [2], [3] and [4], iptables is not compatible with TAP
devices connectd directly to Open vSwitch ports, this is why there used
to be the additional veth + bridge interfaces [5]. But in my setup, this
is not the case anymore as shown in [6] ('ovs-vsctl show' +
'iptables-save' ouptut). I've also pasted the libvirt XML configuration
[7] that shows that the instance is directly connected to the Open vSwitch.

Are the security groups supposed to work when the instance is directly
connected to OVS? If yes, what am I doing wrong?

Regards,

[0] http://paste.openstack.org/show/50490/
[1] http://paste.openstack.org/show/50448/
[2] http://www.spinics.net/linux/fedora/libvirt-users/msg05384.html
[3] http://openvswitch.org/pipermail/discuss/2013-October/011461.html
[4]
http://docs.openstack.org/havana/config-reference/content/under_the_hood_openvswitch.html

[5]
http://docs.openstack.org/havana/config-reference/content/figures/7/a/a/common/figures/under-the-hood-scenario-2-ovs-compute.png

[6] http://paste.openstack.org/show/50486/
[7] http://paste.openstack.org/show/50487/



--
Simon Pasquier
Software Engineer
Bull, Architect of an Open World
Phone: + 33 4 76 29 71 49
http://www.bull.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How to add a comment to a change review?

[Michael Bright]

Thanks Solly!



On 6 November 2013 17:42, Solly Ross  wrote:

> You just click the "review" button under the change list on Gerrit.  It
> should then take you to a screen where you can see inline comments waiting
> to be added and enter an overall comment as well.
>
> The comment system in Gerrit really should be a bit more intuitive.
>
> Best Regards,
> Solly Ross
>
> - Original Message -
> From: "Michael Bright" 
> To: openstack-dev@lists.openstack.org
> Sent: Wednesday, November 6, 2013 11:34:27 AM
> Subject: [openstack-dev] How to add a comment to a change review?
>
>
> Can someone enlighten me as to how I can add a comment to one of my own
> changes on review.openstack.org .
>
> I suppose it's mind numbingly obvious but here for example I just cannot
> see how to add a comment.
>
> It says here:
> https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures
>
>
>
> Leave a comment on the review referencing the bug causing the transient
> failure (not the bug you're attempting to fix with your patch):
> To re-run the check jobs (before a change has been approved), leave a
> comment with the form "recheck bug ".
> To re-run the gate jobs (after a change has been approved), leave a
> comment with the form "reverify bug ".
>
> It must be so obvious ...
>
> Thanks in advance,
> Mike.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How to add a comment to a change review?

[Solly Ross]

You just click the "review" button under the change list on Gerrit.  It should 
then take you to a screen where you can see inline comments waiting to be added 
and enter an overall comment as well.

The comment system in Gerrit really should be a bit more intuitive.

Best Regards,
Solly Ross

- Original Message -
From: "Michael Bright" 
To: openstack-dev@lists.openstack.org
Sent: Wednesday, November 6, 2013 11:34:27 AM
Subject: [openstack-dev] How to add a comment to a change review?


Can someone enlighten me as to how I can add a comment to one of my own changes 
on review.openstack.org . 

I suppose it's mind numbingly obvious but here for example I just cannot see 
how to add a comment. 

It says here: https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures 



Leave a comment on the review referencing the bug causing the transient failure 
(not the bug you're attempting to fix with your patch): 
To re-run the check jobs (before a change has been approved), leave a comment 
with the form "recheck bug ". 
To re-run the gate jobs (after a change has been approved), leave a comment 
with the form "reverify bug ". 

It must be so obvious ... 

Thanks in advance, 
Mike. 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] How to add a comment to a change review?

[Michael Bright]

Can someone enlighten me as to how I can add a comment to one of my own
changes on review.openstack.org.

I suppose it's mind numbingly obvious but here for
exampleI just cannot see
how to add a comment.

It says here: https://wiki.openstack.org/wiki/GerritJenkinsGit#Test_Failures

Leave a comment on the review referencing the bug causing the transient
failure (not the bug you're attempting to fix with your patch):
To re-run the check jobs (before a change has been approved), leave a
comment with the form "recheck bug ".
To re-run the gate jobs (after a change has been approved), leave a comment
with the form "reverify bug ".

It must be so obvious ...

Thanks in advance,
Mike.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Swift multinode installation add repository

[Gerard Marin]

Dear all,

I am trying to install Swift in a distributed multinode environment 
consisiting of 1 Proxy node and 5 Storage nodes. I am following the 
tutorial:


http://docs.openstack.org/developer/swift/howto_installmultinode.html

I have a problem adding the swift-core repository:

add-apt-repository ppa:swift-core/release
Error: can't find signing_key_fingerprint at 
https://launchpad.net/api/1.0/~swift-core/+archive/release


and then I cannot install Swift because it does not find the repository.
How can I solve this problem?

Thank you very much.
Best regards,

Gerard Marin
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [swift] what does swift do if the auditor find that all 3 replicas are corrupt?

[Daniel Li]

Hi,
I have a question about swift:  what does swift do if the auditor find
that all 3 replicas are corrupt?
will it notify the owner of the object(email to the account owner)?

what will happen if the GET request to the corrupted object?
will it return a special error telling that all the replicas are corrupted?
 Or will it just say that the object is not exist?
 Or it just return one of the corrupted replica?
 Or something else?

Thanks very much for your help.

-Daniel
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

[Harshad Nakil]

+1

Regards
-Harshad


> On Nov 6, 2013, at 12:36 AM, Radomir Dopieralski  
> wrote:
>
> Hello,
>
> I'm quite new in the OpenStack project, but I love it already. What is
> especially nifty is the automated review system -- I'm really impressed.
> I'm coming from a project in which we also did reviews of every change
> -- although it was mostly manual, and just one review was enough to
> merge -- and at some point in that project I noticed that it is very
> easy to give reviews that are unhelpful, frustrating and just get in the
> way of the actual work. I started paying attention to how I am reviewing
> code, and I managed to come up with several patterns that are bad. Once
> I know the patterns, it's easier to recognize when I'm doing something
> wrong and rethink the review. I would like to share the patterns that I
> noticed.
>
>
> Not sure if that works...
> =
>
> You see some suspicious piece of code, and you are not sure if it is
> correct or not. So you point it out in the review and -1 it, demanding
> that the author rechecks it and/or prove that it indeed works.
>
> It's your job as a reviewer to check such things, don't put all the
> effort on the author. They probably already checked that this code
> works, and possibly have even written tests for it. If you are not
> familiar with the technology enough to tell whether it's good or not,
> and have no means of testig it yourself, you shouldn't be reviewing it.
> If you do have the means to test it or can find the piece of
> documentation that says that it shouldn't be done -- do it as a part of
> the review.
>
>
> You ain't gonna need it.
> 
>
> The code contains some parts that are potentially reusable later or in
> different areas, so you -1 it and tell the author to move them into
> reusable functions.
>
> The fact that you think something is reusable doesn't necessarily mean
> it is, and overly general code is harder to maintain. Let something
> repeat a couple of times just to be sure it actually is reusable. Once
> you find a repeating pattern, you can refactor the code to use a
> generalized function in its place -- in a separate change.
>
>
> There is an old bug here.
> =
>
> While you review the submitted code, you notice something wrong in the
> code not immediately related to the change you are reviewing. You -1 the
> change and tell the author to fix that bug, or formatting issue, or
> typo, or whatever.
>
> That fix has nothing to do with the change you are reviewing. The
> correct thing to do is to make a mental note of it, and fix it in a
> separate change -- possibly even finding more instances of it or coming
> up with a much better fix after seeing more code.
>
>
> Guess what I mean.
> ==
>
> You notice a pep8 violation, or pep257 violation, or awkward wording of
> a comment or docstring, or a clumsy piece of code. You -1 the change and
> just tell author to "fix it".
>
> It's not so easy to guess what you mean, and in case of a clumsy piece
> of code, not even that certain that better code can be used instead. So
> always provide an example of what you would rather want to see. So
> instead of pointing to indentation rules, just show properly indented
> code. Instead of talking about grammar or spelling, just type the
> corrected comment or docstring. Finally, instead of saying "use list
> comprehension here" or "don't use has_key", just type your proposal of
> how the code should look like. Then we have something concrete to talk
> about. Of course, you can also say why you think this is better, but an
> example is very important. If you are not sure how the improved code
> would look like, just let it go, chances are it would look even worse.
>
>
> Not a complete fix.
> ===
>
> The code fixes some problems (for example, fixes formatting and enables
> some flake8 checks), but leaves some other, related problems still not
> fixed. You -1 it and demand that the author adds fixes for the related
> problem.
>
> Don't live your coding career through the authors. If their fix is good
> and correct and improves the code, let it in, even if you see more
> opportunities to improve it. You can add those additional fixes yourself
> in a separate change. Or, if you don't have time or skill to do that,
> report a bug about the remaining problems and someone else will do it,
> but don't hold the author hostage with your review because you think he
> didn't do enough.
>
>
> Leaving a mark.
> ===
>
> You review a change and see that it is mostly fine, but you feel that
> since you did so much work reviewing it, you should at least find
> *something* wrong. So you find some nitpick and -1 the change just so
> that they know you reviewed it.
>
> This is quite obvious. Just don't do it. It's OK to spend an hour
> reviewing something, and then leaving no comments on it, because it's
> simply fine, or because we had to means to test

Re: [openstack-dev] OpenStack-dev Digest, Vol 19, Issue 10

[Santosh Kumar]

ource Class
> flavors
> >   - fixed JS warnings when $ is not available
> >   - fixed links and naming in Readme
> >   - various code and test fixes (pep8, refactoring)
> >
> >   python-tuskarclient - 0.0.2 (was 0.0.1)
> >   - fixed processing of 301 response code
> >
> >   os-apply-config and os-refresh-config haven't had new commits
> > since the last release
> >
> > This also means that:
> > 1. We are now releasing all the projects we have.
> > 2. *tuskar* projects have got PyPi entries.
> >
> > Last but not least.
> >
> > I'd like to say a big thank you to Chris Jones who taught me 'Release
> > Management 101' and provided patches to openstack/infra-config to make
> > all our projects 'releasable'; Robert Collins for his advice on
> > version numbering; Clark Boylan and Jeremy Stanley for landing of
> > Gerrit ACL patches and debugging PyPi uploads issues; Radomir
> > Dopieralski and Tomas Sedovic for landing a quick fix to tuskar-ui.
> >
> > Thank you all guys, you've helped me a lot!
> >
> > Roman
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Robert Collins >
> Distinguished Technologist
> HP Converged Cloud
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20131106/0d4fea7e/attachment-0001.html>

--

Message: 3
Date: Wed, 6 Nov 2013 14:07:02 +0800
From: Sergey Lukjanov 
To: "OpenStack Development Mailing List (not for usage questions)"

Subject: Re: [openstack-dev] [TripleO] Releases of this week
Message-ID: 
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  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  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
> >  -

[openstack-dev] [State-Management] Slides from taskflow speaker session

[Joshua Harlow]

Thanks all for showing up!

http://www.slideshare.net/harlowja/taskflow-27820295

Not sure if there is an official page for this, anyway link is above (likely 
video link somewhere also).

Questions, comments, feedback welcome! Thxs all for making this possible :-)

-josh

Sent from my really tiny device...
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Code Review (Jenkins-job-builder, BlameUpstreamCommitters plugin support)

[Peter Liljenberg]

Hi,

Could someone review this please:

https://review.openstack.org/#/c/54085/

Regards,
Peter
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] [Climate] Reservation service called Climate

[Sylvain Bauza]

Hi,

During the Design session 
https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API we discussed 
the fact that this is not the role of Nova for doing atomic reservations in 
order to ensure the user needs will be met.

I raised the point (and sorry for my bad accent, was stressy) that we're 
already trying to provide a reservation system for Openstack, called Climate (a 
Stackforge project).
I would really like to discuss with you all, Nova community, about the 
reservation system and ensure that we, at Climate, are on the good path.

Climate is planning to reserve both virtual instances and physical hosts, but 
for the discussion we had, only physical hosts usecase is relevant.

We had an unconference session today at 2pm, I can share you the slides :

https://docs.google.com/presentation/d/1BJGmtzGees6tg_Np7JuKFtuLGiCaguVYD8hYJ2eVKAc/edit#slide=id.p

(please focus on slides 11-14, they're talking on the design for host 
reservations)

All the code is located on Stackforge, but please note the most important part 
of physical host reservations is still under review there :
https://review.openstack.org/#/q/project:+stackforge/climate+status:open,n,z

(We're missing reviewers, by the way !)


I'm open to discuss and waiting your thoughts,
-Sylvain

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 sub-team?

[Miguel Angel]

+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 

> I definitely think this should be a standing Neutron sub team.
>
> mark
>
> > On Nov 6, 2013, at 7:50 AM, "Collins, Sean (Contractor)" <
> sean_colli...@cable.comcast.com> wrote:
> >
> > Hi,
> >
> > Is there any interest in organizing a IPv6 sub-team, similar to how
> > there are sub-teams for FwaaS, VPNaas, ML2, etc?
> >
> > --
> > Sean M. Collins
> > AIM: seanwdp
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [qa] Duplicated test effort development

[Ken'ichi Ohmichi]

Hi,

2013/10/30 Christopher Yeoh :
> Hi,
>
> It looks like we have lots of people writing tests at the moment which is
> great, but the downside is we're starting to see people accidentally writing
> tests for the same APIs at the same time.
>
> There is a google spreadsheet which covers the Nova v2 API where we can
> reserve what tests we're working on but I don't think we have an easily
> editable list for the other APIs. I don't think blueprints/bugs work so well
> at this, and I don't think we have anything else setup at the moment, so as
> a temporary measure I've created an etherpad here:
>
> https://etherpad.openstack.org/p/TempestTestDevelopment
>
> which links to the Nova v2 API spreadsheet and to a new etherpad for glance
> apis (this would ideally be a spreadsheet as well but in the meantime would
> work as a tool to avoid duplicated effort). Add new links if you're working
> on new tests for other APIs.
>
> I think it'd be a really good idea if we all checked these lists and add
> what we're about to work on before starting to write new tests to avoid the
> situation where we have almost identical changesets in the review queue from
> different people.

Thanks for preparing this etherpad page.

To avoid the duplicated works of Tempest, I also have added some contents about
separation negative tests from positive test files.
To separate negative tests, some patches have been queued already in Gerrit.
I wrote these patches' URLs on the etherpad.
I'm glad if developers check this contents before starting this work.


Thanks
Ken'ichi Ohmichi

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Releases of this week

[Roman Podoliaka]

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 
> 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  wrote:
> > Hi all,
> >
> > This week I've been doing releases of all projects, which belong to
> > TripleO program. Here are release notes you might be interested in:
> >
> > os-collect-config  - 0.1.5 (was 0.1.4):
> > - default polling interval was reduced to 30 seconds
> > - requirements were updated to use the new iso8601 version
> > fixing important bugs
> >
> > diskimage-builder - 0.0.9 (was 0.0.8)
> >  - added support for bad Fedora image mirrors (retry the
> > request once on 404)
> >  - removed dependency on dracut-network from fedora element
> >  - fixed the bug with removing of lost+found dir if it's not
> found
> >
> > tripleo-image-elements  - 0.1.0 (was 0.0.4)
> >  - switched to tftpd-hpa on Fedora and Ubuntu
> >  - made it possible to disable file injection in Nova
> >  - switched seed vm to Neutron native PXE
> >  - added Fedora support to apache2 element
> >  - fixed processing of routes in init-neutron-ovs
> >  - fixed Heat watch server url key name in seed vm metadata
> >
> > tripleo-heat-templates - 0.1.0 (was 0.0.1)
> >  - disabled Nova Baremetal file injection (undercloud)
> >  - made LaunchConfiguration resources mergeable
> >  - made neutron public interface configurable (overcloud)
> >  - made it possible to set public interface IP (overcloud)
> >  - allowed making the public interface a VLAN (overcloud)
> >  - added a wait condition for signalling that overcloud is ready
> >  - added metadata for Nova floating-ip extension
> >  - added tuskar API service configuration
> >  - hid AdminToken in Heat templates
> >  - added Ironic service configuration
> >
> >  tuskar - 0.0.2 (was 0.0.1)
> >  - made it possible to pass Glance image id
> >  - fixed the bug with duplicated Resource Class names
> >
> >  tuskar-ui - 0.0.2 (was 0.0.1)
> >   - resource class creation form no longer ignores the image
> selection
> >   - separated flavors creation step
> >   - fail gracefully on node detail page when no overcloud
> >   - added validation of MAC addresses and CIDR values
> >   - stopped appending Resource Class name to Resource Class
> flavors
> >   - fixed JS warnings when $ is not available
> >   - fixed links and naming in Readme
> >   - various code and test fixes (pep8, refactoring)
> >
> >   python-tuskarclient - 0.0.2 (was 0.0.1)
> >   - fixed processing of 301 response code
> >
> >   os-apply-config and os-refresh-config haven't had new commits
> > since the last release
> >
> > This also means that:
> > 1. We are now releasing all the projects we have.
> > 2. *tuskar* projects have got PyPi entries.
> >
> > Last but not least.
> >
> > I'd like to say a big thank you to Chris Jones who taught me 'Release
> > Management 101' and provided patches to openstack/infra-config to make
> > all our projects 'releasable'; Robert Collins for his advice on
> > version numbering; Clark Boylan and Jeremy Stanley for landing of
> > Gerrit ACL patches and debugging PyPi uploads issues; Radomir
> > Dopieralski and Tomas Sedovic for landing a quick fix to tuskar-ui.
> >
> > Thank you all guys, you've helped me a lot!
> >
> > Roman
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Robert Collins 
> Distinguished Technologist<
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] IPv6 sub-team?

[Mark McClain]

I definitely think this should be a standing Neutron sub team. 

mark

> On Nov 6, 2013, at 7:50 AM, "Collins, Sean (Contractor)" 
>  wrote:
> 
> Hi,
> 
> Is there any interest in organizing a IPv6 sub-team, similar to how
> there are sub-teams for FwaaS, VPNaas, ML2, etc?
> 
> -- 
> Sean M. Collins
> AIM: seanwdp
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Bad review patterns

[Radomir Dopieralski]

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 su

Re: [openstack-dev] [Solum] Design Workshop at SFO

[Roshan Agrawal]

Re-sending details for the upcoming Solum workshop at SFO on popular demand

We will also have an "events" section on Solum.io for this kind of 
communication in the next week or so. 

Please confirm your attendance by visiting the eventbrite page: 
https://www.eventbrite.com/event/9130831563 . This is important so we get an 
accurate count of attendees.

From: Roshan Agrawal
Sent: Friday, November 01, 2013 3:17 PM
To: openstack-dev@lists.openstack.org
Subject: [Solum] Design Workshop at SFO

Hello, we are locked down on the plan to hold design workshops on Solum at SFO! 
It it now time to confirm your participation, and make travel arrangements.

Please confirm your attendance by visiting the eventbrite page: 
https://www.eventbrite.com/event/9130831563 . This is important so we get an 
accurate count of attendees.

Workshop dates: Nov 19, 20
Location: Rackspace SFO office (620 Folsom St, San Francisco, CA 94107)
Purpose: working sessions for Solum contributors to discuss design/blueprints.

Meeting Structure
Nov 19 Tuesday 9:00 am - 5 pm
  9:00 - 9:30: check-in
  9:30 - 10:00: introductions, agenda
  10:00 - 5:00: Roundtable workshop, whiteboarding
  5:30 - 7:00: Happy hour (3rd floor at the Rackspace SFO office)

Nov 20 Wednesday 9:30 am - 3:00 pm : Continue workshops
Workshop Concludes 3 pm Wednesday

Please refer to the etherpad page below for the latest info on the event, and 
to provide input on discussion topics for the workshop.
https://etherpad.openstack.org/p/SolumSFOCommunityWorkshop

Thanks, and look forward to seeing you all at the event.

Thanks!
Roshan Agrawal

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [heat][keystone] APIs, roles, request scope and admin-ness

[Jamie Lennox]

On Wed, 2013-11-06 at 06:16 +0800, Clint Byrum wrote:
> Excerpts from Steven Hardy's message of 2013-11-03 00:06:39 +0800:
> > Hi all,
> > 
> > Looking to start a wider discussion, prompted by:
> > https://review.openstack.org/#/c/54651/
> > https://blueprints.launchpad.net/heat/+spec/management-api
> > https://etherpad.openstack.org/p/heat-management-api
> > 
> > Summary - it has been proposed to add a management API to Heat, similar in
> > concept to the admin/public API topology used in keystone.
> > 
> > I'm concerned that this may not be a pattern we want to propagate throughout
> > OpenStack, and that for most services, we should have one API to access 
> > data,
> > with the scope of the data returned/accessible defined by the roles held by
> > the user (ie making proper use of the RBAC facilities afforded to us via
> > keystone).

I feel that i can speak for the keystone developers when i say avoid
this at all costs! Currently in the implementation of keystone what is
exposed on the admin port is the same as the public port with the
intention that we can hopefully remove adminURL altogether. 

> > In the current PoC patch, a users admin-ness is derived from the fact that
> > they are accessing a specific endpoint, and that policy did not deny them
> > access to that endpoint.  I think this is wrong, and we should use keystone
> > roles to decide the scope of the request.
> > 
> > The proposal seems to consider tenants as the top-level of abstraction, with
> > the next level up being a global service provider admin, but this does not
> > consider the keystone v3 concept of domains [1], or that you may wish to
> > provide some of these admin-ish features to domain-admin users (who will
> > adminster data accross multiple tenants, just like has been proposed), via 
> > the
> > public-facing API.
> > 
> > It seems like we need a way of scoping the request (via data in the 
> > context),
> > based on a heirarchy of admin-ness, like:
> > 
> > 1. Normal user
> > 2. Tenant Admin (has admin role in a tenant)
> > 3. Domain Admin (has admin role in all tenants in the domain)
> > 4. Service Admin (has admin role everywhere, like admin_token for keystone)
> > 
> > The current "is_admin" flag which is being used in the PoC patch won't allow
> > this granularity of administrative boundaries to be represented, and 
> > splitting
> > admin actions into a separate API will prevent us providing tenant and 
> > domain
> > level admin functionality to customers in a public cloud environment.
> > 
> > It has been mentioned that in keystone, if you have admin in one tenant, you
> > are admin everywhere, which is a pattern I think we should not follow -
> > keystone folks, what are your thoughts in terms of roadmap to make role
> > assignment (at the request level) scoped to tenants rather than globally
> > applied?  E.g what data can we add to move from X-Roles in auth_token, to
> > expressing roles in multiple tenants and domains?
> > 
> 
> Right, roles should be tenant and domain scoped, and the roles that we
> consume in our policy definitions should not need to know anything about
> the hierarchy. It seems very broken to me that there would be no way to
> make a user who can only create more users in their tenant in Keystone.
> Likewise, I would consider Heat broken if I had to use a special API
> for doing things with a role I already have that is just scoped more
> broadly than a single tenant or domain.

This is possible with the v3 api.

> > Basically, I'm very concerned that we discuss this, get a clear roadmap 
> > which
> > will work with future keystone admin/role models, and is not a short-term 
> > hack
> > which we won't want to maintain long-term.
> > 
> > What are peoples thoughts on this?
> 
> Let's try and find a keystone dev or two in the hallway at the summit
> and get some clarity on the way Keystone is intended to work, which may
> help us decide if we want to follow their admin-specific-API paradigm or
> not.

There are a number of us at summit (myself included). Our sessions tend
to be in the afternoon so you can probably find at least 1 dev in the
dev lounge at the other times. 

> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev