[openstack-dev] [Congress] Fwd: Your draft logo & sneak peek

[Tim Hinrichs]

Hi team,
I just received a draft version of our project logo, using the mascot we
selected together. A final version (and some cool swag) will be ready for
us before the Project Team Gathering in February. Before they make our logo
final, they want to be sure we're happy with our mascot.

We can discuss any concerns in Barcelona and you can also provide direct
feedback to the designers: http://tinyurl.com/OSmascot  Logo feedback is
due Friday, Nov. 11. To get a sense of how ours stacks up to others, check
out this sneak preview of several dozen draft logos from our community:
https://youtu.be/JmMTCWyY8Y4

[image: Congress.png]
__
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] [heat] Rolling Upgrades

[Crag Wolfe]

On 10/21/2016 11:25 AM, Crag Wolfe wrote:
> Another edge case is that if only the first h-engine is upgraded during
> a rolling upgrade and the operator waits awhile before upgrading the
> other h-engines, we'll have a case where we are not distributing newer
> rpc calls as much as we'd like. Specifically, that first h-engine is
> sending newer messages that only get picked up by itself, in addition to
> it picking up older h-engine messages. I'm not sure what to do about
> that other than to suggest "don't do that."

This may be a key case to consider. We'll have to go with major/minor
version pinning and take the future_args route if we can't risk the
above scenario (short of the full blown "RPC version reporting and
detection framework" Michal provided). I.e., the rpc version is pinned
at 1.36 and new args are migrated through future_args, until the next
major version release.

--Crag

__
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] Fwd: Your draft logo & sneak peek

[Joshua Harlow]

Thought others in oslo might want to see :)

*From:* Heidi Joy Tretheway 
*Date:* October 21, 2016 at 10:17 AM
*To:* Joshua Harlow 
*Subject:* Your draft logo & sneak peek
Hi Josh,

We're excited to show you the draft version of your project logo, 
attached. We want to give you and your team a chance to see the mascot 
illustrations before we make them official, so we decided to make 
Barcelona the draft target, with final logos ready by the Project Team 
Gathering in Atlanta in February.


Our illustrators worked as fast as possible to draft nearly 60 logos, 
and we're thrilled to see how they work as a family. Here's a 
50-second "sneak peek" at how they came together: 
https://youtu.be/JmMTCWyY8Y4


We welcome you to *share this logo with your team and discuss it in 
Barcelona*. We're very happy to take feedback on it if we've missed 
the mark. The style of the logos is consistent across projects, and we 
did our best to incorporate any special requests, such as an element 
of an animal that is especially important, or a reference to an old logo.


We ask that you don't start using this logo now since it's a draft. 
Here's *what you can expect for the final product*:


  * A horizontal version of the logo, including your mascot, project
name and the words "An OpenStack Community project"
  * A square(ish) version of the logo, including all of the above
  * A mascot-only version of the logo
  * Stickers for all project teams distributed at the PTG
  * One piece of swag that incorporates all project mascots, such as a
deck of playing cards, distributed at the PTG
  * All digital files will be available through the website


We know this is a busy time for you, so to take some of the burden of 
coordinating feedback off you, we made a feedback form*:* 
http://tinyurl.com/OSmascot  You are also welcome to reach out to 
Heidi Joy directly with questions or concerns. Please provide 
*feedback by Friday, Nov. 11*, so that we can request revisions from 
the illustrators if needed. Or, if this logo looks great, just reply 
to this email and you don't need to take any further action.


Thank you!
Heidi Joy Tretheway - project lead
Todd Morey - creative lead

P.S. Here's an email that you can copy/paste to send to your team 
(remember to attach your logo from my email):


Hi team,
I just received a draft version of our project logo, using the mascot 
we selected together. A final version (and some cool swag) will be 
ready for us before the Project Team Gathering in February. Before 
they make our logo final, they want to be sure we're happy with our 
mascot.


We can discuss any concerns in Barcelona and you can also provide 
direct feedback to the designers: http://tinyurl.com/OSmascot  Logo 
feedback is due Friday, Nov. 11. To get a sense of how ours stacks up 
to others, check out this sneak preview of several dozen draft logos 
from our community: https://youtu.be/JmMTCWyY8Y4



photo   

*Heidi Joy Tretheway*
Senior Marketing Manager, OpenStack Foundation
503 816 9769  | Skype: heidi.tretheway 

 
 




__
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] [QA][Tempest] Check puppet jobs on the gate

[Alex Schultz]

On Fri, Oct 21, 2016 at 4:02 PM, Ken'ichi Ohmichi  wrote:
> Hi QA team,
>
> There are three gate jobs related to puppet jobs (like
> gate-puppet-openstack-integration-4-scenario001-tempest-centos-7-nv)
> and they are marked as non-voting now.
> If finding these jobs failures during Tempest patch reviews even but
> jenkins +1, please notify the failures to the following guys on
> #openstack-qa channel if possible.
>
>   EmilienM
>   mwhahaha
>   dmsimard
>
> It is fine to just notify that without any investigations.
> Some projects are still using Tempest internal code without using
> stable Tempest library code(aka tempest.lib) and the internal change
> of Tempest can affect these projects' gates.
> The puppet jobs can detect such effect before merging, and the above
> guys will help the quality improvement in such cases.
>

Not sure if we'll help in actually fixing it but we can definitely
assist in validating if the failures are an actual issue and bugs need
to be fixed in the other projects.  In the cases where the puppet jobs
are red, please wait for a +1 from one of us before merging as it can
immediately break all of the puppet gates, possibly other project
gates, and other promotion processes within the OpenStack world.

Thanks,
-Alex

> Thanks
> Ken Ohmichi
>
> __
> 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] [QA][Tempest] Check puppet jobs on the gate

[Ken'ichi Ohmichi]

Hi QA team,

There are three gate jobs related to puppet jobs (like
gate-puppet-openstack-integration-4-scenario001-tempest-centos-7-nv)
and they are marked as non-voting now.
If finding these jobs failures during Tempest patch reviews even but
jenkins +1, please notify the failures to the following guys on
#openstack-qa channel if possible.

  EmilienM
  mwhahaha
  dmsimard

It is fine to just notify that without any investigations.
Some projects are still using Tempest internal code without using
stable Tempest library code(aka tempest.lib) and the internal change
of Tempest can affect these projects' gates.
The puppet jobs can detect such effect before merging, and the above
guys will help the quality improvement in such cases.

Thanks
Ken Ohmichi

__
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] [heat] Rolling Upgrades

[Zane Bitter]

On 21/10/16 08:37, Michał Dulko wrote:

> Finally, a note about Oslo versioned objects: they don't really help
> us. They work great for nova where there is just nova-conductor
> reading and writing to the DB, but we have multiple heat-engines doing
> that that need to be restarted in a rolling manner. See the references
> below for greater detail.

They do help in case you're changing RPC arguments *content*. In
particular they make it easier to modify schema of dict-like structures
sent over RPC.


This is technically true, but there's a much simpler solution to that 
which we already have: just don't change the content in 
non-backward-compatible ways (i.e. you can add stuff but not 
change/rename/remove stuff).


We have to do that anyway, because this is effectively our user 
interface, so if we didn't we'd break clients. For that reason, we're 
already much more strict about this than required to avoid this problem 
in the RPC layer.


As Crag said, the problem we do have is when we add flags/arguments to a 
message, how can we ensure that older versions of the engine still 
interpret it correctly.


- ZB

__
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] [heat] Rolling Upgrades

[Zane Bitter]

On 20/10/16 20:02, Crag Wolfe wrote:

AFAIK, only sqlalchemy+mariadb is
being used in production


I believe there are people using Postgres in production, or at least 
there were at one point.


- ZB

__
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] [kolla] Re: Your draft logo & sneak peek

[Steven Dake (stdake)]

Forgot kolla tag in subject.

From: Steven Dake >
Date: Friday, October 21, 2016 at 7:50 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Cc: "Jastrzebski, Michal" 
>
Subject: FW: Your draft logo & sneak peek

Folks,

Inline is the draft logo of the Kolla mascot and logo.  We will be getting 
various types of swag at the first PTG related to our mascot.  The deadline for 
feedback is November 11th, 2016.  See the email inside from Heidi for more 
information on our project mascots.

Super exciting!

Regards
-steve


From: Heidi Joy Tretheway 
>
Date: Friday, October 21, 2016 at 7:16 PM
To: Steven Dake >
Subject: Your draft logo & sneak peek

Hi Steven,

We're excited to show you the draft version of your project logo, attached. We 
want to give you and your team a chance to see the mascot illustrations before 
we make them official, so we decided to make Barcelona the draft target, with 
final logos ready by the Project Team Gathering in Atlanta in February.

Our illustrators worked as fast as possible to draft nearly 60 logos, and we're 
thrilled to see how they work as a family. Here's a 50-second "sneak peek" at 
how they came together: https://youtu.be/JmMTCWyY8Y4

We welcome you to share this logo with your team and discuss it in Barcelona. 
We're very happy to take feedback on it if we've missed the mark. The style of 
the logos is consistent across projects, and we did our best to incorporate any 
special requests, such as an element of an animal that is especially important, 
or a reference to an old logo.



We ask that you don't start using this logo now since it's a draft. Here's what 
you can expect for the final product:

  *   A horizontal version of the logo, including your mascot, project name and 
the words "An OpenStack Community project"
  *   A square(ish) version of the logo, including all of the above
  *   A mascot-only version of the logo
  *   Stickers for all project teams distributed at the PTG
  *   One piece of swag that incorporates all project mascots, such as a deck 
of playing cards, distributed at the PTG
  *   All digital files will be available through the website

We know this is a busy time for you, so to take some of the burden of 
coordinating feedback off you, we made a feedback form: 
http://tinyurl.com/OSmascot  You are also welcome to reach out to Heidi Joy 
directly with questions or concerns. Please provide feedback by Friday, Nov. 
11, so that we can request revisions from the illustrators if needed. Or, if 
this logo looks great, just reply to this email and you don't need to take any 
further action.

Thank you!
Heidi Joy Tretheway - project lead
Todd Morey - creative lead

P.S. Here's an email that you can copy/paste to send to your team (remember to 
attach your logo from my email):

