[openstack-dev] [Networking] Question on portbinding

[Chandan Dutta Chowdhury]

Hello All,


While going through the portbinding extension I noticed that a patch has been 
proposed for calls from nova to checks and updates the port binding attributes 
for a plugin which supports this extension.

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


While going through the code, I don't see the same changes for dhcp and l3 
agents.
These agents while creating ports don't provide portbinding attributes.

Am I missing something ?

Thanks
Chandan 




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

[openstack-dev] [Networking] Question on portbinding

[Chandan Dutta Chowdhury]

Hello All,


While going through the portbinding extension I noticed that a patch has been 
proposed for
calls from nova to checks and updates the port binding attributes for a plugin 
which supports this extension.

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


While going through the code, I don't see the same changes for dhcp and l3 
agents.
These agents while creating ports don't provide portbinding attributes.

Am I missing something ?

Thanks
Chandan 



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

Re: [openstack-dev] [OpenStack-Dev] Cinder API Web Framework Change

[thingee]

On Mon, Jun 24, 2013 at 11:53 PM, John Griffith  wrote:

> All,
>
> I wanted to loop the larger community in on some discussions that have
> been taking place on #openstack-cinder.
>
> During the Summit we talked about switching to Pecan for our API/Web
> framework.  Since then we've registered a BP [1] and some pretty good
> progress has been made.
>
> Since starting this effort however we've been debating the best way to
> implement this change:
>
> 1. Replace existing WSGI framework in the existing API versions
>
> In my opinion there's a bit of risk here with changing the entire
> framework tha the API is built on, and even though I'm confident this can
> be done I'm not sure of the return on the investment and really I don't see
> anything that compelling when you consider all of the changes in not only
> the API code but in the unit tests that would be affected.
>
> 2. Bump to a new API version and isolate the changes to that new version
>
> This is my preference and IMO the right way to go, however there's no
> driving need for another API version bump in Cinder currently.  I
> personally don't like the idea of bumping the API version for every
> release, even if we're keeping things stable and maintaining backward
> compatibility without issues.  For me there isn't an overly compelling
> reason to justify this change for the H release.
>
> My plan is to go with option #2, and to push this change out until the I
> release.  I'd like to know if anybody has strong feelings or justifications
> that we should consider on this before moving forward.
>
> Thanks,
> John
>

I've been involved with the discussions with John and was originally the
person that proposed the pecan switch back at the Havana summit for Cinder
in my session:

https://etherpad.openstack.org/havana-cinder-api2-a-new-hope

I've been writing compatibility for both v1 and v2 in pecan/wsme and while
I would absolutely love to see the wsgi implementation code go and xml
serializing/deserializing code go, as John mentioned, I don't think it's
worth it right now. It just took me writing around 5K lines of code to
realize it.

Sort of reiterating John's points, there's a few reasons why I think we
should wait for v3:

1) We'd likely drop v1 support in that release, so we don't have to worry
about it anymore.

2) Make reviewing a lot easier since it's not one big commit that changes
all controllers and tests. Instead have v3 be introduced using pecan with a
commit for each controller and tests. Eventually allow v3 to be served by
cinder-api in the ending commit.

3) v2 controller code and tests don't have to be updated to use pecan. v2
will continue to use paste and v3 will use pecan.

This is the same approach that Ceilometer has done from Flask to Pecan and
it's working out great.

With all that said, I don't want a version bump either for just a framework
switch, as we just did v2 last release. v3 will be needed soon and once
that happens, I'll already be ready with core API controllers I already
switched over to Pecan.


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

[openstack-dev] [OpenStack-Dev] Cinder API Web Framework Change

[John Griffith]

All,

I wanted to loop the larger community in on some discussions that have been
taking place on #openstack-cinder.

During the Summit we talked about switching to Pecan for our API/Web
framework.  Since then we've registered a BP [1] and some pretty good
progress has been made.

Since starting this effort however we've been debating the best way to
implement this change:

1. Replace existing WSGI framework in the existing API versions

In my opinion there's a bit of risk here with changing the entire framework
tha the API is built on, and even though I'm confident this can be done I'm
not sure of the return on the investment and really I don't see anything
that compelling when you consider all of the changes in not only the API
code but in the unit tests that would be affected.

2. Bump to a new API version and isolate the changes to that new version

This is my preference and IMO the right way to go, however there's no
driving need for another API version bump in Cinder currently.  I
personally don't like the idea of bumping the API version for every
release, even if we're keeping things stable and maintaining backward
compatibility without issues.  For me there isn't an overly compelling
reason to justify this change for the H release.

My plan is to go with option #2, and to push this change out until the I
release.  I'd like to know if anybody has strong feelings or justifications
that we should consider on this before moving forward.

Thanks,
John

[1] https://blueprints.launchpad.net/cinder/+spec/web-framework-switch
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Termination of the title line of commit messages

[Robert Collins]

On 25 June 2013 15:34, Joe Gordon  wrote:

> This is exactly why we want a consensus, so we can automatically enforce it
> without using any human resources (at least during the review process).
>
> If we say we don't care, someone will come along and care.  If we enforce
> one option, if someone disagrees the gate will tell them they are wrong.

Not caring is a valid consensus; if the wiki page had said we
explicitly don't care, I would have raised enforcing proper sentence
structure in the first line here.

-Rob
-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services

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

Re: [openstack-dev] [oslo] Sample config file location inconsistency

[Huang Zhiteng]

I don't think this is a problem but I could be wrong.


On Mon, Jun 24, 2013 at 8:03 PM, Zhongyue Luo wrote:

> Hi team
>
> I'm currently trying to move the generate_sample.sh script in nova to oslo.
>
> Before pushing the patch to gerrit, I wanted to give the output directory
> a default value if it was not stated so I was wondering where projects put
> their sample config file at and did this:
>
> find . -name "*.conf*" ! -path "*.tox*" ! -path "*.venv*" | grep etc
>
> results:
> ./ceilometer/etc/ceilometer/ceilometer.conf.sample
> ./cinder/etc/cinder/cinder.conf.sample
> ./nova/etc/nova/nova.conf.sample
> ./swift/etc/swift.conf-sample
> ./tempest/etc/tempest.conf.sample
> ./glance/etc/glance-cache.conf
> ./quantum/etc/quantum.conf
> ./keystone/etc/keystone.conf.sample
>
> You can see that ceilometer, cinder, and nova put their sample config
> files on ./etc/$PROJECTNAME while the others put it on ./etc
>
> So would this inconsistency be a problem?
>
> IMO, ./etc/$PROJECTNAME makes sense to me if consistency is an issue.
>
> Thoughts?
>
> --
> *Intel SSG/STOD/DCST/CIT*
> 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
> China
> +862161166500
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] Termination of the title line of commit messages

[Joe Gordon]

On Jun 24, 2013 6:49 PM, "Russell Bryant"  wrote:
>
> On 06/24/2013 08:14 PM, Angus Salkeld wrote:
> > On 24/06/13 22:50 +0100, Mark McLoughlin wrote:
> >> Hey,
> >>
> >> Pulling this out of gerrit for discussion.
> >>
> >> Background is one of my patches to diskimage-builder was -1ed because I
> >> terminated the title line of the commit message with a period:
> >>
> >>  https://review.openstack.org/33262
> >>
> >> This is actually the exact opposite to what I consider normal practice
> >> for git commit messages as I explained in the review and the tripleo
> >> wiki page, so I proposed a hacking change here:
> >>
> >>  https://review.openstack.org/33789
> >
> > Can't we just agree to not -1 on this issue? This seems like a major
> > waste of people resources.

This is exactly why we want a consensus, so we can automatically enforce it
without using any human resources (at least during the review process).

If we say we don't care, someone will come along and care.  If we enforce
one option, if someone disagrees the gate will tell them they are wrong.

>
> +100
>
> --
> Russell Bryant
>
> ___
> 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] [oslo] Sample config file location inconsistency

[Zhongyue Luo]

Hi team

I'm currently trying to move the generate_sample.sh script in nova to oslo.

Before pushing the patch to gerrit, I wanted to give the output directory a
default value if it was not stated so I was wondering where projects put
their sample config file at and did this:

find . -name "*.conf*" ! -path "*.tox*" ! -path "*.venv*" | grep etc

results:
./ceilometer/etc/ceilometer/ceilometer.conf.sample
./cinder/etc/cinder/cinder.conf.sample
./nova/etc/nova/nova.conf.sample
./swift/etc/swift.conf-sample
./tempest/etc/tempest.conf.sample
./glance/etc/glance-cache.conf
./quantum/etc/quantum.conf
./keystone/etc/keystone.conf.sample

You can see that ceilometer, cinder, and nova put their sample config files
on ./etc/$PROJECTNAME while the others put it on ./etc

So would this inconsistency be a problem?

IMO, ./etc/$PROJECTNAME makes sense to me if consistency is an issue.

Thoughts?

-- 
*Intel SSG/STOD/DCST/CIT*
880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
China
+862161166500
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Nova scheduler sub-group meeting agenda 6/25

[Dugger, Donald D]

1)  Follow ups on the scheduler BPs
2)  Opens?

