date:20150313



On Fri, Mar 13, 2015, at 01:22 PM, Clint Byrum wrote:
 Excerpts from Doug Hellmann's message of 2015-03-13 08:06:43 -0700:
  
  On Fri, Mar 13, 2015, at 06:57 AM, Thierry Carrez wrote:
   Clint Byrum wrote:
I spend a not-insignificant amount of time deciding which threads to
read and which to fully ignore each day, so extra threads mean extra
work, even with a streamlined workflow of single-key-press-per-thread.

So I'm wondering what people are getting from these announcements being
on the discussion list. I feel like they'd be better off in a weekly
digest, on a web page somewhere, or perhaps with a tag that could be
filtered out for those that don't benefit from them.
   
   The first value of a release announcement is (obviously) to let people
   know something was released. There is a bit of a paradox there with some
   announcements being posted to openstack-announce (in theory low-traffic
   and high-attention), and some announcements being posted to
   openstack-dev (high-traffic and medium-attention). Where is the line
   drawn ?
   
   The second value of a release announcement is the thread it creates in
   case immediate issues are spotted. I kind of like that some
   python-*client release announcements are followed-up by a this broke
   the world thread, all in a single convenient package. Delaying
   announcements defeats that purpose.
   
   We need to adapt our current (restricted) usage of openstack-announce to
   a big-tent less-hierarchical future anyway: if we continue to split
   announcements, which projects are deemed important enough to be
   granted openstack-announce access ?
   
   Personally in the future I'm not opposed to allowing any openstack
   project (big-tent definition) to post to openstack-announce (ideally in
   a standard / autogenerated format) with reply-to set to openstack-dev.
   We could use a separate list, but then release and OSSA announcements
   are the only thing we use -announce for currently, so I'm not sure it's
   worth it.
   
   So I'm +1 on using a specific list (and setting reply-to to -dev), and
   I'm suggesting openstack-announce should be reused to avoid creating two
   classes of deliverables (-announce worthy and not).
  
  We had complaints in the past when we *didn't* send release
  announcements because people were then unaware of why a new release
  might be causing changes in behavior, so we built a bunch of tools to
  make it easy to create uniform and informative release note emails
  containing the level of detail people wanted. So far those are only
  being used by Oslo, but we're moving the scripts to the release-tools
  repo to make them easy for all library maintainers to use.
  
 
 This is really what I'm asking about. If people were less happy with not
 having them, then it makes sense to have them.
 
  These announcements are primarily for our developer community and the
  folks at the distros who need to know to package the new versions. Are
  we going to start having non-dev folks who subscribe to the announce
  list complain about the release announcements for libraries, then? Are
  enough developers subscribed to the announce list that they will see the
  release messages to meet the original needs we were trying to meet?
  
 
 I hope I don't come across as complaining. I archive them very rapidly
 without ever looking at the content currently. Sometimes they come up in
 my searches for topics and then having them in the single timeline is
 great, but I have an email reader that supports this without changing
 the list behavior. I am more wondering if people who aren't as optimized
 as I am have trouble keeping up with them. And having a few less things
 to archive manually would certainly be nicer for me, but is a secondary
 goal.
 
 I haven't seen very much interest in changing things, mostly people in
 support of keeping them as-is. So I suspect people are not annoyed about
 this in particular, and we can close the book on this thread.

OK, I also don't want to give the impression that I don't want to change
things, but I want to make sure we still achieve the goals we had. If
there's a way to make the messages easier to process that doesn't hide
them from the audience that needs to see them, we can adjust our
processes.

Doug

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

2015-03-13 Thread Mike Bayer



Adam Young ayo...@redhat.com wrote:

 On 03/10/2015 10:23 AM, Mike Bayer wrote:
 if *that’s*
  what you mean, that’s known as a “polymorphic foreign key”, and
 it is not actually a foreign key at all, it is a terrible antipattern 
 started by
 the PHP/Rails community and carried forth by projects like Django. 
 A) Heh. it is much, much older than that.  SQL Database have been around for 
 long enough for these antipatterns to be discovered and rediscovered by 
 multiple generations.  I'm aware of the mean by which we cn mitigate them. 
 
 But that is not what we are doing here.  These are no parity issues even.  
 It is distributed data.
 
 User sand Groups are in, not just one LDAP server,  but many.  With 
 Federation, the users  will not even be in a system we can enumerate.  Which 
 is good, we should never have been allowing list users in the first place.
 
 What the Assignments table is doing is pulling together the User and groups 
 from remote systems together with role defintions and project definitions in 
 the local database.  The data is not in one database.  It is in Many.

Of course, if you are referring to data that is related to rows in a
*remote* database, either another SQL database or something else like an
LDAP, you need not have any kind of “foreign key” setup. This is normally
technically infeasible in any case unless you want to do remote schema
access (which you do not). Although I do recommend that referring to remote
databases be done using some kind of portable identifier, usually a GUID,
and not the auto incrementing integers that are local to the schema.

If I can summarize the proposed reasons to remove foreign keys, since my
original question was, can you elaborate on your reasoning that FK
constraints should be used less overall?”, and I just want to make sure 
I’ve got my answer:

1. You have modified your schema such that you are no longer pointing to a
remote record, or that remote record is not in the local database. This
reason is perfectly fine.

2. You’ve benchmarked that the presence of foreign keys is making your
application measurably slower. This reason is perfectly fine, but I don’t
believe Keystone would ever see this (but since we’d be measuring, it
doesn’t matter what I think).

3. You still have tables/rows that refer to each other, but you either have
changed it to not refer to the primary key (note that at least Postgresql
supports foreign keys to UNIQUE columns), or it still refers to the primary
key but the FK is just removed for arbitrary, non-performance based reasons,
or you’re doing some non-normalized, relationally incorrect thing like a 
“polymorphic foreign key”.  I’m totally against these reason, but it does not 
seem 
like this is being proposed.  

So I think Morgan’s original idea was that, for those inter-table
relationships where we refer to something that could just as well come from
a remote datasource, we should not assume any foreign key is present. That
is great. My only point is, if for the time being there *are* two tables
there with a column that refers to the PK of the other, unless you’ve proven
a performance issue, a plain, non-CASCADING foreign key should be left in
place, even though the application should in no way assume this FK is 
present.   Obviously any kind of application logic that makes use of 
an integrity error to learn something about the database should be removed.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

2015-03-13 Thread Sabari Murugesan

+1 to 1500 UTC.

On Fri, Mar 13, 2015 at 11:23 AM, Steve Lewis steve.le...@rackspace.com
wrote:

 +1 consistent time

 +1 for 1500 UTC since that has come up.

 On 09/03/15 09:07, Nikhil Komawar wrote:
 
 So, the new proposal is:
 Glance meetings [1] to be conducted
 weekly on
 Thursdays at 1400UTC [2] on
 #openstack-meeting-4

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Do we need release announcements for all the things?

2015-03-13 Thread Clint Byrum

Excerpts from Doug Hellmann's message of 2015-03-13 08:06:43 -0700:
 
 On Fri, Mar 13, 2015, at 06:57 AM, Thierry Carrez wrote:
  Clint Byrum wrote:
   I spend a not-insignificant amount of time deciding which threads to
   read and which to fully ignore each day, so extra threads mean extra
   work, even with a streamlined workflow of single-key-press-per-thread.
   
   So I'm wondering what people are getting from these announcements being
   on the discussion list. I feel like they'd be better off in a weekly
   digest, on a web page somewhere, or perhaps with a tag that could be
   filtered out for those that don't benefit from them.
  
  The first value of a release announcement is (obviously) to let people
  know something was released. There is a bit of a paradox there with some
  announcements being posted to openstack-announce (in theory low-traffic
  and high-attention), and some announcements being posted to
  openstack-dev (high-traffic and medium-attention). Where is the line
  drawn ?
  
  The second value of a release announcement is the thread it creates in
  case immediate issues are spotted. I kind of like that some
  python-*client release announcements are followed-up by a this broke
  the world thread, all in a single convenient package. Delaying
  announcements defeats that purpose.
  
  We need to adapt our current (restricted) usage of openstack-announce to
  a big-tent less-hierarchical future anyway: if we continue to split
  announcements, which projects are deemed important enough to be
  granted openstack-announce access ?
  
  Personally in the future I'm not opposed to allowing any openstack
  project (big-tent definition) to post to openstack-announce (ideally in
  a standard / autogenerated format) with reply-to set to openstack-dev.
  We could use a separate list, but then release and OSSA announcements
  are the only thing we use -announce for currently, so I'm not sure it's
  worth it.
  
  So I'm +1 on using a specific list (and setting reply-to to -dev), and
  I'm suggesting openstack-announce should be reused to avoid creating two
  classes of deliverables (-announce worthy and not).
 
 We had complaints in the past when we *didn't* send release
 announcements because people were then unaware of why a new release
 might be causing changes in behavior, so we built a bunch of tools to
 make it easy to create uniform and informative release note emails
 containing the level of detail people wanted. So far those are only
 being used by Oslo, but we're moving the scripts to the release-tools
 repo to make them easy for all library maintainers to use.
 

This is really what I'm asking about. If people were less happy with not
having them, then it makes sense to have them.

 These announcements are primarily for our developer community and the
 folks at the distros who need to know to package the new versions. Are
 we going to start having non-dev folks who subscribe to the announce
 list complain about the release announcements for libraries, then? Are
 enough developers subscribed to the announce list that they will see the
 release messages to meet the original needs we were trying to meet?
 

I hope I don't come across as complaining. I archive them very rapidly
without ever looking at the content currently. Sometimes they come up in
my searches for topics and then having them in the single timeline is
great, but I have an email reader that supports this without changing
the list behavior. I am more wondering if people who aren't as optimized
as I am have trouble keeping up with them. And having a few less things
to archive manually would certainly be nicer for me, but is a secondary
goal.

I haven't seen very much interest in changing things, mostly people in
support of keeping them as-is. So I suspect people are not annoyed about
this in particular, and we can close the book on this thread.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Do we need release announcements for all the things?

2015-03-13 Thread Jeremy Stanley

On 2015-03-13 20:09:40 +0100 (+0100), Ihar Hrachyshka wrote:
[...]
 PS: I am not subscribed to announce list. Though I am ok to do so
 if we push announcements there.

You might want to consider subscribing regardless of the outcome of
this discussion. There is often helpful community information
announced there which doesn't necessarily get cross-posted to the
-dev ML.

 (Do we have a way to *discuss* releases there though?)

As Thierry mentioned, we would set Reply-To (hopefully also
Mail-Followup-To) on those so that discussion automatically happens
on the -dev ml and doesn't add further noise to -announce.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

2015-03-13 Thread Steve Lewis

+1 consistent time

+1 for 1500 UTC since that has come up.

On 09/03/15 09:07, Nikhil Komawar wrote:

So, the new proposal is:
Glance meetings [1] to be conducted
weekly on
Thursdays at 1400UTC [2] on
#openstack-meeting-4

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Do we need release announcements for all the things?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/12/2015 09:22 PM, Clint Byrum wrote:
 I spend a not-insignificant amount of time deciding which threads
 to read and which to fully ignore each day, so extra threads mean
 extra work, even with a streamlined workflow of
 single-key-press-per-thread.
 
 So I'm wondering what people are getting from these announcements
 being on the discussion list. I feel like they'd be better off in a
 weekly digest, on a web page somewhere, or perhaps with a tag that
 could be filtered out for those that don't benefit from them.

So here is what I personally get from those announcements:

- - since I'm a stable maintainer, when a gate failure occurs, we
usually have a habit of checking whether there were any recent library
releases. So I go to the list and check recent announcements.
Sometimes it becomes obvious to understand what's the coolprit, since
they contain not only version numbers, but also brief changelogs.
Sometimes announcement transforms into a thread if something goes
wrong due to release. So it's a good place to discuss any gate issues.

- - since I'm an oslo liaison for neutron, I find it extremely helpful
to track which new features are coming into the libraries, or when it
comes to a new library, I consider the official announcement as a sign
that now we're ok with consuming its releases.

For the 2nd case, weekly digest would also work. For the 1st one, not
at all.

PS: I am not subscribed to announce list. Though I am ok to do so if
we push announcements there. (Do we have a way to *discuss* releases
there though?)

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVAzX0AAoJEC5aWaUY1u577MUIAMgoyvbzSuVfBbL5d/fbEiKv
2pIK3W/4w3WALYLMHd+ZBBkktSc3dmpyZun6+4QH5qrXG0QsbdqENXUQKxQBag5b
TgAOh2NqXsFt3PsZDVV3joxuPTJrcvOKd6ISPm5WiEWFGx39WDoRFlBK4kFgFEN4
2/TvT8fvPnits8anJknlWQfCfwrtrqBaCK7uPdzSz88NYT2bARArT7y2cLWYLjVd
5GWoz2NvrLuJfhRhQ6IMIbzHnhSR/xIg1XGN1fKJIuHyaQdA/Xsy/6tB+5/oarG9
TTEofQ2+B7HCNaFH3UqUo0RMFBjP9JP+Qs2+/YlIUer5sH/G73IlvPLA8Rc8Mk0=
=vXtG
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] A question about libvirt cpu mode=none configuration