Hi team,
I just received a draft version of our project logo, using the mascot we 
selected together. A final version (and some cool swag) will be ready for us 
before the Project Team Gathering in February. Before they make our logo final, 
they want to be sure we're happy with our mascot.

We can discuss any concerns in Barcelona and you can also provide direct 
feedback to the designers: http://tinyurl.com/OSmascot  Logo feedback is due 
Friday, Nov. 11. To get a sense of how ours stacks up to others, check out this 
sneak preview of several dozen draft logos from our community: 
https://youtu.be/JmMTCWyY8Y4


[photo]
Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | Skype: 
heidi.tretheway
[https://s3.amazonaws.com/images.wisestamp.com/icons_32/linkedin.png]
 [https://s3.amazonaws.com/images.wisestamp.com/icons_32/twitter.png] 
  
[https://s3.amazonaws.com/ucwebapp.wisestamp.com/5dafe09f-4769-4e67-8016-7a75904bb079/OpenStackicon.format_png.resize_32x32.png]
 


[cid:472D98FC-AE1F-44D2-BCBC-78723140CD99]

__
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] [heat] Rolling Upgrades

[Crag Wolfe]

On 10/20/2016 09:30 PM, Rabi Mishra wrote:
> Thanks Crag on starting the thread. Few comments inline.
> 

Happy to get it started. Thanks for the comments.

> On Fri, Oct 21, 2016 at 5:32 AM, Crag Wolfe  > wrote:
> 
> At Summit, folks will be discussing the rolling upgrade issue across a
> couple of sessions. I personally won't be able to attend, but thought
> I would share my thoughts on the subject.
> 
> To handle rolling upgrades, there are two general cases to consider:
> database model changes and RPC method signature changes.
> 
> For DB Model changes (this has already been well discussed on the
> mailing list, see the footnotes), let's assume for the moment we don't
> want to use triggers. If we are moving data from one column/table to
> another, the pattern looks like:
> 
> legacy release: write to old location
> release+1: write to old and new location, read from old
> release+2: write to old and new location, read from new,
>provide migration utility
> release+3: write to new location, read from new
> 
> Not sure I understand this. Is it always about changing the table name
> or column name of a table?
> What about adding a new column to an existing table? I assume the db api
> implementation have to ignore the additional column values when writing
> to old location. 
>  

I picked the slightly more complicated case of changing location, but
the basic principle is the same for adding a column. Typically, it would
look like:

release+1: write to the new column, but always ignore it
release+2: read and write from the new column

It might be, depending on the details, that you could skip straight to
release+2. E.g., if the following scenario is OK (which could happen
during a rolling upgrade):
a) h-engine-new-release writes to the new column b)
h-engine-legacy-release updates the table ignoring the new column c)
h-engine-new-release reads the table, sees the column written in a) and
possibly updates the table. Most of the time that could lead to breakage
and so we would need two releases.

> 
> Works great! The main issue is if the duplicated old and new data
> happens to be large. For a heat-specific example (one that is close to
> my heart), consider moving resource/event properties data into a
> separate table.
> 
> We could speed up the process by adding config variables that specify
> where to read from, but that is putting a burden on the operator,
> creating a risk that data is lost if the config variables are not
> updated in the correct order after each full rolling restart, etc.
> 
> Which brings us back to triggers. AFAIK, only sqlalchemy+mariadb is
> being used in production, so we really only have one backend we would
> have to write triggers for. If the data duplication is too unpalatable
> for a given migration (using the +1, +2, +3 pattern above), we may
> have to wade into the less simple world of triggers.
> 
> I think we can only enable the trigger during the upgrade process and
> then disable it.
>

More research required. :-) I just hope it does not put too much of a
burden on operators.

> 
> For RPC changes, we don't have a great solution right now (looking
> specifically at heat/engine/service.py). If we add a field, an older
> running heat-engine will break if it receives a request from a newer
> running heat-engine. For a relevant example, consider adding the
> "root_id" as an argument (
> https://review.openstack.org/#/c/354621/13/heat/engine/service.py
>  ).
> 
> Looking for the simplest solution -- if we introduce a mandatory
> "future_args" arg (a dict) now to all rpc methods (perhaps provide a
> decorator to do so), then we could follow this pattern post-Ocata:
> 
> legacy release: accepts the future_args param (but does nothing with
> it).
> release+1: accept the new parameter with a default of None,
>pass the value of the new parameter in future_args.
> release+2: accept the new parameter, pass the value of the new parameter
>in its proper placeholder, no longer in future_args.
> 
> This is something similar to the one is being used by neutron for the
> agents,
> i.e consistently capturing those new/unknown arguments with keyword
> arguments
> and ignoring them on agent side; and by not enforcing newer RPC entry point
> versions on server side. However,  this makes the rpc api less strict
> and not ideal.
> 

I'm not sure what the definition of ideal is here. But, full disclaimer
is that I've thought about RPC a lot less than the DB side. :-)

FWIW, we might as well be explicit in stating that we only expect two
minor versions to be running at once (during a rolling upgrade). That is
a simpler problem than having to support N minor versions.

> The 

[openstack-dev] FW: Your draft logo & sneak peek

[Steven Dake (stdake)]

Folks,

Inline is the draft logo of the Kolla mascot and logo.  We will be getting 
various types of swag at the first PTG related to our mascot.  The deadline for 
feedback is November 11th, 2016.  See the email inside from Heidi for more 
information on our project mascots.

Super exciting!

Regards
-steve


From: Heidi Joy Tretheway 
>
Date: Friday, October 21, 2016 at 7:16 PM
To: Steven Dake >
Subject: Your draft logo & sneak peek

Hi Steven,

We're excited to show you the draft version of your project logo, attached. We 
want to give you and your team a chance to see the mascot illustrations before 
we make them official, so we decided to make Barcelona the draft target, with 
final logos ready by the Project Team Gathering in Atlanta in February.

Our illustrators worked as fast as possible to draft nearly 60 logos, and we're 
thrilled to see how they work as a family. Here's a 50-second "sneak peek" at 
how they came together: https://youtu.be/JmMTCWyY8Y4

We welcome you to share this logo with your team and discuss it in Barcelona. 
We're very happy to take feedback on it if we've missed the mark. The style of 
the logos is consistent across projects, and we did our best to incorporate any 
special requests, such as an element of an animal that is especially important, 
or a reference to an old logo.



We ask that you don't start using this logo now since it's a draft. Here's what 
you can expect for the final product:

  *   A horizontal version of the logo, including your mascot, project name and 
the words "An OpenStack Community project"
  *   A square(ish) version of the logo, including all of the above
  *   A mascot-only version of the logo
  *   Stickers for all project teams distributed at the PTG
  *   One piece of swag that incorporates all project mascots, such as a deck 
of playing cards, distributed at the PTG
  *   All digital files will be available through the website

We know this is a busy time for you, so to take some of the burden of 
coordinating feedback off you, we made a feedback form: 
http://tinyurl.com/OSmascot  You are also welcome to reach out to Heidi Joy 
directly with questions or concerns. Please provide feedback by Friday, Nov. 
11, so that we can request revisions from the illustrators if needed. Or, if 
this logo looks great, just reply to this email and you don't need to take any 
further action.

Thank you!
Heidi Joy Tretheway - project lead
Todd Morey - creative lead

P.S. Here's an email that you can copy/paste to send to your team (remember to 
attach your logo from my email):

Hi team,
I just received a draft version of our project logo, using the mascot we 
selected together. A final version (and some cool swag) will be ready for us 
before the Project Team Gathering in February. Before they make our logo final, 
they want to be sure we're happy with our mascot.

We can discuss any concerns in Barcelona and you can also provide direct 
feedback to the designers: http://tinyurl.com/OSmascot  Logo feedback is due 
Friday, Nov. 11. To get a sense of how ours stacks up to others, check out this 
sneak preview of several dozen draft logos from our community: 
https://youtu.be/JmMTCWyY8Y4