Not really much on the agenda for this week, we'll probably have a short 
meeting (I'm still studying the scheduler's use of fan-out messages and the DB, 
I'll want to go over that in more detail once I complete my study).

PS: The list of scheduler BPs is:

1)   Extending data in host state
2)   Utilization based scheduling
3)   Whole host allocation capability
4)   Coexistence of different schedulers
5)   Rack aware scheduling
6)   List scheduler hints via API
7)   Host directory service
8)   The future of the scheduler
9)   Network bandwisth aware scheduling (and wider aspects)
10) ensembles/vclusters

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786



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

Re: [openstack-dev] Termination of the title line of commit messages

[Russell Bryant]

On 06/24/2013 08:14 PM, Angus Salkeld wrote:
> On 24/06/13 22:50 +0100, Mark McLoughlin wrote:
>> Hey,
>>
>> Pulling this out of gerrit for discussion.
>>
>> Background is one of my patches to diskimage-builder was -1ed because I
>> terminated the title line of the commit message with a period:
>>
>>  https://review.openstack.org/33262
>>
>> This is actually the exact opposite to what I consider normal practice
>> for git commit messages as I explained in the review and the tripleo
>> wiki page, so I proposed a hacking change here:
>>
>>  https://review.openstack.org/33789
> 
> Can't we just agree to not -1 on this issue? This seems like a major
> waste of people resources.

+100

-- 
Russell Bryant

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

Re: [openstack-dev] Termination of the title line of commit messages

[Angus Salkeld]

On 24/06/13 22:50 +0100, Mark McLoughlin wrote:

Hey,

Pulling this out of gerrit for discussion.

Background is one of my patches to diskimage-builder was -1ed because I
terminated the title line of the commit message with a period:

 https://review.openstack.org/33262

This is actually the exact opposite to what I consider normal practice
for git commit messages as I explained in the review and the tripleo
wiki page, so I proposed a hacking change here:

 https://review.openstack.org/33789


Can't we just agree to not -1 on this issue? This seems like a major
waste of people resources.

-Angus



The rationale for *not* having a period is:

 * With the 50 char limit, space is at a premium on the first line

 * The first line is often used as the Subject: in [PATCH] emails -
   subject lines in emails generally don't end in a period

 * Examples in:

 
https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure

   don't end in period

   (Note - the "should not end with a period" was only added by me
   recently)

 * Another common reference on git commit messages

 http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html 
doesn't either

 * In git's own git repo, 1.43% of commit messages in the last year
   ended in a period

 * I'm not aware of any other OpenStack project which enforces this.
   Looking at the history of various projects for the past year (and
   excluding merge commits which don't end with a period), the use of
   period termination runs at between 10 and 30%.

Unlike other nitpicking I tend to do with commit messages, I previously
never thought this was worth even mentioning to committers but if some
reviewers were going to start -1ing people for the *correct* style then
I figured it was best to clear it up.

Now, for Robert's comments in the review:


It would have been nice for this to be discussed rather than dropping
into the communal standards without warning;


I tried my best do explain why period termination is broken in the
diskimage-builder review and wiki page, so it's not like I was trying to
avoid a discussion.

In any case, if I, jogo and sdague got this wrong somehow, the mistake
is only a git-revert away from being corrected.


the prior documentation *did not* require a period,


Yes, but the examples didn't use a period which obviously means a policy
to *require* a period is a bit bizarre.

I'm pretty confident that danpb didn't mention this when he wrote the
page because he either felt it was obvious or not worth mentioning. I've
cc-ed him to be sure.


and the reference that was sourced that
doesn't use them is one in the git-via-email world which is not how
OpenStack does *any* of it's git communications, so the 'gets used
like subject line of emails' point is entirely irrelevant.


git was born came from a git-via-email world and its usage conventions
reflect that. I raised the subject line point to try and explain how git
conventions may have arisen.


In TripleO we have been using a period because the first line of the
commit message acts like the first line of a docstring: it is a pithy
description of the object it describes. Docstrings are also space
limited, and yet PEP8 happily requires good sentence structure and
grammar there.


It's not a docstring, though. It's a git commit message.


tl;dr - this is an unpythonic change, and the lack of discussion is
quite annoying.


Well, the former point is irrelevant and hopefully this email corrects
the latter point :)

Cheers,
Mark.


___
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] Termination of the title line of commit messages

[John Griffith]

On Mon, Jun 24, 2013 at 5:36 PM, Christopher Yeoh  wrote:

> On Tue, Jun 25, 2013 at 7:56 AM, Joe Gordon  wrote:
>
>> As long as it gets auto enforced in hacking, I'll adapt to whatever. I
>> admit I've been bleeding my first line to 72 characters recently as I
>> wasn't sure we were still enforcing at 50. But I'm adaptable to 50. Makes
>> you get to the point with that first line.
>>
>> FWIW we say 50 and enforce 72 (
>> https://github.com/openstack-dev/hacking/blob/master/hacking/core.py#L778
>> ).
>>
>>
>
> I'd prefer 72 than 50. I thought it was enforced at 50 and so there's been
> few changes I've submitted recently where
> I've resorted to dropping vowels to make it fit. My preference also would
> be there to be no period at the end
>
> Chris
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Shorter the better IMO, I'd prefer we leave it alone but I've got enough
to work on that I'll just go with the flow if everyone decides to change
it.  I'd prefer to have more concise summaries when browsing changes.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Termination of the title line of commit messages

[Christopher Yeoh]

On Tue, Jun 25, 2013 at 7:56 AM, Joe Gordon  wrote:

> As long as it gets auto enforced in hacking, I'll adapt to whatever. I
> admit I've been bleeding my first line to 72 characters recently as I
> wasn't sure we were still enforcing at 50. But I'm adaptable to 50. Makes
> you get to the point with that first line.
>
> FWIW we say 50 and enforce 72 (
> https://github.com/openstack-dev/hacking/blob/master/hacking/core.py#L778
> ).
>
>

I'd prefer 72 than 50. I thought it was enforced at 50 and so there's been
few changes I've submitted recently where
I've resorted to dropping vowels to make it fit. My preference also would
be there to be no period at the end

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

Re: [openstack-dev] defaults: making OpenStack work out of the box.

[Joe Gordon]

On Mon, Jun 24, 2013 at 3:46 PM, Monty Taylor  wrote:

>
>
> On 05/29/2013 08:48 AM, Doug Hellmann wrote:
> >
> >
> >
> > On Wed, May 29, 2013 at 6:12 AM, Thierry Carrez  > > wrote:
> >
> > Robert Collins wrote:
> > > On the other hand, we're finding a large chunk of the work we're
> doing
> > > is changing defaults.
> > >
> > > If we were changing them down from 'this works for prod clouds' to
> > > 'this works for a test cloud' - that would be fine. But we're
> changing
> > > them *up* : larger sqlalchemy pools, larger quotas for 'admin',
> larger
> > > quotas for end users.
> > >
> > > Another large chunk of the bring up is determining private network
> > > details w/in Quantum - something that isn't (typically) exposed to
> > > either the real world *or* other machines w/in the datacentre.
> > >
> > > So I find myself asking two questions:
> > >
> > > a) why aren't the defaults suitable for production? Where they are
> not
> > > suitable, it's just friction waiting to trip new deployers up.
> > >
> > > b) perhaps we can document - or even automate - some defaults for
> > > things like Quantum topology, which will work ok everywhere, and
> which
> > > we can tell folk who are just getting going 'follow this, it will
> work
> > > well enough for you to get experience with the rest of the
> system'..
> >
> > Default values always target a specific use case, as for some
> parameters
> > there is just no default value that works for "most cases".
> >
> > The trick is to define a target use case for your defaults, and not
> have
> > half the default values care for a all-in-one while the others care
> for
> > a thousand nodes deployment. You'll always create friction for some
> > categories of users, but at least it should be a consistent friction
> :)
> >
> > Alternatively you can ship multiple sets of defaults (I remember
> MySQL
> > doing this for some time) if it's difficult to get documentation to
> > cover the various use cases.
>
> These went stale very quickly...
>
> > It's easy for developers to override the defaults to work for all-in-one
> > deployments via devstack. We should try to make the baked-in defaults
> > more useful for non-development use cases. Perhaps the defaults should
> > work for a "moderate" size with a few compute nodes (someone should
> > suggest a specific number), which would make them useful for
> > proof-of-concept setups. We can also ship separate example files for
> > "large" deployments, as you suggest.
>
> I'm going to suggest a "moderate" size default suggestion.
>
> What if our defaults are sensible for a single rack of gear? It seems to
> be a common enough unit of measure - and having a rack-sized set of
> defaults on a couple of machines probably won't kill much. OTOH - if
> you're doing a data center, there is NO WAY you're going to not
> configure something.
>


For a concrete example, rate limiting.


https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/limits.py#L225

Here are the current values:

DEFAULT_LIMITS = [

Limit("POST", "*", ".*", 10, PER_MINUTE),
Limit("POST", "*/servers", "^/servers", 50, PER_DAY),
Limit("PUT", "*", ".*", 10, PER_MINUTE),
Limit("GET", "*changes-since*", ".*changes-since.*", 3, PER_MINUTE),
Limit("DELETE", "*", ".*", 100, PER_MINUTE),
Limit("GET", "*/os-fping", "^/os-fping", 12, PER_HOUR),
]