On 03/13/2015 07:50 AM, Daniel P. Berrange wrote:

On Fri, Mar 13, 2015 at 08:42:25AM -0400, Steve Gordon wrote:

- Original Message -

From: park jianlong...@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org

hello Nova

By default, nova libvirt driver configuration for guest cpu as cpu_mode
= none,
you could add cpu features by changing flavor section as below, there
will NOT
be any issues for this cmd.

$nova flavor-key m1.small set capabilities:cpu_info:features=in ***
but, nova will ignore the cpu features after the guest boot up
successfully, which
means the feature does NOT take effect(not be written into the xml for
the guest).

And there is no message telling the users that the features does NOT
take effect...
this may make the users confused...

This issue is more general than the cpu_mode=none case, in that the
capabilities filter is filtering *hosts* based on their CPU features.
As you have discovered, whether they are actually exposing those
features to guests in their current configuration is not taken into
account (that is, cpu_mode/cpu_model settings aren't considered at
all). Ideally they would be, but I'm not sure this is trivial.

If you set  'cpu_mode=host-model' or 'cpu_mode=host-passthrough'
then it will take effect, as the guest will see the full CPU model
of the host that is picked. IMHO the capabilities:cpu_info:features
filter only makes sense when using those two cpu modes. If you
left the default cpu_mode=None or set cpu_mode=custom, then this
capabilities feature is meaningless from a conceptual POV. So the
fact that it has no effect on the guest CPU is not a bug it is
by design.

If the cpu features aren't going to be passed through into the guest, does it 
make sense for the scheduler to filter based on them?

Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] No concept for user owner of a neutron port... security issue?

2015-03-13 Thread Paul Ward

From what I can tell, neutron ports do not have the concept of an 
owner that is a user.  They have device_owner, which seems to be 
more for things like assigning to a router.


The reason I bring this up is because there seems to be no way to 
restrict the update/delete of a port to only the owner of the nova 
server it's attached to.  You can set the policy file to enforce 
tenant_id, but that would still allow any user in a tenant to delete any 
OTHER user's neutron port in that same tenant.


This actually seems like a security problem to me.  But given it deals 
with a core neutron object, maybe the best way to approach it is with a 
blueprint in Liberty rather than a bug...


Thoughts?


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Do we need release announcements for all the things?

2015-03-13 Thread Dolph Mathews

On Fri, Mar 13, 2015 at 10:06 AM, Doug Hellmann d...@doughellmann.com
wrote:



 On Fri, Mar 13, 2015, at 06:57 AM, Thierry Carrez wrote:
  Clint Byrum wrote:
   I spend a not-insignificant amount of time deciding which threads to
   read and which to fully ignore each day, so extra threads mean extra
   work, even with a streamlined workflow of single-key-press-per-thread.
  
   So I'm wondering what people are getting from these announcements being
   on the discussion list. I feel like they'd be better off in a weekly
   digest, on a web page somewhere, or perhaps with a tag that could be
   filtered out for those that don't benefit from them.
 
  The first value of a release announcement is (obviously) to let people
  know something was released. There is a bit of a paradox there with some
  announcements being posted to openstack-announce (in theory low-traffic
  and high-attention), and some announcements being posted to
  openstack-dev (high-traffic and medium-attention). Where is the line
  drawn ?
 
  The second value of a release announcement is the thread it creates in
  case immediate issues are spotted. I kind of like that some
  python-*client release announcements are followed-up by a this broke
  the world thread, all in a single convenient package. Delaying
  announcements defeats that purpose.
 
  We need to adapt our current (restricted) usage of openstack-announce to
  a big-tent less-hierarchical future anyway: if we continue to split
  announcements, which projects are deemed important enough to be
  granted openstack-announce access ?
 
  Personally in the future I'm not opposed to allowing any openstack
  project (big-tent definition) to post to openstack-announce (ideally in
  a standard / autogenerated format) with reply-to set to openstack-dev.
  We could use a separate list, but then release and OSSA announcements
  are the only thing we use -announce for currently, so I'm not sure it's
  worth it.
 
  So I'm +1 on using a specific list (and setting reply-to to -dev), and
  I'm suggesting openstack-announce should be reused to avoid creating two
  classes of deliverables (-announce worthy and not).

 We had complaints in the past when we *didn't* send release
 announcements because people were then unaware of why a new release
 might be causing changes in behavior, so we built a bunch of tools to
 make it easy to create uniform and informative release note emails
 containing the level of detail people wanted. So far those are only
 being used by Oslo, but we're moving the scripts to the release-tools
 repo to make them easy for all library maintainers to use.


Can we just change the subject line produced by the tooling from:

  [openstack-dev] [all] oslo.versionedobjects 0.1.1 release

to something like:

  [openstack-dev] [release] oslo.versionedobjects 0.1.1

That way everyone can more reliably filter these announcements as they wish?

I fall into the camp of I don't ever want to see these announcements...
until something is broken and I need a culprit.



 These announcements are primarily for our developer community and the
 folks at the distros who need to know to package the new versions. Are
 we going to start having non-dev folks who subscribe to the announce
 list complain about the release announcements for libraries, then? Are
 enough developers subscribed to the announce list that they will see the
 release messages to meet the original needs we were trying to meet?

 
  Posting on -dev with a subject prefix would only marginally improve the
  situation (release announcements are already pretty easy to spot and
  manually filter out), so I'm +0 on that.
 
  Weekly posts or ratelimiting would imho remove 99% of the interest of
  release announcements, so I'm -1 on that solution.
 
  --
  Thierry Carrez (ttx)
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] No concept for user owner of a neutron port... security issue?

2015-03-13 Thread Kevin Benton

Things in Neutron are restricted at the tenant level. Nothing pays
attention to the user ID (other than maybe a custom policy.json entry). If
you have two users that aren't trusted together, they shouldn't be in the
same tenant.

If we want to change that model, it will definitely require a blueprint
because it would need to be changed for everything rather than just ports.

On Fri, Mar 13, 2015 at 11:48 AM, Paul Ward wpw...@linux.vnet.ibm.com
wrote:

 From what I can tell, neutron ports do not have the concept of an owner
 that is a user.  They have device_owner, which seems to be more for
 things like assigning to a router.

 The reason I bring this up is because there seems to be no way to restrict
 the update/delete of a port to only the owner of the nova server it's
 attached to.  You can set the policy file to enforce tenant_id, but that
 would still allow any user in a tenant to delete any OTHER user's neutron
 port in that same tenant.

 This actually seems like a security problem to me.  But given it deals
 with a core neutron object, maybe the best way to approach it is with a
 blueprint in Liberty rather than a bug...

 Thoughts?


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

2015-03-13 Thread Nikhil Komawar

Here's what it looks like so far:-


1400UTC: 3 votes (all core reviewers)

1500UTC: 5 votes (one core reviewer)

Both: 4 votes (all core reviewers)


Let's wait another couple days to see if more people respond.


I have a feeling that the weight is slightly tilted towards 1400UTC based on a 
few assumptions about the past activity of those participants, their cross 
project inputs, etc.


Thanks,
-Nikhil

From: Mikhail Fedosin mfedo...@mirantis.com
Sent: Friday, March 13, 2015 3:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

Both options are good, it's a little better at 1500 UTC.
+1 consistent time.

On Fri, Mar 13, 2015 at 9:23 PM, Steve Lewis 
steve.le...@rackspace.commailto:steve.le...@rackspace.com wrote:
+1 consistent time

+1 for 1500 UTC since that has come up.

On 09/03/15 09:07, Nikhil Komawar wrote:

So, the new proposal is:
Glance meetings [1] to be conducted
weekly on
Thursdays at 1400UTC [2] on
#openstack-meeting-4

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Sahara] Sahara plugin for Ambari

2015-03-13 Thread Craig Peters

All,

Several organizations have expressed interest in leveraging Saraha's
understanding of OpenStack Hadoop deployment, and Ambari's flexibility
about defining what Hadoop packages are deployed to the target cluster.
I've started an etherpad to capture everyone's thoughts on the subject.
https://etherpad.openstack.org/p/sahara-ambari-plugin

Best regards,
Craig

-- 
Craig Peters
Product Manager
www.mirantis.com
d: +1 650 490 4324
m: +1 925 639 0804
e: cpet...@mirantis.com
skype: craig.l.peters
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Mistral] Mistral sublime plugin available

2015-03-13 Thread Lingxian Kong

very cool!

2015-03-14 8:56 GMT+08:00 Dmitri Zimine dzim...@stackstorm.com:
 Mistral team got an exciting contribution:

 our good friend and industry veteran GP De Ciantis had built a sublime
 plugin for Mistral DSL - workbooks, workflows, etc.

 Check it out, and enjoy writing Mistral workflows!

 https://github.com/giampierod/mistral-sublime

 Thanks GP for an excellent contrib!

 Regards,
 DZ.

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Regards!
---
Lingxian Kong

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Lack of low-hanging-fruit Neutron bugs

2015-03-13 Thread Vikram Hosakote (vhosakot)

Dear Neutron developers,

I have been playing with OpenStack Neutron since Grizzly but never
committed a bug upstream. I want to fix a neutron bug and do not see
any unassigned low-hanging-fruit starter bug in
https://bugs.launchpad.net/neutron/+bugs?field.tag=low-hanging-fruit.
I was not able to get info about unassigned low-hanging-fruit bugs in
the Neutron meetings webpage
https://wiki.openstack.org/wiki/Network/Meetings either. Clearly, I do
not know where to look. Hence, sending this email :)

I do not know which bug to pick from
https://bugs.launchpad.net/neutron. I need help to pick one please.

I have experience with Neutron, namespaces, OVS bridge, agents (dhcp-
agent [dnsmasq], L3-agent, LBaaS), reading Neutron¹s Python code,
Linux, DevStack, git, gerrit, *.ini config files, REST, etc.

I prefer a Low/Medium importance bug. ŒLow¹ would be best as it will
be my first Neutron bug. I would like to fix a bug in neutron-server/
neutron-agents rather than a bug in Neutron clients (like Neutron CLI,
python-neutron-client).

Can anyone please give me a bug to fix :) I may ask help if needed
once I start fixing it.

Thanks a lot!

Regards,
Vikram Hosakote   |  vhosakot at cisco dot com
Cloud and Virtualization Group
Cisco Systems   |  Boxborough MA (snow is melting!)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] How to setup keystone using httpd and mod_wsgi?

2015-03-13 Thread Omkar Joshi

Hi,


Please let me know if there is any document for this? I am using openstack
icehouserdo.

-- 
Thanks,
Omkar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] The expected behavior of os-tenant-network API

2015-03-13 Thread Alex Xu

Hi, All,

When review the policy patches. I found there is a little strange behavior
in os-tenant-network API. And just file a bug for them:

1. non-admin can't create network by os-tenant-network API
https://bugs.launchpad.net/nova/+bug/1432101

2. non-admin can delete a network without any associate
https://bugs.launchpad.net/nova/+bug/1432100


For index method in os-tenant-network, look like there are different
behavior between FlatManager and VlanManager. FlatManager can saw networks
without any associate, but VlanManager is not. But this sounds make sense.

just want to ensure is there anyone have full view of our expected behavior
on os-tenant-network and os-network API to avoid the API behavior broken by
me.

Thanks
Alex
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How to setup keystone using httpd and mod_wsgi?

2015-03-13 Thread Dolph Mathews

Here's a minimal example I wrote (based on master)

  https://github.com/dolph/keystone-deploy/tree/master/playbooks/roles/http

And one intended for production:


https://github.com/stackforge/os-ansible-deployment/tree/master/playbooks/roles/os_keystone/tasks#

You can also checkout DevStack.

On Friday, March 13, 2015, Omkar Joshi o...@hedviginc.com wrote:

 Hi,


 Please let me know if there is any document for this? I am using openstack
 icehouserdo.

 --
 Thanks,
 Omkar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Group-Based-Policy] How to deal with improvements

2015-03-13 Thread Sumit Naiksatam

Hi Ivar, My personal preference is to see information related to a
particular feature in one place. So in cases like the ones you
describe, I would propose that we update the existing spec. Of course,
there is the problem of updating the same spec across different
releases (since we create a new directory for every release). Perhaps,
even in such cases we can start by copying over the original spec as
the first patch set, and then amend the specs to add the new changes
(thus making it clear as to what the delta is).

Definitely would like to hear what others think about this.

Thanks,
~Sumit.

On Wed, Mar 11, 2015 at 5:51 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote:
Hello Folks,

As a follow up of [0] I was working on a proposal for adding the same
sharing capabilities to servicechain constructs. While thinking about the
use cases for doing this, a question came to my mind: How should I deal with
this improvement from a process perspective?

I'm not sure adding sharing capabilities to 2 more objects is exactly a new
feature... It is more of a follow up of an existing one! What is the
expected process in this case? Should I create a new spec? Modify the
existing one? Create a detailed launchpad blueprint without a spec?

Please provide guidance, thanks,

Ivar.

[0]
https://github.com/stackforge/group-based-policy-specs/blob/master/specs/juno/introduce-shared-attribute.rst

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] looking for feedback on object versioning