[photo]
Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | Skype: 
heidi.tretheway
[https://s3.amazonaws.com/images.wisestamp.com/icons_32/linkedin.png]
 [https://s3.amazonaws.com/images.wisestamp.com/icons_32/twitter.png] 
  
[https://s3.amazonaws.com/ucwebapp.wisestamp.com/5dafe09f-4769-4e67-8016-7a75904bb079/OpenStackicon.format_png.resize_32x32.png]
 


[cid:472D98FC-AE1F-44D2-BCBC-78723140CD99]

__
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] [QA] Draft logo for OpenStack QA project

[Omichi, Kenichi]

Hi QA team,

I just received a draft version of our project logo, please find it which is 
attached in this mail.
A final version (and some cool swag) will be ready for us before the Project 
Team Gathering in February.
Before they make our logo final, they want to be sure we're happy with our 
mascot.

We can discuss any concerns in Barcelona and you can also provide direct 
feedback to the designers: http://tinyurl.com/OSmascot  Logo feedback is due 
Friday, Nov. 11. To get a sense of how ours stacks up to others, check out this 
sneak preview of several dozen draft logos from our community: 
https://youtu.be/JmMTCWyY8Y4

Thanks
Ken Ohmichi



From: Kenichi Oomichi [mailto:ken-oomi...@wx.jp.nec.com]
Sent: Friday, October 21, 2016 10:20 AM
To: Omichi, Kenichi 
Subject: FW: Your draft logo & sneak peek



差出人: Heidi Joy Tretheway
宛先: Oomichi Kenichi
件名: Your draft logo & sneak peek
Hi Ken’ichi,

We're excited to show you the draft version of your project logo, attached. We 
want to give you and your team a chance to see the mascot illustrations before 
we make them official, so we decided to make Barcelona the draft target, with 
final logos ready by the Project Team Gathering in Atlanta in February.

Our illustrators worked as fast as possible to draft nearly 60 logos, and we're 
thrilled to see how they work as a family. Here's a 50-second "sneak peek" at 
how they came together: https://youtu.be/JmMTCWyY8Y4

We welcome you to share this logo with your team and discuss it in Barcelona. 
We're very happy to take feedback on it if we've missed the mark. The style of 
the logos is consistent across projects, and we did our best to incorporate any 
special requests, such as an element of an animal that is especially important, 
or a reference to an old logo.

We ask that you don't start using this logo now since it's a draft. Here's what 
you can expect for the final product:

  *   A horizontal version of the logo, including your mascot, project name and 
the words "An OpenStack Community project"
  *   A square(ish) version of the logo, including all of the above
  *   A mascot-only version of the logo
  *   Stickers for all project teams distributed at the PTG
  *   One piece of swag that incorporates all project mascots, such as a deck 
of playing cards, distributed at the PTG
  *   All digital files will be available through the website

We know this is a busy time for you, so to take some of the burden of 
coordinating feedback off you, we made a feedback form: 
http://tinyurl.com/OSmascot  You are also welcome to reach out to Heidi Joy 
directly with questions or concerns. Please provide feedback by Friday, Nov. 
11, so that we can request revisions from the illustrators if needed. Or, if 
this logo looks great, just reply to this email and you don't need to take any 
further action.

Thank you!
Heidi Joy Tretheway - project lead
Todd Morey - creative lead

[photo]

Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | Skype: 
heidi.tretheway
[https://s3.amazonaws.com/images.wisestamp.com/icons_32/linkedin.png]
 [https://s3.amazonaws.com/images.wisestamp.com/icons_32/twitter.png] 
  
[https://s3.amazonaws.com/ucwebapp.wisestamp.com/5dafe09f-4769-4e67-8016-7a75904bb079/OpenStackicon.format_png.resize_32x32.png]
 

[cid:image001.png@01D22B85.87435FB0]


__
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] [tripleo] Demo: Deploying OpenStack using TripleO UI

[Ana Krivokapic]

I'd like to share a demo video of the current state of TripleO UI:

https://www.youtube.com/watch?v=01yta_1FKaQ

P.S. Please note that some of the validations are failing due to physical
limitations (low disk space, etc) of the virtual test setup I used to make
this video.

-- 
Regards,
Ana Krivokapic
Senior Software Engineer
OpenStack team
Red Hat 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

[openstack-dev] [DefCore][Interop] Fall 2016 OpenStack Interoperability Issues Report

[Egle Sigler]

Hello Everyone,

The DefCore Committee has been working to provide a periodic report on a
tractable, small number of major barriers we have uncovered during the
course of work to the community that we wish to focus
attention on.  The report is intended to be constructive rather than
critical, and assist the community in recognizing barriers to
interoperability so that they can be addressed.

The full report is available here:
https://github.com/openstack/defcore/blob/master/doc/source/periodic_report
s/fall_2016.rst

Our first report covers the following issues:
* Issue 1: Testing Interoperability
https://github.com/openstack/defcore/blob/master/doc/source/periodic_report
s/fall_2016.rst#issue-1-testing-interoperability
* Issue 2: Varying Models for API Evolution
https://github.com/openstack/defcore/blob/master/doc/source/periodic_report
s/fall_2016.rst#issue-2-varying-models-for-api-evolution
* Issue 3: External Network Connectivity
https://github.com/openstack/defcore/blob/master/doc/source/periodic_report
s/fall_2016.rst#issue-3-external-network-connectivity
* Issue 4: API and Policy Discoverability
https://github.com/openstack/defcore/blob/master/doc/source/periodic_report
s/fall_2016.rst#issue-4-api-and-policy-discoverability
* Issue 5: Lack of Clarity on DefCore's Purpose and Abilities
https://github.com/openstack/defcore/blob/master/doc/source/periodic_report
s/fall_2016.rst#issue-5-lack-of-clarity-on-defcore-s-purpose-and-abilities


Please let us know if you have any questions about the report.

If you are attending OpenStack Summit in Barcelona, please join us for
DefCore and RefStack sessions:

* Interop (DefCore) Working Group Work Session: Tuesday, October 25,
2:15pm-2:55pm, AC Hotel - P14 - Pedralbes,
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/1679
8
* OpenStack Interoperability Challenge: Running Unmodified Apps in Any
OpenStack Cloud, Wednesday, October 26, 9:25am-9:35am, Keynote stage,
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/1736
2
* RefStack Work Sessions  Wednesday, Octover 26, 5:05 - 5:45 pm, 5:55 -
6:35 pm,  AC Hotel - P3 - Gràcia ,
https://etherpad.openstack.org/p/refstack-ocata-summit
* Interop? You Keep Using That Word, I Do Not Think It Means What You
Think It Means. Thursday, October 27, 9:50am-10:30am, CCIB - Centre de
Convencions Internacional de Barcelona - P1 - Room 117,
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/1633
9
* Beyond Refstack: The Interop Challenge. Thursday, October 27,
11:00am-11:40am, Hilton Diagonal Mar - P0 - Ballroom A.
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/1641
2
* Heat: Work Session (DefCore related) Friday, October 28,
11:00am-11:40am, AC Hotel - P3 - Gràcia,
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/1706
3

Thank you,
Egle Sigler








__
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] [glance] draft logo of glance mascot

[Brian Rosmaita]

Hello Glancers,

Heidi Joy Tretheway and Todd Morey from the foundation have sent us the
attached sneak preview of the Glance mascot/logo.  (As you may recall, we
voted for a chipmunk [0].)

They've set up a handy form [1] so that you can provide individual
feedback.  The project logos will be finalized in time for the February
PTG, so please provide any feedback before Friday, November 11.

Before providing feedback, you might want to take a look at a short
(50-second) video [2] to see how the logos developed and how they present
a consistent interface across OpenStack projects.

Since we're looking at light turnout for the Barcelona summit, I've put
discussion of the logo on the agenda for the November 3 edition of the
Glance weekly meeting [3].

Keep in mind that the logo is still a draft, so please don't tweet it or
use it in any promotional materials.

cheers,
brian

[0] https://etherpad.openstack.org/p/glance-project-mascot
[1] http://tinyurl.com/OSmascot
[2] https://youtu.be/JmMTCWyY8Y4
[3] https://etherpad.openstack.org/p/glance-team-meeting-agenda

__
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] [QA][os-faults] OpenStack destructive and reliability testing announcement

[Ilya Shakhat]

Hello,

A while ago we've introduced a new library called os-faults [1]. The main
purpose of the library is to provide a unified API to perform different
destructive actions in OpenStack cloud. The library can do service-related
operations (e.g. kill particular service) and node-related (e.g. switch
power off). The library have been already used in reliability testing [2]
and is used in a new project called stepler [3].

If you are interested in reliability and destructive testing of OpenStack
welcome to our design session at the summit, 10/27 (Thurs) 11:00 - 11:40.

More information on the topic:
 * official docs - http://os-faults.readthedocs.io/
 * os-faults intro - https://youtu.be/tawwDFWZL80
 * reliability testing - https://youtu.be/9puoDd14IxU

Thanks,
Ilya

[1] https://github.com/openstack/os-faults
[2]
http://docs.openstack.org/developer/performance-docs/test_results/reliability/version_2/index.html
[3] https://github.com/Mirantis/stepler
__
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][Design Session] Where to propose extensions to trusts?

[Johannes Grassler]

Hello,

On 10/21/2016 03:07 PM, Steve Martinelli wrote:

On Fri, Oct 21, 2016 at 5:01 AM, Johannes Grassler 
wrote:

I've got a last minute proposal, or rather two of them for the Keystone
side of the design sessions in Barcelona.

[...]

The Authorization work session is more than appropriate, please go ahead
and add the items to the etherpad.


Ok, will do. Thank you!


Do try to be there in person, it'll make  things easier. If you can't make
the session then you can always pop into another keystone session or lurk
around until the end of one where we can talk.


I'll try to make the Authorization session. I think I can find an arrangement
for the Barbican session.

Cheers,

Johannes

--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany

__
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] [manila][share-migration] query about host-assisted migration

[Wang, Peter (Xu)]

jiang




--

Message: 3
Date: Fri, 21 Oct 2016 03:20:01 +
From: "Kruithof Jr, Pieter" <pieter.kruithof...@intel.com>
To: "openstack-dev@lists.openstack.org"
<openstack-dev@lists.openstack.org>
Cc: "openstack-operat...@lists.openstack.org"
<openstack-operat...@lists.openstack.org>,
"user-commit...@lists.openstack.org"
<user-commit...@lists.openstack.org>
Subject: [openstack-dev] Participate in a Usability Study at
Barcelona: Get a free bluetooth speaker and OpenStack t-shirt for your
time
Message-ID: <60ff081c-dbd5-49a7-b624-b2f7583e6...@intel.com>
Content-Type: text/plain; charset="utf-8"

Apologies for any cross-postings.


Hi Folks,

I wanted to send a second notice that there will be two usability studies being 
conducted in Barcelona with cloud operators. We had nearly a 100% show rate 
last summit and the results had a direct impact on the OpenStackClient.  In 
fact, the results were shared at the OSC working session the next day.

Intel is providing a Philips bluetooth speaker to show our appreciation for 
your time.  In addition, the foundation is providing a t-shirt to each person 
that participates in the study. I may even give anyone suffering from jetlag a 
Red Bull to get them through the day.

___
The first study will be on Monday, October 24th and is intended to investigate 
the current APIs to understand any specific pain points associated with 
completing tasks that span projects such as quotas.  This study will last 45 
minutes per operator.

You can schedule a time here:

http://doodle.com/poll/fwfi2sfcuctxv3u8

Note that you may need to set the time zone in Doodle to Spain > Ceuta

___
The second study will be on Tuesday, October 25th and is intended to 
investigate the OpenStackClient to understand any specific pain points and 
opportunities associated with completing tasks with the client.  This study 
will last 45 minutes per operator.  We ran a similar study at the previous 
summit and the feedback from users was that it was a good opportunity to ?test 
drive? the client with an OSC expert in the room with them.

You can schedule a time here:

http://doodle.com/poll/894aqsmheaa2mv5a

Note that you may need to set the time zone in Doodle to Spain > Ceuta


For both studies, someone with the OpenStack UX project will send you a 
calendar invite after you select a time(s) that are convenient for you.


Thanks,


Piet Kruithof
PTL OpenStack UX

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/0de6e75e/attachment-0001.html>

--