What do people use in production, or do you use it at all?

Rate limiting to 10 POSTS per minute and 50 servers per day seems
*way* to low for any sort of deployment - production or otherwise.



>
>
> > --
> > Thierry Carrez (ttx)
> > Release Manager, OpenStack
> >
> > ___
> > 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
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] defaults: making OpenStack work out of the box.

[Doug Hellmann]

On Mon, Jun 24, 2013 at 6:46 PM, Monty Taylor  wrote:

>
>
> On 05/29/2013 08:48 AM, Doug Hellmann wrote:
> >
> >
> >
> > On Wed, May 29, 2013 at 6:12 AM, Thierry Carrez  > > wrote:
> >
> > Robert Collins wrote:
> > > On the other hand, we're finding a large chunk of the work we're
> doing
> > > is changing defaults.
> > >
> > > If we were changing them down from 'this works for prod clouds' to
> > > 'this works for a test cloud' - that would be fine. But we're
> changing
> > > them *up* : larger sqlalchemy pools, larger quotas for 'admin',
> larger
> > > quotas for end users.
> > >
> > > Another large chunk of the bring up is determining private network
> > > details w/in Quantum - something that isn't (typically) exposed to
> > > either the real world *or* other machines w/in the datacentre.
> > >
> > > So I find myself asking two questions:
> > >
> > > a) why aren't the defaults suitable for production? Where they are
> not
> > > suitable, it's just friction waiting to trip new deployers up.
> > >
> > > b) perhaps we can document - or even automate - some defaults for
> > > things like Quantum topology, which will work ok everywhere, and
> which
> > > we can tell folk who are just getting going 'follow this, it will
> work
> > > well enough for you to get experience with the rest of the
> system'..
> >
> > Default values always target a specific use case, as for some
> parameters
> > there is just no default value that works for "most cases".
> >
> > The trick is to define a target use case for your defaults, and not
> have
> > half the default values care for a all-in-one while the others care
> for
> > a thousand nodes deployment. You'll always create friction for some
> > categories of users, but at least it should be a consistent friction
> :)
> >
> > Alternatively you can ship multiple sets of defaults (I remember
> MySQL
> > doing this for some time) if it's difficult to get documentation to
> > cover the various use cases.
>
> These went stale very quickly...
>
> > It's easy for developers to override the defaults to work for all-in-one
> > deployments via devstack. We should try to make the baked-in defaults
> > more useful for non-development use cases. Perhaps the defaults should
> > work for a "moderate" size with a few compute nodes (someone should
> > suggest a specific number), which would make them useful for
> > proof-of-concept setups. We can also ship separate example files for
> > "large" deployments, as you suggest.
>
> I'm going to suggest a "moderate" size default suggestion.
>
> What if our defaults are sensible for a single rack of gear? It seems to
> be a common enough unit of measure - and having a rack-sized set of
> defaults on a couple of machines probably won't kill much. OTOH - if
> you're doing a data center, there is NO WAY you're going to not
> configure something.
>

+1


>
>
> > --
> > Thierry Carrez (ttx)
> > Release Manager, OpenStack
> >
> > ___
> > 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
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] defaults: making OpenStack work out of the box.

[Monty Taylor]

On 05/29/2013 08:48 AM, Doug Hellmann wrote:
> 
> 
> 
> On Wed, May 29, 2013 at 6:12 AM, Thierry Carrez  > wrote:
> 
> Robert Collins wrote:
> > On the other hand, we're finding a large chunk of the work we're doing
> > is changing defaults.
> >
> > If we were changing them down from 'this works for prod clouds' to
> > 'this works for a test cloud' - that would be fine. But we're changing
> > them *up* : larger sqlalchemy pools, larger quotas for 'admin', larger
> > quotas for end users.
> >
> > Another large chunk of the bring up is determining private network
> > details w/in Quantum - something that isn't (typically) exposed to
> > either the real world *or* other machines w/in the datacentre.
> >
> > So I find myself asking two questions:
> >
> > a) why aren't the defaults suitable for production? Where they are not
> > suitable, it's just friction waiting to trip new deployers up.
> >
> > b) perhaps we can document - or even automate - some defaults for
> > things like Quantum topology, which will work ok everywhere, and which
> > we can tell folk who are just getting going 'follow this, it will work
> > well enough for you to get experience with the rest of the system'..
> 
> Default values always target a specific use case, as for some parameters
> there is just no default value that works for "most cases".
> 
> The trick is to define a target use case for your defaults, and not have
> half the default values care for a all-in-one while the others care for
> a thousand nodes deployment. You'll always create friction for some
> categories of users, but at least it should be a consistent friction :)
> 
> Alternatively you can ship multiple sets of defaults (I remember MySQL
> doing this for some time) if it's difficult to get documentation to
> cover the various use cases.

These went stale very quickly...

> It's easy for developers to override the defaults to work for all-in-one
> deployments via devstack. We should try to make the baked-in defaults
> more useful for non-development use cases. Perhaps the defaults should
> work for a "moderate" size with a few compute nodes (someone should
> suggest a specific number), which would make them useful for
> proof-of-concept setups. We can also ship separate example files for
> "large" deployments, as you suggest.

I'm going to suggest a "moderate" size default suggestion.

What if our defaults are sensible for a single rack of gear? It seems to
be a common enough unit of measure - and having a rack-sized set of
defaults on a couple of machines probably won't kill much. OTOH - if
you're doing a data center, there is NO WAY you're going to not
configure something.


> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
> 
> ___
> 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] Termination of the title line of commit messages

[Melanie Witt]

On Jun 24, 2013, at 2:50 PM, Mark McLoughlin wrote:
> 
> Unlike other nitpicking I tend to do with commit messages, I previously
> never thought this was worth even mentioning to committers but if some
> reviewers were going to start -1ing people for the *correct* style then
> I figured it was best to clear it up.

I too have never thought it worth mentioning, similar to capitalizing the first 
word of the first line of the commit message or not. I thought any way works, 
as long as the first line is brief so it shows up nicely browsing on github.

Personally, I treat the first line like you mention the subject line of an 
email, which I never capitalize or use a period at the end.

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

Re: [openstack-dev] Termination of the title line of commit messages

[Monty Taylor]

On 06/24/2013 06:19 PM, Sean Dague wrote:
> On 06/24/2013 06:15 PM, Monty Taylor wrote:
>>
>>
>> On 06/24/2013 05:56 PM, Mark McLoughlin wrote:
>>> On Mon, 2013-06-24 at 22:50 +0100, Mark McLoughlin wrote:
 Hey,

 Pulling this out of gerrit for discussion.

 Background is one of my patches to diskimage-builder was -1ed because I
 terminated the title line of the commit message with a period:

https://review.openstack.org/33262

 This is actually the exact opposite to what I consider normal practice
 for git commit messages as I explained in the review and the tripleo
 wiki page, so I proposed a hacking change here:

https://review.openstack.org/33789

 The rationale for *not* having a period is:

* With the 50 char limit, space is at a premium on the first line

* The first line is often used as the Subject: in [PATCH] emails -
  subject lines in emails generally don't end in a period

* Examples in:

   
 https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure


  don't end in period

  (Note - the "should not end with a period" was only added by me
  recently)

* Another common reference on git commit messages

   
 http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
 doesn't either

* In git's own git repo, 1.43% of commit messages in the last year
  ended in a period

* I'm not aware of any other OpenStack project which enforces this.
  Looking at the history of various projects for the past year (and
  excluding merge commits which don't end with a period), the use of
  period termination runs at between 10 and 30%.

 Unlike other nitpicking I tend to do with commit messages, I previously
 never thought this was worth even mentioning to committers but if some
 reviewers were going to start -1ing people for the *correct* style then
 I figured it was best to clear it up.

 Now, for Robert's comments in the review:

> It would have been nice for this to be discussed rather than dropping
> into the communal standards without warning;

 I tried my best do explain why period termination is broken in the
 diskimage-builder review and wiki page, so it's not like I was
 trying to
 avoid a discussion.

 In any case, if I, jogo and sdague got this wrong somehow, the mistake
 is only a git-revert away from being corrected.

> the prior documentation *did not* require a period,

 Yes, but the examples didn't use a period which obviously means a
 policy
 to *require* a period is a bit bizarre.

 I'm pretty confident that danpb didn't mention this when he wrote the
 page because he either felt it was obvious or not worth mentioning.
 I've
 cc-ed him to be sure.

> and the reference that was sourced that
> doesn't use them is one in the git-via-email world which is not how
> OpenStack does *any* of it's git communications, so the 'gets used
> like subject line of emails' point is entirely irrelevant.

 git was born came from a git-via-email world and its usage conventions
 reflect that. I raised the subject line point to try and explain how
 git
 conventions may have arisen.

> In TripleO we have been using a period because the first line of the
> commit message acts like the first line of a docstring: it is a pithy
> description of the object it describes. Docstrings are also space
> limited, and yet PEP8 happily requires good sentence structure and
> grammar there.

 It's not a docstring, though. It's a git commit message.

> tl;dr - this is an unpythonic change, and the lack of discussion is
> quite annoying.

 Well, the former point is irrelevant and hopefully this email corrects
 the latter point :)