Hi,

I've recently submitted some code for review at 
https://review.openstack.org/163060;.


The change involves adding a new reported_at field to the Service object 
class, and I'd like some feedback on the object-versioning aspects of that:


1) Do I need to do anything special in obj_make_compatible()?

2) Is what I've done in _from_db_object() correct?  If I don't do it like this, 
how is the reported_at field handled when a node sends a v1.11 version of the 
object (or the corresponding dict) to another node that wants a v1.12 version 
object?


3) Is it okay to lazy-load a None value in obj_load_attr()?  The nice thing 
about doing it this way is that a large number of unit/functional tests can stay 
as-is.


Thanks,
Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Mistral] Mistral sublime plugin available

2015-03-13 Thread Dmitri Zimine

Mistral team got an exciting contribution: 

our good friend and industry veteran GP De Ciantis had built a sublime plugin 
for Mistral DSL - workbooks, workflows, etc. 

Check it out, and enjoy writing Mistral workflows! 

https://github.com/giampierod/mistral-sublime

Thanks GP for an excellent contrib! 

Regards, 
DZ.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Group-based-policy][GBP] PTL Candidacy

2015-03-13 Thread Bhandaru, Malini K

Sumit's candidacy for GBP PTL is confirmed!

Regards
Malini

-Original Message-
From: Sumit Naiksatam [mailto:sumitnaiksa...@gmail.com] 
Sent: Thursday, March 12, 2015 12:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Bhandaru, Malini K
Subject: [Group-based-policy][GBP] PTL Candidacy

Hi All,

I would like to announce my candidacy for the Group Based Policy (GBP) [1] 
project’s PTL position [2].

I have been involved with GBP for more than a year now. I was responsible for 
setting it up as a StackForge project across multiple repositories, and have 
been serving as the de facto lead. I have made contributions to the project in 
terms of design, implementation, and reviews [3].

My focus during the Kilo cycle has, and, will be to improve the quality of our 
code (reduce bug count, identify and remove obvious performance issues, clear 
technical debt), and most of all to gather feedback from users on the GBP Juno 
release. Based on this feedback, I would like to steer the project in the 
Liberty release towards better integration with other OpenStack components, and 
advanced features that will allow to comprehensively manage and automate policy 
enforcement across those components.

I have enjoyed working with each and every one of the GBP team members, and 
look forward to working with them in the formal capacity of a PTL. I am proud 
of what the team has achieved, and hope to facilitate its growth even further.

To summarize, I am very excited about this opportunity in playing a part in 
GBP’s mission to fully realize the intent-based policy-driven abstractions' 
model.

Best,
Sumit Naiksatam.
(IRC: SumitNaiksatam)

[1] https://wiki.openstack.org/wiki/GroupBasedPolicy
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-March/058783.html
[3] http://stackalytics.com/report/contribution/group-based-policy-group/150
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] is it possible to microversion a static class method?


On 03/12/2015 12:13 PM, Sean Dague wrote:

On 03/12/2015 02:03 PM, Chris Friesen wrote:

Hi,

I'm having an issue with microversions.

The api_version() code has a comment saying This decorator MUST appear
first (the outermost decorator) on an API method for it to work correctly

I tried making a microversioned static class method like this:

 @wsgi.Controller.api_version(2.4)  # noqa
 @staticmethod
 def _my_func(req, foo):

and pycharm highlighted the api_version decorator and complained that
This decorator will not receive a callable it may expect; the built-in
decorator returns a special object.

Is this a spurious warning from pycharm?  The pep8 checks don't complain.

If I don't make it static, then pycharm suggests that the method could
be static.


*API method*

This is not intended for use by methods below the top controller level.
If you want conditionals lower down in your call stack pull the request
version out yourself and use that.


Both the original spec and doc/source/devref/api_microversions.rst contain text 
talking about decorating a private method.  The latter gives this example:


@api_version(2.1, 2.4)
def _version_specific_func(self, req, arg1):
pass

@api_version(min_version=2.5) #noqa
def _version_specific_func(self, req, arg1):
pass

def show(self, req, id):
 common stuff 
self._version_specific_func(req, foo)
 common stuff 

It's entirely possible that such a private method might not need to reference 
self, and could therefore be static, so I think it's a valid question.


Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] if by archived you mean, wipes out your tables completely, then sure, it works fine


On 03/12/2015 05:29 PM, Mike Bayer wrote:

snip


If we assume that all of our tables are filled up with zeroes for those
deleted columns, because that’s the default, this **wipes the whole table
clean**.

How do the tests pass? Well the tests are in test_db_api-ArchiveTestCase,
and actually, they don’t. But they don’t fail every time, because the test
suite here runs with a database that is almost completely empty anyway, so
the broken archival routine doesn’t find too many rows to blow away except
for the rows in “instance_types”, which it only finds sometimes because the
tests are only running it with a small number of things to delete and the
order of the tables is non-deterministic.

I’ve posted the bug report at https://bugs.launchpad.net/nova/+bug/1431571
where I started out not knowing much about how this worked except that my
tests were failing, and slowly stumbled my way to come to this conclusion. A
patch is at https://review.openstack.org/#/c/164009/, where we look at the
actual Python-side default. However I’d recommend that we just hardcode the
zero here, since that’s how our soft-delete columns work.


Nice detective work.  I imagine there was some hair pulling on that one...

Chris


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] is it possible to microversion a static class method?

2015-03-13 Thread Chen CH Ji

I posted same question below yesterday, not sure why it's not posted in the
list ...


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Chris Friesen chris.frie...@windriver.com
To: openstack-dev@lists.openstack.org
Date:   03/13/2015 07:57 AM
Subject:Re: [openstack-dev] [nova] is it possible to microversion a
static class method?



On 03/12/2015 12:13 PM, Sean Dague wrote:
 On 03/12/2015 02:03 PM, Chris Friesen wrote:
 Hi,

 I'm having an issue with microversions.

 The api_version() code has a comment saying This decorator MUST appear
 first (the outermost decorator) on an API method for it to work
correctly

 I tried making a microversioned static class method like this:

  @wsgi.Controller.api_version(2.4)  # noqa
  @staticmethod
  def _my_func(req, foo):

 and pycharm highlighted the api_version decorator and complained that
 This decorator will not receive a callable it may expect; the built-in
 decorator returns a special object.

 Is this a spurious warning from pycharm?  The pep8 checks don't
complain.

 If I don't make it static, then pycharm suggests that the method could
 be static.

 *API method*

 This is not intended for use by methods below the top controller level.
 If you want conditionals lower down in your call stack pull the request
 version out yourself and use that.

Both the original spec and doc/source/devref/api_microversions.rst contain
text
talking about decorating a private method.  The latter gives this example:

 @api_version(2.1, 2.4)
 def _version_specific_func(self, req, arg1):
 pass

 @api_version(min_version=2.5) #noqa
 def _version_specific_func(self, req, arg1):
 pass

 def show(self, req, id):
  common stuff 
 self._version_specific_func(req, foo)
  common stuff 

It's entirely possible that such a private method might not need to
reference
self, and could therefore be static, so I think it's a valid question.

Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] VXLAN with single-NIC compute nodes: Avoiding the MTU pitfalls

2015-03-13 Thread Ian Wells

On 12 March 2015 at 05:33, Fredy Neeser fredy.nee...@solnet.ch wrote:

2. I'm using policy routing on my hosts to steer VXLAN traffic (UDP
dest. port 4789) to interface br-ex.12 -- all other traffic from
192.168.1.14 is source routed from br-ex.1, presumably because br-ex.1 is a
lower-numbered interface than br-ex.12 (?) -- interesting question whether
I'm relying here on the order in which I created these two interfaces.

OK, I have to admit I've never used policy routing in anger so I can't
speak with much confidence here. I wonder if anything (link down, for
instance) might cause Linux to change its preference behaviour, though, and
your to-the-world packets haven't got a policy from what you say so a
preference change would be a disaster.

3. It's not clear to me how to setup multiple nodes with packstack if a
node's tunnel IP does not equal its admin IP (or the OpenStack API IP in
case of a controller node). With packstack, I can only specify the compute
node IPs through CONFIG_COMPUTE_HOSTS. Presumably, these IPs are used for
both packstack deployment (admin IP) and for configuring the VXLAN tunnel
IPs (local_ip and remote_ip parameters). How would I specify different IPs
for these purposes? (Recall that my hosts have a single NIC).

I don't think the single NIC is an issue, particularly, and even less so if
you have multiple interfaces, even VLAN interfaces, with different
addresses. At that point you should be able to use
CONFIG_NEUTRON_OVS_TUNNEL_IF=eth1.12 , which would need to be created and
addressed by the point you run packstack, as it expects it to be there at
this point. In fact the closed bug
https://bugs.launchpad.net/packstack/+bug/1279517 suggests that you're not
the first to try this and it does work (though since the change it refers
to isn't merged you might need to say ...=eth1_12 to keep packstack happy).

You may find that configuring a VLAN interface for eth1.12 (not in a
bridge, with a local address suitable for communication with compute nodes,
for VXLAN traffic) and eth1.1 (in br-ex, for external traffic to use) does
better for you.

Hmm, I only have one NIC (eth0).

Apparently I can't read - where I'm putting eth1 I mean eth0 in your setup,
I must have misread it early on. I'll try and make the switch.

eth0.1 is shorthand notation for eth0 VLAN 1, and there are a bunch of
interface management commands to create interfaces of this type. It appears
to be possible to configure this in the network setup scripts -
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Configure_802_1Q_VLAN_Tagging_Using_the_Command_Line.html
describes the Redhat way, though I've only done this on Ubuntu and Debian
myself.

In order to attach eth0 to br-ex, I had to configure it as an OVSPort.
Maybe I misunderstand your alternative, but are you suggesting to
configure eth0.1 as an OVSPort (connected to br-ex), and eth0.12 as a
standalone interface? (Not sure a physical interface can be brain split
in such a way.)

eth0.1 is a full on network interface and should work as an OVS port. You
would configure the external network in Openstack as flat, rather than
containing VLAN segments, because the tagging is done outside of Openstack
with this approach (otherwise you'd end up with double tagged packets).

And yes, eth0.12 would be a standalone interface.

Note that my physical switch uses a native VLAN of 1 and is configured
with Untag all ports for VLAN 1. Moreover, OVSPort eth0 (attached to
br-ex) is configured for VLAN trunking with a native VLAN of 1 (vlan_mode:
native-untagged, trunks: [1,12], tag: 1), so within bridge br-ex, native
packets are tagged 1.

Yes, as I say, if you moved over to the eth0.1 mechanism above you'd want
the packets to be untagged at the eth0.1 OVS port, because receiving them
via eth0.1 would untag them (and sending them would tag them) and OVS
doesn't need to help you out on the VLAN front any more.

I'm still not a fan of your setup but I don't know if it's just because
it's not where my natural preference lies. You may be inches from making
it work perfectly, and I'm not sure I would be able to tell. That said,
policy routing seems like a workaround to a problem you're having with
packstack; I would definitely go with two addresses if there were any way
to make it configure properly. If I were doing this there would also be
quite a lot of experimentation to verify my guesswork, I have to admit, so
it's not an easy answer.
--
Ian.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Nitpicking in code reviews

2015-03-13 Thread Gorka Eguileor

On Thu, Mar 12, 2015 at 10:58:37AM -0700, Jim Rollenhagen wrote:
 On Thu, Mar 12, 2015 at 09:07:30AM -0500, Flavio Percoco wrote:
  On 11/03/15 15:06 -1000, John Bresnahan wrote:
  FWIW I agree with #3 and #4 but not #1 and #2.  Spelling is an easy enough
  thing to get right and speaks to the quality standard to which the product
  is held even in commit messages and comments (consider the 'broken window
  theory').  Of course everyone makes mistakes (I am a terrible speller) but
  correcting a spelling error should be a trivial matter.  If a reviewer
  notices a spelling error I would expect them to point it.
  
  I'd agree depending on the status of the patch. If the patch has
  already 2 +2s and someone blocks it because of a spelling error, then
  the cost of fixing it, running the CI jobs and getting the reviews
  again is higher than living with a simple typo.
  
  Process and rules are good but we must evaluate them in a case by case
  basis to make sure we're not blocking important work on things that
  are not that relevant after all.
  
 
 In Ironic, we've set up rough guidelines for situations like these.
 
 1) Reviewers should not -1 a patch solely for spelling/grammar errors.
 2) If a reviewer finds one of these errors and feels strongly that it
should be corrected, they should do one of the following:
2a) If it won't slow down the patch (i.e. no +2's on it), fix it
themselves and submit a new patchset. This is even easier for
commit messages; they can be edited directly in Gerrit.
2b) Make a note on the review and push a follow-up patch to fix it.
2c) Ask the submitter for a follow-up patch that fixes it.
 
 This has dramatically reduced our nitpicking on patches and has even
 seemed to improve our general velocity.
 
 // jim
 
  

I like Jim's idea of having some rough guidelines as this will make it
easier for newcomers, like myself, get an idea of how we should vote.
Otherwise we infer them, maybe even incorrectly, from other reviews and
end up -1 patches just for grammar errors in comments, something we
wouldn't have usually done.