Message: 4
Date: Fri, 21 Oct 2016 03:20:30 +
From: "Kruithof Jr, Pieter" <pieter.kruithof...@intel.com>
To: "openstack-dev@lists.openstack.org"
<openstack-dev@lists.openstack.org>,
"openstack-operat...@lists.openstack.org"
<openstack-operat...@lists.openstack.org>
Subject: [openstack-dev] What do customers want?: Six studies
conducted by the OpenStack UX project on behalf of the community
Message-ID: <e0da5ca7-83e2-44b9-875d-7a6296614...@intel.com>
Content-Type: text/plain; charset="utf-8"

Hi Folks,

The OpenStack UX project and Intel have produced three booklets for the 
Barcelona OpenStack Summit based on the OpenStack UX?s work over the past six 
months.

The first is an overview of user research that was conducted on behalf of the 
OpenStack community including operator information needs, novice user 
experience for Horizon, OpenStackClient (OSC) validation and managing quotas at 
scale.

https://drive.google.com/file/d/0B8h-c0zHxYBoXzFMQWJsY09Eclk/view?usp=sharing

The second booklets include the OpenStack Personas and GUI Guidelines:

OpenStack Personas:
https://drive.google.com/file/d/0B8h-c0zHxYBoMXB4UVgtdFFsaDQ/view?usp=sharing

OpenStack GUI Guidelines:
https://drive.google.com/file/d/0B8h-c0zHxYBoV0tHV1l5bVpZZzg/view?usp=sharing


___
Unfortunately, we were unable to include the results for the 
searchlight/horizon integration as well as cloud architect information needs.  
However, the presentations are posted to the OpenStack UX YouTube channel.

https://www.youtube.com/channel/UCt6h129lzcjUqLDY005aCxw

The channel is updated regularly, so it may be worth checking from time to time.


___
For extra credit, my suggestion would be to read the ?State of OpenStack User 
Experience October 2016? which provides a succinct overview of the research 
that was conducted, why it matters, results, and recommendations.

https://docs.google.com/presentation/d/1hZYCOADJ1gXiFHT1ahwv8-tDIQCSingu7zqSMbKFZ_Y/edit?usp=sharing



Thanks,

Piet Kruithof
PTL OpenStack UX project
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lis

[openstack-dev] [Fuel][Plugin]Add multiple backends support

[Wang, Peter (Xu)]

Message: 3
Date: Fri, 21 Oct 2016 03:20:01 +
From: "Kruithof Jr, Pieter" <pieter.kruithof...@intel.com>
To: "openstack-dev@lists.openstack.org"
<openstack-dev@lists.openstack.org>
Cc: "openstack-operat...@lists.openstack.org"
<openstack-operat...@lists.openstack.org>,
"user-commit...@lists.openstack.org"
<user-commit...@lists.openstack.org>
Subject: [openstack-dev] Participate in a Usability Study at
Barcelona: Get a free bluetooth speaker and OpenStack t-shirt for your
time
Message-ID: <60ff081c-dbd5-49a7-b624-b2f7583e6...@intel.com>
Content-Type: text/plain; charset="utf-8"

Apologies for any cross-postings.


Hi Folks,

I wanted to send a second notice that there will be two usability studies being 
conducted in Barcelona with cloud operators. We had nearly a 100% show rate 
last summit and the results had a direct impact on the OpenStackClient.  In 
fact, the results were shared at the OSC working session the next day.

Intel is providing a Philips bluetooth speaker to show our appreciation for 
your time.  In addition, the foundation is providing a t-shirt to each person 
that participates in the study. I may even give anyone suffering from jetlag a 
Red Bull to get them through the day.

___
The first study will be on Monday, October 24th and is intended to investigate 
the current APIs to understand any specific pain points associated with 
completing tasks that span projects such as quotas.  This study will last 45 
minutes per operator.

You can schedule a time here:

http://doodle.com/poll/fwfi2sfcuctxv3u8

Note that you may need to set the time zone in Doodle to Spain > Ceuta

___
The second study will be on Tuesday, October 25th and is intended to 
investigate the OpenStackClient to understand any specific pain points and 
opportunities associated with completing tasks with the client.  This study 
will last 45 minutes per operator.  We ran a similar study at the previous 
summit and the feedback from users was that it was a good opportunity to ?test 
drive? the client with an OSC expert in the room with them.

You can schedule a time here:

http://doodle.com/poll/894aqsmheaa2mv5a

Note that you may need to set the time zone in Doodle to Spain > Ceuta


For both studies, someone with the OpenStack UX project will send you a 
calendar invite after you select a time(s) that are convenient for you.


Thanks,


Piet Kruithof
PTL OpenStack UX

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20161021/0de6e75e/attachment-0001.html>

--

Message: 4
Date: Fri, 21 Oct 2016 03:20:30 +
From: "Kruithof Jr, Pieter" <pieter.kruithof...@intel.com>
To: "openstack-dev@lists.openstack.org"
<openstack-dev@lists.openstack.org>,
"openstack-operat...@lists.openstack.org"
<openstack-operat...@lists.openstack.org>
Subject: [openstack-dev] What do customers want?: Six studies
conducted by the OpenStack UX project on behalf of the community
Message-ID: <e0da5ca7-83e2-44b9-875d-7a6296614...@intel.com>
Content-Type: text/plain; charset="utf-8"

Hi Folks,

The OpenStack UX project and Intel have produced three booklets for the 
Barcelona OpenStack Summit based on the OpenStack UX?s work over the past six 
months.

The first is an overview of user research that was conducted on behalf of the 
OpenStack community including operator information needs, novice user 
experience for Horizon, OpenStackClient (OSC) validation and managing quotas at 
scale.

https://drive.google.com/file/d/0B8h-c0zHxYBoXzFMQWJsY09Eclk/view?usp=sharing

The second booklets include the OpenStack Personas and GUI Guidelines:

OpenStack Personas:
https://drive.google.com/file/d/0B8h-c0zHxYBoMXB4UVgtdFFsaDQ/view?usp=sharing

OpenStack GUI Guidelines:
https://drive.google.com/file/d/0B8h-c0zHxYBoV0tHV1l5bVpZZzg/view?usp=sharing


___
Unfortunately, we were unable to include the results for the 
searchlight/horizon integration as well as cloud architect information needs.  
However, the presentations are posted to the OpenStack UX YouTube channel.

https://www.youtube.com/channel/UCt6h129lzcjUqLDY005aCxw

The channel is updated regularly, so it may be worth checking from time to time.


___
For extra credit, my suggestion would be to read the ?State of OpenStack User 
Experience October 2016? which provides a succinct overview of the research 
that was conducted, why it matters, results, and recommendations.

https://docs.google.com/presentation/d/1hZYCOADJ1gXiFHT1ahwv8-tDIQCSingu7zqSMbKFZ_Y/edit?usp=sharing



Thanks,

Piet Kruithof
PTL OpenStack UX project
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openstack.org/pipermail/openstack-dev/

Re: [openstack-dev] [new][meteos] New project: Meteos

[Jeremy Stanley]

On 2016-10-21 02:21:00 + (+), Hiroyuki Eguchi wrote:
[...]
> The goal of this project is to be a Big Tent project.
> 
> For that, I plan to release the initial version in github by end
> of this year.
[...]
> Everyone can participate in this project as a user, developer,
> reviewer in the same way as another OpenStack projects.
[...]

OpenStack projects aren't developed on Github, only mirrored to it.
I recommend reviewing http://docs.openstack.org/project-team-guide/
and http://docs.openstack.org/infra/manual/ for more information on
how our developer community operates.

Thanks for wanting to get involved in OpenStack!
-- 
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] [Keystone][Design Session] Where to propose extensions to trusts?

[Steve Martinelli]

On Fri, Oct 21, 2016 at 5:01 AM, Johannes Grassler 
wrote:

> Hello,
>
> I've got a last minute proposal, or rather two of them for the Keystone
> side of
> the design sessions in Barcelona. I guess it's something that would fit the
> Authorization work session on Friday (09:00-09:40) but I'm not sure I can
> simply add it on the Etherpad. Also, I may not able to attend the session
> in
>

The Authorization work session is more than appropriate, please go ahead
and add the items to the etherpad. Do try to be there in person, it'll make
things easier. If you can't make the session then you can always pop into
another keystone session or lurk around until the end of one where we can
talk.


> person since I'll need to join the Barbican session in the same time slot
> as
> well[0], so I'd appreciate an alternative venue if that's possible.

Hence I'll put them forth here for now:
>
> 1. Scope extensions for trusts
> ==
>
> Various services (Magnum, Heat, maybe Neutron LBaaS soon) use Keystone
> trusts to
> grant their service users or dedicated trustee users limited rights for
> various
> purposes, such as deferred operations on behalf of the user or providing
> access to
> certificate containers. These trusts can only be limited to a set of roles
> in a
> given project right now. The Admin guide mentions an endpoint limitation
> on top of
> that, but I haven't found any code in Keystone for handling that. I played
> with it
> a bit and found that every keyword argument Keystone doesn't know what to
> do
> with ends up in the trust table's `extra` column, but there's no code for
> doing
> anything with it as far as I can tell. It would be a useful thing, though
> and
> implementing it goes hand in hand with my proposal: I'd like to see an
> ability
> to scope trusts to:
>
>   1) A subset of endpoints (i.e. "This trust may only access Barbican's
> internalURL and nothing else")
>   2) A fixed path (i.e. "This trust may only access
> /v1/secrets/238ca94d-6115-4fe6-b41f-c445eeb47df8)
>   3) A fixed URL (i.e. "This trust may only access
>  http://192.168.123.20:9311/v1/secrets/238ca94d-6115-4fe6-
> b41f-c445eeb47df8)
>
> The main thing I'm currently interested in is whether this is feasible. If
> so,
> I'd be happy to work on a blueprint and implementation. I believe this is
> really important to allow services and users to limit trusts to exactly the
> access level needed and not a bit more.
>
>
> 2. Lightweight trusts
> =
>
> When Keystone trusts are created the current practice is to either
>
>   1) Delegate the trust to a service user using the trust (example: Heat)
>   2) Create a dedicated trustee user for delegating the trust to (example:
>  Magnum)
>
> (1) is fine as far as I'm concerned, but I think (2) could do with some
> improvement. The dedicated trustee user will have a user name and password
> that
> needs to be used to authenticate as that user (along with a trust ID to
> consume
> the trust). I'd rather see a long-lived trust token scoped to the trust
> that
> can be extended upon expiry for that purpose. Just like a regular token, in
> other words. For the following reasons:
>
>   1) Everybody who creates such a user will have different idea of a secure
>  password length. A token is generated by keystone in a centralized
> manner
>  and always of a sufficient length to make for a secure secret.
>   2) It requires third party software that may need to authenticate as the
>  trustee to be aware of trusts. Example: Kubernetes' Cinder volume
> driver
>  (used by Magnum). Most such software should be able to handle an auth
>  token, on the other hand.
>   3) There is less cleanup required after the trust has served its purpose:
>  only the trust needs to be deleted at that point, but no trustee user.
>
> Comments on these two proposals (and advice on a suitable forum for
> discussing
> them at the summit) would be greatly appreciated. Thank you!
>
> Cheers,
>
> Johannes
>
>
> Footnotes:
>
> [0] In a pinch I could probably ask a colleague to stand in for me, but I'd
> prefer a solution where I can be present for both discussions.
>
> --
> Johannes Grassler, Cloud Developer
> SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> Maxfeldstr. 5, 90409 Nürnberg, Germany
>
> __
> 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] [heat] Rolling Upgrades