>>>
>>> I missed this point:
>>>
 Also not that space is limited to 50 characters by choice, not
 necessity (the very same external reference about git commit messages
 pointed out that 50 is not a hard limit). It is a hard limit for us...
 because we chose to make it so.
>>>
>>> It's another pretty common git usage convention - I think the idea is to
>>> make output like 'git log --oneline' fit on 80 char terminals. The
>>> numbers don't add up, though, so maybe it's another thing from the
>>> git-via-email world. Also, the idea is probably to take into account
>>> that the first line can be quoted by e.g. 'Merge "foo"' or 'Revert
>>> "foo"' in the first line of other commit messages.
>>
>> Long commit messages also look like poop in gerrit, and I don't think
>> anyone cares enough about bucking this style thing to go write Java to
>> fix it.
>>
>> 50 chars is common enough that vim syntax

Re: [openstack-dev] Termination of the title line of commit messages

[Joe Gordon]

On Mon, Jun 24, 2013 at 3:19 PM, Sean Dague  wrote:

> On 06/24/2013 06:15 PM, Monty Taylor wrote:
>
>>
>>
>> On 06/24/2013 05:56 PM, Mark McLoughlin wrote:
>>
>>> On Mon, 2013-06-24 at 22:50 +0100, Mark McLoughlin wrote:
>>>
 Hey,

 Pulling this out of gerrit for discussion.

 Background is one of my patches to diskimage-builder was -1ed because I
 terminated the title line of the commit message with a period:

https://review.openstack.org/**33262

 This is actually the exact opposite to what I consider normal practice
 for git commit messages as I explained in the review and the tripleo
 wiki page, so I proposed a hacking change here:

https://review.openstack.org/**33789

 The rationale for *not* having a period is:

* With the 50 char limit, space is at a premium on the first line

* The first line is often used as the Subject: in [PATCH] emails -
  subject lines in emails generally don't end in a period

* Examples in:

https://wiki.openstack.org/**wiki/GitCommitMessages#**
 Summary_of_GIT_commit_message_**structure

  don't end in period

  (Note - the "should not end with a period" was only added by me
  recently)

* Another common reference on git commit messages

http://tbaggery.com/2008/04/**19/a-note-about-git-commit-**
 messages.htmldoesn't
  either

* In git's own git repo, 1.43% of commit messages in the last year
  ended in a period

* I'm not aware of any other OpenStack project which enforces this.
  Looking at the history of various projects for the past year (and
  excluding merge commits which don't end with a period), the use of
  period termination runs at between 10 and 30%.

 Unlike other nitpicking I tend to do with commit messages, I previously
 never thought this was worth even mentioning to committers but if some
 reviewers were going to start -1ing people for the *correct* style then
 I figured it was best to clear it up.

 Now, for Robert's comments in the review:

  It would have been nice for this to be discussed rather than dropping
> into the communal standards without warning;
>

 I tried my best do explain why period termination is broken in the
 diskimage-builder review and wiki page, so it's not like I was trying to
 avoid a discussion.

 In any case, if I, jogo and sdague got this wrong somehow, the mistake
 is only a git-revert away from being corrected.

  the prior documentation *did not* require a period,
>

 Yes, but the examples didn't use a period which obviously means a policy
 to *require* a period is a bit bizarre.

 I'm pretty confident that danpb didn't mention this when he wrote the
 page because he either felt it was obvious or not worth mentioning. I've
 cc-ed him to be sure.

  and the reference that was sourced that
> doesn't use them is one in the git-via-email world which is not how
> OpenStack does *any* of it's git communications, so the 'gets used
> like subject line of emails' point is entirely irrelevant.
>

 git was born came from a git-via-email world and its usage conventions
 reflect that. I raised the subject line point to try and explain how git
 conventions may have arisen.

  In TripleO we have been using a period because the first line of the
> commit message acts like the first line of a docstring: it is a pithy
> description of the object it describes. Docstrings are also space
> limited, and yet PEP8 happily requires good sentence structure and
> grammar there.
>

 It's not a docstring, though. It's a git commit message.

  tl;dr - this is an unpythonic change, and the lack of discussion is
> quite annoying.
>

 Well, the former point is irrelevant and hopefully this email corrects
 the latter point :)

>>>
>>> I missed this point:
>>>
>>>  Also not that space is limited to 50 characters by choice, not
 necessity (the very same external reference about git commit messages
 pointed out that 50 is not a hard limit). It is a hard limit for us...
 because we chose to make it so.

>>>
>>> It's another pretty common git usage convention - I think the idea is to
>>> make output like 'git log --oneline' fit on 80 char terminals. The
>>> numbers don't add up, though, so maybe it's another thing from the
>>> git-via-email world. Also, the idea is probably to take into account
>>> that the first line can be quoted by e.g. 'Merge

Re: [openstack-dev] New BP - ServiceId binding with role definition

[Tiwari, Arvind]

All,

Added etherpad link, please share your comments  or suggestion

https://etherpad.openstack.org/serviceid-binding-with-role-definition

Arvind


From: Tiwari, Arvind
Sent: Wednesday, June 19, 2013 4:42 PM
To: OpenStack Development Mailing List
Subject: New BP - ServiceId binding with role definition

All,

I have added a new BP, which advocates service id binding with role definition

https://blueprints.launchpad.net/keystone/+spec/serviceid-binding-with-role-definition

Please look at it and share your comments.


Arvind

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

Re: [openstack-dev] Termination of the title line of commit messages

[Sean Dague]

On 06/24/2013 06:15 PM, Monty Taylor wrote:



On 06/24/2013 05:56 PM, Mark McLoughlin wrote:

On Mon, 2013-06-24 at 22:50 +0100, Mark McLoughlin wrote:

Hey,

Pulling this out of gerrit for discussion.

Background is one of my patches to diskimage-builder was -1ed because I
terminated the title line of the commit message with a period:

   https://review.openstack.org/33262

This is actually the exact opposite to what I consider normal practice
for git commit messages as I explained in the review and the tripleo
wiki page, so I proposed a hacking change here:

   https://review.openstack.org/33789

The rationale for *not* having a period is:

   * With the 50 char limit, space is at a premium on the first line

   * The first line is often used as the Subject: in [PATCH] emails -
 subject lines in emails generally don't end in a period

   * Examples in:

   
https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure

 don't end in period

 (Note - the "should not end with a period" was only added by me
 recently)

   * Another common reference on git commit messages

   http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html 
doesn't either

   * In git's own git repo, 1.43% of commit messages in the last year
 ended in a period

   * I'm not aware of any other OpenStack project which enforces this.
 Looking at the history of various projects for the past year (and
 excluding merge commits which don't end with a period), the use of
 period termination runs at between 10 and 30%.

Unlike other nitpicking I tend to do with commit messages, I previously
never thought this was worth even mentioning to committers but if some
reviewers were going to start -1ing people for the *correct* style then
I figured it was best to clear it up.

Now, for Robert's comments in the review:


It would have been nice for this to be discussed rather than dropping
into the communal standards without warning;


I tried my best do explain why period termination is broken in the
diskimage-builder review and wiki page, so it's not like I was trying to
avoid a discussion.

In any case, if I, jogo and sdague got this wrong somehow, the mistake
is only a git-revert away from being corrected.


the prior documentation *did not* require a period,


Yes, but the examples didn't use a period which obviously means a policy
to *require* a period is a bit bizarre.

I'm pretty confident that danpb didn't mention this when he wrote the
page because he either felt it was obvious or not worth mentioning. I've
cc-ed him to be sure.


and the reference that was sourced that
doesn't use them is one in the git-via-email world which is not how
OpenStack does *any* of it's git communications, so the 'gets used
like subject line of emails' point is entirely irrelevant.


git was born came from a git-via-email world and its usage conventions
reflect that. I raised the subject line point to try and explain how git
conventions may have arisen.


In TripleO we have been using a period because the first line of the
commit message acts like the first line of a docstring: it is a pithy
description of the object it describes. Docstrings are also space
limited, and yet PEP8 happily requires good sentence structure and
grammar there.


It's not a docstring, though. It's a git commit message.


tl;dr - this is an unpythonic change, and the lack of discussion is
quite annoying.


Well, the former point is irrelevant and hopefully this email corrects
the latter point :)


I missed this point:


Also not that space is limited to 50 characters by choice, not
necessity (the very same external reference about git commit messages
pointed out that 50 is not a hard limit). It is a hard limit for us...
because we chose to make it so.


It's another pretty common git usage convention - I think the idea is to
make output like 'git log --oneline' fit on 80 char terminals. The
numbers don't add up, though, so maybe it's another thing from the
git-via-email world. Also, the idea is probably to take into account
that the first line can be quoted by e.g. 'Merge "foo"' or 'Revert
"foo"' in the first line of other commit messages.


Long commit messages also look like poop in gerrit, and I don't think
anyone cares enough about bucking this style thing to go write Java to
fix it.

50 chars is common enough that vim syntax highlighting groks it. I see
no reason to choose a different thing.