I'm glad to know that all things mentioned by Erno are not really worth
a -1. :)

Gorka.

  On 3/11/15 2:22 PM, Kuvaja, Erno wrote:
  Hi all,
  
  Following the code reviews lately I’ve noticed that we (the fan club
  seems to be growing on weekly basis) have been growing culture of
  nitpicking [1] and bikeshedding [2][3] over almost every single change.
  
  Seriously my dear friends, following things are not worth of “-1” vote
  if even a comment:
  
  1)Minor spelling errors on commit messages (as long as the message comes
  through and flags are not misspelled).
  
  2)Minor spelling errors on comments (docstrings and documentation is
  there and there, but comments, come-on).
  
  3)Used syntax that is functional, readable and does not break
  consistency but does not please your poem bowel.
  
  4)Other things you “just did not realize to check if they were there”.
  After you have gone through the whole change go and look your comments
  again and think twice if your concern/question/whatsoever was addressed
  somewhere else than where your first intuition would have dropped it.
  
  We have relatively high volume for glance at the moment and this
  nitpicking and bikeshedding does not help anyone. At best it just
  tightens nerves and breaks our group. Obviously if there is “you had ONE
  job” kind of situations or there is relatively high amount of errors
  combined with something serious it’s reasonable to ask fix the typos on
  the way as well. The reason being need to increase your statistics,
  personal perfectionist nature or actually I do not care what; just stop
  or go and do it somewhere else.
  
  
  Thanks for bringing all this up, Erno. I've been seeing the same
  pattern for all the points you've mentioned above. It's a good
  reminder for people to treat each patch individually so we avoid
  making our process and rules a pain for everyone.
  
  Flavio
  
  
  Love and pink ponies,
  
  -Erno
  
  [1] www.urbandictionary.com/define.php?term=nitpicking
  http://www.urbandictionary.com/define.php?term=nitpicking
  
  [2] http://bikeshed.com
  
  [3] http://en.wiktionary.org/wiki/bikeshedding
  
  
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  -- 
  @flaper87
  Flavio Percoco
 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] if by archived you mean, wipes out your tables completely, then sure, it works fine

2015-03-13 Thread Thomas Herve

[snip]
If we assume that all of our tables are filled up with zeroes for those
deleted columns, because that’s the default, this **wipes the whole table
clean**.

How do the tests pass? Well the tests are in test_db_api-ArchiveTestCase,
and actually, they don’t. But they don’t fail every time, because the test
suite here runs with a database that is almost completely empty anyway, so
the broken archival routine doesn’t find too many rows to blow away except
for the rows in “instance_types”, which it only finds sometimes because the
tests are only running it with a small number of things to delete and the
order of the tables is non-deterministic.

I’ve posted the bug report at https://bugs.launchpad.net/nova/+bug/1431571
where I started out not knowing much about how this worked except that my
tests were failing, and slowly stumbled my way to come to this conclusion. A
patch is at https://review.openstack.org/#/c/164009/, where we look at the
actual Python-side default. However I’d recommend that we just hardcode the
zero here, since that’s how our soft-delete columns work.

Hi Mike,

Thanks for the investigation. I was wondering when that behavior was introduced
and it seems that
http://git.openstack.org/cgit/openstack/nova/commit/?id=ecf74d4c0a5a8a4290ecac048fc437dafe3d40fc
is the likely culprit, which would mean that only Kilo is affected. Can you
confirm?

Thanks,

--
Thomas

Re: [openstack-dev] [all] Do we need release announcements for all the things?

2015-03-13 Thread Thierry Carrez

Clint Byrum wrote:
 I spend a not-insignificant amount of time deciding which threads to
 read and which to fully ignore each day, so extra threads mean extra
 work, even with a streamlined workflow of single-key-press-per-thread.
 
 So I'm wondering what people are getting from these announcements being
 on the discussion list. I feel like they'd be better off in a weekly
 digest, on a web page somewhere, or perhaps with a tag that could be
 filtered out for those that don't benefit from them.

The first value of a release announcement is (obviously) to let people
know something was released. There is a bit of a paradox there with some
announcements being posted to openstack-announce (in theory low-traffic
and high-attention), and some announcements being posted to
openstack-dev (high-traffic and medium-attention). Where is the line drawn ?

The second value of a release announcement is the thread it creates in
case immediate issues are spotted. I kind of like that some
python-*client release announcements are followed-up by a this broke
the world thread, all in a single convenient package. Delaying
announcements defeats that purpose.

We need to adapt our current (restricted) usage of openstack-announce to
a big-tent less-hierarchical future anyway: if we continue to split
announcements, which projects are deemed important enough to be
granted openstack-announce access ?

Personally in the future I'm not opposed to allowing any openstack
project (big-tent definition) to post to openstack-announce (ideally in
a standard / autogenerated format) with reply-to set to openstack-dev.
We could use a separate list, but then release and OSSA announcements
are the only thing we use -announce for currently, so I'm not sure it's
worth it.

So I'm +1 on using a specific list (and setting reply-to to -dev), and
I'm suggesting openstack-announce should be reused to avoid creating two
classes of deliverables (-announce worthy and not).

Posting on -dev with a subject prefix would only marginally improve the
situation (release announcements are already pretty easy to spot and
manually filter out), so I'm +0 on that.

Weekly posts or ratelimiting would imho remove 99% of the interest of
release announcements, so I'm -1 on that solution.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Deprecation warnings considered harmful?

2015-03-13 Thread Duncan Thomas

On 13 March 2015 at 02:37, Nikhil Manchanda nik...@manchanda.me wrote:

 - We wanted to ensure that we had a corresponding hacking rule in
 place to prevent future patch-sets from using the deprecated module
 names.



There's one in cinder that Jay wrote, please do feel free to copy (and
point out any flaws with it; I'm not aware of any)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB

2015-03-13 Thread Rossella Sblendido

 On 03/07/2015 01:10 PM, Leo Y wrote:
 What happens when neutron DB is updated to change network settings (e.g.
 via Dashboard or manually) when there are communication sessions opened
 in compute nodes. Does it influence those sessions? When the update is
 propagated to compute nodes?

Hi Leo,

when you say change network settings I think you mean a change in the
security group, is my assumption correct? In that case the Neutron
server will notify all the L2 agent (they reside on each compute node)
about the change. There are different kind of messages that the Neutron
server sends depending on the type of the update,
security_groups_rule_updated, security_groups_member_updated,
security_groups_provider_updated. Each L2 agent will process the message
and apply the required modification on the host. In the default
implementation we use iptables to implement security group, so the
update consists in some modifications of the iptables rules. Regarding
the existing connections in the compute nodes they might not be affected
by the change, which is a problem already discussed in this mail thread
[1] and there's a patch in review to fix that [2].
Hope that answers your question.

cheers,

Rossella

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-October/049055.html
[2] https://review.openstack.org/#/c/147713/

On 03/13/2015 04:10 AM, Kevin Benton wrote:
 Yeah, I was making a bad assumption for the l2 and l3. Sorry about that.
 It sounds like we don't have any protection against servers failing to
 send notifications.
 
 On Mar 12, 2015 7:41 PM, Assaf Muller amul...@redhat.com
 mailto:amul...@redhat.com wrote:
 
 
 
 - Original Message -
   However, I briefly looked through the L2 agent code and didn't see a
   periodic task to resync the port information to protect from a
 neutron
   server that failed to send a notification because it crashed or
 lost its
   amqp connection. The L3 agent has a period sync routers task
 that helps in
   this regard.
 
 The L3 agent periodic sync is only if the full_sync flag was turned
 on, which
 is a result of an error.
 
   Maybe another neutron developer more familiar with the L2
   agent can chime in here if I'm missing anything.
 
  i don't think you are missing anything.
  periodic sync would be a good improvement.
 
  YAMAMAOTO Takashi
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Murano] PTL Candidacy

2015-03-13 Thread Sergey Lukjanov

Ack -
https://wiki.openstack.org/wiki/Murano/PTL_Elections_Kilo_Liberty#Candidates

On Wed, Mar 11, 2015 at 1:01 PM, Serg Melikyan smelik...@mirantis.com
wrote:

 Hi folks,

 I'd like to announce my candidacy as PTL for Murano [1].

 I was handling PTL responsibilities in this release cycle so far,
 after Ruslan Kamaldinov (who was handling them in Juno cycle) hand
 over them to me on OpenStack Summit in Paris. I am working on Murano
 since it's kick-off two years ago [2][3].

 As a PTL of Murano I'll continue my work on making Murano better with
 each day and become project of choice for building own Application
 Catalogs  Marketplaces for private  public clouds on OpenStack. I
 will focus on building great environment for contributors and work on
 relationships built around the project itself not only around the
 features needed by contributors.

 [1] http://wiki.openstack.org/wiki/Murano
 [2] http://stackalytics.com/report/contribution/murano/90
 [3] http://stackalytics.com/?
 release=kilometric=commitsproject_type=stackforgemodule=murano-group

 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] if by archived you mean, wipes out your tables completely, then sure, it works fine

2015-03-13 Thread Attila Fazekas

The archiving has issues since very long time [1],
something like this [2] is expected to replace it.

The archiving just move trash to the other side of the desk,
usually just permanently deleting everything what is deleted
for more than 7 day is better for everyone.

For now, maybe just wiping out the shadow tables and the existing nova-mange 
functionality is better choice. [3]

[1] https://bugs.launchpad.net/nova/+bug/1305892
[2] https://blueprints.launchpad.net/nova/+spec/db-purge-engine
[3] https://bugs.launchpad.net/nova/+bug/1426873

- Original Message -
 From: Mike Bayer mba...@redhat.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Friday, March 13, 2015 12:29:55 AM
 Subject: [openstack-dev] [nova] if by archived you mean,wipes out your 
 tables completely, then sure, it works
 fine
 
 Hello Nova -
 
 Not sure if I’m just staring at this for too long, or if
 archive_deleted_rows_for_table() is just not something we ever use.
 Because it looks like it’s really, really broken very disastrously, and I’m
 wondering if I’m just missing something in front of me.
 
 Let’s look at what it does!
 
 First, archive_deleted_rows() calls it with a table name. These names are
 taken by collecting every single table name from nova.db.sqlalchemy.models.
 
 Then, the function uses table reflection (that is, doesn’t look in the model
 at all, just goes right to the database) to load the table definitions:
 
 table = Table(tablename, metadata, autoload=True)
 shadow_tablename = _SHADOW_TABLE_PREFIX + tablename
 rows_archived = 0
 try:
 shadow_table = Table(shadow_tablename, metadata, autoload=True)
 except NoSuchTableError:
 # No corresponding shadow table; skip it.
 return rows_archived
 
 this is pretty heavy handed and wasteful from an efficiency point of view,
 and I’d like to fix this too, but let’s go with it. Now we have the two
 tables.
 
 Then we do this:
 
 deleted_column = table.c.deleted
 query_insert = sql.select([table],
   deleted_column != deleted_column.default).\
   order_by(column).limit(max_rows)
 query_delete = sql.select([column],
   deleted_column != deleted_column.default).\
   order_by(column).limit(max_rows)
 
 We make some SELECT statements that we’re going to use to find “soft
 deleted” rows, and these will be embedded into an INSERT
 and a DELETE. It is trying to make a statement like “SELECT .. FROM
 table WHERE deleted != deleted_default”, so that it finds rows where
 “deleted” has been changed to something, e.g. the row was
 soft deleted.
 
 But what’s the value of “deleted_default” ?   Remember, all this
 table knows is what the database just told us about it, because it only
 uses reflection.  Let’s see what the “deleted” column in a table like
 instance_types looks like:
 
 MariaDB [nova] show create table instance_types;
 | instance_types | CREATE TABLE `instance_types` (
   `created_at` datetime DEFAULT NULL,
 
   …  [omitted] ...
 
   `deleted` int(11) DEFAULT NULL,
 )
 
 The default that we get for this column is NULL. That is very interesting!
 Because, if we look at the *Python-side value of deleted*, we see something
 that is quite the opposite of NULL, e.g. a thing that is most certainly not
 null:
 
 class SoftDeleteMixin(object):
 deleted_at = Column(DateTime)
 deleted = Column(Integer, default=0)
 
 See that zero there? That’s a ***Python-side default***. It is **not the
 server default**!! You will **not** get it from reflection, the database has
 no clue about it (oddly enough, this entire subject matter is fully
 documented in SQLAlchemy’s documentation, and guess what, the docs are free!
 Read them all you like, I won’t ask for a dime, no questions asked!).
 
 So, all of our INSERTS **will** put a zero, not NULL, into that column.
 Let’s look in instance_types and see:
 
 MariaDB [nova] select id, name, deleted from instance_types;
 ++---+-+
 | id | name  | deleted |
 ++---+-+
 |  3 | m1.large  |   0 |
 |  1 | m1.medium |   0 |
 |  7 | m1.micro  |   0 |
 |  6 | m1.nano   |   0 |
 |  5 | m1.small  |   0 |
 |  2 | m1.tiny   |   0 |
 |  4 | m1.xlarge |   0 |
 ++---+-+
 7 rows in set (0.00 sec)
 
 No NULLs.  The value of non-deleted rows is zero.
 
 What does this all mean?
 
 It means, when this archival routine runs, it runs queries like this:
 
 INSERT INTO shadow_quota_usages SELECT quota_usages.created_at,
 quota_usages.updated_at, quota_usages.deleted_at, quota_usages.id,
 quota_usages.project_id, quota_usages.resource, quota_usages.in_use,
 quota_usages.reserved, quota_usages.until_refresh, quota_usages.deleted,
 quota_usages.user_id
 FROM quota_usages
 WHERE quota_usages.deleted IS NOT NULL ORDER BY quota_usages.id
  LIMIT ? OFFSET ?