[Michał Dulko]

On 10/21/2016 02:02 AM, Crag Wolfe wrote:
> At Summit, folks will be discussing the rolling upgrade issue across a
> couple of sessions. I personally won't be able to attend, but thought
> I would share my thoughts on the subject.
>
> To handle rolling upgrades, there are two general cases to consider:
> database model changes and RPC method signature changes.
>
> For DB Model changes (this has already been well discussed on the
> mailing list, see the footnotes), let's assume for the moment we don't
> want to use triggers. If we are moving data from one column/table to
> another, the pattern looks like:
>
> legacy release: write to old location
> release+1: write to old and new location, read from old
> release+2: write to old and new location, read from new,
>provide migration utility
> release+3: write to new location, read from new
>
> Works great! The main issue is if the duplicated old and new data
> happens to be large. For a heat-specific example (one that is close to
> my heart), consider moving resource/event properties data into a
> separate table.
>
> We could speed up the process by adding config variables that specify
> where to read from, but that is putting a burden on the operator,
> creating a risk that data is lost if the config variables are not
> updated in the correct order after each full rolling restart, etc.
>
> Which brings us back to triggers. AFAIK, only sqlalchemy+mariadb is
> being used in production, so we really only have one backend we would
> have to write triggers for. If the data duplication is too unpalatable
> for a given migration (using the +1, +2, +3 pattern above), we may
> have to wade into the less simple world of triggers.

I just wanted to remind that Heat has unit test [2] which is blocking
contracting DB migrations.

> For RPC changes, we don't have a great solution right now (looking
> specifically at heat/engine/service.py). If we add a field, an older
> running heat-engine will break if it receives a request from a newer
> running heat-engine. For a relevant example, consider adding the
> "root_id" as an argument (
> https://review.openstack.org/#/c/354621/13/heat/engine/service.py ).
>
> Looking for the simplest solution -- if we introduce a mandatory
> "future_args" arg (a dict) now to all rpc methods (perhaps provide a
> decorator to do so), then we could follow this pattern post-Ocata:
>
> legacy release: accepts the future_args param (but does nothing with it).
> release+1: accept the new parameter with a default of None,
>pass the value of the new parameter in future_args.
> release+2: accept the new parameter, pass the value of the new parameter
>in its proper placeholder, no longer in future_args.
>
> But, we don't have a way of deleting args. That's not super
> awful... old args never die, they just eventually get ignored. As for
> adding new api's, the pattern would be to add them in release+1, but
> not call them until release+2. [If we really have a case where we need
> to add and use a new api in release+1, the solution may be to have two
> rpc api messaging targets in release+1, one for the previous
> major.minor release and another for the major+1.0 release that has the
> new api. Then, we of course we could remove outdated args in
> major+1.0.]

Another solution is adopting Nova's and Cinder's way. You need some kind
of RPC version reporting and detection framework. In Cinder it's
reported into `services` table [1], and supported RPC API version is
detected [2] based on that data. Then requests are backported into
required version on RPC client level (e.g. [3]).

> Finally, a note about Oslo versioned objects: they don't really help
> us. They work great for nova where there is just nova-conductor
> reading and writing to the DB, but we have multiple heat-engines doing
> that that need to be restarted in a rolling manner. See the references
> below for greater detail.

They do help in case you're changing RPC arguments *content*. In
particular they make it easier to modify schema of dict-like structures
sent over RPC.

> --Crag
>
> References
> --
>
> [openstack-dev] [Heat] Versioned objects upgrade patterns
> http://lists.openstack.org/pipermail/openstack-dev/2016-May/thread.html#95245
>
> [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades:
> database triggers and oslo.versionedobjects
> http://lists.openstack.org/pipermail/openstack-dev/2016-September/102698.html
> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105764.html

[1] 
https://github.com/openstack/heat/blob/master/heat/tests/db/test_migrations.py#L114-L137
[2] 
https://github.com/openstack/cinder/blob/325f99a64aeb3e7a768904781d854c19bb540580/cinder/db/sqlalchemy/models.py#L86-L89
[3] 
https://github.com/openstack/cinder/blob/8a4aecb155478e9493f4d36b080ccdf6be406eba/cinder/rpc.py#L208-L224
[4] 

Re: [openstack-dev] [ironic] [API] Evolving our REST API

[Everett Toews]

On Oct 13, 2016, at 10:00 AM, Devananda van der Veen  
wrote:
> 
> So I have finalized five proposals of substantial changes we can make, that
> folks agreed were important to work on, and which I believe we can do within 
> the
> microversion framework starting immediately. Four of them will, I think, be
> fairly straight forward. The fifth, adding a /tasks/ resource, has the most
> challenges, and its own session planned.

I just want to point out some prior art for a tasks resource [1] in Glance. It 
might help inform your discussion a bit. I can understand how it will be 
challenging. If an API guideline for tasks eventually came out as a result of 
this discussion, it would reduce the challenges for future projects. ;)

Cheers,
Everett

[1] http://developer.openstack.org/api-ref/image/v2/#tasks


__
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][ironic][puppet] Spine/Leaf: Adding Multiple Subnets to ironic-inspector-dnsmasq

[Miles Gould]

On 19/10/16 18:33, Dan Sneddon wrote:

I am doing research to support the spec for TripleO deployment on
routed networks [1]. I would like some input on how to represent
multiple subnet ranges for the provisioning network in undercloud.conf.

[snip]

## inspector_dnsmasq_tftp.erb ##
port=0
interface=<%= @dnsmasq_interface %>
bind-interfaces
dhcp-range=<%= @dnsmasq_ip_range %>,29
dhcp-boot=pxelinux.0,localhost.localdomain,<%= @dnsmasq_local_ip %>
dhcp-sequential-ip



Just to note, there's no problem with this at the dnsmasq level: you can 
specify as many dhcp-range options as you like, one per IP range. 
There's no need to break the configuration up into multiple files to 
support this.



We could potentially represent this data as a JSON, or as a list of
strings.


I vote for JSON (or maybe YAML?) over creating our own ad-hoc string format.


String:
additional_inspection_ipranges =
"172.20.1.0,172.20.1.100,172.20.1.120,255.255.255.0,172.20.1.254;172.20.2.0,172.20.2.100,172.20.2.120,255.255.255.0,172.20.2.254"


If we're creating a string format, the obvious approach is to re-use the 
one dnsmasq uses, which is


[,|][,[,]][,]

If the DHCP server is directly connected to a given network, it can 
deduce the netmask by querying the interface configuration.


OTOH,

 - that doesn't specify gateway
 - I don't like the idea of directly pasting structured strings into 
configuration files without validating their structure, and the 
temptation to do that would be great.


Miles

__
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] [api] [nova] microversion edge case query

[Chris Dent]

On Fri, 21 Oct 2016, Alex Xu wrote:


Also think 404 is right at here. If you return 406 and it is a signal that
if you used a different microversion the situation could be different, the
thing will become strange when we raise the acceptable min_version someday.


Thanks, yeah, what you and Ed have said has been convincing, I've
updated the code at: https://review.openstack.org/#/c/388115/

Jay's review of that has raised a new issue: which is should we even
bother with the decorator style?


--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
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] indoor climbing break at summit?

[Chris Dent]

On Tue, 18 Oct 2016, Miles Gould wrote:


Speaking of which: woo yeah! I'm totally up for this, schedule permitting.


The etherpad is gathering steam, on Monday I'll use the email
addresses on there and send out a plan, so anyone who wants to be
notified, look there, or just show up at the gym at the chosen time.

https://etherpad.openstack.org/p/ocata-climb

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
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] Endpoint structure: a free-for-all

[Doug Hellmann]

> On Oct 21, 2016, at 7:22 AM, Chris Dent  wrote:
> 
>> On Wed, 19 Oct 2016, Sean Dague wrote:
>> 
>> The reason we have volume, volumev2, and volumev3 is that no one actually 
>> wants the unversioned volume endpoint. You can't do anything with it. 
>> Everyone wants the actual endpoint that has resources.
> 
> That's right, they do want the endpoint that has the resources, but
> do they care about asking for a version? I'm not sure. I think they
> just want the thing that's going to work and the version is
> superfluous.
> 
>> We can solve this for all consumers by adding additional version field to 
>> the catalog. This was the direction we were headed last spring before the 
>> api-ref work took over.
> 
> I'd rather not see versions in the service catalog as a reified entity
> because it increases the surface area of an endpoint request. I don't
> want to have think which version I want. Or if I do, I want it to be
> built into the service type. We want the service type to be the
> entrypoint for endpoints...
> 
> In any case, just for reference, both the arch-wg and the api-wg
> have expressed a lot of concern about and interest in the service
> catalog (and the service authority idea that was bouncing around for
> a while too). So I agree with everyone else who is saying "yeah,
> it's time to make this better."

This is the sort of issue that would work well as a community-wide goal. If we 
get a group together to resolve some of the issues you list below, they can act 
as guides to steer the work and help teams with the transition. If we act 
quickly maybe we can make enough progress to do it for Pike. 

Doug