Why 50? NO CLUE


As long as it gets auto enforced in hacking, I'll adapt to whatever. I 
admit I've been bleeding my first line to 72 characters recently as I 
wasn't sure we were still enforcing at 50. But I'm adaptable to 50. 
Makes you get to the point with that first line.


-Sean

--
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] Termination of the title line of commit messages

[Monty Taylor]

On 06/24/2013 05:56 PM, Mark McLoughlin wrote:
> On Mon, 2013-06-24 at 22:50 +0100, Mark McLoughlin wrote:
>> Hey,
>>
>> Pulling this out of gerrit for discussion.
>>
>> Background is one of my patches to diskimage-builder was -1ed because I
>> terminated the title line of the commit message with a period:
>>
>>   https://review.openstack.org/33262
>>
>> This is actually the exact opposite to what I consider normal practice
>> for git commit messages as I explained in the review and the tripleo
>> wiki page, so I proposed a hacking change here:
>>
>>   https://review.openstack.org/33789
>>
>> The rationale for *not* having a period is:
>>
>>   * With the 50 char limit, space is at a premium on the first line
>>
>>   * The first line is often used as the Subject: in [PATCH] emails -
>> subject lines in emails generally don't end in a period
>>
>>   * Examples in:
>>
>>   
>> https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure
>>
>> don't end in period
>>
>> (Note - the "should not end with a period" was only added by me 
>> recently)
>>
>>   * Another common reference on git commit messages
>>
>>   http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html 
>> doesn't either
>>
>>   * In git's own git repo, 1.43% of commit messages in the last year 
>> ended in a period
>>
>>   * I'm not aware of any other OpenStack project which enforces this. 
>> Looking at the history of various projects for the past year (and 
>> excluding merge commits which don't end with a period), the use of 
>> period termination runs at between 10 and 30%.
>>
>> Unlike other nitpicking I tend to do with commit messages, I previously
>> never thought this was worth even mentioning to committers but if some
>> reviewers were going to start -1ing people for the *correct* style then
>> I figured it was best to clear it up.
>>
>> Now, for Robert's comments in the review:
>>
>>> It would have been nice for this to be discussed rather than dropping
>>> into the communal standards without warning;
>>
>> I tried my best do explain why period termination is broken in the
>> diskimage-builder review and wiki page, so it's not like I was trying to
>> avoid a discussion.
>>
>> In any case, if I, jogo and sdague got this wrong somehow, the mistake
>> is only a git-revert away from being corrected.
>>
>>> the prior documentation *did not* require a period,
>>
>> Yes, but the examples didn't use a period which obviously means a policy
>> to *require* a period is a bit bizarre.
>>
>> I'm pretty confident that danpb didn't mention this when he wrote the
>> page because he either felt it was obvious or not worth mentioning. I've
>> cc-ed him to be sure.
>>
>>> and the reference that was sourced that
>>> doesn't use them is one in the git-via-email world which is not how
>>> OpenStack does *any* of it's git communications, so the 'gets used
>>> like subject line of emails' point is entirely irrelevant.
>>
>> git was born came from a git-via-email world and its usage conventions
>> reflect that. I raised the subject line point to try and explain how git
>> conventions may have arisen.
>>
>>> In TripleO we have been using a period because the first line of the
>>> commit message acts like the first line of a docstring: it is a pithy
>>> description of the object it describes. Docstrings are also space
>>> limited, and yet PEP8 happily requires good sentence structure and
>>> grammar there.
>>
>> It's not a docstring, though. It's a git commit message.
>>
>>> tl;dr - this is an unpythonic change, and the lack of discussion is
>>> quite annoying.
>>
>> Well, the former point is irrelevant and hopefully this email corrects
>> the latter point :)
> 
> I missed this point:
> 
>> Also not that space is limited to 50 characters by choice, not
>> necessity (the very same external reference about git commit messages
>> pointed out that 50 is not a hard limit). It is a hard limit for us...
>> because we chose to make it so. 
> 
> It's another pretty common git usage convention - I think the idea is to
> make output like 'git log --oneline' fit on 80 char terminals. The
> numbers don't add up, though, so maybe it's another thing from the
> git-via-email world. Also, the idea is probably to take into account
> that the first line can be quoted by e.g. 'Merge "foo"' or 'Revert
> "foo"' in the first line of other commit messages.

Long commit messages also look like poop in gerrit, and I don't think
anyone cares enough about bucking this style thing to go write Java to
fix it.

50 chars is common enough that vim syntax highlighting groks it. I see
no reason to choose a different thing.

Why 50? NO CLUE

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

Re: [openstack-dev] Termination of the title line of commit messages

[Mark McLoughlin]

On Mon, 2013-06-24 at 22:50 +0100, Mark McLoughlin wrote:
> Hey,
> 
> Pulling this out of gerrit for discussion.
> 
> Background is one of my patches to diskimage-builder was -1ed because I
> terminated the title line of the commit message with a period:
> 
>   https://review.openstack.org/33262
> 
> This is actually the exact opposite to what I consider normal practice
> for git commit messages as I explained in the review and the tripleo
> wiki page, so I proposed a hacking change here:
> 
>   https://review.openstack.org/33789
> 
> The rationale for *not* having a period is:
> 
>   * With the 50 char limit, space is at a premium on the first line
> 
>   * The first line is often used as the Subject: in [PATCH] emails -
> subject lines in emails generally don't end in a period
> 
>   * Examples in:
> 
>   
> https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure
> 
> don't end in period
> 
> (Note - the "should not end with a period" was only added by me 
> recently)
> 
>   * Another common reference on git commit messages
> 
>   http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html 
> doesn't either
> 
>   * In git's own git repo, 1.43% of commit messages in the last year 
> ended in a period
> 
>   * I'm not aware of any other OpenStack project which enforces this. 
> Looking at the history of various projects for the past year (and 
> excluding merge commits which don't end with a period), the use of 
> period termination runs at between 10 and 30%.
> 
> Unlike other nitpicking I tend to do with commit messages, I previously
> never thought this was worth even mentioning to committers but if some
> reviewers were going to start -1ing people for the *correct* style then
> I figured it was best to clear it up.
> 
> Now, for Robert's comments in the review:
> 
> > It would have been nice for this to be discussed rather than dropping
> > into the communal standards without warning;
> 
> I tried my best do explain why period termination is broken in the
> diskimage-builder review and wiki page, so it's not like I was trying to
> avoid a discussion.
> 
> In any case, if I, jogo and sdague got this wrong somehow, the mistake
> is only a git-revert away from being corrected.
> 
> > the prior documentation *did not* require a period,
> 
> Yes, but the examples didn't use a period which obviously means a policy
> to *require* a period is a bit bizarre.
> 
> I'm pretty confident that danpb didn't mention this when he wrote the
> page because he either felt it was obvious or not worth mentioning. I've
> cc-ed him to be sure.
> 
> > and the reference that was sourced that
> > doesn't use them is one in the git-via-email world which is not how
> > OpenStack does *any* of it's git communications, so the 'gets used
> > like subject line of emails' point is entirely irrelevant.
> 
> git was born came from a git-via-email world and its usage conventions
> reflect that. I raised the subject line point to try and explain how git
> conventions may have arisen.
> 
> > In TripleO we have been using a period because the first line of the
> > commit message acts like the first line of a docstring: it is a pithy
> > description of the object it describes. Docstrings are also space
> > limited, and yet PEP8 happily requires good sentence structure and
> > grammar there.
> 
> It's not a docstring, though. It's a git commit message.
> 
> > tl;dr - this is an unpythonic change, and the lack of discussion is
> > quite annoying.
> 
> Well, the former point is irrelevant and hopefully this email corrects
> the latter point :)

I missed this point:

> Also not that space is limited to 50 characters by choice, not
> necessity (the very same external reference about git commit messages
> pointed out that 50 is not a hard limit). It is a hard limit for us...
> because we chose to make it so. 

It's another pretty common git usage convention - I think the idea is to
make output like 'git log --oneline' fit on 80 char terminals. The
numbers don't add up, though, so maybe it's another thing from the
git-via-email world. Also, the idea is probably to take into account
that the first line can be quoted by e.g. 'Merge "foo"' or 'Revert
"foo"' in the first line of other commit messages.

Cheers,
Mark.


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

[openstack-dev] Termination of the title line of commit messages

[Mark McLoughlin]

Hey,

Pulling this out of gerrit for discussion.

Background is one of my patches to diskimage-builder was -1ed because I
terminated the title line of the commit message with a period:

  https://review.openstack.org/33262

This is actually the exact opposite to what I consider normal practice
for git commit messages as I explained in the review and the tripleo
wiki page, so I proposed a hacking change here:

  https://review.openstack.org/33789

The rationale for *not* having a period is:

  * With the 50 char limit, space is at a premium on the first line

  * The first line is often used as the Subject: in [PATCH] emails -
subject lines in emails generally don't end in a period

  * Examples in:

  
https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure

don't end in period

(Note - the "should not end with a period" was only added by me 
recently)

  * Another common reference on git commit messages

  http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html 
doesn't either

  * In git's own git repo, 1.43% of commit messages in the last year 