Re: [openstack-dev] [Ironic] proposing rameshg87 to ironic-core

2015-03-13 Thread Dmitry Tantsur


On 03/12/2015 05:05 PM, Devananda van der Veen wrote:

Without further ado, and since everyone (even though some haven't
replied here) has +1'd this, and since we could really use ramesh's +2's
in the run up to Kilo-3 and feature freeze, even without the customary
waiting/voting period being completely satisfied (after all, when we all
agree, why wait a week?), I'd like to officially welcome him to the core
team.


Sorry for being late to the party with my +1 - I'm still on PTO, but 
lemme congratulate Ramakrishnan with becoming a core. Your reviews have 
extremely helpful!




-Devananda

On Tue, Mar 10, 2015 at 10:03 AM David Shrewsbury
shrewsbury.d...@gmail.com mailto:shrewsbury.d...@gmail.com wrote:

+1


On Mar 9, 2015, at 6:03 PM, Devananda van der Veen
devananda@gmail.com mailto:devananda@gmail.com wrote:

Hi all,

I'd like to propose adding Ramakrishnan (rameshg87) to ironic-core.

He's been consistently providing good code reviews, and been in
the top five active reviewers for the last 90 days and top 10 for
the last 180 days. Two cores have recently approached me to let me
know that they, too, find his reviews valuable.

Furthermore, Ramakrishnan has made significant code contributions
to Ironic over the last year. While working primarily on the iLO
driver, he has also done a lot of refactoring of the core code,
touched on several other drivers, and maintains the proliantutils
library on stackforge. All in all, I feel this demonstrates a good
and growing knowledge of the codebase and architecture of our
project, and feel he'd be a valuable member of the core team.

Stats, for those that want them, are below the break.

Best Regards,
Devananda



http://stackalytics.com/?release=allmodule=ironic-groupuser_id=rameshg87

http://russellbryant.net/openstack-stats/ironic-reviewers-90.txt
http://russellbryant.net/openstack-stats/ironic-reviewers-180.txt
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.__openstack.org?subject:__unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] A question about libvirt cpu mode=none configuration

2015-03-13 Thread park


hello Nova

By default, nova libvirt driver configuration for guest cpu as cpu_mode 
= none,
you could add cpu features by changing flavor section as below, there 
will NOT

be any issues for this cmd.

$nova flavor-key m1.small set capabilities:cpu_info:features=in ***
but, nova will ignore the cpu features after the guest boot up 
successfully, which
means the feature does NOT take effect(not be written into the xml for 
the guest).


And there is no message telling the users that the features does NOT 
take effect...

this may make the users confused...



if we add the feature into the xml file for the guest, this will trigger 
internal error
libvirtError: XML error: Non-empty feature list specified without CPU 
model



so what should we do? Leave it as itself(ignore the users input, and 
boot the guest

successfully), or prompt the users with the errors?

Thanks
Park

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][Tuskar] Common library for shared code

2015-03-13 Thread Jan Provaznik


On 03/10/2015 05:53 PM, James Slagle wrote:

On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník jprov...@redhat.com wrote:

Hi,
it would make sense to have a library for the code shared by Tuskar UI and
CLI (I mean TripleO CLI - whatever it will be, not tuskarclient which is
just a thing wrapper for Tuskar API). There are various actions which
consist from more that a single API call to an openstack service, to give
some examples:

- nodes registration - for loading a list of nodes from a user defined file,
this means parsing a CSV file and then feeding Ironic with this data
- decommission a resource node - this might consist of disabling
monitoring/health checks on this node, then gracefully shut down the node
- stack breakpoints - setting breakpoints will allow manual
inspection/validation of changes during stack-update, user can then update
nodes one-by-one and trigger rollback if needed


I agree something is needed. In addition to the items above, it's much
of the post deployment steps from devtest_overcloud.sh. I'd like to see that be
consumable from the UI and CLI.

I think we should be aware though that where it makes sense to add things
to os-cloud-config directly, we should just do that.



Yes, actually I think most of the devtest_overcloud content fits 
os-cloud-config (and IIRC for this purpose os-cloud-config was created).




It would be nice to have a place (library) where the code could live and
where it could be shared both by web UI and CLI. We already have
os-cloud-config [1] library which focuses on configuring OS cloud after
first installation only (setting endpoints, certificates, flavors...) so not
all shared code fits here. It would make sense to create a new library where
this code could live. This lib could be placed on Stackforge for now and it
might have very similar structure as os-cloud-config.

And most important... what is the best name? Some of ideas were:
- tuskar-common


I agree with Dougal here, -1 on this.


- tripleo-common
- os-cloud-management - I like this one, it's consistent with the
os-cloud-config naming


I'm more or less happy with any of those.

However, If we wanted something to match the os-*-config pattern we might
could go with:
- os-management-config
- os-deployment-config



Well, the scope of this lib will be beyond configuration of a cloud so 
having -config in the name is not ideal. Based on feedback in this 
thread I tend to go ahead with os-cloud-management and unless someone 
rises an objection here now, I'll ask infra team what is the process of 
adding the lib to stackforge.


Jan



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Deprecation warnings considered harmful?

2015-03-13 Thread Duncan Thomas

On 12 March 2015 at 18:48, Doug Hellmann d...@doughellmann.com wrote:

 On Thu, Mar 12, 2015, at 05:24 AM, Duncan Thomas wrote:



 Yay, the system is working as designed!


Good to hear

 

  What are normal, none developer users supposed to do with such warnings,
  other than:
  a) panic or b) Assume openstack is beta quality and then panic

 Next time, please try to be less snide. It makes it difficult to take
 you seriously.


Fair point, I apologise, it was the end of a long day. I was aiming for
humorous rather than snide, and clearly missed by a significant amount.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Deprecation warnings considered harmful?

2015-03-13 Thread Thierry Carrez

Doug Hellmann wrote:
 Yay, the system is working as designed!
 
 Oslo froze early to prepare releases to integrate with the downstream
 projects. You found an issue and reported it. Dims and others worked on
 patches, and we're releasing new versions. All before your feature
 freeze, so you can adopt them.

Also that would likely be considered a bug fix, so I'd say this could
also be fixed after Feature Freeze (before RC1).

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] if by archived you mean, wipes out your tables completely, then sure, it works fine

On 03/13/2015 07:07 AM, Sean Dague wrote:
On 03/13/2015 05:54 AM, Thomas Herve wrote:

[snip]
If we assume that all of our tables are filled up with zeroes for those
deleted columns, because that’s the default, this **wipes the whole table
clean**.

Hi Mike,

Thanks for the investigation. I was wondering when that behavior was
introduced and it seems that
http://git.openstack.org/cgit/openstack/nova/commit/?id=ecf74d4c0a5a8a4290ecac048fc437dafe3d40fc
is the likely culprit, which would mean that only Kilo is affected. Can you
confirm?

Thanks,

Yes, that looks like the problematic patch. I'd rather actually revert
that patch instead.

Also, real tests would be nice to actually prevent future regression.

-Sean

Ok, we've done a straight revert here -
https://review.openstack.org/#/c/164140/

I'm also working on a test enhancement that ensures that all the shadow
tables except the one we believe should contain entries are empty. That
seems to specifically expose and nail this bug. Needs some cleanup, but
should be posted by midday.

-Sean

--
Sean Dague
http://dague.net

Re: [openstack-dev] [neutron] high dhcp lease times in neutron deployments considered harmful (or not???)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

(Sorry for reviving an old thread.)

On 01/28/2015 02:55 PM, Ihar Hrachyshka wrote:
 On 01/28/2015 09:50 AM, Kevin Benton wrote:
 Hi,
 
 Approximately a year and a half ago, the default DHCP lease time
 in Neutron was increased from 120 seconds to 86400 seconds.[1]
 This was done with the goal of reducing DHCP traffic with very
 little discussion (based on what I can see in the review and bug
 report). While it it does indeed reduce DHCP traffic, I don't
 think any bug reports were filed showing that a 120 second lease
 time resulted in too much traffic or that a jump all of the way
 to 86400 seconds was required instead of a value in the same
 order of magnitude.
 
 I guess that would be a good case for FORCERENEW DHCP extension
 [1] though after digging thru dnsmasq code a bit, I doubt it
 supports the extension (though e.g. systemd dhcp client/server from
 networkd module do). Le sigh.
 
 [1]: https://tools.ietf.org/html/rfc3203
 

Note that DHCPv6 has Reconfigure message type exactly for the case of
pushing new configuration to clients that still possess valid IA_ID
configuration. It's defined in RFC3315, section 19 [1].

The only problem with the message type is that DHCP authentication is
mandatory for this type of messages, to avoid potential DoS attacks
(concern that is probably not relevant in our isolated setup).

I haven't had any experience with authN for DHCP before, but afaik it
does not involve any prior data injection into clients. Correct me if
I am wrong.

[1]: http://tools.ietf.org/html/rfc3315#section-19

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVAsRvAAoJEC5aWaUY1u57WDMH/jMthBci6cB1FdLVv92zTXNQ
xl6iQziR8UAUmWrk90jdt9d9QsAJR9Z6zyPb3UuQTsw+NeCUEsTeDyqt6k4LR9nx
kn1a5pNJ+C3EMtNkDv2WP4kPFg/dTfp05dvrxaqJMpSZZAnpfD4v5uraqy5S3S39
uRZy166LeaJ2Nd1yfH9agQfJd347nTXKxpvwZxQPjbw3qOBfkN3W0UNlwYQWbIHr
6wpCVeB7wRsc5isQ2DneGkPERa3ooFMgjLqUMj7hxgvykVikJK1EVY2DxcFRoWPR
mimPhJ4kuCnpmPszJ4BCfTXYuTaggia1XrnDQSRfKlWhgRQPnuk+fxEZFlNAGTk=
=hFap
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Nitpicking in code reviews

2015-03-13 Thread Flavio Percoco


On 13/03/15 10:36 +0100, Gorka Eguileor wrote:

On Thu, Mar 12, 2015 at 10:58:37AM -0700, Jim Rollenhagen wrote:

On Thu, Mar 12, 2015 at 09:07:30AM -0500, Flavio Percoco wrote:
 On 11/03/15 15:06 -1000, John Bresnahan wrote:
 FWIW I agree with #3 and #4 but not #1 and #2.  Spelling is an easy enough
 thing to get right and speaks to the quality standard to which the product
 is held even in commit messages and comments (consider the 'broken window
 theory').  Of course everyone makes mistakes (I am a terrible speller) but
 correcting a spelling error should be a trivial matter.  If a reviewer
 notices a spelling error I would expect them to point it.

 I'd agree depending on the status of the patch. If the patch has
 already 2 +2s and someone blocks it because of a spelling error, then
 the cost of fixing it, running the CI jobs and getting the reviews
 again is higher than living with a simple typo.

 Process and rules are good but we must evaluate them in a case by case
 basis to make sure we're not blocking important work on things that
 are not that relevant after all.


In Ironic, we've set up rough guidelines for situations like these.

1) Reviewers should not -1 a patch solely for spelling/grammar errors.
2) If a reviewer finds one of these errors and feels strongly that it
   should be corrected, they should do one of the following:
   2a) If it won't slow down the patch (i.e. no +2's on it), fix it
   themselves and submit a new patchset. This is even easier for
   commit messages; they can be edited directly in Gerrit.
   2b) Make a note on the review and push a follow-up patch to fix it.
   2c) Ask the submitter for a follow-up patch that fixes it.

This has dramatically reduced our nitpicking on patches and has even
seemed to improve our general velocity.

// jim

 


I like Jim's idea of having some rough guidelines as this will make it
easier for newcomers, like myself, get an idea of how we should vote.
Otherwise we infer them, maybe even incorrectly, from other reviews and
end up -1 patches just for grammar errors in comments, something we
wouldn't have usually done.

I'm glad to know that all things mentioned by Erno are not really worth
a -1. :)


For the sake of nitpicking, more than a policy, this should be a guide
to reviewing and shouldn't be just for Glance. This knowledge is
something the community has been working on over the years and I
believe it's useful for everyone.

As you mentioned, it'd helps newcomers to understand the reviewing
process and it'll help us to educate not just newcomers but old
members too ;)

Cheers,
Fla