> 
> There are a lot of issues:
> 
> * how to deal with versions
> * auth handling at the top-level endpoint
> * service type value consistency amongst clouds
> * public, internal, admin, whatever endpoints (can we make it so
>  there is one and only one‽)
> * dynamic v static service catalogs in the face of different
>  contexts
> * whatever else I'm forgetting right now because the coffee is weak
>  but I'm sure someone else remembers
> 
> -- 
> Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> 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] Endpoint structure: a free-for-all

[Chris Dent]

On Wed, 19 Oct 2016, Sean Dague wrote:

The reason we have volume, volumev2, and volumev3 is that no one actually 
wants the unversioned volume endpoint. You can't do anything with it. 
Everyone wants the actual endpoint that has resources.


That's right, they do want the endpoint that has the resources, but
do they care about asking for a version? I'm not sure. I think they
just want the thing that's going to work and the version is
superfluous.

We can solve this for all consumers by adding additional version field to the 
catalog. This was the direction we were headed last spring before the api-ref 
work took over.


I'd rather not see versions in the service catalog as a reified entity
because it increases the surface area of an endpoint request. I don't
want to have think which version I want. Or if I do, I want it to be
built into the service type. We want the service type to be the
entrypoint for endpoints...

In any case, just for reference, both the arch-wg and the api-wg
have expressed a lot of concern about and interest in the service
catalog (and the service authority idea that was bouncing around for
a while too). So I agree with everyone else who is saying "yeah,
it's time to make this better."

There are a lot of issues:

* how to deal with versions
* auth handling at the top-level endpoint
* service type value consistency amongst clouds
* public, internal, admin, whatever endpoints (can we make it so
  there is one and only one‽)
* dynamic v static service catalogs in the face of different
  contexts
* whatever else I'm forgetting right now because the coffee is weak
  but I'm sure someone else remembers

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
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][cinder] Addressing mangled LUKS passphrases (bug#1633518)

[Lee Yarwood]

Hello,

I documented bug#1633518 [1] last week in which volumes encrypted prior
to Ib563b0ea [2] used a slightly mangled passphrase instead of the
original passphrase provided by the configured key manager.

My first attempt at resolving this [3] prompted an alternative
suggestion from mdbooth of adding the correct passphrase to the LUKS
device when we detect the use of a mangled passphrase.

I'm slightly wary of this option given the changing of passphrases so
I'd really appreciate input from the wider Nova and Cinder groups on
your preference for resolving this :

1. Keep the mangled passphrase in place and attempt to use it after
getting a permission denied error during luksOpen. 

2. Add the correct passphrase and remove the mangled passphrase from the
LUKS device with luksChangeKey when we detect the use of the mangled
passphrase.

3. An alternative suggestion.

FYI, as os-brick has now copied the encryptor classes from Nova into
their own tree any fix will be cherry-picked across shortly after
landing in Nova. I'm also looking into dropping these classes from Nova
for Ocata so we can avoid duplicating effort like this in future.

Thanks in advance,

Lee

[1] https://launchpad.net/bugs/1633518
[2] https://review.openstack.org/#/c/309614/
[3] https://review.openstack.org/#/c/386670/
-- 
Lee Yarwood
Senior Software Engineer
Red Hat

PGP : A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76

__
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] Does it make sense to have self links to things that don't exist?

[Chris Dent]

On Thu, 20 Oct 2016, Matt Riedemann wrote:

It's not convenient, IMO, to provide a link to something that doesn't exist. 
That's just frustrating from the API user point of view.


So is this fine?
Should it be implemented?
Or should the docs say, the link might not exist?
Or should the link to the non-existent handler just be removed?


If the discovery doc is for discovering stuff, it shouldn't list stuff
that doesn't exist. That's pretty simple and straightforward, right?
How could it be anything else?

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
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] Automation and self described APIs

[Gilles Dubreuil]

Ok, OpenStack ransom of success means the APIs request list is growing.
So what's the plan for self-described APIs?
Do we have a standardized solution exposing the requests' methods, 
parameters to other program to exploit?


Sure, some OpenStack APIs advertise their interface using GET method 
such as {"show api version", "/v1/"}.
Although consistent in the format but not available across all projects, 
it doesn't seem to be following a standard anyway, right?
Besides and more importantly it isn't suitable to fully expose the 
requests interfaces.


We know REST is not a standard in itself, but RESTful implementations 
make use of standards, such as HTTP, URI, JSON and XML [1]
This have brought an excellent candidate tailored for the job, the HTTP 
OPTION, please see RFC2616 [2] for more details.
Using such an approach would allow OpenStack APIs requests interfaces 
(methods, parameters and items) to be advertised to other programs.
By offering a new level of API automation, almost over are the days of 
tedious work for every OpenStack client of creating or adding every 
interface corresponding code and its test code.

The next generation of RESTful clients could get up to date automatically.

In the meantime that happens, the only comprehensive APIs reference 
source I've found is developer.openstack.org/api-ref.html 
 [2].

BTW, great work Oslo Sphinx team, thank you!
The API-ref allows most of APIs interfaces to be partly generated using 
web crawlers.
Unfortunately, there a still missing projects from the reference so the 
rest still has to be manually produced and for the one automatically 
generated there are various flaws which require manual intervention.


The flaws I've found:
- Missing requests from API ref: Only a few (example? Ironic: heartbeat  
POST, "/v1/heartbeat/{node_ident}")
- API Inconsistencies: For instance, the call a method for Node Vendor 
[3] or Driver Vendor [4] Passthru is the same, which create a conflict 
for REST Clients.


So again, the API-ref is great and allow to cover the requests list but 
that's not good enough for automation where the requests capabilities 
need to be advertised properly and comprehensively through a standard, 
such as the HTTP Option. Actually the API-ref could benefit from it too 
and consume the latter.


Cheers,
Gilles

PS: In an ideal world, the API is built first and the rest upon.

[1] https://en.wikipedia.org/wiki/Representational_state_transfer
[2] https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
[3] 
http://developer.openstack.org/api-ref/baremetal/?expanded=call-a-method-detail

[4] http://developer.openstack.org/api-ref/baremetal/?expanded=id73-detail

__
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-dev][Fuel][Plugin]

[Julia Aranovich]

Hi Nidhi,

This implemented https://blueprints.launchpad.net/fuel/+spec/dynamic-fields
blueprint provided an ability to use "text_list" and "textarea_list" UI
control types.
They are suitable for settings where the value is a list of strings.
These controls represent on UI a list of single or multiline text inputs
with +/- buttons to add/remove an additional element:

My Setting  value1 +/-
   value2 +/-
   value3 +/-
(the result value for the setting "My Setting" is ['value1', 'value2',
'value3']).


If I understand your case properly, you need something like dynamic groups
of inputs of different type.
This is still not supported by Fuel UI. The implementation does not look
simple, it requires changing of data structure in settings yaml, adding a
new level of nesting. There is a need to think thoroughly about the
details: how to organize such a setting yaml structure, how to declare a
set of inputs in such a group, how inputs should be aligned in the group
(horizontally/vertically), etc.

For now, I would suggest the following ways of how to organize your plugin
settings:

1) use text_list/textarea_list controls for each field from a group that
represents storage backend configuration:

Field1  value_for_backend_1 +/-
value_for_backend_2 +/-
value_for_backend_3 +/-

Field2  value_for_backend_1 +/-
value_for_backend_2 +/-
value_for_backend_3 +/-

Field3  value_for_backend_1 +/-
value_for_backend_2 +/-
value_for_backend_3 +/-

2) use text_list/textarea_list controls to configure a list of storage
backends by declaring their settings as a single comma-separated string:

Backends Settingscomma_separated_settings_for_backend_1 +/-
comma_separated_settings_for_backend_2 +/-
  comma_separated_settings_for_backend_3 +/-

>From my point of view, the first version looks more clear. Will it
suit your case, Nidhi?


Best regards,
Julia

On Fri, Oct 21, 2016 at 8:17 AM  wrote:

> Hi All,
>
>
> This is regarding an info required for fuel plugin development.
>
> We are working on Fuel Cinder Plugin where we require to
>
> configure multiple 'n' number of backends of storage vendor ,
>
> in one go, from Fuel UI screen. where 'n' will be known at run time.
>
>
> Its like from UI, I can configure a set of fields, [field1, field2,
> field3]
>
> for one backend and if user ask to configure 'n' backends then same
>
> set of fields to be asked repeatedly.
>
>
> I have found some similar provision was planned in
>
> https://blueprints.launchpad.net/fuel/+spec/dynamic-fields
>
>
> But when i see implementation
> https://review.openstack.org/#/q/topic:bp/dynamic-fields,n,z
>
> which implements new type as text_list and textarea_list ..
>
> which is capability to add multiple lines of text in single field..
>
>
> It does not look like same as aim of BP, where acceptance criteria for BP
> is
>
> "Enable text and textarea field types to be extended - where a plugin user
> is able to toggle the visibility of additional fields with +/- signs and
> the data provided is used by plugin"
>
>
> Kindly correct my understanding if its wrong, do we have capability to add
> a text field by pressing +/- ?
>
> What capability do we have with Fuel UI to add fields dynamically today ?
>
>
> I have read
> https://openstack.nimeyo.com/44264/openstack-dev-fuel-interaction-between-fuel-plugin-and-fuel
>
> [openstack-dev] [Fuel] interaction between fuel-plugin and fuel-UI -
> OpenStack Mailing List Archive
> 
> openstack.nimeyo.com
> Hi all, I am working on two plugins for fuel : logrotate and cinder-netapp
> (to add ... /lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> where suggestions are made to use restrictions to hide display components.
>
>
> Another suggestion is to use comma separated values.
>
>
> But its an year back post, do we have a better solution today ?
>
>
> Will be helpful if someone can suggest how do we achieve it in fuel UI.
>
>
>
> Thanks
>
> Nidhi
>
>
>
>
>
>
>
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
> __
> OpenStack Development 

[openstack-dev] [daisycloud-core] Meeting minutes for IRC meeting 0800UTC Oct. 21 2016

[hu . zhijiang]

Minutes:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.html
 

Minutes (text): 
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.txt
 

Log:
http://eavesdrop.openstack.org/meetings/daisycloud/2016/daisycloud.2016-10-21-07.59.log.html
 



B.R.,
Zhijiang


__
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] [Keystone][Design Session] Where to propose extensions to trusts?