ended in a period

  * I'm not aware of any other OpenStack project which enforces this. 
Looking at the history of various projects for the past year (and 
excluding merge commits which don't end with a period), the use of 
period termination runs at between 10 and 30%.

Unlike other nitpicking I tend to do with commit messages, I previously
never thought this was worth even mentioning to committers but if some
reviewers were going to start -1ing people for the *correct* style then
I figured it was best to clear it up.

Now, for Robert's comments in the review:

> It would have been nice for this to be discussed rather than dropping
> into the communal standards without warning;

I tried my best do explain why period termination is broken in the
diskimage-builder review and wiki page, so it's not like I was trying to
avoid a discussion.

In any case, if I, jogo and sdague got this wrong somehow, the mistake
is only a git-revert away from being corrected.

> the prior documentation *did not* require a period,

Yes, but the examples didn't use a period which obviously means a policy
to *require* a period is a bit bizarre.

I'm pretty confident that danpb didn't mention this when he wrote the
page because he either felt it was obvious or not worth mentioning. I've
cc-ed him to be sure.

> and the reference that was sourced that
> doesn't use them is one in the git-via-email world which is not how
> OpenStack does *any* of it's git communications, so the 'gets used
> like subject line of emails' point is entirely irrelevant.

git was born came from a git-via-email world and its usage conventions
reflect that. I raised the subject line point to try and explain how git
conventions may have arisen.

> In TripleO we have been using a period because the first line of the
> commit message acts like the first line of a docstring: it is a pithy
> description of the object it describes. Docstrings are also space
> limited, and yet PEP8 happily requires good sentence structure and
> grammar there.

It's not a docstring, though. It's a git commit message.

> tl;dr - this is an unpythonic change, and the lack of discussion is
> quite annoying.

Well, the former point is irrelevant and hopefully this email corrects
the latter point :)

Cheers,
Mark.


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

[openstack-dev] bug 1189711 Should RPC consume_in_thread() be more fault tolerant?

[Ray Pekowski]

The code review for this change is I0d6ec8a5: Make AMQP based RPC consumer
threads more robust: https://review.openstack.org/#/c/32235/

There is a need for more reviewers, since there are some questions
surrounding the implementation and whether mox is being used appropriately
for the unit test cases.

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

[openstack-dev] resize confirm broken on XenServer

[Dan Prince]

Just started seeing these in SmokeStack:

https://bugs.launchpad.net/nova/+bug/1194264

I pushed a revert which should fix the issue:

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

Dan

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

Re: [openstack-dev] AMQP Version upgrade plans?

[Russell Bryant]

On 06/24/2013 02:01 PM, Sunjeet Singh wrote:
> 
> 
> OpenStack currently uses AMQP 0.8. Are there any plans to upgrade?

OpenStack is not specifically tied to an AMQP version.  It's more about
what clients we have support for, what versions they speak, and then
what message brokers support that.

Right now we have support for using the kombu (for RabbitMQ) and qpid
(for Qpid) clients.

I actually have a big interest in adding support for AMQP 1.0.  One of
the *really* interesting things with AMQP 1.0 that is relevant for
OpenStack is that it is not tied to using a message broker.  You can use
it in both a peer-to-peer and a brokered way.  This is interesting,
because depending on the messaging pattern we're using, we may want one
vs the other in different parts of OpenStack.

As for the specifics to doing this, the only AMQP 1.0 client I know of
is Proton.  It does have Python bindings.

http://qpid.apache.org/proton/

As for the server side, ActiveMQ recently added AMQP 1.0 support using
this same library (proton).

http://activemq.apache.org/

-- 
Russell Bryant

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

Re: [openstack-dev] OpenStack Programs

[Robert Collins]

On 24 June 2013 21:50, Thierry Carrez  wrote:

> To match with the current state we would end up with:
> * Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder,
> Ceilometer, Heat)
> * Incubated projects (Trove, Ironic)
> * Programs (Oslo, Infrastructure, Documentation, QA)

Maybe Programs should have an incubation period, where they show they
have their s***^Wstuff together before being blessed ?

> * There are efforts that span multiple projects but work directly on the
> project code repositories, like integrated release, or stable
> maintenance, or vulnerability management (collectively called for the
> convenience of this thread "horizontal efforts"). Should they be
> considered separate programs (without repos) ? Be lumped together into
> some catch-all "integration" or "production" program ? Or ignored as far
> as ATC status goes ? I've mixed feelings about that. On one hand I'd
> like those efforts visible and official to be more widely seen as a good
> way to contribute to OpenStack. On the other hand it's hard to tie ATC
> membership to those since we can't trace that back to commits to a
> specific repo, and I'd like the programs mission statements to be
> precise rather than vague, so that the TC can bless them...

If a Program has no code repos of it's own, but it's contributors
contribute to other projects, ATC status seems like a two-fold thing.
On the one hand, you want ATC status for individual contributors to
vote for the TC. Check, thats achieved. On the other hand you want ATC
status to vote for the PTL of the Program : that will be harder. As
Monty says, lets revisit. Also, I don't think we have any Program
without a code repo today, so it's a moot point : I suggest saying
that until it is revisited, there cannot be a Program w/o a code repo.


-Rob
-- 
Robert Collins 
Distinguished Technologist
HP Cloud Services

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

[openstack-dev] AMQP Version upgrade plans?

[Sunjeet Singh]

OpenStack currently uses AMQP 0.8. Are there any plans to upgrade?


Thank you,
Sunjeet




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

Re: [openstack-dev] OpenStack Programs

[Monty Taylor]

On 06/24/2013 05:50 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> "Official" OpenStack projects are those under the oversight of the
> Technical Committee, and contributing to one grants you ATC status
> (which in turn you use to elect the Technical Committee members).
> 
> The list of official projects used to be simple (Swift+Nova) but
> nowadays it is rather convoluted, with categories like "integrated",
> "incubated", "library", "gating" and "supporting", as described in [1].
> That complexity derived from the need to special-case some projects
> because their PTL would automatically get a TC seat. Now that we
> simplified the TC membership, we can also simplify official projects
> nomenclature by blessing the goals rather than the specific repositories.
> 
> [1] https://wiki.openstack.org/wiki/Projects
> 
> This is why Monty had the idea of "programs" which would be blessed by
> the TC (and then any code under an official program becomes "official").
> Rather than trying to come up with categories that would cover all the
> stuff that the Infrastructure team is working on (gating, supporting,
> libraries...), just say that "Infrastructure" is a program and let them
> add any repo that they need. The TC would bless the *mission statement*
> of the program rather than the specific set of projects implemented to
> reach that goal.
> 
> That sounds like a pretty nice idea, so could we consider everything
> falls under the realm of a "program" ? Like having an "integrated
> release" program that would contain all integrated projects ? I think we
> need to keep special-casing a concept of "projects", separated from
> "programs", since those are accepted one by one by the TC and go through
> an incubation period. Those "projects" would contain at least one repo
> that wants to be part of the integrated, common OpenStack release, plus
> anything the same team works on (like the corresponding python client
> project).
> 
> To match with the current state we would end up with:
> * Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder,
> Ceilometer, Heat)
> * Incubated projects (Trove, Ironic)
> * Programs (Oslo, Infrastructure, Documentation, QA)
> 
> New programs would draft a clear mission statement and apply to the TC
> for consideration. Programs should also expect to have a specific
> "topic" at the Design Summit (most of them already have), and should
> probably designate a lead/ambassador as a clear go-to person.

Thank you for describing the idea very well! I specifically like the
idea of a program proposal drafting a mission statement and having a
PTL. (infra and oslo both do PTLs, so I think it's a fair thing to
except other programs to as well)

> A few questions I had left:
> 
> * There are efforts that span multiple projects but work directly on the
> project code repositories, like integrated release, or stable
> maintenance, or vulnerability management (collectively called for the
> convenience of this thread "horizontal efforts"). Should they be
> considered separate programs (without repos) ? Be lumped together into
> some catch-all "integration" or "production" program ? Or ignored as far
> as ATC status goes ? I've mixed feelings about that. On one hand I'd
> like those efforts visible and official to be more widely seen as a good
> way to contribute to OpenStack. On the other hand it's hard to tie ATC
> membership to those since we can't trace that back to commits to a
> specific repo, and I'd like the programs mission statements to be
> precise rather than vague, so that the TC can bless them...

I'd actually like to revisit this question as a separate thing.
Honestly, I want to see bug work and review work as part of the ATC
calculation. Seriously - both are hard and thankless. I think those are
really the only two places where work on the above stuff can 'fall
through the cracks' by potentially not having a 'patch'.

> * Where would devstack fall ? QA program ? Infrastructure program ?

I think it's honestly a joint-venture between QA and Infra (especially
if you consider developer tooling to fall into the infra umbrella -
which is where it traditionally has fallen) But I'd say it's more
primarily Infra and we use it for QA, rather than the other way around
(as someone said the other day - it's devstack, not teststack or
tempeststack)

> * Where would openstack/requirements fall ?

I think openstack/requirements sits under oslo - although right now it's
a joint-venture between oslo and infra.

Monty

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

[openstack-dev] [Glance] Removing python-sendfile related code from BaseClient

[Paul Bourke]