Gorka.


 On 3/11/15 2:22 PM, Kuvaja, Erno wrote:
 Hi all,
 
 Following the code reviews lately I’ve noticed that we (the fan club
 seems to be growing on weekly basis) have been growing culture of
 nitpicking [1] and bikeshedding [2][3] over almost every single change.
 
 Seriously my dear friends, following things are not worth of “-1” vote
 if even a comment:
 
 1)Minor spelling errors on commit messages (as long as the message comes
 through and flags are not misspelled).
 
 2)Minor spelling errors on comments (docstrings and documentation is
 there and there, but comments, come-on).
 
 3)Used syntax that is functional, readable and does not break
 consistency but does not please your poem bowel.
 
 4)Other things you “just did not realize to check if they were there”.
 After you have gone through the whole change go and look your comments
 again and think twice if your concern/question/whatsoever was addressed
 somewhere else than where your first intuition would have dropped it.
 
 We have relatively high volume for glance at the moment and this
 nitpicking and bikeshedding does not help anyone. At best it just
 tightens nerves and breaks our group. Obviously if there is “you had ONE
 job” kind of situations or there is relatively high amount of errors
 combined with something serious it’s reasonable to ask fix the typos on
 the way as well. The reason being need to increase your statistics,
 personal perfectionist nature or actually I do not care what; just stop
 or go and do it somewhere else.


 Thanks for bringing all this up, Erno. I've been seeing the same
 pattern for all the points you've mentioned above. It's a good
 reminder for people to treat each patch individually so we avoid
 making our process and rules a pain for everyone.

 Flavio

 
 Love and pink ponies,
 
 -Erno
 
 [1] www.urbandictionary.com/define.php?term=nitpicking
 http://www.urbandictionary.com/define.php?term=nitpicking
 
 [2] http://bikeshed.com
 
 [3] http://en.wiktionary.org/wiki/bikeshedding
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 --
 @flaper87
 Flavio Percoco

[openstack-dev] [Heat][Nova] volumes handling on AWS Instance suspend/resume/delete

2015-03-13 Thread Pavlo Shchelokovskyy

Hi all,

as I am removing scheduler tasks from server resources, I have the
following question:

in OS Server resource on suspend/resume/delete we do not care about
attached volumes. In fact Nova keeps them attached to the suspended
instance (volumes are in 'in-use' state) and after server resume they are
still attached to the server without any additional steps. On server delete
Nova again detaches all the volumes automatically.

On the other hand, in AWS Instance resource we manually detach volumes on
delete/suspend and reattach them on resume. What's the point of that? Is it
for some compatibility with instance+volumes behavior in real AWS or some
leftover from earlier Nova days?

An advice from anyone with AWS experience would be appreciated, as if it is
not for compatibility sake, I would gladly remove that seemingly
unnecessary logic.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo][stable] stable/kilo branches created for Oslo libraries

I have created stable/kilo branches for all of the Oslo libraries for which 
stable release support will be provided for the Kilo release. The base versions 
for those branches are:

cliff 1.10.0
debtcollector 0.3.0
oslo.concurrency 1.8.0
oslo.config 1.9.3
oslo.context 0.2.0
oslo.db 1.7.0
oslo.i18n 1.5.0
oslo.log 1.0.0
oslo.messaging 1.8.0
oslo.middleware 1.0.0
oslo.policy 0.3.1
oslo.rootwrap 1.6.0
oslo.serialization 1.4.0
oslo.utils 1.4.0
oslo.versionedobjects 0.1.1
oslo.vmware 0.11.1
oslosphinx 2.5.0
oslotest 1.5.1
stevedore 1.3.0
taskflow 0.7.1
tooz 0.13.1

I have a patch to update the global requirements list to require at least these 
versions ready for review in https://review.openstack.org/162656

Based on the process outlined in the library stable release procedure spec 
(https://review.openstack.org/155072) we should update all project to use the 
versions described in that g-r patch before creating their RC1.

Doug


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] dependency on non-standardized, private APIs

2015-03-13 Thread Rishi Raj Singh

7i
On Mar 3, 2015 8:30 PM, Radoslaw Zarzynski rzarzyn...@mirantis.com
wrote:

 Guys,

 I would like discuss a problem which can be seen in Horizon: breaking
 the boundaries of public, well-specified Object Storage API in favour
 of utilizing a Swift-specific extensions. Ticket #1297173 [1] may serve
 as a good example of such violation. It is about relying on
 non-standard (in the terms of OpenStack Object Storage API v1) and
 undocumented HTTP header provided by Swift. In order to make
 Ceph RADOS Gateway work correctly with Horizon, developers had to
 inspect sources of Swift and implement the same behaviour.

 From my perspective, that practise breaks the the mission of OpenStack
 which is much more than delivering yet another IaaS/PaaS implementation.
 I think its main goal is to provide a universal set of APIs covering all
 functional areas relevant for cloud computing, and to place that set
 of APIs in front as many implementations as possible. Having an open
 source reference implementation of a particular API is required to prove
 its viability, but is secondary to having an open and documented API.

 I have full understanding that situations where the public OpenStack
 interfaces are insufficient to get the work done might exist.
 However, introduction of dependency on implementation-specific feature
 (especially without giving the users a choice via e.g. some
 configuration option) is not the proper way to deal with the problem.
 From my point of view, such cases should be handled with adoption of
 new, carefully designed and documented version of the given API.

 In any case I think that Horizon, at least basic functionality, should
 work with any storage which provides Object Storage API.
 That being said, I'm willing to contribute such patches, if we decide
 to go that way.

 Best regards,
 Radoslaw Zarzynski

 [1] https://bugs.launchpad.net/horizon/+bug/1297173

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel][docker] A FFE request for docker improvements for the 6.0.1 release

2015-03-13 Thread Bogdan Dobrelya

Hello.

I'd like to request a FFE for Docker host networking improvements [0]
for the Fuel 6.0.1 feature freeze.

This is really important to have it implemented for the 6.0.1 release as
it would increase the overall user experience for deploying and scaling
Openstack environments and would drastically improve Docker
implementation, Fuel Master node upgrades story, and its overall
performance experience.

In order to make it happen, we should finish the merging of two
remaining patches [1], [2] for master branch and backport them for the
6.0.1.

The merging is currently blocked by CI issue [3] and we're expecting it
to be fixed after the devops version on CI nodes updated and the fix for
[3] applied. That should not take longer than a two work days.

[0]
https://blueprints.launchpad.net/fuel/+spec/fuel-master-docker-host-networking
[1] https://review.openstack.org/#/c/121559/
[2] https://review.openstack.org/#/c/146885/
[3] https://bugs.launchpad.net/fuel/+bug/1431477

-- 
Best regards,
Bogdan Dobrelya,
Skype #bogdando_at_yahoo.com
Irc #bogdando

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] A question about libvirt cpu mode=none configuration

2015-03-13 Thread Steve Gordon

- Original Message -
 From: park jianlong...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org

 hello Nova

 By default, nova libvirt driver configuration for guest cpu as cpu_mode
 = none,
 you could add cpu features by changing flavor section as below, there
 will NOT
 be any issues for this cmd.

 $nova flavor-key m1.small set capabilities:cpu_info:features=in ***
 but, nova will ignore the cpu features after the guest boot up
 successfully, which
 means the feature does NOT take effect(not be written into the xml for
 the guest).

 And there is no message telling the users that the features does NOT
 take effect...
 this may make the users confused...

This issue is more general than the cpu_mode=none case, in that the 
capabilities filter is filtering *hosts* based on their CPU features. As you 
have discovered, whether they are actually exposing those features to guests in 
their current configuration is not taken into account (that is, 
cpu_mode/cpu_model settings aren't considered at all). Ideally they would be, 
but I'm not sure this is trivial.

-Steve

 if we add the feature into the xml file for the guest, this will trigger
 internal error
 libvirtError: XML error: Non-empty feature list specified without CPU
 model

 so what should we do? Leave it as itself(ignore the users input, and
 boot the guest
 successfully), or prompt the users with the errors?

 Thanks
  Park

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] is it possible to microversion a static class method?

On 03/13/2015 02:55 AM, Chris Friesen wrote:
 On 03/12/2015 12:13 PM, Sean Dague wrote:
 On 03/12/2015 02:03 PM, Chris Friesen wrote:
 Hi,

 I'm having an issue with microversions.

 The api_version() code has a comment saying This decorator MUST appear
 first (the outermost decorator) on an API method for it to work
 correctly

 I tried making a microversioned static class method like this:

  @wsgi.Controller.api_version(2.4)  # noqa
  @staticmethod
  def _my_func(req, foo):

 and pycharm highlighted the api_version decorator and complained that
 This decorator will not receive a callable it may expect; the built-in
 decorator returns a special object.

 Is this a spurious warning from pycharm?  The pep8 checks don't
 complain.

 If I don't make it static, then pycharm suggests that the method could
 be static.

 *API method*

 This is not intended for use by methods below the top controller level.
 If you want conditionals lower down in your call stack pull the request
 version out yourself and use that.
 
 Both the original spec and doc/source/devref/api_microversions.rst
 contain text talking about decorating a private method.  The latter
 gives this example:
 
 @api_version(2.1, 2.4)
 def _version_specific_func(self, req, arg1):
 pass
 
 @api_version(min_version=2.5) #noqa
 def _version_specific_func(self, req, arg1):
 pass
 
 def show(self, req, id):
  common stuff 
 self._version_specific_func(req, foo)
  common stuff 
 
 It's entirely possible that such a private method might not need to
 reference self, and could therefore be static, so I think it's a valid
 question.

That's a doc bug, we should change it.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Deprecation warnings considered harmful?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/13/2015 01:37 AM, Nikhil Manchanda wrote:
 Looking back at the meeting eavesdrop, the primary reasons why we 
 deferred this work to Liberty was twofold:
 
 - It wasn't a set plan based on information available to us at the
 time. This being the case, we decided to wait until we had more
 information regarding the requirements around this from oslo.
 
 - We wanted to ensure that we had a corresponding hacking rule in 
 place to prevent future patch-sets from using the deprecated
 module names.
 

For hacking check, I have a patch in review for 'hacking' repo to add
checks (both for stable branches where oslo.* namespace is used, and
new branches where oslo_* is expected):

- - https://review.openstack.org/157894

Also, neutron has a (test covered) hacking check at:

http://git.openstack.org/cgit/openstack/neutron/tree/neutron/hacking/checks.py#n119

Feel free to adopt.

 We specifically didn't consider the impact of logging statements
 with deprecation warnings at the meeting.
 
 We now have a better picture of the actual status -- with the oslo 
 decision that these namespace packages are definitely going away. 
 I've added an agenda item to bring this up again at the next Trove 
 weekly meeting [1] so that we can address this.
 
 [1] https://wiki.openstack.org/wiki/Meetings/TroveMeeting
 
 Thanks, Nikhil
 
 
 
 On Thu, Mar 12, 2015 at 4:05 PM, Robert Collins 
 robe...@robertcollins.net mailto:robe...@robertcollins.net
 wrote:
 
 On 13 March 2015 at 09:43, Ihar Hrachyshka ihrac...@redhat.com 
 mailto:ihrac...@redhat.com wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 03/12/2015 09:35 PM, Robert Collins wrote:
 On 13 March 2015 at 08:09, Ihar Hrachyshka
 ihrac...@redhat.com
 mailto:ihrac...@redhat.com
 wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 On 03/12/2015 11:38 AM, Boris Bobrov wrote:
 On Thursday 12 March 2015 12:59:10 Duncan Thomas wrote:
 So, assuming that all of the oslo depreciations aren't
 going to be fixed before release
 
 What makes you think that?
 
 In my opinion it's just one component's problem. These 
 particular deprecation warnings are a result of still
 on-going migration from oslo.package to oslo_package.
 Ironically, all components except oslo have already moved
 to the new naming scheme.
 
 It's actually wrong. For example, Trove decided to stay on
 using the old namespace for Kilo.
 
 Why?
 
 -Rob
 
 
 
 http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2015-02-11.log

 
 
 starting from 2015-02-11T18:03:11. I guess the assumption was
 that there is immediate benefit, and they can just wait. Though I
 don't think the fact that it means deprecation warnings in their
 logs was appreciated at the time of decision.
 
 Thanks, reading that it looks like the actual status (oslo decided 
 most definitely that namespace packages are going away, its just a 
 matter of when) wasn't understood in that meeting.
 
 Is it possible to put it back on the agenda for the next Trove
 meeting?
 
 Cheers, Rob
 
 -- Robert Collins rbtcoll...@hp.com mailto:rbtcoll...@hp.com 
 Distinguished Technologist HP Converged Cloud
 
 __

 
OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 __

 
OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVAskYAAoJEC5aWaUY1u57xD0H/13+RPI3IKDu//5FSKoENIwb
26cVv00Kd3KIAXWPVSFCzTgNjuRzhHtG0PHc4T18unbtS47zSOZGVE8J0dLlXhQV
AV9Q3p/qXbjPvGMuUCYDIDI8XGErMXkbZbKRsoEQKKrp2aXupiDJ7u0UoxKNlKOs
cwIVPYDX7cmRebdb25nYhs3X0L/oHyem6sHtWQCcElLpmIeYoTD/VdAoCy7hQhZc
s9t5f6xJev0N7/134qh1OhVDTP0UKhgR7N2r8TLUwNN9B1k6RcHxU0Fem6cbE5kZ
WytbX78LOWY6PDaJ00vfdtgQo+FVvLOfzP2O6BArF8MSQT9kp2QH/GD2EyZ6i7M=
=RXO/
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-operators][rally] What's new in Rally v0.0.2