[Johannes Grassler]

Hello,

I've got a last minute proposal, or rather two of them for the Keystone side of
the design sessions in Barcelona. I guess it's something that would fit the
Authorization work session on Friday (09:00-09:40) but I'm not sure I can
simply add it on the Etherpad. Also, I may not able to attend the session in
person since I'll need to join the Barbican session in the same time slot as
well[0], so I'd appreciate an alternative venue if that's possible.

Hence I'll put them forth here for now:

1. Scope extensions for trusts
==

Various services (Magnum, Heat, maybe Neutron LBaaS soon) use Keystone trusts to
grant their service users or dedicated trustee users limited rights for various
purposes, such as deferred operations on behalf of the user or providing access 
to
certificate containers. These trusts can only be limited to a set of roles in a
given project right now. The Admin guide mentions an endpoint limitation on top 
of
that, but I haven't found any code in Keystone for handling that. I played with 
it
a bit and found that every keyword argument Keystone doesn't know what to do
with ends up in the trust table's `extra` column, but there's no code for doing
anything with it as far as I can tell. It would be a useful thing, though and
implementing it goes hand in hand with my proposal: I'd like to see an ability
to scope trusts to:

  1) A subset of endpoints (i.e. "This trust may only access Barbican's internalURL 
and nothing else")
  2) A fixed path (i.e. "This trust may only access 
/v1/secrets/238ca94d-6115-4fe6-b41f-c445eeb47df8)
  3) A fixed URL (i.e. "This trust may only access
 http://192.168.123.20:9311/v1/secrets/238ca94d-6115-4fe6-b41f-c445eeb47df8)

The main thing I'm currently interested in is whether this is feasible. If so,
I'd be happy to work on a blueprint and implementation. I believe this is
really important to allow services and users to limit trusts to exactly the
access level needed and not a bit more.


2. Lightweight trusts
=

When Keystone trusts are created the current practice is to either

  1) Delegate the trust to a service user using the trust (example: Heat)
  2) Create a dedicated trustee user for delegating the trust to (example:
 Magnum)

(1) is fine as far as I'm concerned, but I think (2) could do with some
improvement. The dedicated trustee user will have a user name and password that
needs to be used to authenticate as that user (along with a trust ID to consume
the trust). I'd rather see a long-lived trust token scoped to the trust that
can be extended upon expiry for that purpose. Just like a regular token, in
other words. For the following reasons:

  1) Everybody who creates such a user will have different idea of a secure
 password length. A token is generated by keystone in a centralized manner
 and always of a sufficient length to make for a secure secret.
  2) It requires third party software that may need to authenticate as the
 trustee to be aware of trusts. Example: Kubernetes' Cinder volume driver
 (used by Magnum). Most such software should be able to handle an auth
 token, on the other hand.
  3) There is less cleanup required after the trust has served its purpose:
 only the trust needs to be deleted at that point, but no trustee user.

Comments on these two proposals (and advice on a suitable forum for discussing
them at the summit) would be greatly appreciated. Thank you!

Cheers,

Johannes


Footnotes:

[0] In a pinch I could probably ask a colleague to stand in for me, but I'd
prefer a solution where I can be present for both discussions.

--
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany

__
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][calico][tempest][gate] Help setting up DSVM gate job for networking-calico

[Neil Jerram]

Thanks very much, Kevin.  After removing that line that disables tempest,
things are looking a lot saner [1].  There are still other detailed things
wrong with the config, and failures to look at, but I think I know how to
attack those now.

(I also realized, from your help, that networking-calico/devstack/settings
is incorrectly confusing two things: (a) What is a minimal complete
devstack configuration, to demonstrate networking-calico function? and (b)
What are the changes to devstack configuration that should be made if
someone decides to do 'enable_plugin networking-calico'?  So I'll also see
about de-confusing that.)

  Neil

[1]
http://logs.openstack.org/63/339263/6/experimental/gate-tempest-dsvm-networking-calico-nv/3639cd8/console.html


On Fri, Oct 21, 2016 at 8:06 AM Kevin Benton  wrote:

> Left a comment on your patch. Looks like you have tempest disabled in your
> devstack settings file.
>
> On Thu, Oct 20, 2016 at 4:34 AM, Neil Jerram  wrote:
>
> I'm trying to set up a dsvm gate job for networking-calico [1] - which I
> think means
> - using DevStack to set up a single combined controller/compute node, with
> networking-calico settings and plugin [2]
> - using Tempest to run some tests on that; ideally including some
> networking-related tests :-)
>
> Unfortunately it doesn't run well yet [3][4]: I see tests failing because
> of something to do with credentials, and that also seem unrelated to
> networking, and I'm not sure if any networking-related tests are running.
>
> I've tried comparing against the similar job for networking-ovn [5][6].
> Before the point where Tempest starts reporting success/failure of
> individual tests, the only notable difference I see is that the
> networking-calico output has:
>
> sed: can't read /opt/stack/new/tempest/etc/tempest.conf: No such file or
> directory
> Running tempest with a custom regex filter
> all create: /opt/stack/new/tempest/.tox/tempest
> all installdeps: setuptools, -r/opt/stack/new/tempest/requirements.txt
> all develop-inst: /opt/stack/new/tempest
>
> where the networking-ovn output only has:
>
> Running tempest with a custom regex filter
> all develop-inst-noop: /opt/stack/new/tempest
>
> Is that significant?
>
> Then the next, very obvious, difference is that the networking-calico
> output seems to have the results of individual tests all jumbled up - like
> output from multiple threads without a lock:
>
> ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./}
> ${OS_TEST_PATH:-./tempest/test_discover}  --load-list /tmp/tmpGuFAar
> 2016-10-19 17:43:01.981 30902 INFO tempest [-] Using tempest config file
> /etc/tempest/tempest.conf
> 2016-10-19 17:43:02.005 30904 INFO tempest [-] Using tempest confi20g1
> 6file -/10e-19tc/te mp1e7s:4t3:/te02.030m 3pe0s908t INFO. tceonf
> mpest [-] Using tempest config file /etc/tempest/tempest.co20n1f6
> -10-19 17:43:02.059 30906 INFO tempest [-] Using tempest config file
> /etc/tempest/tempest.conf
> {0} setUpClass
> (tempest.api.baremetal.admin.test_api_discovery.TestApiDiscovery) ...
> SKIPPED: TestApiDiscovery skipped as Ironic is not available
> 2016-10-19 17:43:02.373 30902 INFO tempest.test [-]  'tempest.lib.exceptions.InvalidCredentials'> raised in
> AgentsAdminTestJSON.setUpClass. Invoking tearDownClass.
> {3} setUpClass (tempest.api.baremetal.admin.test_nodes.TestNodes) ...
> SKIPPED: TestNodes skipped as Ironic is not available
> {2} setUpClass (tempest.api.baremetal.admin.test_drivers.TestDrivers) ...
> SKIPPED: TestDrivers skipped as Ironic is not available
> {2} setUpClass
> (tempest.api.baremetal.admin.test_ports_negative.TestPortsNegative) ...
> SKIPPED: TestPortsNegative skipped as Ironic is not available
> 20{3} setUpClass
> (tempest.api.baremetal.admin.test_nodestates.TestNodeStates) ... SKIPPED:
> TestNodeStates skipped as Ironic is not available
> 16{0} setUpClass
> (tempest.api.compute.admin.test_agents.AgentsAdminTestJSON) [0.00s] ...
> FAILED
> 2{3} setUpClass (tempest.api.baremetal.admin.test_ports.TestPorts) ...
> SKIPPED: TestPorts skipped as Ironic is not available
> 021-106-1-016190- -111097:- 147:13:9403:2. 104728.32 :4{1} setUpClass
> (tempest.api.baremetal.admin.test_chassis.TestChassis) ... SKIPPED:
> TestChassis skipped as Ironic is not available
> 23:3020.41356 7-9 093136 INFO tempest.test [-]  'tempest.lib.exceptions.InvalidCre908 INFO- t19de 90empe17st.:4tes3:0tn22
> t. [i3-8aIN]l6 FOs  t'30em904 IN class resFa't.O teitesmpstt
> eedst.teste[ -mp] [- in]e< s cBtl<.aarlisb.ecmetexalceptions.Invs
> 'temNodesAdminTestJSON.setUpCalpesidCredentitlaa.lliss 'teb.eassxce.
> Inlspmtvoki'>on ras.piieInng vassliedtdC i.lrn
> Agitgeber.aeergaxDcdteoepesntAdtiwmioniannlCsN'el>sga .asrItsan.iiv
>
> whereas the networking-ovn output looks neat:
>
> ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./}
> ${OS_TEST_PATH:-./tempest/test_discover}  --load-list /tmp/tmpl_uSDt
> {0} setUpClass
> 

Re: [openstack-dev] [glance][VMT][Security] Glance coresec reorg

[Flavio Percoco]

On 20/10/16 12:33 -0700, Steve Lewis wrote:

I'm not voicing as a core here, but in the course of several cycles I have
seen Erno and Ian each providing the care and insight needed by this role
and trust them to do the job well.



+1k to the above!

Thank you both for stepping up for this critical task.
Flavio



On Wed, Oct 19, 2016 at 3:50 PM, Jeremy Stanley  wrote:


On 2016-10-18 22:22:28 + (+), Brian Rosmaita wrote:
> Thus, the main point of this email is to propose Ian Cordasco and Erno
> Kuvaja as new members of the Glance coresec team.  They've both been
> Glance cores for several cycles, have a broad knowledge of the software
> and team, contribute high-quality reviews, and are conversant with good
> security practices.
[...]

Sounds good to me. From a VMT perspective, I'm just happy to see
Glance keeping active participants with available bandwidth looking
at prospective vulnerability reports so we can continue to churn
through them faster and make them public sooner. Thanks for keeping
the wheels turning!
--
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





--
SteveL



__
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


signature.asc
Description: 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] [release][ptl] pausing releases until 1 Nov

[Julien Danjou]

On Thu, Oct 20 2016, Emilien Macchi wrote:

> I take this opportunity to thank doug/dims/ttx for their hard work on
> release management; they always help PTLs in a productive and
> responsive way to reach the goals.
> As a PTL, I always feel happy to deal with release management assisted
> by such a great team, with nice tools like reno and openstack/releases
> repo.

Ditto.

Also I'd like to emphasize how happy I become dealing with the
openstack/releases repository even and especially for independent
projects, where nothing peculiar has been implemented. :-)

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


signature.asc
Description: 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] [vitrage][aodh] about aodh notifier to create a event alarm

[Afek, Ifat (Nokia - IL)]

dwj,

This would be great! Thanks for your help.

Ifat.

From: "dong.wenj...@zte.com.cn"
Date: Friday, 21 October 2016 at 04:14
To: "Afek, Ifat (Nokia - IL)", gordon chung
Cc: "OpenStack Development Mailing List (not for usage questions)"
Subject: 答复: Re: 答复: Re: [openstack-dev] [vitrage][aodh] about aodh notifier to 
create a event alarm


Hi All,

I think it's clear now.
We can start to implement  the Aodh-message-bus-notificationsBP. :)
Thanks~

BR,
dwj





"Afek, Ifat (Nokia - IL)" >

2016-10-21 01:23


收件人
gordon chung >, 
"dong.wenj...@zte.com.cn" 
>
抄送
"OpenStack Development Mailing List (not for usage questions)" 
>
主题
Re: 答复: Re: [openstack-dev] [vitrage][aodh] about aodh notifier to 
create a event alarm












On 20/10/2016, 20:14, "gordon chung" > wrote:

>
>On 20/10/16 01:01 PM, Afek, Ifat (Nokia - IL) wrote:
>> Well… long time ago I asked to add another notification topic to Aodh, and 
>> you said that you blocked it. If that’s not the case, everything is fine :-)
>> Like I said before, we planned on implementing it in Newton, but 
>> unfortunately it didn’t happen. I really hope to improve the Vitrage-Aodh 
>> integration in Ocata.
>>
>>
>>
>> Ifat.
>
>i see. i wasn't being critical about no work but i'll be honest, i don't
>remember what this is about since i was looking at other stuff so if you
>have a patch/ML to refresh my memory, that'd help.
>
>this is the only thread[1] i recall, and even then, i don't remember
>much about it. :(
>
>[1] http://lists.openstack.org/pipermail/openstack-dev/2016-June/098074.html
>
>cheers,
>
>--
>gord

What I recall was a few months earlier, we had a chat on ceilometer IRC 
channel… not sure if I can find the exact date.
Anyway, I guess it doesn’t matter now. If you think the change can be done, 
then great.

Ifat.



__
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][calico][tempest][gate] Help setting up DSVM gate job for networking-calico

[Kevin Benton]

Left a comment on your patch. Looks like you have tempest disabled in your
devstack settings file.

On Thu, Oct 20, 2016 at 4:34 AM, Neil Jerram  wrote:

> I'm trying to set up a dsvm gate job for networking-calico [1] - which I
> think means
> - using DevStack to set up a single combined controller/compute node, with
> networking-calico settings and plugin [2]
> - using Tempest to run some tests on that; ideally including some
> networking-related tests :-)
>
> Unfortunately it doesn't run well yet [3][4]: I see tests failing because
> of something to do with credentials, and that also seem unrelated to
> networking, and I'm not sure if any networking-related tests are running.
>
> I've tried comparing against the similar job for networking-ovn [5][6].
> Before the point where Tempest starts reporting success/failure of
> individual tests, the only notable difference I see is that the
> networking-calico output has:
>
> sed: can't read /opt/stack/new/tempest/etc/tempest.conf: No such file or
> directory
> Running tempest with a custom regex filter
> all create: /opt/stack/new/tempest/.tox/tempest
> all installdeps: setuptools, -r/opt/stack/new/tempest/requirements.txt
> all develop-inst: /opt/stack/new/tempest
>
> where the networking-ovn output only has:
>
> Running tempest with a custom regex filter
> all develop-inst-noop: /opt/stack/new/tempest
>
> Is that significant?
>
> Then the next, very obvious, difference is that the networking-calico
> output seems to have the results of individual tests all jumbled up - like
> output from multiple threads without a lock:
>
> ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./}
> ${OS_TEST_PATH:-./tempest/test_discover}  --load-list /tmp/tmpGuFAar
> 2016-10-19 17:43:01.981 30902 INFO tempest [-] Using tempest config file
> /etc/tempest/tempest.conf
> 2016-10-19 17:43:02.005 30904 INFO tempest [-] Using tempest confi20g1
> 6file -/10e-19tc/te mp1e7s:4t3:/te02.030m 3pe0s908t INFO. tceonf
> mpest [-] Using tempest config file /etc/tempest/tempest.co20n1f6
> -10-19 17:43:02.059 30906 INFO tempest [-] Using tempest config file
> /etc/tempest/tempest.conf
> {0} setUpClass 
> (tempest.api.baremetal.admin.test_api_discovery.TestApiDiscovery)
> ... SKIPPED: TestApiDiscovery skipped as Ironic is not available
> 2016-10-19 17:43:02.373 30902 INFO tempest.test [-]  'tempest.lib.exceptions.InvalidCredentials'> raised in
> AgentsAdminTestJSON.setUpClass. Invoking tearDownClass.
> {3} setUpClass (tempest.api.baremetal.admin.test_nodes.TestNodes) ...
> SKIPPED: TestNodes skipped as Ironic is not available
> {2} setUpClass (tempest.api.baremetal.admin.test_drivers.TestDrivers) ...
> SKIPPED: TestDrivers skipped as Ironic is not available
> {2} setUpClass 
> (tempest.api.baremetal.admin.test_ports_negative.TestPortsNegative)
> ... SKIPPED: TestPortsNegative skipped as Ironic is not available
> 20{3} setUpClass (tempest.api.baremetal.admin.test_nodestates.TestNodeStates)
> ... SKIPPED: TestNodeStates skipped as Ironic is not available
> 16{0} setUpClass (tempest.api.compute.admin.test_agents.AgentsAdminTestJSON)
> [0.00s] ... FAILED
> 2{3} setUpClass (tempest.api.baremetal.admin.test_ports.TestPorts) ...
> SKIPPED: TestPorts skipped as Ironic is not available
> 021-106-1-016190- -111097:- 147:13:9403:2. 104728.32 :4{1} setUpClass
> (tempest.api.baremetal.admin.test_chassis.TestChassis) ... SKIPPED:
> TestChassis skipped as Ironic is not available
> 23:3020.41356 7-9 093136 INFO tempest.test [-]  'tempest.lib.exceptions.InvalidCre908 INFO- t19de 90empe17st.:4tes3:0tn22
> t. [i3-8aIN]l6 FOs  t'30em904 IN class resFa't.O teitesmpstt
> eedst.teste[ -mp] [- in]e< s cBtl<.aarlisb.ecmetexalceptions.Invs
> 'temNodesAdminTestJSON.setUpCalpesidCredentitlaa.lliss 'teb.eassxce.
> Inlspmtvoki'>on ras.piieInng vassliedtdC i.lrn Agitgeber.
> aeergaxDcdteoepesntAdtiwmioniannlCsN'el>sga .asrItsan.iiv
>
> whereas the networking-ovn output looks neat:
>
> ${PYTHON:-python} -m subunit.run discover -t ${OS_TOP_LEVEL:-./}
> ${OS_TEST_PATH:-./tempest/test_discover}  --load-list /tmp/tmpl_uSDt
> {0} setUpClass (tempest.api.baremetal.admin.test_nodestates.TestNodeStates)
> ... SKIPPED: TestNodeStates skipped as Ironic is not available
> {2} setUpClass 
> (tempest.api.baremetal.admin.test_api_discovery.TestApiDiscovery)
> ... SKIPPED: TestApiDiscovery skipped as Ironic is not available
> {2} setUpClass (tempest.api.baremetal.admin.test_ports.TestPorts) ...
> SKIPPED: TestPorts skipped as Ironic is not available
> {3} setUpClass (tempest.api.baremetal.admin.test_chassis.TestChassis) ...
> SKIPPED: TestChassis skipped as Ironic is not available
> {1} setUpClass (tempest.api.baremetal.admin.test_drivers.TestDrivers) ...
> SKIPPED: TestDrivers skipped as Ironic is not available
> {1} setUpClass (tempest.api.baremetal.admin.test_nodes.TestNodes) ...
> SKIPPED: TestNodes skipped as Ironic is not available
> {1} setUpClass 
> 

[openstack-dev] [Congress] IRC during summit

[Eric K]

Hi all!

To help us connect and coordinate during the upcoming summit, those who are
interested can try IRCcloud (https://www.irccloud.com ; suggested by aimeeu)
to communicate over the #congress channel. The service acts as an IRC
bouncer to keep your nick connected and send push notifications to the
mobile app. I just tried it out and it works pretty well.

To be notified of all messages on the channel, set your mobile app to
³Notify on all messages² (under display options). To be notified only of
messages that mention your nick, just keep the default settings.

See you all at the summit soon!


__
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] [api] [nova] microversion edge case query

[Alex Xu]

2016-10-19 0:58 GMT+08:00 Ed Leafe :

> On Oct 18, 2016, at 11:01 AM, Chris Dent  wrote:
> >
> > If the requested microversion is greater than the maximum, a 404 still
> > makes some sense (no mapping _now_), but a 406 could as well because it
> > provides a signal that if you used a different microversion the
> > situation could be different and the time represented by the
> > requested microversion has conceptual awareness of its past.
> >
> > What do people think?
> >
> > I think I recall there was some discussion of this sort of thing
> > with regard to some of the proxy APIs at the nova midcycle but I
> > can't remember the details of the outcome.
>
> The only way that that could happen (besides a total collapse of the
> review process) is when a method is removed from the API. When that
> happens, the latest version has its max set to the last microversion where
> that method is supported. For microversions after that, 404 is the correct
> response. For all other methods, the latest version should not have a
> maximum specified.
>


Also think 404 is right at here. If you return 406 and it is a signal that
if you used a different microversion the situation could be different, the
thing will become strange when we raise the acceptable min_version someday.



>
> -- Ed Leafe
>
>
>
>
>
>
> __
> 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