I'm adding some unit tests for glance/common/client.py as part of
bug/1115551, and noticed the image_iterator() function
(https://github.com/openstack/glance/blob/master/glance/common/client.py#L568)
returns two non-existent types, SendFileIterator and
ImageBodyIterator.

It seems there's no code path that goes down this route; would I be
correct in assuming this is left over from the legacy glanceclient?

I think there's two possible actions - one would be to remove this and
related code that calls it from do_request.  The other would be to
restore these iterator classes back, so this functionality would still
be supported if desired.  Thoughts?

Thanks,
-Paul

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

[openstack-dev] [Horizon[ Update on the realtime-communication blueprint

[Tomas Sedovic]

All,

Presenting a new version of the proof of concept for the 
realtime-communication Horizon blueprint[0]. Here's the code:


https://review.openstack.org/#/q/status:open+project:openstack/horizon+branch:master+topic:bp/realtime-communication,n,z

Following the previous discussion, this iteration listens to the 
OpenStack notifications and passes them using websocket (or one of the 
fallbacks) to the connected browsers. That means adding oslo-incubator 
as a dependency (the RPC bits of it at least).


The code grew a bit more complex, because as far as I can see, the RPC 
helpers in oslo-incubator are deeply intertwined with eventlet, but 
there is no suitable web realtime library built on top of eventlet*.


The available solutions are built on top of gevent or tornado, both of 
which come with their own event loops. In order to both receive 
notifications and push them to the browsers, we need two separate 
threads, one for each event loop.


We're only talking about a 150 lines of code and I don't expect it to 
grow much beyond that, so I'm not really worried about that now. But if 
there are better solutions, please share them.


The original PoC was built on top of gevent and gevent-socketio, neither 
of which is likely to be Python3-compatible any time soon. Since that's 
a requirement for new dependencies, I've switched to Tornado[1] and 
SockJS-tornado[2] that are both compatible with Python 3.


I didn't add the dependencies to openstack/requirements[3] yet but if 
you are fine with this stack, I shall do so and we can start thinking 
about merging this.


To try it out, please run the server:

./horizon-realtime.py --config-file etc/horizon/horizon-realtime.conf

navigate to `http://localhost:8080/project/instances` (you can verify 
the WebSocket connection in the JavaScript console) and then launch an 
instance out of band (e.g. via the nova command line). The webpage 
should update automatically when you add, suspend, resume or delete the 
instance.


T.

[0]: https://blueprints.launchpad.net/horizon/+spec/realtime-communication
[1]: http://www.tornadoweb.org/en/stable/
[2]: https://github.com/mrjoes/sockjs-tornado
[3]: https://github.com/openstack/requirements

* eventlet ships with a WebSocket implementation, but it lacks the 
fallback transports, etc. that socket.io and SockJS provide.


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

Re: [openstack-dev] [Nova] Adding a xenapi_max_ephemeral_disk_size_gb flag

[John Garbutt]

So in the current review, I have just gone for switching between
2000GB and 1024 GB.

I figure we can try this simpler approach, and worry about
generalizing it if people need it later.

John

On 24 June 2013 16:13, Russell Bryant  wrote:
> On 06/21/2013 05:55 AM, John Garbutt wrote:
>> Its just that the limit you want to set varies depending on the
>> flavor. So flavor = 10TB, limit = 2000GB, the final disk is a bit of
>> an odd size, maybe 1024GB would be a better split.
>>
>> Although you make a good point, maybe we should set the "splitting
>> point" in extra specs in the flavor, rather than a config value.
>
> Sounds like it, if it's flavor specific anyway.
>
> --
> Russell Bryant
>
> ___
> 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 Programs

[Mark Washenberger]

Thanks for kicking off this discussion! I think the idea of programs has
fantastic promise.


On Mon, Jun 24, 2013 at 2:50 AM, Thierry Carrez wrote:

> Hi everyone,
>
> "Official" OpenStack projects are those under the oversight of the
> Technical Committee, and contributing to one grants you ATC status
> (which in turn you use to elect the Technical Committee members).
>
> The list of official projects used to be simple (Swift+Nova) but
> nowadays it is rather convoluted, with categories like "integrated",
> "incubated", "library", "gating" and "supporting", as described in [1].
> That complexity derived from the need to special-case some projects
> because their PTL would automatically get a TC seat. Now that we
> simplified the TC membership, we can also simplify official projects
> nomenclature by blessing the goals rather than the specific repositories.
>
> [1] https://wiki.openstack.org/wiki/Projects
>
> This is why Monty had the idea of "programs" which would be blessed by
> the TC (and then any code under an official program becomes "official").
> Rather than trying to come up with categories that would cover all the
> stuff that the Infrastructure team is working on (gating, supporting,
> libraries...), just say that "Infrastructure" is a program and let them
> add any repo that they need. The TC would bless the *mission statement*
> of the program rather than the specific set of projects implemented to
> reach that goal.
>
> That sounds like a pretty nice idea, so could we consider everything
> falls under the realm of a "program" ? Like having an "integrated
> release" program that would contain all integrated projects ? I think we
> need to keep special-casing a concept of "projects", separated from
> "programs", since those are accepted one by one by the TC and go through
> an incubation period. Those "projects" would contain at least one repo
> that wants to be part of the integrated, common OpenStack release, plus
> anything the same team works on (like the corresponding python client
> project).
>
> To match with the current state we would end up with:
> * Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder,
> Ceilometer, Heat)
> * Incubated projects (Trove, Ironic)
> * Programs (Oslo, Infrastructure, Documentation, QA)
>
> New programs would draft a clear mission statement and apply to the TC
> for consideration. Programs should also expect to have a specific
> "topic" at the Design Summit (most of them already have), and should
> probably designate a lead/ambassador as a clear go-to person.
>
> A few questions I had left:
>
> * There are efforts that span multiple projects but work directly on the
> project code repositories, like integrated release, or stable
> maintenance, or vulnerability management (collectively called for the
> convenience of this thread "horizontal efforts"). Should they be
> considered separate programs (without repos) ? Be lumped together into
> some catch-all "integration" or "production" program ? Or ignored as far
> as ATC status goes ? I've mixed feelings about that. On one hand I'd
> like those efforts visible and official to be more widely seen as a good
> way to contribute to OpenStack. On the other hand it's hard to tie ATC
> membership to those since we can't trace that back to commits to a
> specific repo


Can you clarify this concern? Overall, folks would still be ATCs of the
projects that they were committing on in the name of the given program, so
their "OpenStack ATC" status would be successfully tracked regardless. Is
the problem organizing leadership votes *within* the program? If so, could
we settle on horizontal votes being extended to all OpenStack ATCs? or is
that just too wide open?



> , and I'd like the programs mission statements to be
> precise rather than vague, so that the TC can bless them...
>

Can you give an example of the kind of vagueness you're worried about?
Perhaps it is just a failure of my imagination, but I can't seem to
conceive of a way a program mission statement would be distinctly more
vague than a project mission statement.


>
> * Where would devstack fall ? QA program ? Infrastructure program ?
>
> * Where would openstack/requirements fall ?
>
> --
> Thierry Carrez (ttx)
>
> ___
> 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] [Nova] Adding a xenapi_max_ephemeral_disk_size_gb flag

[Russell Bryant]

On 06/21/2013 05:55 AM, John Garbutt wrote:
> Its just that the limit you want to set varies depending on the
> flavor. So flavor = 10TB, limit = 2000GB, the final disk is a bit of
> an odd size, maybe 1024GB would be a better split.
> 
> Although you make a good point, maybe we should set the "splitting
> point" in extra specs in the flavor, rather than a config value.

Sounds like it, if it's flavor specific anyway.

-- 
Russell Bryant

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

Re: [openstack-dev] Cells design issue

[Russell Bryant]

On 06/21/2013 12:16 PM, Armando Migliaccio wrote:
> In my view a cell should only know about the queue it's connected to,
> and let the 'global' message queue to do its job of dispatching the
> messages to the right recipient: that would solve the problem altogether.
> 
> Were federated  queues and
> topic routing
> 
> not considered fit for the purpose? I guess the drawback with this is
> that it is tight to Rabbit.
>

FWIW, qpid does this, too.  It wouldn't be a rabbit specific approach.
I also agree that this seems like a more natural approach and is worth
exploring if someone wants to dig into it some more.

-- 
Russell Bryant

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

[openstack-dev] [Infra] Meeting Tuesday June 25th at 19:00 UTC

[Elizabeth Krumbach Joseph]

The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting tomorrow, Tuesday June 25th, at 19:00 UTC in
#openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

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

Re: [openstack-dev] [Networking] Allocation of IPs

[Mark McClain]

Here's the blueprint…

https://blueprints.launchpad.net/quantum/+spec/configurable-ip-allocation


On Jun 21, 2013, at 5:34 PM, Edgar Magana  wrote:

> Mark,
> 
> Can you point me to the BP for this feature?
> I want to keep an eye on it.
> 
> Thanks,
> 
> Edgar
> 
> From: Mark McClain 
> Reply-To: OpenStack List 
> Date: Friday, June 21, 2013 12:41 PM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [Networking] Allocation of IPs
> 
> There will be a deployment option where you can configure the default IP 
> allocator.  Additionally, the allocator will be configurable at subnet 
> creation time.
> 
> mark
> 
> 
> On Jun 20, 2013, at 4:51 PM, Edgar Magana  wrote:
> 
>> Could it be possible to add a flag to disable the allocation for the IP?
>> If the "no allocation" flag is enabled, all ports will have an empty value 
>> for IPs.
>>  It will increase the config parameters in quantum, should we try it?
>> 
>> Edgar
>> 
>> From: Mark McClain 
>> Reply-To: OpenStack List 
>> Date: Thursday, June 20, 2013 1:13 PM
>> To: OpenStack List 
>> Subject: Re: [openstack-dev] [Networking] Allocation of IPs
>> 
>> There's work under way to make IP allocation pluggable. One of the options 
>> will include not having an allocator for a subnet.
>> 
>> mark
>> 
>> On Jun 20, 2013, at 2:36 PM, Edgar Magana  wrote:
>> 
>>> Developers,
>>> 
>>> So far in Networking (formerly Quantum) IPs are pre-allocated when a new 
>>> port is created by the following def:
>>> _allocate_ips_for_port(self, context, network, port):
>>> 
>>> If we are using a real DHCP (not the dnsmasq process) that does not accept 
>>> static IP allocation because it only allocates IPs based on its own 
>>> algorithm, how can we tell Networking to not allocate an IP at all?
>>> I don’t think that is possible based on the code but I would like to know 
>>> if somebody has gone through the same problem and have a workaround 
>>> solution.
>>> 
>>> Cheers,
>>> 
>>> Edgar
>>> 
>>> ___
>>> 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.orghttp://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
> ___
> 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] [Ceilometer] A DB question for UniqueName/Event/Trait