2015-03-13 Thread Andrey Kurilin

Good news!

 Our goal is to cut releases ever 2 weeks.

+1 for it. End-users will be able to use new features quicker.

On Thu, Mar 12, 2015 at 7:03 PM, Boris Pavlovic bo...@pavlovic.me wrote:

 Hi stackers,

 For those who doesn't know Rally team started making releases.

 There are 3 major reasons why we started doing releases:

  * A lot of people started using Rally in their CI/CD.

 Usually they don't like to depend on something that is from master.
 And would like to have smooth testable upgrades between versions

  * Rally is used in gates of many projects.

 As far as you know in Rally everything is plugable. These plugins can
 be
 put  in project tree. This is nice flexibility for all projects. But
 it blocks a lot
development of Rally. To resolve this issue we are going to allow
 projects t
specify which version of Rally to run in their trees. This resolves 2
 issues:
1) projects gates won't depend on Rally master
2) projects have smooth, no downtime, testable way to switch to newer
version of Rally

  * Release notes - as a simple way to track project changes.



 Release stats:
 +--+-+
 | Commits  | **100** |
 +--+-+
 | Bug fixes| **18**  |
 +--+-+
 | Dev cycle|   **45 days**   |
 +--+-+
 | Release date | **12/Mar/2015** |
 +--+-+


 Release notes:

 https://rally.readthedocs.org/en/latest/release_notes/v0.0.2.html


 Pypi:

 https://pypi.python.org/pypi/rally/0.0.2


 Future goals:

 Our goal is to cut releases ever 2 weeks.  As far as project is quite
 bugless and stable we don't need feature freeze at all, so I don't think
 that it will be hard to achieve this goal.


 Best regards,
 Boris Pavlovic

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][docker] A FFE request for docker improvements for the 6.0.1 release

2015-03-13 Thread Matthew Mosesohn

This should be for 6.1, not 6.0.1.
On Mar 13, 2015 2:10 PM, Bogdan Dobrelya bdobre...@mirantis.com wrote:

 Hello.

 I'd like to request a FFE for Docker host networking improvements [0]
 for the Fuel 6.0.1 feature freeze.

 This is really important to have it implemented for the 6.0.1 release as
 it would increase the overall user experience for deploying and scaling
 Openstack environments and would drastically improve Docker
 implementation, Fuel Master node upgrades story, and its overall
 performance experience.

 In order to make it happen, we should finish the merging of two
 remaining patches [1], [2] for master branch and backport them for the
 6.0.1.

 The merging is currently blocked by CI issue [3] and we're expecting it
 to be fixed after the devops version on CI nodes updated and the fix for
 [3] applied. That should not take longer than a two work days.

 [0]

 https://blueprints.launchpad.net/fuel/+spec/fuel-master-docker-host-networking
 [1] https://review.openstack.org/#/c/121559/
 [2] https://review.openstack.org/#/c/146885/
 [3] https://bugs.launchpad.net/fuel/+bug/1431477

 --
 Best regards,
 Bogdan Dobrelya,
 Skype #bogdando_at_yahoo.com
 Irc #bogdando

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][docker] A FFE request for docker improvements for the 6.0.1 release

2015-03-13 Thread Bogdan Dobrelya

On 13.03.2015 12:12, Matthew Mosesohn wrote:
 This should be for 6.1, not 6.0.1.

Yes, exactly. Thank you for the fix. This is the 6.1 feature and we'd
like it to be put for the 6.1 FFE :)

 
 On Mar 13, 2015 2:10 PM, Bogdan Dobrelya bdobre...@mirantis.com
 mailto:bdobre...@mirantis.com wrote:
 
 Hello.
 
 I'd like to request a FFE for Docker host networking improvements [0]
 for the Fuel 6.0.1 feature freeze.
 
 This is really important to have it implemented for the 6.0.1 release as
 it would increase the overall user experience for deploying and scaling
 Openstack environments and would drastically improve Docker
 implementation, Fuel Master node upgrades story, and its overall
 performance experience.
 
 In order to make it happen, we should finish the merging of two
 remaining patches [1], [2] for master branch and backport them for the
 6.0.1.
 
 The merging is currently blocked by CI issue [3] and we're expecting it
 to be fixed after the devops version on CI nodes updated and the fix for
 [3] applied. That should not take longer than a two work days.
 
 [0]
 
 https://blueprints.launchpad.net/fuel/+spec/fuel-master-docker-host-networking
 [1] https://review.openstack.org/#/c/121559/
 [2] https://review.openstack.org/#/c/146885/
 [3] https://bugs.launchpad.net/fuel/+bug/1431477
 
 --
 Best regards,
 Bogdan Dobrelya,
 Skype #bogdando_at_yahoo.com http://bogdando_at_yahoo.com
 Irc #bogdando
 


-- 
Best regards,
Bogdan Dobrelya,
Skype #bogdando_at_yahoo.com
Irc #bogdando

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] if by archived you mean, wipes out your tables completely, then sure, it works fine

On 03/13/2015 05:54 AM, Thomas Herve wrote:

[snip]
If we assume that all of our tables are filled up with zeroes for those
deleted columns, because that’s the default, this **wipes the whole table
clean**.

Hi Mike,

Thanks for the investigation. I was wondering when that behavior was
introduced and it seems that
http://git.openstack.org/cgit/openstack/nova/commit/?id=ecf74d4c0a5a8a4290ecac048fc437dafe3d40fc
is the likely culprit, which would mean that only Kilo is affected. Can you
confirm?

Thanks,

Yes, that looks like the problematic patch. I'd rather actually revert
that patch instead.

Also, real tests would be nice to actually prevent future regression.

-Sean

--
Sean Dague
http://dague.net

Re: [openstack-dev] [packaging][neutron] --config-dir vs. --config-file



On Fri, Mar 13, 2015, at 10:11 AM, Ihar Hrachyshka wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi all,
 
 (I'm starting a new [packaging] tag in this mailing list to reach out
 people who are packaging our software in distributions and whatnot.)
 
 Neutron vendor split [1] introduced situations where the set of
 configuration files for L3/VPN agent is not stable and depends on
 which packages are installed in the system. Specifically,
 fwaas_driver.ini file is now shipped in neutron_fwaas tarball
 (openstack-neutron-fwaas package in RDO), and so
 - --config-file=/etc/neutron/fwaas_driver.ini argument should be passed
 to L3/VPN agent *only* when the new package with the file is installed.
 
 In devstack, we solve the problem by dynamically generating CLI
 arguments list based on which services are configured in local.conf
 [2]. It's not a viable approach in proper distribution packages
 though, where we usually hardcode arguments [3] in our service
 manifests (systemd unit files, in case of RDO).
 
 The immediate solution to solve the issue would be to use --config-dir
 argument that is also provided to us by oslo.config instead of
 - --config-file, and put auxiliary files there [4] (those may be just
 symbolic links to actual files).
 
 I initially thought to put the directory under /etc/neutron/, but then
 realized we may be interested in keeping it out of user sight while it
 only references stock (upstream) configuration files.
 
 But then a question arises: whether it's useful just for this
 particular case? Maybe there is value in using --config-dir outside of
 it? And in that case, maybe the approach should be replicated to other
 services?
 
 AFAIU --config-dir could actually be useful to configure services. Now
 instead of messing with configuration files that are shipped with
 packages (and handling .rpmnew files [5] that are generated on upgrade
 when local changes to those files are detected), users (or
 deployment/installation tools) could instead drop a *.conf file in
 that configuration directory, being sure their stock configuration
 file is always current, and no .rpmnew files are there to manually
 solve conflicts).

The --config-dir option was added at the request of some of the folks
working on deployment automation (I don't remember if it was the puppet
folks, the chef folks, or both) because it's easier to add a file than
to modify one. 

So yes, if each driver or add-on or whatever uses a separate file *and
configuration section* for its overrides, oslo.config can just read all
of the files and merge them together. Only the options actually being
used by running code will be validated, so there's no harm in deploying
extra configuration files.

 
 We can also use two --config-dir arguments, one for stock/upstream
 configuration files, located out of /etc/neutron/, and another one
 available for population with user configuration files, under
 /etc/neutron/. This is similar to how we put settings considered to be
 'sane distro defaults' in neutron-dist.conf file that is not available
 for modification [6][7].
 
 Of course users would still be able to set up their deployment the old
 way. In that case, nothing will change for them. So the approach is
 backwards compatible.
 
 I wonder whether the idea seems reasonable and actually useful for
 people. If so, we may want to come up with some packaging standards
 (on where to put those config-dir(s), how to name them, how to
 maintain symbolic links inside them) to avoid more work for deployment
 tools.
 
 [1]:
 https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition
 [2]:
 http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron#n393
 [3]:
 https://github.com/openstack-packages/neutron/blob/f20-master/neutron-l3-agent.service#L8
 [4]: https://review.gerrithub.io/#/c/218562/
 [5]:
 https://ask.fedoraproject.org/en/question/25722/what-are-rpmnew-files/
 [6]:
 https://github.com/openstack-packages/neutron/blob/f20-master/neutron-dist.conf
 [7]:
 https://github.com/openstack-packages/neutron/blob/f20-master/openstack-neutron.spec#L700
 
 Regards,
 /Ihar
 
 /Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 
 iQEcBAEBAgAGBQJVAu/8AAoJEC5aWaUY1u57yx4H/0AE+8LH6wByyBQAGvcSU0i7
 0BNThPS2sy0sPEHIZCH7OH3prAAyG0IFb2NNyHvMjTbVHPR+wjavsxPcAth09vrh
 rQgnSTA9IkdX2w1+M/vKu0QKUPNQrs5KVIchUatsoReeM9Mmrq6YqG56dEx33Emi
 FvpTb7B6V4EOvrCRp6TT4gOHOrHO5kwa62sXSFP8+IpzOcOKeO9XTFTC7PeKFtMi
 AHwjvpHjnOl8bNpTbGz5nVZkAT/XTv0TiiPIQF7NFPIkzlan4E/K04N8DIis5fdA
 P+8eDaEGDxsW4LYZ9AfITml3G0uVqcpiRIwwIL4f84ubQKjSARW8Roi1FwPSsbI=
 =gkZr
 -END PGP SIGNATURE-
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__

Re: [openstack-dev] [all] Do we need release announcements for all the things?



On Fri, Mar 13, 2015, at 06:57 AM, Thierry Carrez wrote:
 Clint Byrum wrote:
  I spend a not-insignificant amount of time deciding which threads to
  read and which to fully ignore each day, so extra threads mean extra
  work, even with a streamlined workflow of single-key-press-per-thread.
  
  So I'm wondering what people are getting from these announcements being
  on the discussion list. I feel like they'd be better off in a weekly
  digest, on a web page somewhere, or perhaps with a tag that could be
  filtered out for those that don't benefit from them.
 
 The first value of a release announcement is (obviously) to let people
 know something was released. There is a bit of a paradox there with some
 announcements being posted to openstack-announce (in theory low-traffic
 and high-attention), and some announcements being posted to
 openstack-dev (high-traffic and medium-attention). Where is the line
 drawn ?
 
 The second value of a release announcement is the thread it creates in
 case immediate issues are spotted. I kind of like that some
 python-*client release announcements are followed-up by a this broke
 the world thread, all in a single convenient package. Delaying
 announcements defeats that purpose.
 
 We need to adapt our current (restricted) usage of openstack-announce to
 a big-tent less-hierarchical future anyway: if we continue to split
 announcements, which projects are deemed important enough to be
 granted openstack-announce access ?
 
 Personally in the future I'm not opposed to allowing any openstack
 project (big-tent definition) to post to openstack-announce (ideally in
 a standard / autogenerated format) with reply-to set to openstack-dev.
 We could use a separate list, but then release and OSSA announcements
 are the only thing we use -announce for currently, so I'm not sure it's
 worth it.
 
 So I'm +1 on using a specific list (and setting reply-to to -dev), and
 I'm suggesting openstack-announce should be reused to avoid creating two
 classes of deliverables (-announce worthy and not).

We had complaints in the past when we *didn't* send release
announcements because people were then unaware of why a new release
might be causing changes in behavior, so we built a bunch of tools to
make it easy to create uniform and informative release note emails
containing the level of detail people wanted. So far those are only
being used by Oslo, but we're moving the scripts to the release-tools
repo to make them easy for all library maintainers to use.

These announcements are primarily for our developer community and the
folks at the distros who need to know to package the new versions. Are
we going to start having non-dev folks who subscribe to the announce
list complain about the release announcements for libraries, then? Are
enough developers subscribed to the announce list that they will see the
release messages to meet the original needs we were trying to meet?

 
 Posting on -dev with a subject prefix would only marginally improve the
 situation (release announcements are already pretty easy to spot and
 manually filter out), so I'm +0 on that.
 
 Weekly posts or ratelimiting would imho remove 99% of the interest of
 release announcements, so I'm -1 on that solution.
 
 -- 
 Thierry Carrez (ttx)
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Deprecation warnings considered harmful?



On Fri, Mar 13, 2015, at 07:05 AM, Thierry Carrez wrote:
 Doug Hellmann wrote:
  Yay, the system is working as designed!
  
  Oslo froze early to prepare releases to integrate with the downstream
  projects. You found an issue and reported it. Dims and others worked on
  patches, and we're releasing new versions. All before your feature
  freeze, so you can adopt them.
 
 Also that would likely be considered a bug fix, so I'd say this could
 also be fixed after Feature Freeze (before RC1).

Sure, I was just pointing out Dims' quick turn-around time on the fixes.

Doug

 
 -- 
 Thierry Carrez (ttx)
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Deprecation warnings considered harmful?



On Fri, Mar 13, 2015, at 06:52 AM, Duncan Thomas wrote:
 On 12 March 2015 at 18:48, Doug Hellmann d...@doughellmann.com wrote:
 
  On Thu, Mar 12, 2015, at 05:24 AM, Duncan Thomas wrote:
 
 
 
  Yay, the system is working as designed!
 
 
 Good to hear
 
  
 
   What are normal, none developer users supposed to do with such warnings,
   other than:
   a) panic or b) Assume openstack is beta quality and then panic
 
  Next time, please try to be less snide. It makes it difficult to take
  you seriously.
 
 
 Fair point, I apologise, it was the end of a long day. I was aiming for
 humorous rather than snide, and clearly missed by a significant amount.

Thank you. I definitely know the effects of long days. :-)

Doug

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] dependency on non-standardized, private APIs

2015-03-13 Thread Rishi Raj Singh

Sorry,

that was by mistake.

On Fri, Mar 13, 2015 at 8:19 PM, Rishi Raj Singh rishiraj.de...@gmail.com
wrote:

 7i
 On Mar 3, 2015 8:30 PM, Radoslaw Zarzynski rzarzyn...@mirantis.com
 wrote:

 Guys,

 I would like discuss a problem which can be seen in Horizon: breaking
 the boundaries of public, well-specified Object Storage API in favour
 of utilizing a Swift-specific extensions. Ticket #1297173 [1] may serve
 as a good example of such violation. It is about relying on
 non-standard (in the terms of OpenStack Object Storage API v1) and
 undocumented HTTP header provided by Swift. In order to make
 Ceph RADOS Gateway work correctly with Horizon, developers had to
 inspect sources of Swift and implement the same behaviour.

 From my perspective, that practise breaks the the mission of OpenStack
 which is much more than delivering yet another IaaS/PaaS implementation.
 I think its main goal is to provide a universal set of APIs covering all
 functional areas relevant for cloud computing, and to place that set
 of APIs in front as many implementations as possible. Having an open
 source reference implementation of a particular API is required to prove
 its viability, but is secondary to having an open and documented API.

 I have full understanding that situations where the public OpenStack
 interfaces are insufficient to get the work done might exist.
 However, introduction of dependency on implementation-specific feature
 (especially without giving the users a choice via e.g. some
 configuration option) is not the proper way to deal with the problem.
 From my point of view, such cases should be handled with adoption of
 new, carefully designed and documented version of the given API.

 In any case I think that Horizon, at least basic functionality, should
 work with any storage which provides Object Storage API.
 That being said, I'm willing to contribute such patches, if we decide
 to go that way.

 Best regards,
 Radoslaw Zarzynski

 [1] https://bugs.launchpad.net/horizon/+bug/1297173

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Deprecation warnings considered harmful?



On Fri, Mar 13, 2015, at 07:25 AM, Ihar Hrachyshka wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 03/13/2015 01:37 AM, Nikhil Manchanda wrote:
  Looking back at the meeting eavesdrop, the primary reasons why we 
  deferred this work to Liberty was twofold:
  
  - It wasn't a set plan based on information available to us at the
  time. This being the case, we decided to wait until we had more
  information regarding the requirements around this from oslo.
  
  - We wanted to ensure that we had a corresponding hacking rule in 
  place to prevent future patch-sets from using the deprecated
  module names.
  
 
 For hacking check, I have a patch in review for 'hacking' repo to add
 checks (both for stable branches where oslo.* namespace is used, and
 new branches where oslo_* is expected):
 
 - - https://review.openstack.org/157894
 
 Also, neutron has a (test covered) hacking check at:
 
 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/hacking/checks.py#n119
 
 Feel free to adopt.

I wish we, as a community, were less obsessed with creating so many
hacking rules. These are really minor changes and it's going to be a
relatively short-lived issue that could just be fixed once. If there's a
regression, fixing *that* won't be hard or take long.

As I said in the IRC snippet pasted into the meeting log linked
elsewhere in the thread, I want to drop the oslo package during the
next cycle. It's not clear that all projects will be ready for us to do
that, and that's why it's not a definite plan, yet. We're trying to be
cognizant of the fact that you all have other things you're trying to
accomplish too, and that this work appears like code churn even though
it is solving a problem many developers have had in their development
environments. 

In any case, you should plan for all Oslo libraries to drop the
namespace packages entirely *soon*. If not for Liberty then definitely
for M. There's no sense at all in delaying the work needed in your
projects beyond L-1, and landing the changes sooner is better than
waiting.

Doug

 
  We specifically didn't consider the impact of logging statements
  with deprecation warnings at the meeting.
  
  We now have a better picture of the actual status -- with the oslo 
  decision that these namespace packages are definitely going away. 
  I've added an agenda item to bring this up again at the next Trove 
  weekly meeting [1] so that we can address this.
  
  [1] https://wiki.openstack.org/wiki/Meetings/TroveMeeting
  
  Thanks, Nikhil
  
  
  
  On Thu, Mar 12, 2015 at 4:05 PM, Robert Collins 
  robe...@robertcollins.net mailto:robe...@robertcollins.net
  wrote:
  
  On 13 March 2015 at 09:43, Ihar Hrachyshka ihrac...@redhat.com 
  mailto:ihrac...@redhat.com wrote:
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
  
  On 03/12/2015 09:35 PM, Robert Collins wrote:
  On 13 March 2015 at 08:09, Ihar Hrachyshka
  ihrac...@redhat.com
  mailto:ihrac...@redhat.com
  wrote:
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
  
  On 03/12/2015 11:38 AM, Boris Bobrov wrote:
  On Thursday 12 March 2015 12:59:10 Duncan Thomas wrote:
  So, assuming that all of the oslo depreciations aren't
  going to be fixed before release
  
  What makes you think that?
  
  In my opinion it's just one component's problem. These 
  particular deprecation warnings are a result of still
  on-going migration from oslo.package to oslo_package.
  Ironically, all components except oslo have already moved
  to the new naming scheme.
  
  It's actually wrong. For example, Trove decided to stay on
  using the old namespace for Kilo.
  
  Why?
  
  -Rob
  
  
  
  http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2015-02-11.log
 
  
  
  starting from 2015-02-11T18:03:11. I guess the assumption was
  that there is immediate benefit, and they can just wait. Though I
  don't think the fact that it means deprecation warnings in their
  logs was appreciated at the time of decision.
  
  Thanks, reading that it looks like the actual status (oslo decided 
  most definitely that namespace packages are going away, its just a 
  matter of when) wasn't understood in that meeting.
  
  Is it possible to put it back on the agenda for the next Trove
  meeting?
  
  Cheers, Rob
  
  -- Robert Collins rbtcoll...@hp.com mailto:rbtcoll...@hp.com 
  Distinguished Technologist HP Converged Cloud
  
  __
 
  
 OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: 
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
  http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
  
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
  
  __
 
  
 OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:

Re: [openstack-dev] [nova] A question about libvirt cpu mode=none configuration

2015-03-13 Thread Daniel P. Berrange

On Fri, Mar 13, 2015 at 08:42:25AM -0400, Steve Gordon wrote:
 - Original Message -
  From: park jianlong...@gmail.com
  To: OpenStack Development Mailing List (not for usage questions) 
  openstack-dev@lists.openstack.org

  hello Nova

  By default, nova libvirt driver configuration for guest cpu as cpu_mode
  = none,
  you could add cpu features by changing flavor section as below, there
  will NOT
  be any issues for this cmd.

  $nova flavor-key m1.small set capabilities:cpu_info:features=in ***
  but, nova will ignore the cpu features after the guest boot up
  successfully, which
  means the feature does NOT take effect(not be written into the xml for
  the guest).

  And there is no message telling the users that the features does NOT
  take effect...
  this may make the users confused...

 This issue is more general than the cpu_mode=none case, in that the
 capabilities filter is filtering *hosts* based on their CPU features.
 As you have discovered, whether they are actually exposing those
 features to guests in their current configuration is not taken into
 account (that is, cpu_mode/cpu_model settings aren't considered at
 all). Ideally they would be, but I'm not sure this is trivial.

If you set  'cpu_mode=host-model' or 'cpu_mode=host-passthrough'
then it will take effect, as the guest will see the full CPU model
of the host that is picked. IMHO the capabilities:cpu_info:features
filter only makes sense when using those two cpu modes. If you
left the default cpu_mode=None or set cpu_mode=custom, then this
capabilities feature is meaningless from a conceptual POV. So the
fact that it has no effect on the guest CPU is not a bug it is
by design.

Regards,
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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] A question about libvirt cpu mode=none configuration

2015-03-13 Thread park

On 2015年03月13日 20:42, Steve Gordon wrote:

- Original Message -

From: park jianlong...@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org

hello Nova

By default, nova libvirt driver configuration for guest cpu as cpu_mode
= none,
you could add cpu features by changing flavor section as below, there
will NOT
be any issues for this cmd.

$nova flavor-key m1.small set capabilities:cpu_info:features=in ***
but, nova will ignore the cpu features after the guest boot up
successfully, which
means the feature does NOT take effect(not be written into the xml for
the guest).

And there is no message telling the users that the features does NOT
take effect...
this may make the users confused...

This issue is more general than the cpu_mode=none case, in that the 
capabilities filter is filtering *hosts* based on their CPU features. As you 
have discovered, whether they are actually exposing those features to guests in 
their current configuration is not taken into account (that is, 
cpu_mode/cpu_model settings aren't considered at all). Ideally they would be, 
but I'm not sure this is trivial.

+1
and I think the CPU configuration should take effect,
otherwise, users should be prompted some messages..

-Steve

if we add the feature into the xml file for the guest, this will trigger
internal error
libvirtError: XML error: Non-empty feature list specified without CPU
model

so what should we do? Leave it as itself(ignore the users input, and
boot the guest
successfully), or prompt the users with the errors?

Thanks
  Park

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] oslo.versionedobjects 0.1.1 release

The Oslo team is satisfied to announce the release of:

oslo.versionedobjects 0.1.1: oslo.versionedobjects library

For more details, please see the git log history below and:

http://launchpad.net/oslo.versionedobjects/+milestone/0.1.1

Please report issues through launchpad:

http://bugs.launchpad.net/oslo.versionedobjects

Changes in oslo.versionedobjects 0.1.0..0.1.1
-

36be0e5 Sync from oslo-incubator
4201a4f Properly serialize/deserialize arguments in fake indirection api
0b4668f Allow passing serializer and indirection API objects to Fixture
a63ef59 Make serializer use the provided base class for the indirection api

Diffstat (except docs and test files)
-

oslo_versionedobjects/base.py  |  4 +-
oslo_versionedobjects/fixture.py   | 26 +
oslo_versionedobjects/openstack/common/_i18n.py|  4 +-
.../openstack/common/versionutils.py   | 15 ++--
5 files changed, 77 insertions(+), 15 deletions(-)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] if by archived you mean, wipes out your tables completely, then sure, it works fine

On 03/13/2015 07:57 AM, Sean Dague wrote:
On 03/13/2015 07:07 AM, Sean Dague wrote:
On 03/13/2015 05:54 AM, Thomas Herve wrote:

[snip]
If we assume that all of our tables are filled up with zeroes for those
deleted columns, because that’s the default, this **wipes the whole table
clean**.

I’ve posted the bug report at https://bugs.launchpad.net/nova/+bug/1431571
where I started out not knowing much about how this worked except that my
tests were failing, and slowly stumbled my way to come to this conclusion.
A
patch is at https://review.openstack.org/#/c/164009/, where we look at the
actual Python-side default. However I’d recommend that we just hardcode the
zero here, since that’s how our soft-delete columns work.

Hi Mike,

Thanks for the investigation. I was wondering when that behavior was
introduced and it seems that
http://git.openstack.org/cgit/openstack/nova/commit/?id=ecf74d4c0a5a8a4290ecac048fc437dafe3d40fc
is the likely culprit, which would mean that only Kilo is affected. Can
you confirm?

Thanks,

Yes, that looks like the problematic patch. I'd rather actually revert
that patch instead.

Also, real tests would be nice to actually prevent future regression.

-Sean

Ok, we've done a straight revert here -
https://review.openstack.org/#/c/164140/

The test additions are now posted here -
https://review.openstack.org/#/c/164178/

-Sean

--
Sean Dague
http://dague.net

[openstack-dev] [packaging][neutron] --config-dir vs. --config-file