[Jay Pipes]

On 06/24/2013 04:49 AM, Wang, Shane wrote:

Hi

I am looking at ceilometer DB code. I find there are 3 tables (UniqueName, Event, Trait), and in 
Trait, the two columns "name_id" and "event_id" refer to table UniqueName and 
table Event.

My question is why we need UniqueName and Event, because in both tables there 
are no many other columns, so why not fill unique_name into Trait directly.

Thanks in advance.


Hi Shane,

The purpose of the separate UniqueName table, IIRC, is to reduce the 
footprint of the main Event and Trait tables. A smaller integer foreign 
key can be used instead of a larger string key.


Best,
-jay


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

[openstack-dev] OpenStack Programs

[Thierry Carrez]

Hi everyone,

"Official" OpenStack projects are those under the oversight of the
Technical Committee, and contributing to one grants you ATC status
(which in turn you use to elect the Technical Committee members).

The list of official projects used to be simple (Swift+Nova) but
nowadays it is rather convoluted, with categories like "integrated",
"incubated", "library", "gating" and "supporting", as described in [1].
That complexity derived from the need to special-case some projects
because their PTL would automatically get a TC seat. Now that we
simplified the TC membership, we can also simplify official projects
nomenclature by blessing the goals rather than the specific repositories.

[1] https://wiki.openstack.org/wiki/Projects

This is why Monty had the idea of "programs" which would be blessed by
the TC (and then any code under an official program becomes "official").
Rather than trying to come up with categories that would cover all the
stuff that the Infrastructure team is working on (gating, supporting,
libraries...), just say that "Infrastructure" is a program and let them
add any repo that they need. The TC would bless the *mission statement*
of the program rather than the specific set of projects implemented to
reach that goal.

That sounds like a pretty nice idea, so could we consider everything
falls under the realm of a "program" ? Like having an "integrated
release" program that would contain all integrated projects ? I think we
need to keep special-casing a concept of "projects", separated from
"programs", since those are accepted one by one by the TC and go through
an incubation period. Those "projects" would contain at least one repo
that wants to be part of the integrated, common OpenStack release, plus
anything the same team works on (like the corresponding python client
project).

To match with the current state we would end up with:
* Projects (Nova, Neutron, Swift, Glance, Keystone, Horizon, Cinder,
Ceilometer, Heat)
* Incubated projects (Trove, Ironic)
* Programs (Oslo, Infrastructure, Documentation, QA)

New programs would draft a clear mission statement and apply to the TC
for consideration. Programs should also expect to have a specific
"topic" at the Design Summit (most of them already have), and should
probably designate a lead/ambassador as a clear go-to person.

A few questions I had left:

* There are efforts that span multiple projects but work directly on the
project code repositories, like integrated release, or stable
maintenance, or vulnerability management (collectively called for the
convenience of this thread "horizontal efforts"). Should they be
considered separate programs (without repos) ? Be lumped together into
some catch-all "integration" or "production" program ? Or ignored as far
as ATC status goes ? I've mixed feelings about that. On one hand I'd
like those efforts visible and official to be more widely seen as a good
way to contribute to OpenStack. On the other hand it's hard to tie ATC
membership to those since we can't trace that back to commits to a
specific repo, and I'd like the programs mission statements to be
precise rather than vague, so that the TC can bless them...

* Where would devstack fall ? QA program ? Infrastructure program ?

* Where would openstack/requirements fall ?

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [Ceilometer] A DB question for UniqueName/Event/Trait

[Wang, Shane]

Hi

I am looking at ceilometer DB code. I find there are 3 tables (UniqueName, 
Event, Trait), and in Trait, the two columns "name_id" and "event_id" refer to 
table UniqueName and table Event.

My question is why we need UniqueName and Event, because in both tables there 
are no many other columns, so why not fill unique_name into Trait directly.

Thanks in advance.
--
Shane

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

Re: [openstack-dev] Celery

[Steven Hardy]

On Fri, Jun 21, 2013 at 05:33:05PM +, Jessica Lucci wrote:
> Hello all,
> 
> Included here is a link to a Celery wiki, explaining what the Celery project 
> is and how it works. Currently, celery is being used in a distributed pattern 
> for the WIP task flow project. As such, links to both the distributed 
> project, and its' parent task flow project have been included for your 
> viewing pleasure. Please feel free to ask any questions/address any concerns 
> regarding either celery or the task flow project as a whole. (:
> 
> Celery: https://wiki.openstack.org/wiki/Celery
> Distributed: https://wiki.openstack.org/wiki/DistributedTaskManagement
> TaskFlow: https://wiki.openstack.org/wiki/TaskFlow

There was some discussion of Celery in #heat last week, and one question I
have is re supported brokers, and qpid in particular.

It appears from these pages that celery does not work with qpid, and is not
a supported broker, can you confirm that is the case?

http://docs.celeryproject.org/en/latest/getting-started/brokers/index.html
https://github.com/celery/kombu/issues/54

Related question - if the TaskFlow effort is aiming to become a library in
oslo, or an openstack project in its own right, are there plans to
implement an oslo RPC transport driver for celery?

Thanks!

Steve

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

Re: [openstack-dev] [Horizon] Is it the time to separate horizon and openstack_dashboard?

[Matthias Runge]

On 22/06/13 06:43, Zhigang Wang wrote:
> Current issues:
> 
> * Some places still tight to OpenStack.
> * It pulls all the OpenStack related dependencies, e.g., the client
> api modules, openstack_auth, etc.
> * The test cases.
> 
Yes, I absolutely agree. I think you should create a blueprint to track
all required changes and create bugs for each change.

I think, splitting the code is really appreciated, but also creates some
overhead as well (project naming etc...)

Matthias


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

Re: [openstack-dev] [Nova] Adding a xenapi_max_ephemeral_disk_size_gb flag

[Mate Lakat]

Hi,

I guess, the splitting point is defined by the hypervisor, so I guess
that's a +1 for the config option. Does any other hypervisor have such a
limit? If so, it would make sense to set it to the minimum of all those
limits.

Mate

On Thu, Jun 20, 2013 at 06:02:44PM +0100, John Garbutt wrote:
> Hi,
> 
> I have had some discussions about if I should add a config flag in this 
> change:
> https://review.openstack.org/#/c/32760/
> 
> I am looking to support adding a large amount of ephemeral disk space
> to a VM, but the VHD format has a limit of around 2TB per disk. To
> work around this in XenServer, I plan to add several smaller disks to
> make up the full ephemeral disk space.
> 
> To me it seems worth adding a configuration flag (in this case),
> because there is no easy way to guess the correct value, and there
> doesn't seem to be a great value to hardcode it to. Having said that,
> I suspect the default value will be all most people need, whether or
> not they have very large ephemeral disk space in their flavors.
> 
> I am curious about what people think (in general, and in this case)
> about the tradeoff between: hardcode, magic heuristic calculation, add
> config
> 
> John
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Mate Lakat

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

Re: [openstack-dev] Gerrit's Jenkins should stop running tests after first failure

[Christopher Yeoh]

On Thu, Jun 20, 2013 at 7:31 AM, Dan Smith  wrote:

> Or, you can run dash.py, which will show you a personalized view of
> zuul:
>
> https://github.com/kk7ds/openstack-gerrit-dashboard
>
> Running it with a refresh of thirty seconds or so will give you status
> of your patches as they make their way through the queues, as well as
> early failure warning (in the form of a red line):
>
>
This is really nice!

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