Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Clark Boylan]

On Wed, May 30, 2018, at 8:13 AM, Zane Bitter wrote:
> On 30/05/18 00:52, Cédric Jeanneret wrote:
> >> Another issue is that if the original author needs to rev the patch
> >> again for any reason, they then need to figure out how to check out the
> >> modified patch. This requires a fairly sophisticated knowledge of both
> >> git and gerrit, which isn't a problem for those of us who have been
> >> using them for years but is potentially a nightmarish introduction for a
> >> relatively new contributor. Sometimes it's the right choice though
> >> (especially if the patch owner hasn't been seen for a while).
> > hm, "Download" -> copy/paste, and Voilà. Gerrit interface is pretty nice
> > with the user (I an "old new contributor", never really struggled with
> > Gerrit itself.. On the other hand, heat, ansible, that's another story :) ).
> 
> OK, so I am sitting here with a branch containing a patch I have sent 
> for review, and that I need to revise, but somebody else has pushed a 
> revision upstream. Which of the 4 'Download' commands do I use to 
> replace my commit with the latest one from upstream?
> 
> (Hint: it's a trick question)
> 
> Now imagine it wasn't the last patch in the series.
> 
> - ZB
> 
> (P.S. without testing, I believe the correct answers are `git reset 
> --hard FETCH_HEAD` and `git rebase HEAD~ --onto FETCH_HEAD` 
> respectively.)

We do have tools for this and it is the same tool you use to push code to 
gerrit. `git review -d changenumber` will grab the latest patchset from that 
change and check it out locally. You can use `git review -d 
changenumber,patchsetnumber` to pick a different older patchset. If you have a 
series of changes things become more complicated. I personally like to always 
operate against leaf most change, make local updates, then squash "back" onto 
the appropriate changes in the series to keep existing changes happy.

Yes, this is complicated especially for new users. In general though I think 
git review addresses the simpler cases of I need to use latest version of my 
change. If we use change series as proposed in this thread I think keeping the 
parent of the child changes up to date is going to be up to the more 
experienced nit picker that is addressing the minor problems and not the 
original change author.

Clark

__
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] [tc][all] A culture change (nitpicking)

[Zane Bitter]

On 30/05/18 00:52, Cédric Jeanneret wrote:

Another issue is that if the original author needs to rev the patch
again for any reason, they then need to figure out how to check out the
modified patch. This requires a fairly sophisticated knowledge of both
git and gerrit, which isn't a problem for those of us who have been
using them for years but is potentially a nightmarish introduction for a
relatively new contributor. Sometimes it's the right choice though
(especially if the patch owner hasn't been seen for a while).

hm, "Download" -> copy/paste, and Voilà. Gerrit interface is pretty nice
with the user (I an "old new contributor", never really struggled with
Gerrit itself.. On the other hand, heat, ansible, that's another story :) ).


OK, so I am sitting here with a branch containing a patch I have sent 
for review, and that I need to revise, but somebody else has pushed a 
revision upstream. Which of the 4 'Download' commands do I use to 
replace my commit with the latest one from upstream?


(Hint: it's a trick question)

Now imagine it wasn't the last patch in the series.

- ZB

(P.S. without testing, I believe the correct answers are `git reset 
--hard FETCH_HEAD` and `git rebase HEAD~ --onto FETCH_HEAD` 
respectively.)


__
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] [stable] [tooz] [ceilometer] cmd2 without upper constraints causes errors in tox-py27

[Jeremy Stanley]

On 2018-05-30 16:59:10 +0200 (+0200), Julien Danjou wrote:
[...]
> I see cliff has already set that requirements in its master branch, but
> no new version has been released. Releasing a new cliff version should
> fix that issue.

Yes, that's in progress today.
-- 
Jeremy Stanley


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] [stable] [tooz] [ceilometer] cmd2 without upper constraints causes errors in tox-py27

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-05-30 13:00:31 +:
> On 2018-05-30 14:42:58 +0200 (+0200), Julien Danjou wrote:
> [...]
> > The question is: why cmd2 0.9.0 does not work and how do we fix that?
> 
> The cmd2 maintainers decided that they no longer want to carry
> support for old Python interpreters, so versions starting with 0.9.0
> only work on Python 3.4 and later:
> 
> https://github.com/python-cmd2/cmd2/issues/421
> 

I expect we're going to see more and more upstream tools dropping
python 2 support as we approach the 2020 deadline. It would help
the community immensely if we had a few people who could become
familiar enough with environment markers and requirements specification
to be ready to help folks fix the problems that come up when we
have future cases. I'm sure the requirements team would be happy
to help find documentation and explain the fix for this specific
case if you have questions.

Doug

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

Re: [openstack-dev] [stable] [tooz] [ceilometer] cmd2 without upper constraints causes errors in tox-py27

[Julien Danjou]

On Wed, May 30 2018, Elõd Illés wrote:

> cmd2 says that:
>
> "Python 2.7 support is EOL
>
> Support for adding new features to the Python 2.7 release of |cmd2| was
> discontinued on April 15, 2018. Bug fixes will be supported for Python 2.7 via
> 0.8.x until August 31, 2018.
>
> Supporting Python 2 was an increasing burden on our limited resources.
> Switching to support only Python 3 will allow us to clean up the codebase,
> remove some cruft, and focus on developing new features."

Erf. :(

So the problem is that cmd2 is not a requirements in Ceilometer. It's
pulled by cliff. As far as I can see, cliff latest version (2.11.0)
announces it supports Python 2.7 (obviously) while also depends on
cmd2>=0.6.7. Cliff needs to upper cap cmd2 if it wants to support
Python 2.

I see cliff has already set that requirements in its master branch, but
no new version has been released. Releasing a new cliff version should
fix that issue.

-- 
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] Questions about token scopes

[Lance Bragstad]

On 05/30/2018 08:47 AM, Matt Riedemann wrote:
> I know the keystone team has been doing a lot of work on scoped tokens
> and Lance has been trying to roll that out to other projects (like nova).
>
> In Rocky the nova team is adding granular policy rules to the
> placement API [1] which is a good opportunity to set scope on those
> rules as well.
>
> For now, we've just said everything is system scope since resources in
> placement, for the most part, are managed by "the system". But we do
> have some resources in placement which have project/user information
> in them, so could theoretically also be scoped to a project, like GET
> /usages [2].
>
> While going through this, I've been hammering Lance with questions but
> I had some more this morning and wanted to send them to the list to
> help spread the load and share the knowledge on working with scoped
> tokens in the other projects.

++ good idea

>
> So here goes with the random questions:
>
> * devstack has the admin project/user - does that by default get
> system scope tokens? I see the scope is part of the token create
> request [3] but it's optional, so is there a default value if not
> specified?

No, not necessarily. The keystone-manage bootstrap command is what
bootstraps new deployments with the admin user, an admin role, a project
to work in, etc. It also grants the newly created admin user the admin
role on a project and the system. This functionality was added in Queens
[0]. This should be backwards compatible and allow the admin user to get
tokens scoped to whatever they had authorization on previously. The only
thing they should notice is that they have another role assignment on
something called the "system". That being said, they can start
requesting system-scoped tokens from keystone. We have a document that
tries to explain the differences in scopes and what they mean [1].

[0] https://review.openstack.org/#/c/530410/
[1] https://docs.openstack.org/keystone/latest/admin/identity-tokens.html

>
> * Why don't the token create and show APIs return the scope?

Good question. In a way, they do. If you look at a response when you
authenticate for a token or validate a token, you should see an object
contained within the token reference for the purpose of scope. For
example, a project-scoped token will have a project object in the
response [2]. A domain-scoped token will have a domain object in the
response [3]. The same is true for system scoped tokens [4]. Unscoped
tokens do not have any of these objects present and do not contain a
service catalog [5]. While scope isn't explicitly denoted by an
attribute, it can be derived from the attributes of the token response.

[2] http://paste.openstack.org/raw/722349/
[3] http://paste.openstack.org/raw/722351/
[4] http://paste.openstack.org/raw/722348/
[5] http://paste.openstack.org/raw/722350/


>
> * It looks like python-openstackclient doesn't allow specifying a
> scope when issuing a token, is that going to be added?

Yes, I have a patch up for it [6]. I wanted to get this in during
Queens, but it missed the boat. I believe this and a new release of
oslo.context are the only bits left in order for services to have
everything they need to easily consume system-scoped tokens.
Keystonemiddleware should know how to handle system-scoped tokens in
front of each service [7]. The oslo.context library should be smart
enough to handle system scope set by keystonemiddleware if context is
built from environment variables [8]. Both keystoneauth [9] and
python-keystoneclient [10] should have what they need to generate
system-scoped tokens.

That should be enough to allow the service to pass a request environment
to oslo.context and use the context object to reason about the scope of
the request. As opposed to trying to understand different token scope
responses from keystone. We attempted to abstract that away in to the
context object.

[6] https://review.openstack.org/#/c/524416/
[7] https://review.openstack.org/#/c/564072/
[8] https://review.openstack.org/#/c/530509/
[9] https://review.openstack.org/#/c/529665/
[10] https://review.openstack.org/#/c/524415/

>
> The reason I'm asking about OSC stuff is because we have the
> osc-placement plugin [4] which allows users with the admin role to
> work with resources in placement, which could be useful for things
> like fixing up incorrect or leaked allocations, i.e. fixing the
> fallout of a bug in nova. I'm wondering if we define all of the
> placement API rules as system scope and we're enforcing scope, will
> admins, as we know them today, continue to be able to use those APIs?
> Or will deployments just need to grow a system-scope admin
> project/user and per-project admin users, and then use the former for
> working with placement via the OSC plugin?

Uhm, if I understand your question, it depends on how you define the
scope types for those APIs. If you set them to system-scope, then an
operator will need to use a system-scoped token in order to access 

Re: [openstack-dev] [octavia] TERMINATED_HTTPS + SSL to backend server

[Michael Johnson]

Hi Mihaela,

Backend re-encryption is on our roadmap[1], but not yet implemented.
We have all of the technical pieces to make this work, it's just
someone getting time to do the API additions and update the flows.

[1] 
https://wiki.openstack.org/wiki/Octavia/Roadmap#Considerations_for_Octavia_3.0.2B

Michael

On Wed, May 30, 2018 at 1:45 AM,   wrote:
> Hello,
>
>
>
> Is there any user story for the scenario below?
>
>
>
> -  Octavia is set to TERMINATED_HTTPS and also initiates SSL to
> backend servers
>
>
>
> After testing all the combination possible and after looking at the Octavia
> haproxy templates in Queens version I understand that this kind of setup is
> currently not supported.
>
>
>
> Thanks,
>
> Mihaela
>
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> __
> 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] Winterscale: a proposal regarding the project infrastructure

[James E. Blair]

Hi,

With recent changes implemented by the OpenStack Foundation to include
projects other than "OpenStack" under its umbrella, it has become clear
that the "Project Infrastructure Team" needs to change.

The infrastructure that is run for the OpenStack project is valued by
other OpenStack Foundation projects (and beyond).  Our community has not
only produced an amazing cloud infrastructure system, but it has also
pioneered new tools and techniques for software development and
collaboration.

For some time it's been apparent that we need to alter the way we run
services in order to accommodate other Foundation projects.  We've been
talking about this informally for at least the last several months.  One
of the biggest sticking points has been a name for the effort.  It seems
very likely that we will want a new top-level domain for hosting
multiple projects in a neutral environment (so that people don't have to
say "hosted on OpenStack's infrastructure").  But finding such a name is
difficult, and even before we do, we need to talk about it.

I propose we call the overall effort "winterscale".  In the best
tradition of code names, it means nothing; look for no hidden meaning
here.  We won't use it for any actual services we provide.  We'll use it
to refer to the overall effort of restructuring our team and
infrastructure to provide services to projects beyond OpenStack itself.
And we'll stop using it when the restructuring effort is concluded.

This is my first proposal: that we acknowledge this effort is underway
and name it as such.

My second proposal is an organizational structure for this effort.
First, some goals:

* The infrastructure should be collaboratively run as it is now, and
  the operational decisions should be made by the core reviewers as
  they are now.

* Issues of service definition (i.e., what services we offer and how
  they are used) should be made via a collaborative process including
  the infrastructure operators and the projects which use it.

To that end, I propose that we:

* Work with the Foundation to create a new effort independent of the
  OpenStack project with the goal of operating infrastructure for the
  wider OpenStack Foundation community.

* Work with the Foundation marketing team to help us with the branding
  and marketing of this effort.

* Establish a "winterscale infrastructure team" (to be renamed)
  consisting of the current infra-core team members to operate this
  effort.

* Move many of the git repos currently under the OpenStack project
  infrastructure team's governance to this new team.

* Establish a "winterscale infrastructure council" (to be renamed) which
  will govern the services that the team provides by vote.  The council
  will consist of the PTL of the winterscale infrastructure team and one
  member from each official OpenStack Foundation project.  Currently, as
  I understand it, there's only one: OpenStack.  But we expect kata,
  zuul, and others to be declared official in the not too distant
  future.  The winterscale representative (the PTL) will have
  tiebreaking and veto power over council decisions.

  (This is structured loosely based on the current Infrastructure
  Council used by the OpenStack Project Infrastructure Team.)

None of this is obviously final.  My goal here is to give this effort a
name and a starting point so that we can discuss it and make progress.

-Jim

__
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] Signing off

[Gage Hugo]

It was great working with you Henry.  Hope to see you around sometime and
wishing you all the best!

On Wed, May 30, 2018 at 3:45 AM, Henry Nash  wrote:

> Hi
>
> It is with a somewhat heavy heart that I have decided that it is time to
> hang up my keystone core status. Having been involved since the closing
> stages of Folsom, I've had a good run! When I look at how far keystone has
> come since the v2 days, it is remarkable - and we should all feel a sense
> of pride in that.
>
> Thanks to all the hard work, commitment, humour and support from all the
> keystone folks over the years - I am sure we will continue to interact and
> meet among the many other open source projects that many of us are becoming
> involved with. Ad astra!
>
> Best regards,
>
> Henry
> Twitter: @henrynash
> linkedIn: www.linkedin.com/in/henrypnash
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> __
> 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] [tc][all] A culture change (nitpicking)

[Luigi Toscano]

On Wednesday, 30 May 2018 17:13:41 CEST Zane Bitter wrote:
> On 30/05/18 00:52, Cédric Jeanneret wrote:
> >> Another issue is that if the original author needs to rev the patch
> >> again for any reason, they then need to figure out how to check out the
> >> modified patch. This requires a fairly sophisticated knowledge of both
> >> git and gerrit, which isn't a problem for those of us who have been
> >> using them for years but is potentially a nightmarish introduction for a
> >> relatively new contributor. Sometimes it's the right choice though
> >> (especially if the patch owner hasn't been seen for a while).
> > 
> > hm, "Download" -> copy/paste, and Voilà. Gerrit interface is pretty nice
> > with the user (I an "old new contributor", never really struggled with
> > Gerrit itself.. On the other hand, heat, ansible, that's another story :)
> > ).
> OK, so I am sitting here with a branch containing a patch I have sent
> for review, and that I need to revise, but somebody else has pushed a
> revision upstream. Which of the 4 'Download' commands do I use to
> replace my commit with the latest one from upstream?
> 
> (Hint: it's a trick question)
> 
> Now imagine it wasn't the last patch in the series.

Maybe using git review is enough:

git review -d 

We document git review -d for rebasing and adding new review on top of a 
existing reviews, but not explicitly for amending a change:
https://docs.openstack.org/infra/manual/developers.html

Ciao
-- 
Luigi



__
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-Infra] Winterscale: a proposal regarding the project infrastructure

[Doug Hellmann]

Excerpts from corvus's message of 2018-05-30 09:25:14 -0700:
> Hi,
> 
> With recent changes implemented by the OpenStack Foundation to include
> projects other than "OpenStack" under its umbrella, it has become clear
> that the "Project Infrastructure Team" needs to change.
> 
> The infrastructure that is run for the OpenStack project is valued by
> other OpenStack Foundation projects (and beyond).  Our community has not
> only produced an amazing cloud infrastructure system, but it has also
> pioneered new tools and techniques for software development and
> collaboration.
> 
> For some time it's been apparent that we need to alter the way we run
> services in order to accommodate other Foundation projects.  We've been
> talking about this informally for at least the last several months.  One
> of the biggest sticking points has been a name for the effort.  It seems
> very likely that we will want a new top-level domain for hosting
> multiple projects in a neutral environment (so that people don't have to
> say "hosted on OpenStack's infrastructure").  But finding such a name is
> difficult, and even before we do, we need to talk about it.
> 
> I propose we call the overall effort "winterscale".  In the best
> tradition of code names, it means nothing; look for no hidden meaning
> here.  We won't use it for any actual services we provide.  We'll use it
> to refer to the overall effort of restructuring our team and
> infrastructure to provide services to projects beyond OpenStack itself.
> And we'll stop using it when the restructuring effort is concluded.
> 
> This is my first proposal: that we acknowledge this effort is underway
> and name it as such.
> 
> My second proposal is an organizational structure for this effort.
> First, some goals:
> 
> * The infrastructure should be collaboratively run as it is now, and
>   the operational decisions should be made by the core reviewers as
>   they are now.
> 
> * Issues of service definition (i.e., what services we offer and how
>   they are used) should be made via a collaborative process including
>   the infrastructure operators and the projects which use it.
> 
> To that end, I propose that we:
> 
> * Work with the Foundation to create a new effort independent of the
>   OpenStack project with the goal of operating infrastructure for the
>   wider OpenStack Foundation community.
> 
> * Work with the Foundation marketing team to help us with the branding
>   and marketing of this effort.
> 
> * Establish a "winterscale infrastructure team" (to be renamed)
>   consisting of the current infra-core team members to operate this
>   effort.
> 
> * Move many of the git repos currently under the OpenStack project
>   infrastructure team's governance to this new team.

I'm curious about the "many" in that sentence. Which do you anticipate
not moving, and if this new team replaces the existing team then who
would end up owning the ones that do not move?

> 
> * Establish a "winterscale infrastructure council" (to be renamed) which
>   will govern the services that the team provides by vote.  The council
>   will consist of the PTL of the winterscale infrastructure team and one
>   member from each official OpenStack Foundation project.  Currently, as
>   I understand it, there's only one: OpenStack.  But we expect kata,
>   zuul, and others to be declared official in the not too distant
>   future.  The winterscale representative (the PTL) will have
>   tiebreaking and veto power over council decisions.

That structure seems sound, although it means the council is going
to be rather small (at least in the near term).  What sorts of
decisions do you anticipate needing to be addressed by this council?

> 
>   (This is structured loosely based on the current Infrastructure
>   Council used by the OpenStack Project Infrastructure Team.)
> 
> None of this is obviously final.  My goal here is to give this effort a
> name and a starting point so that we can discuss it and make progress.
> 
> -Jim
> 

Thanks for starting this thread! I've replied to both mailing lists
because I wasn't sure which was more appropriate. Please let me
know if I should focus future replies on one list.

Doug

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

Re: [openstack-dev] [tc][forum] TC Retrospective for Queens/Rocky

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-05-29 22:57:45 +:
> On 2018-05-29 17:26:16 -0400 (-0400), Doug Hellmann wrote:
> [...]
> > There was some discussion of whether the office hours themselves
> > are useful, based on the apparent lack of participation. We had
> > theories that this was a combination of bad times (meaning that TC
> > members haven't always attended) and bad platforms (meaning that
> > some parts of the community we are trying to reach may emphasize
> > other tools over IRC for real time chat). We need to look into that.
> [...]
> 
> We also had some consensus in the room on starting to use meetbot
> during office hours to highlight whatever we discussed in the
> resulting meeting minutes. I'm planning to do that at our 01:00z
> office hour (a couple hours from now) and see how it goes, though
> that timeslot in particular tends to have little or no discussion.

Thanks for remembering, and reminding me.

The minutes from the most recent office hours are at
http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-05-30-01.00.html
for anyone interested in following them.

Doug

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

Re: [openstack-dev] [OpenStack-Infra] Winterscale: a proposal regarding the project infrastructure

[Jeremy Stanley]

On 2018-05-30 10:09:23 -0700 (-0700), James E. Blair wrote:
[...]
> An example of something that probably shouldn't move is
> "openstack-zuul-jobs".  We still need people that are concerned with how
> OpenStack uses the winterscale service.  I'm not sure whether that
> should be its own team or should those functions get folded into other
> teams.
[...]

At least for some undefined transitional period, anything we think
shouldn't move can remain the domain of the existing Infrastructure
team under OpenStack TC governance. Once we get a better feel for
what's left, that team will likely get scaled back to just the
remaining interested maintainers and its continued governance
situation can be revisited at that future date.
-- 
Jeremy Stanley


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] [keystone] Signing off

[Kristi Nikolla]

Thank you for all your invaluable contributions Henry. It has been a pleasure 
working with you. Best of luck!

Kristi

‐‐‐ Original Message ‐‐‐
On May 30, 2018 4:45 AM, Henry Nash  wrote:

> Hi
>
> It is with a somewhat heavy heart that I have decided that it is time to hang 
> up my keystone core status. Having been involved since the closing stages of 
> Folsom, I've had a good run! When I look at how far keystone has come since 
> the v2 days, it is remarkable - and we should all feel a sense of pride in 
> that.
>
> Thanks to all the hard work, commitment, humour and support from all the 
> keystone folks over the years - I am sure we will continue to interact and 
> meet among the many other open source projects that many of us are becoming 
> involved with. Ad astra!
>
> Best regards,
>
> Henry
> Twitter: @henrynash
> linkedIn: www.linkedin.com/in/henrypnash
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU__
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] Following the new PTI for document build, broken local builds

[Stephen Finucane]

On Thu, 2018-04-26 at 15:49 +0100, Stephen Finucane wrote:
> On Wed, 2018-04-25 at 12:06 -0500, Sean McGinnis wrote:
> > > > > 
> > > > > [1] https://review.openstack.org/#/c/564232/
> > > > > 
> > > > 
> > > > The only concern I have is that it may slow the transition to the
> > > > python 3 version of the jobs, since someone would have to actually
> > > > fix the warnings before they could add the new job. I'm not sure I
> > > > want to couple the tasks of fixing doc build warnings with also
> > > > making those docs build under python 3 (which is usually quite
> > > > simple).
> > > > 
> > > > Is there some other way to enable this flag independently of the move to
> > > > the python3 job?
> > > 
> > > The existing proposal is:
> > > 
> > > https://review.openstack.org/559348
> > > 
> > > TL;DR if you still have a build_sphinx section in setup.cfg then defaults
> > > will remain the same, but when removing it as part of the transition to 
> > > the
> > > new PTI you'll have to eliminate any warnings. (Although AFAICT it doesn't
> > > hurt to leave that section in place as long as you need, and you can still
> > > do the rest of the PTI conversion.)
> > > 
> > > The hold-up is that the job in question is also potentially used by other
> > > Zuul users outside of OpenStack - including those who aren't using pbr at
> > > all (i.e. there's no setup.cfg). So we need to warn those folks to 
> > > prepare.
> > > 
> > > cheers,
> > > Zane.
> > > 
> > 
> > Ah, I had looked but did not find an existing proposal. Looks like that 
> > would
> > work too. I am good either way, but I will leave my approach out there just 
> > as
> > another option to consider. I'll abandon that if folks prefer this way.
> 
> Yeah, I reviewed your patch but assumed you'd seen mine already and
> were looking for a quicker alternative.
> 
> I've started the process of adding this to zuul-jobs by posting the
> warning to zuul-announce (though it's waiting moderation by corvus). We
>  only need to wait two weeks after sending that message before we can
> merge the patch to zuul-jobs, so I guess we should go that way now?
> 
> Stephen

This is now merged:

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

For anyone that has migrated to the new PTI for documentation (namely,
not using 'python setup.py build_sphinx'), you may find your docs
builds are now broken. This will likely be a result of regressions
introduced since the migration to the new PTI and should be trivial to
resolve. If you have any issues, feel free to jump on #openstack-doc
where one of the lovely docs people will be happy to help.

Cheers,
Stephen

PS: I do realize this has likely incurred some extra work for some
projects. No one likes busy work and I'm sorry to have forced that upon
people but this change was essential to ensure every project could rely
on the gate to actually validate their documentation.

__
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-Infra] Winterscale: a proposal regarding the project infrastructure

[James E. Blair]

Doug Hellmann  writes:

>> * Move many of the git repos currently under the OpenStack project
>>   infrastructure team's governance to this new team.
>
> I'm curious about the "many" in that sentence. Which do you anticipate
> not moving, and if this new team replaces the existing team then who
> would end up owning the ones that do not move?

There are a lot.  Generally speaking, I think most of the custom
software, deployment tooling, and configuration would move.

An example of something that probably shouldn't move is
"openstack-zuul-jobs".  We still need people that are concerned with how
OpenStack uses the winterscale service.  I'm not sure whether that
should be its own team or should those functions get folded into other
teams.

>> * Establish a "winterscale infrastructure council" (to be renamed) which
>>   will govern the services that the team provides by vote.  The council
>>   will consist of the PTL of the winterscale infrastructure team and one
>>   member from each official OpenStack Foundation project.  Currently, as
>>   I understand it, there's only one: OpenStack.  But we expect kata,
>>   zuul, and others to be declared official in the not too distant
>>   future.  The winterscale representative (the PTL) will have
>>   tiebreaking and veto power over council decisions.
>
> That structure seems sound, although it means the council is going
> to be rather small (at least in the near term).  What sorts of
> decisions do you anticipate needing to be addressed by this council?

Yes, very small.  Perhaps we need an interim structure until it gets
larger?  Or perhaps just discipline and agreement that the two people on
it will consult with the necessary constituencies and represent them
well?

I expect the council not to have to vote very often.  Perhaps only on
substantial changes to services (bringing a new offering online,
retiring a disused offering, establishing parameters of a service).  As
an example, the recent thread on "terms of service" would be a good
topic for the council to settle.

>>   (This is structured loosely based on the current Infrastructure
>>   Council used by the OpenStack Project Infrastructure Team.)
>> 
>> None of this is obviously final.  My goal here is to give this effort a
>> name and a starting point so that we can discuss it and make progress.
>> 
>> -Jim
>> 
>
> Thanks for starting this thread! I've replied to both mailing lists
> because I wasn't sure which was more appropriate. Please let me
> know if I should focus future replies on one list.

Indeed, perhaps we should steer this toward openstack-dev now.  I'll
drop openstack-infra from future replies.

-Jim

__
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][api][grapql] Proof of Concept

[Flint WALRUS]

Hi Gilles, I hope you enjoyed your Summit!?

Did you had any interesting talk to report about our little initiative ?
Le dim. 6 mai 2018 à 15:01, Gilles Dubreuil  a écrit :

>
> Akihiro, thank you for your precious help!
>
> Regarding the choice of Neutron as PoC, I'm sorry for not providing much
> details when I said "because of its specific data model",
> effectively the original mention was  "its API exposes things at an
> individual table level, requiring the client to join that information to
> get the answers they need".
> I realize now such description probably applies to many OpenStack APIs.
> So I'm not sure what was the reason for choosing Neutron.
> I suppose Nova is also a good candidate because API is quite complex too,
> in a different way, and need to expose the data API and the control API
> plane as we discussed.
>
> After all Neutron is maybe not the best candidate but it seems good
> enough.
>
> And as Flint say the extension mechanism shouldn't be an issue.
>
> So if someone believe there is a better candidate for the PoC, please
> speak now.
>
> Thanks,
> Gilles
>
> PS: Flint,  Thank you for offering to be the advocate for Berlin. That's
> great!
>
>
> On 06/05/18 02:23, Flint WALRUS wrote:
>
> Hi Akihiro,
>
> Thanks a lot for this insight on how neutron behave.
>
> We would love to get support and backing from the neutron team in order to
> be able to get the best PoC possible.
>
> Someone suggested neutron as a good choice because of it simple database
> model. As GraphQL can manage your behavior of an extension declaring its
> own schemes I don’t think it would take that much time to implement it.
>
> @Gilles, if I goes to the berlin summitt I could definitely do the
> networking and relationship work needed to get support on our PoC from
> different teams members. This would help to spread the world multiple time
> and don’t have a long time before someone come to talk about this subject
> as what happens with the 2015 talk of the Facebook speaker.
>
> Le sam. 5 mai 2018 à 18:05, Akihiro Motoki  a écrit :
>
>> Hi,
>>
>> I am happy to see the effort to explore a new API mechanism.
>> I would like to see good progress and help effort as API liaison from the
>> neutron team.
>>
>> > Neutron has been selected for the PoC because of its specific data
>> model
>>
>> On the other hand, I am not sure this is the right reason to choose
>> 'neutron' only from this reason. I would like to note "its specific data
>> model" is not the reason that makes the progress of API versioning slowest
>> in the OpenStack community. I believe it is worth recognized as I would
>> like not to block the effort due to the neutron-specific reasons.
>> The most complicated point in the neutron API is that the neutron API
>> layer allows neutron plugins to declare which features are supported. The
>> neutron API is a collection of API extensions defined in the neutron-lib
>> repo and each neutron plugin can declare which subset(s) of the neutron
>> APIs are supported. (For more detail, you can check how the neutron API
>> extension mechanism is implemented). It is not defined only by the neutron
>> API layer. We need to communicate which API features are supported by
>> communicating enabled service plugins.
>>
>> I am afraid that most efforts to explore a new mechanism in neutron will
>> be spent to address the above points which is not directly related to
>> GraphQL itself.
>> Of course, it would be great if you overcome long-standing complicated
>> topics as part of GraphQL effort :)
>>
>> I am happy to help the effort and understand how the neutron API is
>> defined.
>>
>> Thanks,
>> Akihiro
>>
>>
>> 2018年5月5日(土) 18:16 Gilles Dubreuil :
>>
>>> Hello,
>>>
>>> Few of us recently discussed [1] how GraphQL [2], the next evolution
>>> from REST, could transform OpenStack APIs for the better.
>>> Effectively we believe OpenStack APIs provide perfect use cases for
>>> GraphQL DSL approach, to bring among other advantages, better
>>> performance and stability, easier developments and consumption, and with
>>> GraphQL Schema provide automation capabilities never achieved before.
>>>
>>> The API SIG suggested to start an API GraphQL Proof of Concept (PoC) to
>>> demonstrate the capabilities before eventually extend GraphQL to other
>>> projects.
>>> Neutron has been selected for the PoC because of its specific data model.
>>>
>>> So if you are interested, please join us.
>>> For those who can make it, we'll also discuss this during the SIG API
>>> BoF at OpenStack Summit at Vancouver [3]
>>>
>>> To learn more about GraphQL, check-out howtographql.com [4].
>>>
>>> So let's get started...
>>>
>>>
>>> [1]
>>> http://lists.openstack.org/pipermail/openstack-dev/2018-May/130054.html
>>> [2] http://graphql.org/
>>> [3]
>>>
>>> https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21798/api-special-interest-group-session
>>> [4] https://www.howtographql.com/
>>>
>>> Regards,
>>> Gilles
>>>
>>>
>>>
>>>
>>> 

Re: [openstack-dev] [Cyborg] [Nova] Cyborg traits

[Eric Fried]

This all sounds fully reasonable to me.  One thing, though...

>>   * There is a resource class per device category e.g.
>> CUSTOM_ACCELERATOR_GPU, CUSTOM_ACCELERATOR_FPGA.

Let's propose standard resource classes for these ASAP.

https://github.com/openstack/nova/blob/d741f624c81baf89fc8b6b94a2bc20eb5355a818/nova/rc_fields.py

-efried
.

__
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] Hello all, puppet modules

[Remo Mattei]

Hello all, 
I have talked to several people about this and I would love to get this 
finalized once and for all. I have checked the OpenStack puppet modules which 
are mostly developed by the Red Hat team, as of right now, TripleO is using a 
combo of Ansible and puppet to deploy but in the next couple of releases, the 
plan is to move away from the puppet option. 


So consequently, what will be the plan of TripleO and the puppet modules?

Thanks
__
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-Infra] Winterscale: a proposal regarding the project infrastructure

[James E. Blair]

Doug Hellmann  writes:

>> >> * Establish a "winterscale infrastructure council" (to be renamed) which
>> >>   will govern the services that the team provides by vote.  The council
>> >>   will consist of the PTL of the winterscale infrastructure team and one
>> >>   member from each official OpenStack Foundation project.  Currently, as
>> >>   I understand it, there's only one: OpenStack.  But we expect kata,
>> >>   zuul, and others to be declared official in the not too distant
>> >>   future.  The winterscale representative (the PTL) will have
>> >>   tiebreaking and veto power over council decisions.
>> >
>> > That structure seems sound, although it means the council is going
>> > to be rather small (at least in the near term).  What sorts of
>> > decisions do you anticipate needing to be addressed by this council?
>> 
>> Yes, very small.  Perhaps we need an interim structure until it gets
>> larger?  Or perhaps just discipline and agreement that the two people on
>> it will consult with the necessary constituencies and represent them
>> well?
>
> I don't want to make too much out of it, but it does feel a bit odd
> to have a 2 person body where 1 person has the final decision power. :-)
>
> Having 2 people per official team (including winterscale) would
> give us more depth of coverage overall (allowing for quorum when
> someone is on vacation, for example).  In the short term, it also
> has the benefit of having twice as many people involved.

That's a good idea, and we can scale it down later if needed.

>> I expect the council not to have to vote very often.  Perhaps only on
>> substantial changes to services (bringing a new offering online,
>> retiring a disused offering, establishing parameters of a service).  As
>> an example, the recent thread on "terms of service" would be a good
>> topic for the council to settle.
>
> OK, so not on every change but on the significant ones that might affect
> more than one project. Ideally any sort of conflict would be worked out
> in advance, but it's good to have the process in place to resolve
> problems before they come up.

Yes, and like most things, I think the biggest value will be in having
the forum to propose changes, discuss them, and collect feedback from
all members of participating projects (not just voting members).
Hopefully in most decisions, the votes are just a formality which
confirms the consensus (but if there isn't consensus, we still need to
be able to make a decision).

-Jim

__
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] [tc][forum] TC Retrospective for Queens/Rocky

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2018-05-29 17:26:16 -0400:

[snip]

> Chris brought up a concern about whether we have much traction on
> "doing stuff" and especially "getting things done that not everyone
> wants," Graham noted a lack of "visible impact," and Zane mentioned
> the TC vision in particular. Based on conversations last week, I
> am currently tracking a list of 20+ things the TC is working on. I
> will add the public ones to the wiki page this week as I catch up
> with my notes (remember, sometimes these things involve disputes
> that can be more smoothly handled one-on-one, so not everything
> that is going on is necessarily going to have its own email thread
> announcing it).

I have updated our tracking page in the wiki
(https://wiki.openstack.org/wiki/Technical_Committee_Tracker).

I listed drivers for the topics where I knew we had commitments. Several
of you raised issues, but I didn't want to volunteer anyone to work on
something just because they raised it.

I'm missing details and/or whole topics. Please review the list and
make any updates you think are necessary.

Doug

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

[openstack-dev] [tc] StarlingX project status update

[Mohammed Naser]

Hi everyone:

Over the past week in the summit, there was a lot of discussion
regarding StarlingX
and members of the technical commitee had a few productive discussions regarding
the best approach to deal with a proposed new pilot project for
incubation in the OSF's Edge
Computing strategic focus area: StarlingX.

If you're not aware, StarlingX includes forks of some OpenStack
components and other open source software
which contain certain features that are specific to edge and
industrial IoT computing use cases.  The code
behind the project is from Wind River (and is used to build a product
called "Titanium
Cloud").

At the moment, the goal of StarlingX hosting their projects on the
community infrastructure
is to get the developers used to the Gerrit workflow.  The intention
is to evenutally
work with upstream teams in order to bring the features and bug fixes which are
specific to the fork back upstream, with an ideal goal of bringing all
the differences
upstream.

We've discussed around all the different ways that we can approach
this and how to
help the StarlingX team be part of our community.  If we can
succesfully do this, it would
be a big success for our community as well as our community gaining
contributors from
the Wind River team.  In an ideal world, it's a win-win.

The plan at the moment is the following:
- StarlingX will have the first import of code that is not forked,
simply other software that
  they've developed to help deliver their product.  This code can be
hosted with no problems.
- StarlingX will generate a list of patches to be brought upstream and
the StarlingX team
  will work together with upstream teams in order to start backporting
and upstreaming the
  codebase.  Emilien Macchi (EmilienM) and I have volunteered to take
on the responsibility of
  monitoring the progress upstreaming these patches.
- StarlingX contains a few forks of other non-OpenStack software. The
StarlingX team will work
  with the authors of the original projects to ensure that they do not
mind us hosting a fork
  of their software.  If they don't, we'll proceed to host those
projects. If they prefer
  something else (hosting it themselves, placing it on another hosting
service, etc.),
  the StarlingX team will work with them in that way.

We discussed approaches for cases where patches aren't acceptable
upstream, because they
diverge from the project mission or aren't comprehensive. Ideally all
of those could be turned
into acceptable changes that meet both team's criteria. In some cases,
adding plugin interfaces
or driver interfaces may be the best alternative. Only as a last
resort would we retain the
forks for a long period of time.

From what was brought up, the team from Wind River is hoping to
on-board roughly 50 new full
time contributors.  In combination with the features that they've
built that we can hopefully
upstream, I am hopeful that we can come to a win-win situation for
everyone in this.

Regards,
Mohammed

__
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] Questions about token scopes

[Matt Riedemann]

On 5/30/2018 9:53 AM, Lance Bragstad wrote:

While scope isn't explicitly denoted by an
attribute, it can be derived from the attributes of the token response.



Yeah, this was confusing to me, which is why I reported it as a bug in 
the API reference documentation:


https://bugs.launchpad.net/keystone/+bug/1774229


* It looks like python-openstackclient doesn't allow specifying a
scope when issuing a token, is that going to be added?

Yes, I have a patch up for it [6]. I wanted to get this in during
Queens, but it missed the boat. I believe this and a new release of
oslo.context are the only bits left in order for services to have
everything they need to easily consume system-scoped tokens.
Keystonemiddleware should know how to handle system-scoped tokens in
front of each service [7]. The oslo.context library should be smart
enough to handle system scope set by keystonemiddleware if context is
built from environment variables [8]. Both keystoneauth [9] and
python-keystoneclient [10] should have what they need to generate
system-scoped tokens.

That should be enough to allow the service to pass a request environment
to oslo.context and use the context object to reason about the scope of
the request. As opposed to trying to understand different token scope
responses from keystone. We attempted to abstract that away in to the
context object.

[6]https://review.openstack.org/#/c/524416/
[7]https://review.openstack.org/#/c/564072/
[8]https://review.openstack.org/#/c/530509/
[9]https://review.openstack.org/#/c/529665/
[10]https://review.openstack.org/#/c/524415/


I think your reply in IRC was more what I was looking for:

lbragstad	mriedem: if you install 
https://review.openstack.org/#/c/524416/5 locally with devstack and 
setup a clouds.yaml, ``openstack token issue --os-cloud 
devstack-system-admin`` should work	15:39

lbragstad   http://paste.openstack.org/raw/722357/  15:39

So users with the system role will need to create a token using that 
role to get the system-scoped token, as far as I understand. There is no 
--scope option on the 'openstack token issue' CLI.



Uhm, if I understand your question, it depends on how you define the
scope types for those APIs. If you set them to system-scope, then an
operator will need to use a system-scoped token in order to access those
APIs iff the placement configuration file contains placement.conf
[oslo.policy] enforce_scope = True. Otherwise, setting that option to
false will log a warning to operators saying that someone is accessing a
system-scoped API with a project-scoped token (e.g. education needs to
happen).



All placement APIs will be system scoped for now, so yeah I guess if 
operators enable scope enforcement they'll just have to learn how to 
deal with system-scope enforced APIs.


Here is another random question:

Do we have any CI jobs running devstack/tempest with scope enforcement 
enabled to see what blows up?


--

Thanks,

Matt

__
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-Infra] Winterscale: a proposal regarding the project infrastructure

[Doug Hellmann]

Excerpts from Jeremy Stanley's message of 2018-05-30 17:30:23 +:
> On 2018-05-30 10:09:23 -0700 (-0700), James E. Blair wrote:
> [...]
> > An example of something that probably shouldn't move is
> > "openstack-zuul-jobs".  We still need people that are concerned with how
> > OpenStack uses the winterscale service.  I'm not sure whether that
> > should be its own team or should those functions get folded into other
> > teams.
> [...]
> 
> At least for some undefined transitional period, anything we think
> shouldn't move can remain the domain of the existing Infrastructure
> team under OpenStack TC governance. Once we get a better feel for
> what's left, that team will likely get scaled back to just the
> remaining interested maintainers and its continued governance
> situation can be revisited at that future date.

That feels like a good solution.

Doug

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

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Chris Dent]

On Wed, 30 May 2018, Julia Kreger wrote:


I don't feel like anyone is proposing to end the use of -1's, but that
we should generally be encouraging, accepting, and trusting.


Being encouraging, accepting, and trusting is the outcome I'd like
to see from this process. Being less nitpicking is a behavior or
process change. Adjusting attitudes (in some environments lightly,
in others more) so that we (where "we" is regulars in the projects,
experienced reviewers, and cores) perceive patches as something to
be grateful for and shepherded instead of an intrusion or obligation
would be a significant and beneficial culture change.

A perhaps more straightforward way to put it is: When someone (even
one of "us") submits a patch they are doing us (the same "we" as
above) a favor and we owe them not just a cordial and supportive
response, but one with some continuity.

Like many, I'm guilty of letting a false or inflated sense of urgency
get the better of me and being an ass in some reviews. Sorry about
that.

A cultural shift in this area will improve things for all of us.
Nitpicking is symptomatic of an attitude, one we can change, not the
disease itself.


We also need to be mindful
of context as well, and in the grand scheme not try for something
perfect as many often do. This *does* mean we land something that
needs to be fixed later or reverted later, but neither are things we
should fear. We can't let that fear control us.


Yes, very much yes.

--
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] [OpenStack-Infra] Winterscale: a proposal regarding the project infrastructure

[Doug Hellmann]

Excerpts from corvus's message of 2018-05-30 10:09:23 -0700:
> Doug Hellmann  writes:
> 
> >> * Move many of the git repos currently under the OpenStack project
> >>   infrastructure team's governance to this new team.
> >
> > I'm curious about the "many" in that sentence. Which do you anticipate
> > not moving, and if this new team replaces the existing team then who
> > would end up owning the ones that do not move?
> 
> There are a lot.  Generally speaking, I think most of the custom
> software, deployment tooling, and configuration would move.
> 
> An example of something that probably shouldn't move is
> "openstack-zuul-jobs".  We still need people that are concerned with how
> OpenStack uses the winterscale service.  I'm not sure whether that
> should be its own team or should those functions get folded into other
> teams.
> 
> >> * Establish a "winterscale infrastructure council" (to be renamed) which
> >>   will govern the services that the team provides by vote.  The council
> >>   will consist of the PTL of the winterscale infrastructure team and one
> >>   member from each official OpenStack Foundation project.  Currently, as
> >>   I understand it, there's only one: OpenStack.  But we expect kata,
> >>   zuul, and others to be declared official in the not too distant
> >>   future.  The winterscale representative (the PTL) will have
> >>   tiebreaking and veto power over council decisions.
> >
> > That structure seems sound, although it means the council is going
> > to be rather small (at least in the near term).  What sorts of
> > decisions do you anticipate needing to be addressed by this council?
> 
> Yes, very small.  Perhaps we need an interim structure until it gets
> larger?  Or perhaps just discipline and agreement that the two people on
> it will consult with the necessary constituencies and represent them
> well?

I don't want to make too much out of it, but it does feel a bit odd
to have a 2 person body where 1 person has the final decision power. :-)

Having 2 people per official team (including winterscale) would
give us more depth of coverage overall (allowing for quorum when
someone is on vacation, for example).  In the short term, it also
has the benefit of having twice as many people involved.

> I expect the council not to have to vote very often.  Perhaps only on
> substantial changes to services (bringing a new offering online,
> retiring a disused offering, establishing parameters of a service).  As
> an example, the recent thread on "terms of service" would be a good
> topic for the council to settle.

OK, so not on every change but on the significant ones that might affect
more than one project. Ideally any sort of conflict would be worked out
in advance, but it's good to have the process in place to resolve
problems before they come up.

Doug

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

Re: [openstack-dev] [tripleo] [barbican] [tc] key store in base services

[Ade Lee]

On Thu, 2018-05-17 at 09:58 +0200, Thierry Carrez wrote:
> Jeremy Stanley wrote:
> > [...]
> > As a community, we're likely to continue to make imbalanced
> > trade-offs against relevant security features if we don't move
> > forward and declare that some sort of standardized key storage
> > solution is a fundamental component on which OpenStack services can
> > rely. Being able to just assume that you can encrypt volumes in
> > Swift, even as a means to further secure a TripleO undercloud,
> > would
> > be a step in the right direction for security-minded deployments.
> > 
> > Unfortunately, I'm unable to find any follow-up summary on the
> > mailing list from the aforementioned session, but recollection from
> > those who were present (I had a schedule conflict at that time) was
> > that a Castellan-compatible key store would at least be a candidate
> > for inclusion in our base services list:
> > 
> > https://governance.openstack.org/tc/reference/base-services.html
> 
> Yes, last time this was discussed, there was lazy consensus that
> adding 
> "a Castellan-compatible secret store" would be a good addition to
> the 
> base services list if we wanted to avoid proliferation of half-baked 
> keystore implementations in various components.
> 
> The two blockers were:
> 
> 1/ castellan had to be made less Barbican-specific, offer at least
> one 
> other secrets store (Vault), and move under Oslo (done)
> 
> 2/ some projects (was it Designate ? Octavia ?) were relying on
> advanced 
> functions of Barbican not generally found in other secrets store,
> like 
> certificate generation, and so would prefer to depend on Barbican 
> itself, which confuses the messaging around the base service addition
> a 
> bit ("any Castellan-supported secret store as long as it's Barbican")
> 

As far as I know, Octavia no longer depends on barbican specific
functions.  Rather, they use castellan now.

And the current oslo-config work provides secrets through a castellan
backend.

So it seems that the two blockers above have been resolved. So is it
time to ad a castellan compatible secret store to the base services?

Ade   

__
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] CI Team Sprint 13 Summary

[Matt Young]

Greetings,

The TripleO CI team has just completed Sprint 13 (5/3 - 05/23).  The
following is a summary of activities during our sprint.   Details on our
team structure can be found in the spec [1].


# Sprint 13 Epic (CI Squad): Upgrade Support and Refactoring

- Epic Card: https://trello.com/c/cuKevn28/728-sprint-13-upgrades-goals
- Tasks: http://ow.ly/L86Y30kg75L

This sprint was spent with the CI squad focused on Upgrades.

We wanted to be able to use existing/working/tested CI collateral (ansible
playbooks and roles) used in CI today.  Throughout many of these are
references to  “{{ release }}” (e.g. ‘queens’, ‘pike’).  In order to not
retrofit the bulk of these with “upgrade aware” conditionals and/or logic
we needed a tool/module that could generate the inputs for the ‘release’
variable (and other similar inputs).   This allows us to reuse our common
roles and playbooks by decoupling the specifics of {upgrades, updates, FFU}
* {pike, queens, rocky,…}.  We’ve created this tool, and also put into
place a linting and unit tests for it as well.  We also made a few of the
jobs that had been prototyped and created in previous sprints voting, then
used them to validate changes to said jobs to wire in the new workflow/tool.

We are optimistic that work done in sprint 13 will prove useful in future
sprints.  A table to describe some of the problem set and our thinking
around variables used in CI is at [2].  The tool and tests are at [3].


# Sprint 13 Epic (Tempest Squad):

- Epic Card:
https://trello.com/c/efqE5XMr/82-sprint-13-refactor-python-tempestconf
- Tasks: http://ow.ly/LH8Q30kgd1C

In Sprint 13 the tempest squad was focused on refactoring
python-tempestconf.  It is the primary tool used by tempest users to
generate tempest.conf automatically so that users can easily run tempest
tests. Currently in TripleO and Infrared CI, we pass numerous parameters
manually via CLI.  This is cumbersome and error prone.

The high level goals were to reduce the number of default CLI overrides
used today, and to prepare python-tempestconf enabling better integration
with refstack-client.  This entailed service discoverability work.  We
added support for keystone, glance, cinder, swift, and neutron.  Additional
service support is planned for future sprints.  We also improved existing
documentation for python-tempestconf.


# Ruck & Rover (Sprint 13)

Sagi Shnaidman (sshnaidm), Matt Young (myoung)
https://review.rdoproject.org/etherpad/p/ruckrover-sprint13

A few notable issues where substantial time was spent are below.  Note that
this is not an inclusive list:

- When centos 7.5 was released, this caused a number of issues that
impacted gates.  This included deltas between package versions in BM vs.
container images, changes to centos that caused failures when modifying
images (e.g. IPA) in gates, and the like.
- We experienced issues with our promoter server, and the tripleo-infra
tenant generally around DNS and networking throughput, which impactacted
ability to process promotions.
- RHOS-13 jobs were created, and will eventually be used to gate changes to
TQ/TQE.
- Numerous patches/fixes to RDO Phase 2 jobs and CI infra. We had
accumulated technical debt.  While we have additional work to do,
particularly around some of the BM configs, we made good progress in
bringing various jobs back online.  We are still working on this in sprint
14 and moving forward.

Thanks,

The Tripleo CI team

[1]
https://specs.openstack.org/openstack/tripleo-specs/specs/policy/ci-team-structure.html
[2] https://wiki.openstack.org/wiki/Tripleo-upgrades-fs-variables
[3]
https://github.com/openstack-infra/tripleo-ci/blob/master/scripts/emit_releases_file
__
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] [barbican] [tc] key store in base services

[Ade Lee]

On Thu, 2018-05-17 at 10:33 +0200, Cédric Jeanneret wrote:
> 
> On 05/17/2018 10:18 AM, Bogdan Dobrelya wrote:
> > On 5/17/18 9:58 AM, Thierry Carrez wrote:
> > > Jeremy Stanley wrote:
> > > > [...]
> > > > As a community, we're likely to continue to make imbalanced
> > > > trade-offs against relevant security features if we don't move
> > > > forward and declare that some sort of standardized key storage
> > > > solution is a fundamental component on which OpenStack services
> > > > can
> > > > rely. Being able to just assume that you can encrypt volumes in
> > > > Swift, even as a means to further secure a TripleO undercloud,
> > > > would
> > > > be a step in the right direction for security-minded
> > > > deployments.
> > > > 
> > > > Unfortunately, I'm unable to find any follow-up summary on the
> > > > mailing list from the aforementioned session, but recollection
> > > > from
> > > > those who were present (I had a schedule conflict at that time)
> > > > was
> > > > that a Castellan-compatible key store would at least be a
> > > > candidate
> > > > for inclusion in our base services list:
> > > > 
> > > > https://governance.openstack.org/tc/reference/base-services.htm
> > > > l
> > > 
> > > Yes, last time this was discussed, there was lazy consensus that
> > > adding "a Castellan-compatible secret store" would be a good
> > > addition
> > > to the base services list if we wanted to avoid proliferation of
> > > half-baked keystore implementations in various components.
> > > 
> > > The two blockers were:
> > > 
> > > 1/ castellan had to be made less Barbican-specific, offer at
> > > least one
> > > other secrets store (Vault), and move under Oslo (done)
> > 
> > Back to the subject and tripleo underclouds running Barbican, using
> > vault as a backend may be a good option, given that openshift
> > supports
> > [0] it as well for storing k8s secrets, and kubespray does [1] for
> > vanilla k8s deployments, and that we have openshift/k8s-based
> > control
> > plane for openstack on the integration roadmap. So we'll highly
> > likely
> > end up running Barbican/Vault on undercloud anyway.
> > 
> > [0]
> > https://blog.openshift.com/managing-secrets-openshift-vault-integra
> > tion/
> > [1]
> > https://github.com/kubernetes-incubator/kubespray/blob/master/docs/
> > vault.md
> > 
> 
> That just sounds lovely, especially since this allows to converge
> "secure storage" tech between projects.
> On my own, I was considering some secure storage (custodia) in the
> context of the public TLS certificate storage/update/provisioning.
> Having by default a native way to store secrets used by the overcloud
> deploy/life is a really good thing, and will prevent leaks, having
> ardcoded passwords in files and so on (although, yeah, you'll need
> something to access barbican ;)).
> 

I think that for consistency sake, we will want to use a Castellan-
compatible back-end in the undercloud, rather than something more
custom like a LUKS encrypted partition or similar.

Right now, that means either castellan -> vault or castellan->
barbican.  In the future, it could also mean castellan-> custodia.

If you do use Barbican, you could still use vault as a backend to
Barbican.  ie. castellan -> barbican -> vault.

 
> > > 
> > > 2/ some projects (was it Designate ? Octavia ?) were relying on
> > > advanced functions of Barbican not generally found in other
> > > secrets
> > > store, like certificate generation, and so would prefer to depend
> > > on
> > > Barbican itself, which confuses the messaging around the base
> > > service
> > > addition a bit ("any Castellan-supported secret store as long as
> > > it's
> > > Barbican")
> > > 
> > 
> > 
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] [OpenStack-Infra] Winterscale: a proposal regarding the project infrastructure

[Anita Kuno]

On 2018-05-30 12:25 PM, James E. Blair wrote:

I propose we call the overall effort "winterscale".  In the best
tradition of code names, it means nothing; look for no hidden meaning
here.  We won't use it for any actual services we provide.  We'll use it
to refer to the overall effort of restructuring our team and
infrastructure to provide services to projects beyond OpenStack itself.
And we'll stop using it when the restructuring effort is concluded.


I think as names with no meaning go, this is one I find acceptable.

Thank you Jim,
Anita

__
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] spec review day next week Tuesday 2018-06-05

[melanie witt]

Howdy all,

This cycle, we have our spec freeze later than usual at milestone r-2 
June 7 because of the review runways system we've been trying out. We 
wanted to allow more time for spec approvals as blueprints were 
completed via runways.


So, ahead of the spec freeze, let's have a spec review day next week 
Tuesday June 5 to ensure we get what spec approvals we can over the line 
before the freeze. Please try to make some time on Tuesday to review 
some specs and thanks in advance for participating!


Cheers,
-melanie

__
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] [tc][all] A culture change (nitpicking)

[Davanum Srinivas]

Please see below:

On Wed, May 30, 2018 at 2:37 PM, Chris Dent  wrote:
> On Wed, 30 May 2018, Julia Kreger wrote:
>
>> I don't feel like anyone is proposing to end the use of -1's, but that
>> we should generally be encouraging, accepting, and trusting.
>
>
> Being encouraging, accepting, and trusting is the outcome I'd like
> to see from this process. Being less nitpicking is a behavior or
> process change. Adjusting attitudes (in some environments lightly,
> in others more) so that we (where "we" is regulars in the projects,
> experienced reviewers, and cores) perceive patches as something to
> be grateful for and shepherded instead of an intrusion or obligation
> would be a significant and beneficial culture change.
>
> A perhaps more straightforward way to put it is: When someone (even
> one of "us") submits a patch they are doing us (the same "we" as
> above) a favor and we owe them not just a cordial and supportive
> response, but one with some continuity.
>
> Like many, I'm guilty of letting a false or inflated sense of urgency
> get the better of me and being an ass in some reviews. Sorry about
> that.
>
> A cultural shift in this area will improve things for all of us.
> Nitpicking is symptomatic of an attitude, one we can change, not the
> disease itself.
>
>> We also need to be mindful
>> of context as well, and in the grand scheme not try for something
>> perfect as many often do. This *does* mean we land something that
>> needs to be fixed later or reverted later, but neither are things we
>> should fear. We can't let that fear control us.

Let me poke at this a bit. Some of the projects do say (not in so many words):

"master should be always deployable and fully backward compatible and
so we cant let anything in anytime that could possibly regress anyone"

Should we change that attitude too? Anyone agree? disagree?

Thanks,
Dims

>
> Yes, very much yes.
>
> --
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [tc][all] A culture change (nitpicking)

[Amy Marrich]

Coming from Ops, yes things should always be deployable, backward
compatible and shouldn't break, but at the same time we're talking about a
master branch which is always in flux and not an actual release. I think
that statement you provided Dims should apply to releases or tags and not
the master branch as a whole. And to be honest unless someone desperately
needed something just committed into master, I doubt most folks are using
master in dev let alone production, at least that's my hope.

We can't move forward as a community if we don't welcome new members to it,
which is the heart of this proposal.

Amy (spotz)

On Wed, May 30, 2018 at 2:50 PM, Davanum Srinivas  wrote:

> Please see below:
>
> On Wed, May 30, 2018 at 2:37 PM, Chris Dent 
> wrote:
> > On Wed, 30 May 2018, Julia Kreger wrote:
> >
> >> I don't feel like anyone is proposing to end the use of -1's, but that
> >> we should generally be encouraging, accepting, and trusting.
> >
> >
> > Being encouraging, accepting, and trusting is the outcome I'd like
> > to see from this process. Being less nitpicking is a behavior or
> > process change. Adjusting attitudes (in some environments lightly,
> > in others more) so that we (where "we" is regulars in the projects,
> > experienced reviewers, and cores) perceive patches as something to
> > be grateful for and shepherded instead of an intrusion or obligation
> > would be a significant and beneficial culture change.
> >
> > A perhaps more straightforward way to put it is: When someone (even
> > one of "us") submits a patch they are doing us (the same "we" as
> > above) a favor and we owe them not just a cordial and supportive
> > response, but one with some continuity.
> >
> > Like many, I'm guilty of letting a false or inflated sense of urgency
> > get the better of me and being an ass in some reviews. Sorry about
> > that.
> >
> > A cultural shift in this area will improve things for all of us.
> > Nitpicking is symptomatic of an attitude, one we can change, not the
> > disease itself.
> >
> >> We also need to be mindful
> >> of context as well, and in the grand scheme not try for something
> >> perfect as many often do. This *does* mean we land something that
> >> needs to be fixed later or reverted later, but neither are things we
> >> should fear. We can't let that fear control us.
>
> Let me poke at this a bit. Some of the projects do say (not in so many
> words):
>
> "master should be always deployable and fully backward compatible and
> so we cant let anything in anytime that could possibly regress anyone"
>
> Should we change that attitude too? Anyone agree? disagree?
>
> Thanks,
> Dims
>
> >
> > Yes, very much yes.
> >
> > --
> > 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
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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] [oslo] Summit onboarding and project update slides

[Ben Nemec]

As promised in the sessions, here are the slides that were presented:

https://www.slideshare.net/BenNemec1/oslo-vancouver-onboarding

https://www.slideshare.net/BenNemec1/oslo-vancouver-project-update

The font in the onboarding one got a little funny in the conversion, so 
if you want to see the original that is more readable let me know and I 
can send it to you.


-Ben

__
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] [stable][kolla] tagging newton EOL

[Tony Breeds]

On Sat, Apr 14, 2018 at 11:02:54AM +0800, Jeffrey Zhang wrote:
> hi stable team,
> 
> Kolla project is ready for Newton EOL.  Since kolla-ansible is split from
> kolla since ocata cycle, so there is not newton branch in kolla-ansible.
> please make following repo EOL
> 
> openstack/kolla

Okay I did this today but to be perfectly frank I suspect I've done it
wrong.

There was already an existing tag for newton-eol pointing at
3.0.3-20'ish so I tagged what was the HEAD of the existing newton branch
which was 3.0.0.0rc1-335'ish:

About to delete the branch stable/newton from openstack/kolla (rev 
40e768ec2a370dc010be773af37e2ce417adda80)

I'm not really sure about the history there.  I apologise if I've made a
mistake.

but at least as we have everything in git we can recover the branches
and retag if required.

Yours Tony.


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] [tc][all] A culture change (nitpicking)

[Jeremy Stanley]

On 2018-05-30 14:50:11 -0700 (-0700), Davanum Srinivas wrote:
[...]
> Let me poke at this a bit. Some of the projects do say (not in so
> many words):
> 
> "master should be always deployable and fully backward compatible and
> so we cant let anything in anytime that could possibly regress anyone"
> 
> Should we change that attitude too? Anyone agree? disagree?

I think this is orthogonal to the thread. The idea is that we should
avoid nettling contributors over minor imperfections in their
submissions (grammatical, spelling or typographical errors in code
comments and documentation, mild inefficiencies in implementations,
et cetera). Clearly we shouldn't merge broken features, changes
which fail tests/linters, and so on. For me the rule of thumb is,
"will the software be better or worse if this is merged?" It's not
about perfection or imperfection, it's about incremental
improvement. If a proposed change is an improvement, that's enough.
If it's not perfect... well, that's just opportunity for more
improvement later.
-- 
Jeremy Stanley


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

[openstack-dev] Ceph multiattach support

[fengyd]

 Hi,

I'm using Ceph for cinder backend.
Do you have any plan to support multiattach for Ceph backend?

Thanks

Yafeng
__
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] core team update

[melanie witt]

Howdy everyone,

As I'm sure many of you have noticed, Sean Dague has shifted his focus 
onto other projects outside of Nova for some time now, and with that, 
I'm removing him from the core team at this time.


I consider our team fortunate to have had the opportunity to work with 
Sean over the years and he is certainly welcome back to the core team if 
he returns to active reviewing someday in the future. Thank you Sean, 
for all of your contributions!


Best,
-melanie

__
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] [tc][all] A culture change (nitpicking)

[Jeremy Stanley]

On 2018-05-31 00:21:35 + (+), Fox, Kevin M wrote:
> To play devils advocate and as someone that has had to git bisect
> an ugly regression once I still think its important not to break
> trunk. It can be much harder to deal with difficult issues like
> that if trunk frequently breaks.
[...]

Agreed. We made a choice as a community early on to avoid doing
that. (Almost) always deployable is (almost) always testable; if
trunk is broken, then as a developer working on a bugfix or new
feature you have to hunt for a known-working state in the history to
develop against and then rebase onto all the broken and cross your
fingers that you're not making the job of whoever has to untangle
trunk before release that much harder.
-- 
Jeremy Stanley


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] [tc][all] A culture change (nitpicking)

[Matthew Treinish]

On Thu, May 31, 2018 at 12:21:35AM +, Fox, Kevin M wrote:
> To play devils advocate and as someone that has had to git bisect an ugly 
> regression once I still think its important not to break trunk. It can be 
> much harder to deal with difficult issues like that if trunk frequently 
> breaks.
> 
> Thanks,
> Kevin
> 
> From: Sean McGinnis [sean.mcgin...@gmx.com]
> Sent: Wednesday, May 30, 2018 5:01 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [tc][all] A culture change (nitpicking)
> 
> > "master should be always deployable and fully backward compatible and
> > so we cant let anything in anytime that could possibly regress anyone"
> >
> > Should we change that attitude too? Anyone agree? disagree?
> >
> > Thanks,
> > Dims
> >
> I'll definitely jump at this one.
> 
> I've always thought (and shared on the ML several times now) that our
> implied
> but not explicit support for CD from any random commit was a bad thing.
> 
> While I think it's good to support the idea that master is always
> deployable, I
> do not think it is a good mindset to think that every commit is a
> "release" and
> therefore should be supported until the end of time. We have a coordinated
> release for a reason, and I think design decisions and fixes should be
> based on
> the assumption that a release is a release and the point at which we
> need to be
> cognizant and caring about keeping backward compatibility. Doing that for
> every single commit is not ideal for the overall health of the product, IMO.
> 

It's more than just a CD guarantee, while from a quick glance it would seem like
that's the only value it goes much deeper than that. Ensuring that every commit
works, is deployable, and maintains backwards compatibility is what enables us
to have such a high quality end result at release time. Quite frankly it's
looking at every commit as always being a working unit that enables us to manage
a project this size at this velocity. Even if people assume no one is actually
CDing the projects(which we shouldn't), it's a flawed assumption to think that
everyone is running strictly the same code as what's in the release tarballs. I
can't think of any production cloud out there that doesn't carry patches to fix
things encountered in the real world. Or look at stable maint we regularly need
to backport fixes to fix bugs found after release. If we can't rely on these to
always work this makes our life much more difficult, both as upstream
maintainers but also as downstream consumers of OpenStack.

The other aspect to look at here is just the review mindset, supporting every
every commit is useable puts reviewers in the mindset to consider things like
backwards compatibility and deployability when looking at proposed changes. If
we stop looking for these potential issues, we t will also cause many more bugs
to be in our released code. To simply discount this as only a release concern
and punt this kind of scrutiny until it's time to release is not only going to
make release time much more stressful. Also, our testing is built to try and
ensure every commit works **before** we merge it. If we decided to take this
stance as a community then we should really just rip out all the testing,
because that's what it's there to verify and help us make sure we don't land a
change that doesn't work. If we don't actually care about that making sure every
commit is deployable we are wasting quite a lot of resources on it.

-Matt Treinish


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

[openstack-dev] [swift] change in review policy: normally one +2 is sufficient

[John Dickinson]

During today's Swift team meeting[1], we discussed the idea of
relaxing review guidelines. We agreed the normal case is "one core
reviewer's approval is sufficient to land code".

We've long had a "one +2" policy for trivial and obviously correct
patches. Put simply, the old policy was one of "normally, two +2s are
needed, but if a reviewer feels it's not necessary to get another
review, go ahead and land it." Our new policy inverts that. Normally,
one +2 is needed, but a core may want to ask for additional reviews
for significant or complex patches.

When the Swift team gathers in Denver for the next PTG, we'll spend
some time revisiting this decision and reflect on the impact it has
had for the community and codebase.

[1] 
http://eavesdrop.openstack.org/meetings/swift/2018/swift.2018-05-30-21.00.log.html



--John




__
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] [OpenStackAnsible] Tag repos as newton-eol

[Tony Breeds]

On Sun, Apr 29, 2018 at 09:36:15AM +0200, Jean-Philippe Evrard wrote:
> Hello,
> 
> > I'd like to phase out openstack/openstack-ansible-tests and
> > openstack/openstack-ansible later.
> 
> Now that we had the time to bump the roles in openstack-ansible, and
> adapt the tests, we can now EOL the rest of newton, i.e.:
> openstack/openstack-ansible and openstack/openstack-ansible-tests.
> 
> Thanks for the help again Tony!

Done.

http://git.openstack.org/cgit/openstack/openstack-ansible/tag/?h=newton-eol
http://git.openstack.org/cgit/openstack/openstack-ansible-tests/tag/?h=newton-eol

Sorry for the delay.

Yours Tony.


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] [tc][all] A culture change (nitpicking)

[Fox, Kevin M]

To play devils advocate and as someone that has had to git bisect an ugly 
regression once I still think its important not to break trunk. It can be much 
harder to deal with difficult issues like that if trunk frequently breaks.

Thanks,
Kevin

From: Sean McGinnis [sean.mcgin...@gmx.com]
Sent: Wednesday, May 30, 2018 5:01 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tc][all] A culture change (nitpicking)

> "master should be always deployable and fully backward compatible and
> so we cant let anything in anytime that could possibly regress anyone"
>
> Should we change that attitude too? Anyone agree? disagree?
>
> Thanks,
> Dims
>
I'll definitely jump at this one.

I've always thought (and shared on the ML several times now) that our
implied
but not explicit support for CD from any random commit was a bad thing.

While I think it's good to support the idea that master is always
deployable, I
do not think it is a good mindset to think that every commit is a
"release" and
therefore should be supported until the end of time. We have a coordinated
release for a reason, and I think design decisions and fixes should be
based on
the assumption that a release is a release and the point at which we
need to be
cognizant and caring about keeping backward compatibility. Doing that for
every single commit is not ideal for the overall health of the product, IMO.

__
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] Ceph multiattach support

[Alan Bishop]

On Wed, May 30, 2018 at 10:00 PM, fengyd  wrote:
> Hi,
>
> I'm using Ceph for cinder backend.
> Do you have any plan to support multiattach for Ceph backend?

A lot of people have expressed an interest in this, so I'm sure
multi-attach with Ceph will eventually be supported. However, it will
require a fair amount of investigation to fully understand what is
needed for the feature to work correctly. The situation is summarized
in a comment in the Cinder code [1].

[1] 
https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/rbd.py#L486

Alan

> Thanks
>
> Yafeng
>
> __
> 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] [tc][all] A culture change (nitpicking)

[Sean McGinnis]

"master should be always deployable and fully backward compatible and
so we cant let anything in anytime that could possibly regress anyone"

Should we change that attitude too? Anyone agree? disagree?

Thanks,
Dims


I'll definitely jump at this one.

I've always thought (and shared on the ML several times now) that our 
implied

but not explicit support for CD from any random commit was a bad thing.

While I think it's good to support the idea that master is always 
deployable, I
do not think it is a good mindset to think that every commit is a 
"release" and

therefore should be supported until the end of time. We have a coordinated
release for a reason, and I think design decisions and fixes should be 
based on
the assumption that a release is a release and the point at which we 
need to be

cognizant and caring about keeping backward compatibility. Doing that for
every single commit is not ideal for the overall health of the product, IMO.

__
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] Ceph multiattach support

[Erik McCormick]

The lack of ceph support is a ceph problem rather than a Cinder problem.
There are issues with replication and multi-attached RBD volumes asd I
understand it. The ceph folks are aware but have other priorities
presently. I encourage making your interest known to them.

In the meantime,  check out Manilla with cephfs if you are running modern
versions of both Ceph and Openstack.

-Erik



On Wed, May 30, 2018, 10:02 PM fengyd  wrote:

> Hi,
>
> I'm using Ceph for cinder backend.
> Do you have any plan to support multiattach for Ceph backend?
>
> Thanks
>
> Yafeng
> __
> 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] [tripleo] The Weekly Owl - 22th Edition

[Emilien Macchi]

Welcome to the twenty second edition of a weekly update in TripleO world!
The goal is to provide a short reading (less than 5 minutes) to learn
what's new this week.
Any contributions and feedback are welcome.
Link to the previous version:
http://lists.openstack.org/pipermail/openstack-dev/2018-May/130528.html

+-+
| General announcements |
+-+

+--> OpenStack community met last week for the Summit in Vancouver, we had
great presentations and also great feedback!
+--> Milestone 2 deadline is next week!

+-+
| Owls at Summit |
+-+

+--> TripleO project updates: from Queens to Rocky and beyond
Recording: https://www.youtube.com/watch?v=4q_zkvOP8Dk
Slides: https://t.co/DYOAjt1jDk

+--> TripleO onboarding session:
https://etherpad.openstack.org/p/YVR-forum-tripleo-onboarding
People used that time to ask any questions about TripleO and the team was
happy to answer and provide support.

+--> TripleO Ops and User Feedback:
https://etherpad.openstack.org/p/tripleo-rocky-ops-and-user-feedback
Feedback about logging, documentation were the main topics we covered but
other things were discussed, see etherpad.

+--> TripleO and Ansible integration:
https://etherpad.openstack.org/p/tripleo-rocky-ansible-integration
James did a great job at presenting the config-download feature and how we
now use Ansible for some deployment tasks.

+--+
| Continuous Integration |
+--+

+--> Ruck is arxcruz and Rover is rlandy. Please let them know any new CI
issue.
+--> Master promotion is 0 day, Queens is 0 days, Pike is 3 days and Ocata
is 4 days.
+--> Sprint 13 themes were Upgrade CI (new jobs, forward looking release
state machine, voting jobs).
+--> More: https://etherpad.openstack.org/p/tripleo-ci-squad-meeting

+-+
| Upgrades |
+-+

+--> FFU at Summit: https://www.youtube.com/watch?v=YJXem5d6fkI
+--> Need reviews converge patches and docs updates
+--> More: https://etherpad.openstack.org/p/tripleo-upgrade-squad-status

+---+
| Containers |
+---+

+--> Efforts arounds all-in-one installer, image prepare and image
workflows, good progress overall.
+--> Focus is on stabilization and make the containerized undercloud the
default in TripleO.
+--> Tomorrow is containerized undercloud deep dive: https://etherpad.
openstack.org/p/tripleo-deep-dive-containerized-undercloud
+--> More: https://etherpad.openstack.org/p/tripleo-containers-squad-status

+--+
| config-download |
+--+

+--> config download status commands and workflows
+--> UI work still ongoing
+--> Major doc update (merged): https://review.openstack.org/#/c/566606
+--> More: https://etherpad.openstack.org/p/tripleo-config-downlo
ad-squad-status

+--+
| Integration |
+--+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-integration-squad-status

+-+
| UI/CLI |
+-+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-ui-cli-squad-status

+---+
| Validations |
+---+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-validations-squad-status

+---+
| Networking |
+---+

+--> No updates this week.
+--> More: https://etherpad.openstack.org/p/tripleo-networking-squad-status

+--+
| Workflows |
+--+

+--> Mistral project update https://www.youtube.com/watch?v=y9qieruccO4
+--> Validate workflow input:
https://bugs.launchpad.net/tripleo/+bug/1774166
+--> More: https://etherpad.openstack.org/p/tripleo-workflows-squad-status

+---+
| Security |
+---+

+--> Public TLS is being refactored
+--> Kerberos auth for keystone update
+--> More: https://etherpad.openstack.org/p/tripleo-security-squad

++
| Owl fact  |
++

Owl flight is silent, unlike most birds, owls make virtually no noise when
they fly. They have special feathers that break turbulence into smaller
currents, which reduces sound. Soft velvety down further muffles noise.
Source: http://mentalfloss.com/article/68473/15-mysterious-facts-about-owls

Thank you all for reading and stay tuned!
--
Your fellow reporter, Emilien Macchi
__
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] [tc][all] A culture change (nitpicking)

[Davanum Srinivas]

On Wed, May 30, 2018 at 5:23 PM, Jeremy Stanley  wrote:
> On 2018-05-30 14:50:11 -0700 (-0700), Davanum Srinivas wrote:
> [...]
>> Let me poke at this a bit. Some of the projects do say (not in so
>> many words):
>>
>> "master should be always deployable and fully backward compatible and
>> so we cant let anything in anytime that could possibly regress anyone"
>>
>> Should we change that attitude too? Anyone agree? disagree?
>
> I think this is orthogonal to the thread. The idea is that we should
> avoid nettling contributors over minor imperfections in their
> submissions (grammatical, spelling or typographical errors in code
> comments and documentation, mild inefficiencies in implementations,
> et cetera). Clearly we shouldn't merge broken features, changes
> which fail tests/linters, and so on. For me the rule of thumb is,
> "will the software be better or worse if this is merged?" It's not
> about perfection or imperfection, it's about incremental
> improvement. If a proposed change is an improvement, that's enough.
> If it's not perfect... well, that's just opportunity for more
> improvement later.

Well said Jeremy!

> --
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] Winterscale: a proposal regarding the project infrastructure

[Joshua Hesketh]

On Thu, May 31, 2018 at 2:25 AM, James E. Blair  wrote:

> Hi,
>
> With recent changes implemented by the OpenStack Foundation to include
> projects other than "OpenStack" under its umbrella, it has become clear
> that the "Project Infrastructure Team" needs to change.
>
> The infrastructure that is run for the OpenStack project is valued by
> other OpenStack Foundation projects (and beyond).  Our community has not
> only produced an amazing cloud infrastructure system, but it has also
> pioneered new tools and techniques for software development and
> collaboration.
>
> For some time it's been apparent that we need to alter the way we run
> services in order to accommodate other Foundation projects.  We've been
> talking about this informally for at least the last several months.  One
> of the biggest sticking points has been a name for the effort.  It seems
> very likely that we will want a new top-level domain for hosting
> multiple projects in a neutral environment (so that people don't have to
> say "hosted on OpenStack's infrastructure").  But finding such a name is
> difficult, and even before we do, we need to talk about it.
>
> I propose we call the overall effort "winterscale".  In the best
> tradition of code names, it means nothing; look for no hidden meaning
> here.  We won't use it for any actual services we provide.  We'll use it
> to refer to the overall effort of restructuring our team and
> infrastructure to provide services to projects beyond OpenStack itself.
> And we'll stop using it when the restructuring effort is concluded.
>
> This is my first proposal: that we acknowledge this effort is underway
> and name it as such.
>
> My second proposal is an organizational structure for this effort.
> First, some goals:
>
> * The infrastructure should be collaboratively run as it is now, and
>   the operational decisions should be made by the core reviewers as
>   they are now.
>
> * Issues of service definition (i.e., what services we offer and how
>   they are used) should be made via a collaborative process including
>   the infrastructure operators and the projects which use it.
>
> To that end, I propose that we:
>
> * Work with the Foundation to create a new effort independent of the
>   OpenStack project with the goal of operating infrastructure for the
>   wider OpenStack Foundation community.
>
> * Work with the Foundation marketing team to help us with the branding
>   and marketing of this effort.
>
> * Establish a "winterscale infrastructure team" (to be renamed)
>   consisting of the current infra-core team members to operate this
>   effort.
>
> * Move many of the git repos currently under the OpenStack project
>   infrastructure team's governance to this new team.
>
> * Establish a "winterscale infrastructure council" (to be renamed) which
>   will govern the services that the team provides by vote.  The council
>   will consist of the PTL of the winterscale infrastructure team and one
>   member from each official OpenStack Foundation project.  Currently, as
>   I understand it, there's only one: OpenStack.  But we expect kata,
>   zuul, and others to be declared official in the not too distant
>   future.  The winterscale representative (the PTL) will have
>   tiebreaking and veto power over council decisions.
>


So the "winterscale infrastructure council"'s purview is quite limited in
scope to just govern the services provided?

If so, would you foresee a need to maintain some kind of "Infrastructure
council" as it exists at the moment to be the technical design body?

Specifically, wouldn't we still want somewhere for the "winterscale
infrastructure team" to be represented and would that expand to any
infrastructure-related core teams?

Cheers,
Josh




>
>   (This is structured loosely based on the current Infrastructure
>   Council used by the OpenStack Project Infrastructure Team.)
>
> None of this is obviously final.  My goal here is to give this effort a
> name and a starting point so that we can discuss it and make progress.
>
> -Jim
>
> __
> 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] [tc][all] A culture change (nitpicking)

[Davanum Srinivas]

On Wed, May 30, 2018 at 6:09 PM, Matthew Treinish  wrote:
> On Thu, May 31, 2018 at 12:21:35AM +, Fox, Kevin M wrote:
>> To play devils advocate and as someone that has had to git bisect an ugly 
>> regression once I still think its important not to break trunk. It can be 
>> much harder to deal with difficult issues like that if trunk frequently 
>> breaks.
>>
>> Thanks,
>> Kevin
>> 
>> From: Sean McGinnis [sean.mcgin...@gmx.com]
>> Sent: Wednesday, May 30, 2018 5:01 PM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [tc][all] A culture change (nitpicking)
>>
>> > "master should be always deployable and fully backward compatible and
>> > so we cant let anything in anytime that could possibly regress anyone"
>> >
>> > Should we change that attitude too? Anyone agree? disagree?
>> >
>> > Thanks,
>> > Dims
>> >
>> I'll definitely jump at this one.
>>
>> I've always thought (and shared on the ML several times now) that our
>> implied
>> but not explicit support for CD from any random commit was a bad thing.
>>
>> While I think it's good to support the idea that master is always
>> deployable, I
>> do not think it is a good mindset to think that every commit is a
>> "release" and
>> therefore should be supported until the end of time. We have a coordinated
>> release for a reason, and I think design decisions and fixes should be
>> based on
>> the assumption that a release is a release and the point at which we
>> need to be
>> cognizant and caring about keeping backward compatibility. Doing that for
>> every single commit is not ideal for the overall health of the product, IMO.
>>
>
> It's more than just a CD guarantee, while from a quick glance it would seem 
> like
> that's the only value it goes much deeper than that. Ensuring that every 
> commit
> works, is deployable, and maintains backwards compatibility is what enables us
> to have such a high quality end result at release time. Quite frankly it's
> looking at every commit as always being a working unit that enables us to 
> manage
> a project this size at this velocity. Even if people assume no one is actually
> CDing the projects(which we shouldn't), it's a flawed assumption to think that
> everyone is running strictly the same code as what's in the release tarballs. 
> I
> can't think of any production cloud out there that doesn't carry patches to 
> fix
> things encountered in the real world. Or look at stable maint we regularly 
> need
> to backport fixes to fix bugs found after release. If we can't rely on these 
> to
> always work this makes our life much more difficult, both as upstream
> maintainers but also as downstream consumers of OpenStack.
>
> The other aspect to look at here is just the review mindset, supporting every
> every commit is useable puts reviewers in the mindset to consider things like
> backwards compatibility and deployability when looking at proposed changes. If
> we stop looking for these potential issues, we t will also cause many more 
> bugs
> to be in our released code. To simply discount this as only a release concern
> and punt this kind of scrutiny until it's time to release is not only going to
> make release time much more stressful. Also, our testing is built to try and
> ensure every commit works **before** we merge it. If we decided to take this
> stance as a community then we should really just rip out all the testing,
> because that's what it's there to verify and help us make sure we don't land a
> change that doesn't work. If we don't actually care about that making sure 
> every
> commit is deployable we are wasting quite a lot of resources on it.

"rip out all testing" is probably taking it too far Matt.

 Instead of perfection when merging, we should look for iteration and
reverts. That's what i would like to see. I am not asking for a
"Commit-Then-Review" like the ASF. I want us to be just be practical
and have some leeway to iterate / update / experiment instead of
absolute perfection from all angles. We should move the needle at
least a bit away from it.

>
> -Matt Treinish
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] Questions about token scopes

[Ghanshyam Mann]

On Wed, May 30, 2018 at 11:53 PM, Lance Bragstad  wrote:
>
>
> On 05/30/2018 08:47 AM, Matt Riedemann wrote:
>> I know the keystone team has been doing a lot of work on scoped tokens
>> and Lance has been trying to roll that out to other projects (like nova).
>>
>> In Rocky the nova team is adding granular policy rules to the
>> placement API [1] which is a good opportunity to set scope on those
>> rules as well.
>>
>> For now, we've just said everything is system scope since resources in
>> placement, for the most part, are managed by "the system". But we do
>> have some resources in placement which have project/user information
>> in them, so could theoretically also be scoped to a project, like GET
>> /usages [2].

Just adding that this is same for nova policy also. As you might know
spec[1] try to make nova policy more granular but on hold because of
default roles things. We will do policy rule split with more better
defaults values like read-only for GET APIs.

Along with that, like you mentioned about scope setting for placement
policy rules, we need to do same for nova policy also. That can be
done later or together with nova policy granular. spec.

[1] https://review.openstack.org/#/c/547850/

>>
>> While going through this, I've been hammering Lance with questions but
>> I had some more this morning and wanted to send them to the list to
>> help spread the load and share the knowledge on working with scoped
>> tokens in the other projects.
>
> ++ good idea
>
>>
>> So here goes with the random questions:
>>
>> * devstack has the admin project/user - does that by default get
>> system scope tokens? I see the scope is part of the token create
>> request [3] but it's optional, so is there a default value if not
>> specified?
>
> No, not necessarily. The keystone-manage bootstrap command is what
> bootstraps new deployments with the admin user, an admin role, a project
> to work in, etc. It also grants the newly created admin user the admin
> role on a project and the system. This functionality was added in Queens
> [0]. This should be backwards compatible and allow the admin user to get
> tokens scoped to whatever they had authorization on previously. The only
> thing they should notice is that they have another role assignment on
> something called the "system". That being said, they can start
> requesting system-scoped tokens from keystone. We have a document that
> tries to explain the differences in scopes and what they mean [1].

Another related question is, does scope setting will impact existing
operator? I mean when policy rule start setting scope, that might
break the existing operator as their current token (say project
scoped) might not be able to authorize the policy modified with
setting the system scope.

In that case, how we are going to avoid the upgrade break. One way can
be to soft enforcement scope things for a cycle with warning and then
start enforcing that after one cycle (like we do for any policy rule
change)? but not sure at this point.

>
> [0] https://review.openstack.org/#/c/530410/
> [1] https://docs.openstack.org/keystone/latest/admin/identity-tokens.html
>
>>
>> * Why don't the token create and show APIs return the scope?
>
> Good question. In a way, they do. If you look at a response when you
> authenticate for a token or validate a token, you should see an object
> contained within the token reference for the purpose of scope. For
> example, a project-scoped token will have a project object in the
> response [2]. A domain-scoped token will have a domain object in the
> response [3]. The same is true for system scoped tokens [4]. Unscoped
> tokens do not have any of these objects present and do not contain a
> service catalog [5]. While scope isn't explicitly denoted by an
> attribute, it can be derived from the attributes of the token response.
>
> [2] http://paste.openstack.org/raw/722349/
> [3] http://paste.openstack.org/raw/722351/
> [4] http://paste.openstack.org/raw/722348/
> [5] http://paste.openstack.org/raw/722350/
>
>
>>
>> * It looks like python-openstackclient doesn't allow specifying a
>> scope when issuing a token, is that going to be added?
>
> Yes, I have a patch up for it [6]. I wanted to get this in during
> Queens, but it missed the boat. I believe this and a new release of
> oslo.context are the only bits left in order for services to have
> everything they need to easily consume system-scoped tokens.
> Keystonemiddleware should know how to handle system-scoped tokens in
> front of each service [7]. The oslo.context library should be smart
> enough to handle system scope set by keystonemiddleware if context is
> built from environment variables [8]. Both keystoneauth [9] and
> python-keystoneclient [10] should have what they need to generate
> system-scoped tokens.
>
> That should be enough to allow the service to pass a request environment
> to oslo.context and use the context object to reason about the scope of
> the request. As opposed to trying 

Re: [openstack-dev] [horizon] Font awesome currently broken with Debian Sid and Horizon

[Thomas Goirand]

On 05/30/2018 04:13 PM, Ivan Kolodyazhny wrote:
> Hi Thomas,
>  
> 
> As my python3-xstatic-font-awesome removes the embedded fonts
> 
> 
> It sounds like you broke xstatic-* packages for Debian and use something
> we don't test with Horizon at all.
> 
> Speaking about Rocky/master version, our upper-constraint
> XStatic-Font-Awesome===4.7.0.0 [1]. We don't test horizon with font
> awesome v 5.0.10.
> 
> 
> Second, it'd be nice if Horizon could adapt and use the new v5
> font-awesome, so that the problem is completely solved.
> 
> +1. I'll put my +2/A once somebody provides a patch for it with a
> detailed description how can I test it. Unfortunately, Horizon team has
> a very limited set of resources, so we can't adopt new version of
> xstatic-* fast :(.
> 
> [1] 
> https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L61
> 
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/

Ivan,

The point of Xstatic packages is so that, in distributions, they depend
on the asset which is packaged separately, so that there's no
duplication of data in the distro. In this case, the
python3-xstatic-font-awesome package depends on the fonts-font-awesome
package. And it is the later that got updated in Debian. I don't
maintain it, so it's not my fault. This broke many packages, including
the openstackdocstheme also.

Of course, I could revert what was previously done, and have
python3-xstatic-font-awesome to contain the fonts data again. But that's
not desirable.

What we really want is have Horizon fixed, and use a newer version of
font-awesome (ie: v5) if possible. Using only glyphs from fa-solid-900
will make it possible to have Horizon work with both v4 and v5, which
would be even better (of course, package maintainers would have to set
correct links to the right font file, but that's a packaging detail).

Cheers,

Thomas Goirand (zigo)

__
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] [docs] Documentation meeting minutes for 2018-05-30

[Petr Kovar]

===
#openstack-doc: docteam
===


Meeting started by pkovar at 16:00:44 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/docteam/2018/docteam.2018-05-30-16.00.log.html
.



Meeting summary
---

* Ops docs discussion  (pkovar, 16:05:40)
  * LINK:

http://lists.openstack.org/pipermail/openstack-operators/2018-May/015318.html
(pkovar, 16:05:45)
  * Ops community plans to take ownership of the ops, ha and
architecture guides  (pkovar, 16:05:49)
  * though the details and scope of content are to be agreed on yet
(pkovar, 16:06:38)
  * primarily, the community wants to work on ops guide  (pkovar,
16:07:02)

* Contributor Guide lead  (pkovar, 16:09:21)
  * After Mike P's departure, Kendall N is the new lead  (pkovar,
16:09:26)

* Default warning-is-error to True for non-legacy Sphinx projects
  (pkovar, 16:09:37)
  * LINK: https://review.openstack.org/#/c/559348/  (pkovar, 16:09:43)
  * Just merged today  (pkovar, 16:09:47)

* Vancouver Summit  (pkovar, 16:11:46)
  * Docs-i18N - Project Update recording available online, thanks to
everybody involved!  (pkovar, 16:11:51)
  * LINK: https://www.youtube.com/watch?v=FIGErKqXAy8  (pkovar,
16:11:55)

* Bug Triage Team  (pkovar, 16:12:36)
  * LINK: https://wiki.openstack.org/wiki/Documentation/SpecialityTeams
(pkovar, 16:12:41)
  * Backlog stable, number of unresolved bugs started to decrease
recently  (pkovar, 16:12:45)

* Ops docs discussion  (pkovar, 16:22:56)
  * when migrating the ops guide, it might be easier for ops folks to
just copy the rst files from openstack-manuals  (pkovar, 16:22:58)
  * and save time on conversion from wiki  (pkovar, 16:23:35)



Meeting ended at 16:25:49 UTC.



People present (lines said)
---

* pkovar (39)
* dhellmann (15)
* openstack (3)
* stephenfin (3)



Generated by `MeetBot`_ 0.1.4


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

Re: [openstack-dev] [Heat] : Query regarding bug 1769089

[Ashika Meher Majety]

Hi Kaz,

Thank you for the update regarding the issue ( https://storyboard.
openstack.org/#!/story/1769089 ). To be more clear the issue is as follows,
we have tried accessing horizon(GUI) with port forwarding(tunnel link) and
also with the direct IP. So, when we use port forwarding stack launch is
possible in only one of the link. The other is showing the error "None type
object has no attribute 'encode' ". If we restart the apache server then
also it is not working in both. We didn't get any errors in heat-api or
heat-engine logs, the error is shown in the stack launch form at the top.
It is not only with the template I attached in the storyboard, but seen for
all types of HOT templates. This might be somewhat clearer.

Regards,
Ashika Meher

On Wed, May 30, 2018 at 6:56 PM, Kaz Shinohara  wrote:

> Hi,
>
>
> First off, sorry for being late to response.
>
> Looking at your comment,
> your environment is Newton & AFAIK Newton is EOL, even if you will wait
> for the fix, it will not be delivered to Newton.
> https://releases.openstack.org/
>
> Current my concern is that your raised issue may happen in Queens code too
> (latest maintained)
> Note: dashboard for heat is split out from Horizon since Queens.
>
> Let me check if I could reproduce your issue at my environment(Queens)
> first.
> I will update my result at https://storyboard.
> openstack.org/#!/story/1769089
>
> Cheers,
> Kaz
>
>
>
> 2018-05-30 21:56 GMT+09:00 Ashika Meher Majety :
>
>> Hello,
>>
>> We have raised a bug in launchpad and the bug link is as follows:
>> https://bugs.launchpad.net/heat-dashboard/+bug/1769089 .
>> Can anyone please provide a solution or fix for this issue since it's
>> been 20 days since we have created this bug.
>>
>> Thanks,
>> Ashika Meher
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

[Ed Leafe]

On May 6, 2018, at 8:01 AM, Gilles Dubreuil  wrote:

> Regarding the choice of Neutron as PoC, I'm sorry for not providing much 
> details when I said "because of its specific data model",
> effectively the original mention was  "its API exposes things at an 
> individual table level, requiring the client to join that information to get 
> the answers they need".
> I realize now such description probably applies to many OpenStack APIs.
> So I'm not sure what was the reason for choosing Neutron.

Blame Monty!

It was Monty who suggested Neutron due to his particular experience working 
with the API. Since none of the rest of us in the API-SIG had any better 
suggestions, that was what we passed on to you. But I think that any target 
that demonstrates the advantages to be had by adopting GraphQL is fine. So if 
the team working on this think they can create a more impressive PoC with 
another API, the API-SIG will support that.


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [tap-as-a-service] core reviewer update

[Takashi Yamamoto]

hi,

i plan to add Kazuhiro Suzuki to tap-as-a-service-core group. [1]
he is one of active members of the project.
he is also the original author of tap-as-a-service-dashboard.
i'll make the change after a week unless i hear any objections/concerns.

[1] https://review.openstack.org/#/admin/groups/957,members
http://stackalytics.com/report/contribution/tap-as-a-service/120

__
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] No meeting 31 May 2018

[Tom Barron]

We don't have anything on the agenda yet for this week's manila 
meeting and my travel plans just got shuffled so I'm in the air at our 
regular time so let's cancel this week's meeting and start 
up again the following week.


We'll have a summary of relevant Summit events then.

-- Tom Barron (tbarron)


__
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] [tc][all] A culture change (nitpicking)

[Ed Leafe]

On May 30, 2018, at 5:11 AM, Dmitry Tantsur  wrote:

> Whatever decision the TC takes, I would like it to make sure that we don't 
> paint putting -1 as a bad act. Nor do I want "if you care, just follow-up" to 
> be an excuse for putting up bad contributions.
> 
> Additionally, I would like to have something saying that a -1 is valid and 
> appropriate, if a contribution substantially increases the project's 
> technical debt. After already spending *days* refactoring ironic unit tests, 
> I will -1 the hell out of a patch that will try to bring them back to their 
> initial state, I promise :)

Yes to this. -1 should never mean anything other than "some more work needs to 
be done before this can merge". It most certainly does not mean "your code is 
bad and you should feel terrible".

While this started as a discussion about reducing nitpicking, which I think we 
can all embrace, we shouldn't let it slide into imagining that contributors are 
such fragile things that pointing out an error/problem in the code is seen as a 
personal attack. Of course you should not be mean when you do so. But that's 
very, very rare in my OpenStack experience. Nitpicking, on the other hand, is 
much more prevalent, and I welcome these efforts to reduce it.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
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] [Cyborg] [Nova] Cyborg traits

[Sylvain Bauza]

On Wed, May 30, 2018 at 1:33 AM, Nadathur, Sundar  wrote:

> Hi all,
>The Cyborg/Nova scheduling spec [1] details what traits will be applied
> to the resource providers that represent devices like GPUs. Some of the
> traits referred to vendor names. I got feedback that traits must not refer
> to products or specific models of devices. I agree. However, we need some
> reference to device types to enable matching the VM driver with the device.
>
> TL;DR We need some reference to device types, but we don't need product
> names. I will update the spec [1] to clarify that. Rest of this email
> clarifies why we need device types in traits, and what traits we propose to
> include.
>
> In general, an accelerator device is operated by two pieces of software: a
> driver in the kernel (which may discover and handle the PF for SR-IOV
> devices), and a driver/library in the guest (which may handle the assigned
> VF).
>
> The device assigned to the VM must match the driver/library packaged in
> the VM. For this, the request must explicitly state what category of
> devices it needs. For example, if the VM needs a GPU, it needs to say
> whether it needs an AMD GPU or an Nvidia GPU, since it may have the
> driver/libraries for that vendor alone. It may also need to state what
> version of Cuda is needed, if it is a Nvidia GPU. These aspects are
> necessarily vendor-specific.
>
>
FWIW, the vGPU implementation for Nova also has the same concern. We want
to provide traits for explicitly say "use this vGPU type" but given it's
related to a specific vendor, we can't just say "ask for this frame buffer
size, or just for the display heads", but rather "we need a vGPU accepting
Quadro vDWS license".


> Further, one driver/library version may handle multiple devices. Since a
> new driver version may be backwards compatible, multiple driver versions
> may manage the same device. The development/release of the driver/library
> inside the VM should be independent of the kernel driver for that device.
>
>
I agree.


> For FPGAs, there is an additional twist as the VM may need specific
> bitstream(s), and they match only specific device/region types. The
> bitstream for a device from a vendor will not fit any other device from the
> same vendor, let alone other vendors. IOW, the region type is specific not
> just to a vendor but to a device type within the vendor. So, it is
> essential to identify the device type.
>
> So, the proposed set of RCs and traits are as below. As we learn more
> about actual usages by operators, we may need to evolve this set.
>
>- There is a resource class per device category e.g.
>CUSTOM_ACCELERATOR_GPU, CUSTOM_ACCELERATOR_FPGA.
>- The resource provider that represents a device has the following
>traits:
>   - Vendor/Category trait: e.g. CUSTOM_GPU_AMD, CUSTOM_FPGA_XILINX.
>   - Device type trait which is a refinement of vendor/category trait
>   e.g. CUSTOM_FPGA_XILINX_VU9P.
>
> NOTE: This is not a product or model, at least for FPGAs. Multiple
> products may use the same FPGA chip.
> NOTE: The reason for having both the vendor/category and this one is that
> a flavor may ask for either, depending on the granularity desired. IOW, if
> one driver can handle all devices from a vendor (*eye roll*), the flavor
> can ask for the vendor/category trait alone. If there are separate drivers
> for different device families from the same vendor, the flavor must specify
> the trait for the device family.
> NOTE: The equivalent trait for GPUs may be like CUSTOM_GPU_NVIDIA_P90, but
> I'll let others decide if that is a product or not.
>
>
I was about to propose the same for vGPUs in Nova, ie. using custom traits.
The only concern is that we need operators to set the traits directly using
osc-placement instead of having Nova magically provide those traits. But
anyway, given operators need to set the vGPU types they want, I think it's
acceptable.



>
>- For FPGAs, we have additional traits:
>  - Functionality trait: e.g. CUSTOM_FPGA_COMPUTE,
>  CUSTOM_FPGA_NETWORK, CUSTOM_FPGA_STORAGE
>  - Region type ID.  e.g. CUSTOM_FPGA_INTEL_REGION_.
>  - Optionally, a function ID, indicating what function is
>  currently programmed in the region RP. e.g. 
> CUSTOM_FPGA_INTEL_FUNCTION_.
>  Not all implementations may provide it. The function trait may 
> change on
>  reprogramming, but it is not expected to be frequent.
>  - Possibly, CUSTOM_PROGRAMMABLE as a separate trait.
>
> [1] https://review.openstack.org/#/c/554717/
>


I'll try to review the spec as soon as I can.

-Sylvain

>
>
> Thanks.
>
> Regards,
> Sundar
>
> __
> 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] [octavia] TERMINATED_HTTPS + SSL to backend server

[mihaela.balas]

Hello,

Is there any user story for the scenario below?


-  Octavia is set to TERMINATED_HTTPS and also initiates SSL to backend 
servers

After testing all the combination possible and after looking at the Octavia 
haproxy templates in Queens version I understand that this kind of setup is 
currently not supported.

Thanks,
Mihaela

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

__
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] Signing off

[Henry Nash]

Hi
 
It is with a somewhat heavy heart that I have decided that it is time to hang up my keystone core status. Having been involved since the closing stages of Folsom, I've had a good run! When I look at how far keystone has come since the v2 days, it is remarkable - and we should all feel a sense of pride in that.
 
Thanks to all the hard work, commitment, humour and support from all the keystone folks over the years - I am sure we will continue to interact and meet among the many other open source projects that many of us are becoming involved with. Ad astra!
 
Best regards,
 
Henry
Twitter: @henrynash
linkedIn: www.linkedin.com/in/henrypnash
 Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



__
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] [Cyborg] [Nova] Cyborg traits

[Nadathur, Sundar]

Hi Sylvain,
  Glad to know we are on the same page. I haven't updated the spec with 
this proposal yet, in case I got more comments :). I will do so by today.


Thanks,
Sundar

On 5/30/2018 12:34 AM, Sylvain Bauza wrote:



On Wed, May 30, 2018 at 1:33 AM, Nadathur, Sundar 
mailto:sundar.nadat...@intel.com>> wrote:


Hi all,
   The Cyborg/Nova scheduling spec [1] details what traits will be
applied to the resource providers that represent devices like
GPUs. Some of the traits referred to vendor names. I got feedback
that traits must not refer to products or specific models of
devices. I agree. However, we need some reference to device types
to enable matching the VM driver with the device.

TL;DR We need some reference to device types, but we don't need
product names. I will update the spec [1] to clarify that. Rest of
this email clarifies why we need device types in traits, and what
traits we propose to include.

In general, an accelerator device is operated by two pieces of
software: a driver in the kernel (which may discover and handle
the PF for SR-IOV  devices), and a driver/library in the guest
(which may handle the assigned VF).

The device assigned to the VM must match the driver/library
packaged in the VM. For this, the request must explicitly state
what category of devices it needs. For example, if the VM needs a
GPU, it needs to say whether it needs an AMD GPU or an Nvidia GPU,
since it may have the driver/libraries for that vendor alone. It
may also need to state what version of Cuda is needed, if it is a
Nvidia GPU. These aspects are necessarily vendor-specific.


FWIW, the vGPU implementation for Nova also has the same concern. We 
want to provide traits for explicitly say "use this vGPU type" but 
given it's related to a specific vendor, we can't just say "ask for 
this frame buffer size, or just for the display heads", but rather "we 
need a vGPU accepting Quadro vDWS license".


Further, one driver/library version may handle multiple devices.
Since a new driver version may be backwards compatible, multiple
driver versions may manage the same device. The
development/release of the driver/library inside the VM should be
independent of the kernel driver for that device.


I agree.

For FPGAs, there is an additional twist as the VM may need
specific bitstream(s), and they match only specific device/region
types. The bitstream for a device from a vendor will not fit any
other device from the same vendor, let alone other vendors. IOW,
the region type is specific not just to a vendor but to a device
type within the vendor. So, it is essential to identify the device
type.

So, the proposed set of RCs and traits are as below. As we learn
more about actual usages by operators, we may need to evolve this set.

  * There is a resource class per device category e.g.
CUSTOM_ACCELERATOR_GPU, CUSTOM_ACCELERATOR_FPGA.
  * The resource provider that represents a device has the
following traits:
  o Vendor/Category trait: e.g. CUSTOM_GPU_AMD,
CUSTOM_FPGA_XILINX.
  o Device type trait which is a refinement of vendor/category
trait e.g. CUSTOM_FPGA_XILINX_VU9P.

NOTE: This is not a product or model, at least for FPGAs.
Multiple products may use the same FPGA chip.
NOTE: The reason for having both the vendor/category and
this one is that a flavor may ask for either, depending on
the granularity desired. IOW, if one driver can handle all
devices from a vendor (*eye roll*), the flavor can ask for
the vendor/category trait alone. If there are separate
drivers for different device families from the same
vendor, the flavor must specify the trait for the device
family.
NOTE: The equivalent trait for GPUs may be like
CUSTOM_GPU_NVIDIA_P90, but I'll let others decide if that
is a product or not.


I was about to propose the same for vGPUs in Nova, ie. using custom 
traits. The only concern is that we need operators to set the traits 
directly using osc-placement instead of having Nova magically provide 
those traits. But anyway, given operators need to set the vGPU types 
they want, I think it's acceptable.



  o For FPGAs, we have additional traits:
  + Functionality trait: e.g. CUSTOM_FPGA_COMPUTE,
CUSTOM_FPGA_NETWORK, CUSTOM_FPGA_STORAGE
  + Region type ID.  e.g. CUSTOM_FPGA_INTEL_REGION_.
  + Optionally, a function ID, indicating what function is
currently programmed in the region RP. e.g.
CUSTOM_FPGA_INTEL_FUNCTION_. Not all
implementations may provide it. The function trait may
change on reprogramming, but it is not expected to be
 

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Dmitry Tantsur]

Hi,

This is a great discussion and a great suggestion overall, but I'd like to add a 
grain of salt here, especially after reading some comments.


Nitpicking is bad, no disagreement. However, I don't like this whole discussion 
to end up marking -1's as offense or aggression. Just as often as I see 
newcomers proposing patches frustrated with many iterations, I see newcomers 
being afraid to -1.


In my personal experience I have two remarkable cases:
1. A person asking me (via a private message) to not put -1 on their patches 
because they may have problems with their managers.
2. A person proposing a follow-up on *any* comment to their patch, including 
important ones.


Whatever decision the TC takes, I would like it to make sure that we don't paint 
putting -1 as a bad act. Nor do I want "if you care, just follow-up" to be an 
excuse for putting up bad contributions.


Additionally, I would like to have something saying that a -1 is valid and 
appropriate, if a contribution substantially increases the project's technical 
debt. After already spending *days* refactoring ironic unit tests, I will -1 the 
hell out of a patch that will try to bring them back to their initial state, I 
promise :)


Dmitry

On 05/29/2018 03:55 PM, Julia Kreger wrote:

During the Forum, the topic of review culture came up in session after
session. During these discussions, the subject of our use of nitpicks
were often raised as a point of contention and frustration, especially
by community members that have left the community and that were
attempting to re-engage the community. Contributors raised the point
of review feedback requiring for extremely precise English, or
compliance to a particular core reviewer's style preferences, which
may not be the same as another core reviewer.

These things are not just frustrating, but also very inhibiting for
part time contributors such as students who may also be time limited.
Or an operator who noticed something that was clearly a bug and that
put forth a very minor fix and doesn't have the time to revise it over
and over.

While nitpicks do help guide and teach, the consensus seemed to be
that we do need to shift the culture a little bit. As such, I've
proposed a change to our principles[1] in governance that attempts to
capture the essence and spirit of the nitpicking topic as a first
step.

-Julia
-
[1]: https://review.openstack.org/570940

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




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

Re: [openstack-dev] [keystone] Signing off

[Colleen Murphy]

On Wed, May 30, 2018, at 10:45 AM, Henry Nash wrote:
> Hi
>  
> It is with a somewhat heavy heart that I have decided that it is time to
> hang up my keystone core status. Having been involved since the closing
> stages of Folsom, I've had a good run! When I look at how far keystone
> has come since the v2 days, it is remarkable - and we should all feel a
> sense of pride in that. 
> Thanks to all the hard work, commitment, humour and support from all the
> keystone folks over the years - I am sure we will continue to interact
> and meet among the many other open source projects that many of us are
> becoming involved with. Ad astra! 
> Best regards,
>  
> Henry
> Twitter: @henrynash
> linkedIn: www.linkedin.com/in/henrypnash
> 

Thank you for all the incredible work you've done for this project! You were an 
invaluable asset at the PTGs, it was great to see you there even though 
keystone hasn't been your main focus lately. Wishing you the best of luck.

Colleen

__
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] collect up and down time for deployed openstack resources

[amal kammoun]

Hi,

We aim at collecting inter failures time for the compute and network
resources (i.e., availability and reliability of each resource).

Is there any mean via Restfull to collect these metrics ?

If not, which OpenStack/celiometer/heat modules may be extended in order to
collect this information via the implementation of a prob protocol for
instance?


Thanks in adavance,


Regards,


Amal
__
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] [tc] Organizational diversity tag

[Thierry Carrez]

Samuel Cassiba wrote:

[...]
The moniker of 'low-activity' does give the very real, negative 
perception that things are just barely hanging on. It conveys the 
subconscious, officiated statement (!!!whether or not this was 
intended!!!) that nobody in their right mind should consider using the 
subproject, let alone develop on or against it, for fear that it wind up 
some poor end-user's support nightmare. [...]
Yes, that's fair... and why my original suggestion was to do a (regular) 
qualitative report that would use words rather than binary tags.


--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tc][all] A culture change (nitpicking)

[Thierry Carrez]

Jay S Bryant wrote:


On 5/29/2018 3:19 PM, Doug Hellmann wrote:

Excerpts from Jonathan Proulx's message of 2018-05-29 16:05:06 -0400:

On Tue, May 29, 2018 at 03:53:41PM -0400, Doug Hellmann wrote:
:> >> maybe we're all saying the same thing here?
:> > Yeah, I feel like we're all essentially in agreement that nits 
(of the

:> > English mistake of typo type) do need to get fixed, but sometimes
:> > (often?) putting the burden of fixing them on the original patch
:> > contributor is neither fair nor constructive.
:> I am ok with this statement if we are all in agreement that doing
:> follow-up patches is an acceptable practice.
:
:Has it ever not been?
:
:It seems like it has always come down to a bit of negotiation with
:the original author, hasn't it? And that won't change, except that
:we will be emphasizing to reviewers that we encourage them to be
:more active in seeking out that negotiation and then proposing
:patches?

Exactly, it's more codifying a default.

It's not been unacceptable but I think there's some understandable
reluctance to make changes to someone else's work, you don't want to
seem like your taking over or getting in the way.  At least that's
what's in my head when deciding should this be a comment or a patch.

I think this discussion suggests for certain class of "nits" patch is
preferred to comment.  If that is true making this explicit is a good
thing becuase let's face it my social skills are only marginally
better than my speeling :)

-Jon


OK, that's all good. I'm just surprised to learn that throwing a
follow-up patch on top of someone else's patch was ever seen as
discouraged.

The spice must flow,
Doug


Maybe it would be different now that I am a Core/PTL but in the past I 
had been warned to be careful as it could be misinterpreted if I was 
changing other people's patches or that it could look like I was trying 
to pad my numbers. (I am a nit-picker though I do my best not to be.


There still seems to be some confusion between "new patchset over 
existing change" and "follow-up separate change" as to what is the 
recommended way to fix nits.


To clarify, the proposal here is to encourage the posting of a follow-up 
change.


--
Thierry Carrez (ttx)

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

[openstack-dev] [docs] Documentation meeting today

[Petr Kovar]

Hi all,

The docs meeting will continue today at 16:00 UTC in
#openstack-doc, as scheduled. For more details, see the meeting page:

https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Cheers,
pk

__
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] [stable] [tooz] [ceilometer] cmd2 without upper constraints causes errors in tox-py27

[Elõd Illés]

Hi,

In the last two days the ceilometer [1] [2] [3] and tooz [4] [5] [6] 
tox-py27 periodic stable jobs are failing. The root cause is the following:

* cmd2 released version 0.9.0, which requires python >=3.4 from now on.
These projects have comment in their tox.ini that they do not consume 
upper-constraints.txt (in which there is an upper constraints for cmd2).


My question is: could we use upper-constraints.txt on these projects as 
well, or is there any reason why it isn't the case?
Of course an entry could be added to test-requirements.txt with 
"cmd2<0.9.0", but wouldn't it be better to use the upper-constraints.txt?


Thanks in advance,

Előd

[1] 
http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/ceilometer/stable/queens/openstack-tox-py27/b44c7cd/
[2] 
http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/ceilometer/stable/pike/openstack-tox-py27/6c4fd5d/
[3] 
http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/ceilometer/stable/ocata/openstack-tox-py27/4d2d0b3/


[4] 
http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/tooz/stable/queens/openstack-tox-py27/37bd360/
[5] 
http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/tooz/stable/pike/openstack-tox-py27/8bb8c29/
[6] 
http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/tooz/stable/ocata/openstack-tox-py27/1016d56/



__
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] [stable] [tooz] [ceilometer] cmd2 without upper constraints causes errors in tox-py27

[Julien Danjou]

On Wed, May 30 2018, Elõd Illés wrote:

> In the last two days the ceilometer [1] [2] [3] and tooz [4] [5] [6] tox-py27
> periodic stable jobs are failing. The root cause is the following:
> * cmd2 released version 0.9.0, which requires python >=3.4 from now on.
> These projects have comment in their tox.ini that they do not consume
> upper-constraints.txt (in which there is an upper constraints for cmd2).
>
> My question is: could we use upper-constraints.txt on these projects as well,
> or is there any reason why it isn't the case?
> Of course an entry could be added to test-requirements.txt with "cmd2<0.9.0",
> but wouldn't it be better to use the upper-constraints.txt?

The question is: why cmd2 0.9.0 does not work and how do we fix that?

-- 
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] [nova] [placement] Upgrade concerns with nested Resource Providers

[Balázs Gibizer]

On Tue, May 29, 2018 at 3:12 PM, Sylvain Bauza  
wrote:



On Tue, May 29, 2018 at 2:21 PM, Balázs Gibizer 
 wrote:



On Tue, May 29, 2018 at 1:47 PM, Sylvain Bauza  
wrote:



Le mar. 29 mai 2018 à 11:02, Balázs Gibizer 
 a écrit :



On Tue, May 29, 2018 at 9:38 AM, Sylvain Bauza 
wrote:
>
>
> On Tue, May 29, 2018 at 3:08 AM, TETSURO NAKAMURA
>  wrote
>
>> > In that situation, say for example with VGPU inventories, that
>> would mean
>> > that the compute node would stop reporting inventories for its
>> root RP, but
>> > would rather report inventories for at least one single child 
RP.
>> > In that model, do we reconcile the allocations that were 
already

>> made
>> > against the "root RP" inventory ?
>>
>> It would be nice to see Eric and Jay comment on this,
>> but if I'm not mistaken, when the virt driver stops reporting
>> inventories for its root RP, placement would try to delete that
>> inventory inside and raise InventoryInUse exception if any
>> allocations still exist on that resource.
>>
>> ```
>> update_from_provider_tree() (nova/compute/resource_tracker.py)
>>   + _set_inventory_for_provider() 
(nova/scheduler/client/report.py)
>>   + put() - PUT /resource_providers//inventories 
with

>> new inventories (scheduler/client/report.py)
>>   + set_inventories() (placement/handler/inventory.py)
>>   + _set_inventory()
>> (placement/objects/resource_proveider.py)
>>   + _delete_inventory_from_provider()
>> (placement/objects/resource_proveider.py)
>>   -> raise exception.InventoryInUse
>> ```
>>
>> So we need some trick something like deleting VGPU allocations
>> before upgrading and set the allocation again for the created 
new

>> child after upgrading?
>>
>
> I wonder if we should keep the existing inventory in the root 
RP, and
> somehow just reserve the left resources (so Placement wouldn't 
pass

> that root RP for queries, but would still have allocations). But
> then, where and how to do this ? By the resource tracker ?
>

AFAIK it is the virt driver that decides to model the VGU resource 
at a
different place in the RP tree so I think it is the responsibility 
of
the same virt driver to move any existing allocation from the old 
place

to the new place during this change.

Cheers,
gibi


Why not instead not move the allocation but rather have the virt 
driver updating the root RP by modifying the reserved value to the 
total size?


That way, the virt driver wouldn't need to ask for an allocation 
but rather continue to provide inventories...


Thoughts?


Keeping the old allocaton at the old RP and adding a similar sized 
reservation in the new RP feels hackis as those are not really 
reserved GPUs but used GPUs just from the old RP. If somebody sums 
up the total reported GPUs in this setup via the placement API then 
she will get more GPUs in total that what is physically visible for 
the hypervisor as the GPUs part of the old allocation reported twice 
in two different total value. Could we just report less GPU 
inventories to the new RP until the old RP has GPU allocations?





We could keep the old inventory in the root RP for the previous vGPU 
type already supported in Queens and just add other inventories for 
other vGPU types now supported. That looks possibly the simpliest 
option as the virt driver knows that.


That works for me. Can we somehow deprecate the previous, already 
supported vGPU types to eventually get rid of the splitted inventory?






Some alternatives from my jetlagged brain:

a) Implement a move inventory/allocation API in placement. Given a 
resource class and a source RP uuid and a destination RP uuid 
placement moves the inventory and allocations of that resource class 
from the source RP to the destination RP. Then the virt drive can 
call this API to move the allocation. This has an impact on the fast 
forward upgrade as it needs running virt driver to do the allocation 
move.




Instead of having the virt driver doing that (TBH, I don't like that 
given both Xen and libvirt drivers have the same problem), we could 
write a nova-manage upgrade call for that that would call the 
Placement API, sure.


The nova-manage is another possible way similar to my idea #c) but 
there I imagined the logic in placement-manage instead of nova-manage.




b) For this I assume that live migrating an instance having a GPU 
allocation on the old RP will allocate GPU for that instance from 
the new RP. In the virt driver do not report GPUs to the new RP 
while there is allocation for such GPUs in the old RP. Let the 
deployer live migrate away the instances. When the virt driver 
detects that there is no more GPU allocations on the old RP it can 
delete the inventory from the old RP and report it to the new RP.




For the moment, vGPUs don't support live migration, even within QEMU. 
I haven't checked that, but IIUC when you live-migrate an instance 
that have vGPUs, it will just migrate it without 

[openstack-dev] [watcher] Cancel meeting today

[Чадин Александр]

Hi Watchers,

I cancel weekly meeting today because of urgent internal meetings.
I’m available on openstack-watcher channel most of the time.
Let’s meet on June 6.


Best Regards,

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

Re: [openstack-dev] [stable] [tooz] [ceilometer] cmd2 without upper constraints causes errors in tox-py27

[Elõd Illés]

cmd2 says that:

"Python 2.7 support is EOL

Support for adding new features to the Python 2.7 release of |cmd2| was 
discontinued on April 15, 2018. Bug fixes will be supported for Python 
2.7 via 0.8.x until August 31, 2018.


Supporting Python 2 was an increasing burden on our limited resources. 
Switching to support only Python 3 will allow us to clean up the 
codebase, remove some cruft, and focus on developing new features."


See: https://github.com/python-cmd2/cmd2

Előd

On 2018-05-30 14:42, Julien Danjou wrote:

On Wed, May 30 2018, Elõd Illés wrote:


In the last two days the ceilometer [1] [2] [3] and tooz [4] [5] [6] tox-py27
periodic stable jobs are failing. The root cause is the following:
* cmd2 released version 0.9.0, which requires python >=3.4 from now on.
These projects have comment in their tox.ini that they do not consume
upper-constraints.txt (in which there is an upper constraints for cmd2).

My question is: could we use upper-constraints.txt on these projects as well,
or is there any reason why it isn't the case?
Of course an entry could be added to test-requirements.txt with "cmd2<0.9.0",
but wouldn't it be better to use the upper-constraints.txt?

The question is: why cmd2 0.9.0 does not work and how do we fix that?



__
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] [Heat] : Query regarding bug 1769089

[Ashika Meher Majety]

Hello,

We have raised a bug in launchpad and the bug link is as follows:
https://bugs.launchpad.net/heat-dashboard/+bug/1769089 .
Can anyone please provide a solution or fix for this issue since it's been
20 days since we have created this bug.

Thanks,
Ashika Meher
__
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] [TC] [Infra] Terms of service for hosted projects

[Thierry Carrez]

Jeremy Stanley wrote:

On 2018-05-29 10:53:03 -0400 (-0400), Zane Bitter wrote:

It is my understanding that the infra team will enforce the
following conditions when a repo import request is received:

* The repo must be licensed under an OSI-approved open source
license.


That has been our custom, but we should add a statement to this
effect in the aforementioned document.


* If the repo is a fork of another project, there must be (public)
evidence of an attempt to co-ordinate with the upstream first.


I don't recall this ever being mandated, though the project-config
reviewers do often provide suggestions to project creators such as
places in the existing community with which they might consider
cooperating/collaborating.


Right, that was never a rule (for Stackforge or the current 
"non-official project hosting" space), and I doubt very much we have 
enforced it in the past. FWIW we currently host forks of gitdm, gerrit, 
as well as copies of all sorts of JS code under xstatic-*. That said, I 
think consulting upstream in case of code copies/forks is a good 
practice to add in the future.



[...]

In addition, I think we should require projects hosted on our
infrastructure to agree to other policies:

* Adhere to the OpenStack Foundation Code of Conduct.


This seems like a reasonable addition to our hosting requirements.


* Not misrepresent their relationship to the official OpenStack
project or the Foundation. Ideally we'd come up with language that
they *can* use to describe their status, such as "hosted on the
OpenStack infrastructure".


Also a great suggestion. We sort of say that in the "what being an
unoffocial project is not" bullet list, but it could use some
fleshing out.
"The OpenStack infrastructure" is likely to be changed in the near 
future to a more neutral name, but I would keep the "hosted on" language 
to describe the relationship.


--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Heat] : Query regarding bug 1769089

[Goutham Pratapa]

Try asking people in webirc


webchat.freenode.net

Nickname  :  your name
channel:  #openstack-heat

and you will find people ask them it's better to talk to them rather than
here  people might not respond here there you have a good chance


https://review.openstack.org/#/admin/groups/114,members you will find
people with these names ping them directly...




Cheers
Goutham.









On Wed, May 30, 2018 at 6:26 PM, Ashika Meher Majety 
wrote:

> Hello,
>
> We have raised a bug in launchpad and the bug link is as follows:
> https://bugs.launchpad.net/heat-dashboard/+bug/1769089 .
> Can anyone please provide a solution or fix for this issue since it's been
> 20 days since we have created this bug.
>
> Thanks,
> Ashika Meher
>
> __
> 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
>
>


-- 
Cheers !!!
Goutham Pratapa
__
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] : Query regarding bug 1769089

[Kaz Shinohara]

Hi,


First off, sorry for being late to response.

Looking at your comment,
your environment is Newton & AFAIK Newton is EOL, even if you will wait for
the fix, it will not be delivered to Newton.
https://releases.openstack.org/

Current my concern is that your raised issue may happen in Queens code too
(latest maintained)
Note: dashboard for heat is split out from Horizon since Queens.

Let me check if I could reproduce your issue at my environment(Queens)
first.
I will update my result at https://storyboard.openstack.org/#!/story/1769089

Cheers,
Kaz



2018-05-30 21:56 GMT+09:00 Ashika Meher Majety :

> Hello,
>
> We have raised a bug in launchpad and the bug link is as follows:
> https://bugs.launchpad.net/heat-dashboard/+bug/1769089 .
> Can anyone please provide a solution or fix for this issue since it's been
> 20 days since we have created this bug.
>
> Thanks,
> Ashika Meher
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Font awesome currently broken with Debian Sid and Horizon

[Thomas Goirand]

Hi Radomir,

I'm adding the debian bug as Cc.

On 05/28/2018 08:35 AM, Radomir Dopieralski wrote:
> I did a quick search for all the glyphs we are using:
> 
> ~/dev/horizon(master)> ag 'fa-' | egrep -o 'fa-[a-z-]*' | sort | uniq
> fa-
> fa-angle-left
> [...]

Thanks for your investigation.

I did a quick test, and loaded all of these glyphs into a test HTML
page. As much as I can see, only 4 glyphs aren't in fa-solid-900:

fa-cloud-upload
fa-pencil
fa-share-square-o
fa-sign-out

It'd be nice if we could replace these by glyphs present in fa-solid-900
so we could simply replace the old v4 font by fa-solid-900 only.

Your thoughts?

Cheers,

Thomas Goirand (zigo)

__
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] [tc][all] A culture change (nitpicking)

[Julia Kreger]

On Tue, May 29, 2018 at 7:42 PM, Zane Bitter  wrote:
[trim]
> Since I am replying to this thread, Julia also mentioned the situation where
> two core reviewers are asking for opposite changes to a patch. It is never
> ever ever the contributor's responsibility to resolve a dispute between two
> core reviewers! If you see a core reviewer's advice on a patch and you want
> to give the opposite advice, by all means take it up immediately - with *the
> other core reviewer*. NOT the submitter. Preferably on IRC and not in the
> review. You work together every day, you can figure it out! A random
> contributor has no chance of parachuting into the middle of that dynamic and
> walking out unscathed, and they should never be asked to.
>

Absolutely agree! In the case that was in mind where it has happened
to me personally, I think it was 10-15 revisions apart, so it becomes
a little hard to identify when your starting to play the game of "make
the cores happy to land it". It is not a fun game for the contributor.
Truthfully it caused me to add the behavior of intentionally waiting
longer between uploads of new revisions... which does not help at all.

The other conundrum is when you disagree and the person has left a -1
which blocks forward progress and any additional reviews since it gets
viewed as "not ready", which makes it even harder and slower to build
consensus. At some point you get into "Oh, what formatting can I
change to clear that -1 because the person is not responding" mode.

At least beginning to shift the review culture should help many of these issues.

__
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] Signing off

[Harry Rybacki]

On Wed, May 30, 2018 at 5:05 AM, Colleen Murphy  wrote:
> On Wed, May 30, 2018, at 10:45 AM, Henry Nash wrote:
>> Hi
>>
>> It is with a somewhat heavy heart that I have decided that it is time to
>> hang up my keystone core status. Having been involved since the closing
>> stages of Folsom, I've had a good run! When I look at how far keystone
>> has come since the v2 days, it is remarkable - and we should all feel a
>> sense of pride in that.
>> Thanks to all the hard work, commitment, humour and support from all the
>> keystone folks over the years - I am sure we will continue to interact
>> and meet among the many other open source projects that many of us are
>> becoming involved with. Ad astra!
>> Best regards,
>>
>> Henry
>> Twitter: @henrynash
>> linkedIn: www.linkedin.com/in/henrypnash
>>
>
> Thank you for all the incredible work you've done for this project! You were 
> an invaluable asset at the PTGs, it was great to see you there even though 
> keystone hasn't been your main focus lately. Wishing you the best of luck.
>
Hear, hear. Keystone has largely been shaped by those continual
efforts, Henry. Your face may be missed but your voice will hang
around to guide us future. Hope to run into you somewhere, sometime!

/R

> Colleen
>
> __
> 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

Harry

__
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] [stable] [tooz] [ceilometer] cmd2 without upper constraints causes errors in tox-py27

[Jeremy Stanley]

On 2018-05-30 14:42:58 +0200 (+0200), Julien Danjou wrote:
[...]
> The question is: why cmd2 0.9.0 does not work and how do we fix that?

The cmd2 maintainers decided that they no longer want to carry
support for old Python interpreters, so versions starting with 0.9.0
only work on Python 3.4 and later:

https://github.com/python-cmd2/cmd2/issues/421

-- 
Jeremy Stanley


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] [Heat] : Query regarding bug 1769089

[Rico Lin]

Hi

As Kaz mentioned,
Since we moved to StoryBoard (instead of Launchapd) please maintain your
bug here: https://storyboard.openstack.org/#!/story/1769089

Also, I try to use the same template [1] as you did to create a stack in
master version and it works (I can't reproduce it)

If possible, can you trace log to find where that error is from, is it from
heat-eng.log, heat-api.log, or other where?

Also, Heat IRC is at #heat not  #openstack-heat  :)



[1] TEMPLATE

description: Template for router create
heat_template_version: '2013-05-23'
resources:
  router:
type: OS::Neutron::Router
properties:
  name: resourceRouter


2018-05-30 21:26 GMT+08:00 Kaz Shinohara :

> Hi,
>
>
> First off, sorry for being late to response.
>
> Looking at your comment,
> your environment is Newton & AFAIK Newton is EOL, even if you will wait
> for the fix, it will not be delivered to Newton.
> https://releases.openstack.org/
>
> Current my concern is that your raised issue may happen in Queens code too
> (latest maintained)
> Note: dashboard for heat is split out from Horizon since Queens.
>
> Let me check if I could reproduce your issue at my environment(Queens)
> first.
> I will update my result at https://storyboard.
> openstack.org/#!/story/1769089
>
> Cheers,
> Kaz
>
>
>
> 2018-05-30 21:56 GMT+09:00 Ashika Meher Majety :
>
>> Hello,
>>
>> We have raised a bug in launchpad and the bug link is as follows:
>> https://bugs.launchpad.net/heat-dashboard/+bug/1769089 .
>> Can anyone please provide a solution or fix for this issue since it's
>> been 20 days since we have created this bug.
>>
>> Thanks,
>> Ashika Meher
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>


-- 
May The Force of OpenStack Be With You,

*Rico Lin*irc: ricolin
__
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] Questions about token scopes

[Matt Riedemann]

I know the keystone team has been doing a lot of work on scoped tokens 
and Lance has been trying to roll that out to other projects (like nova).


In Rocky the nova team is adding granular policy rules to the placement 
API [1] which is a good opportunity to set scope on those rules as well.


For now, we've just said everything is system scope since resources in 
placement, for the most part, are managed by "the system". But we do 
have some resources in placement which have project/user information in 
them, so could theoretically also be scoped to a project, like GET 
/usages [2].


While going through this, I've been hammering Lance with questions but I 
had some more this morning and wanted to send them to the list to help 
spread the load and share the knowledge on working with scoped tokens in 
the other projects.


So here goes with the random questions:

* devstack has the admin project/user - does that by default get system 
scope tokens? I see the scope is part of the token create request [3] 
but it's optional, so is there a default value if not specified?


* Why don't the token create and show APIs return the scope?

* It looks like python-openstackclient doesn't allow specifying a scope 
when issuing a token, is that going to be added?


The reason I'm asking about OSC stuff is because we have the 
osc-placement plugin [4] which allows users with the admin role to work 
with resources in placement, which could be useful for things like 
fixing up incorrect or leaked allocations, i.e. fixing the fallout of a 
bug in nova. I'm wondering if we define all of the placement API rules 
as system scope and we're enforcing scope, will admins, as we know them 
today, continue to be able to use those APIs? Or will deployments just 
need to grow a system-scope admin project/user and per-project admin 
users, and then use the former for working with placement via the OSC 
plugin?


[1] 
https://review.openstack.org/#/q/topic:bp/granular-placement-policy+(status:open+OR+status:merged)

[2] https://developer.openstack.org/api-ref/placement/#list-usages
[3] 
https://developer.openstack.org/api-ref/identity/v3/index.html#password-authentication-with-scoped-authorization

[4] https://docs.openstack.org/osc-placement/latest/index.html

--

Thanks,

Matt

__
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] Signing off

[Lance Bragstad]

I remember when I first started contributing upstream, I spent a
Saturday sending you internal emails asking about the intricacies of
database migrations :)

Since then you've give me (or I've stolen) a number of other tools and
techniques. Thanks for everything you've done for this community, Henry.
It's been a pleasure!

On 05/30/2018 03:45 AM, Henry Nash wrote:
> Hi
>  
> It is with a somewhat heavy heart that I have decided that it is time
> to hang up my keystone core status. Having been involved since the
> closing stages of Folsom, I've had a good run! When I look at how far
> keystone has come since the v2 days, it is remarkable - and we should
> all feel a sense of pride in that.
>  
> Thanks to all the hard work, commitment, humour and support from all
> the keystone folks over the years - I am sure we will continue to
> interact and meet among the many other open source projects that many
> of us are becoming involved with. Ad astra!
>  
> Best regards,
>  
> Henry
> Twitter: @henrynash
> linkedIn: www.linkedin.com/in/ henrypnash
>  
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
> __
> 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



signature.asc
Description: OpenPGP digital 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] [tripleo] Containerized Undercloud deep-dive

[Dan Prince]

We are on for this tomorrow (Thursday) at 2pm UTC (10am EST).

We'll meet here: https://redhat.bluejeans.com/dprince/ and record it
live. We'll do an overview presentation and then perhaps jump into a
terminal for some live questions.

Dan

On Tue, May 15, 2018 at 10:51 AM, Emilien Macchi  wrote:
> Dan and I are organizing a deep-dive session focused on the containerized
> undercloud.
>
> https://etherpad.openstack.org/p/tripleo-deep-dive-containerized-undercloud
>
> We proposed a date + list of topics but feel free to comment and ask for
> topics/questions.
> Thanks,
> --
> Emilien & Dan
>
> __
> 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] [tripleo] Containerized Undercloud deep-dive

[Cédric Jeanneret]

On 05/30/2018 04:10 PM, Dan Prince wrote:
> We are on for this tomorrow (Thursday) at 2pm UTC (10am EST).

meaning 3:00pm CET - conflicting with my squad meeting (3:30pm for squad
red) :(. I'll watch it on youtube then.

> 
> We'll meet here: https://redhat.bluejeans.com/dprince/ and record it
> live. We'll do an overview presentation and then perhaps jump into a
> terminal for some live questions.
> 
> Dan
> 
> On Tue, May 15, 2018 at 10:51 AM, Emilien Macchi  wrote:
>> Dan and I are organizing a deep-dive session focused on the containerized
>> undercloud.
>>
>> https://etherpad.openstack.org/p/tripleo-deep-dive-containerized-undercloud
>>
>> We proposed a date + list of topics but feel free to comment and ask for
>> topics/questions.
>> Thanks,
>> --
>> Emilien & Dan
>>
>> __
>> 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
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



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

Re: [openstack-dev] [Nova] z/VM introducing a new config driveformat

[Dan Smith]

> can I know a use case for this 'live copy metadata or ' the 'only way
> to access device tags when hot-attach?  my thought is this is one time
> thing in cloud-init side either through metatdata service or config
> drive and won't be used later? then why I need a live copy?

If I do something like this:

  nova interface-attach --tag=data-network --port-id=foo myserver

Then we update the device metadata live, which is visible immediately
via the metadata service. However, in config drive, that only gets
updated the next time the drive is generated (which may be a long time
away). For more information on device metadata, see:

  
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-device-role-tagging.html

Further, some of the drivers support setting the admin password securely
via metadata, which similarly requires the instance pulling updated
information out, which wouldn't be available in the config drive. For
reference:

  
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1985-L1993

--Dan

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

Re: [openstack-dev] [horizon] Font awesome currently broken with Debian Sid and Horizon

[Ivan Kolodyazhny]

Hi Thomas,


> As my python3-xstatic-font-awesome removes the embedded fonts


It sounds like you broke xstatic-* packages for Debian and use something we
don't test with Horizon at all.

Speaking about Rocky/master version, our upper-constraint
XStatic-Font-Awesome===4.7.0.0 [1]. We don't test horizon with font awesome
v 5.0.10.


Second, it'd be nice if Horizon could adapt and use the new v5
> font-awesome, so that the problem is completely solved.

+1. I'll put my +2/A once somebody provides a patch for it with a detailed
description how can I test it. Unfortunately, Horizon team has a very
limited set of resources, so we can't adopt new version of xstatic-* fast
:(.

[1]
https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L61

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/

On Wed, May 30, 2018 at 4:27 PM, Thomas Goirand  wrote:

> Hi Radomir,
>
> I'm adding the debian bug as Cc.
>
> On 05/28/2018 08:35 AM, Radomir Dopieralski wrote:
> > I did a quick search for all the glyphs we are using:
> >
> > ~/dev/horizon(master)> ag 'fa-' | egrep -o 'fa-[a-z-]*' | sort | uniq
> > fa-
> > fa-angle-left
> > [...]
>
> Thanks for your investigation.
>
> I did a quick test, and loaded all of these glyphs into a test HTML
> page. As much as I can see, only 4 glyphs aren't in fa-solid-900:
>
> fa-cloud-upload
> fa-pencil
> fa-share-square-o
> fa-sign-out
>
> It'd be nice if we could replace these by glyphs present in fa-solid-900
> so we could simply replace the old v4 font by fa-solid-900 only.
>
> Your thoughts?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> 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] [tc][all] A culture change (nitpicking)

[Dmitry Tantsur]

On 05/30/2018 03:54 PM, Julia Kreger wrote:

On Tue, May 29, 2018 at 7:42 PM, Zane Bitter  wrote:
[trim]

Since I am replying to this thread, Julia also mentioned the situation where
two core reviewers are asking for opposite changes to a patch. It is never
ever ever the contributor's responsibility to resolve a dispute between two
core reviewers! If you see a core reviewer's advice on a patch and you want
to give the opposite advice, by all means take it up immediately - with *the
other core reviewer*. NOT the submitter. Preferably on IRC and not in the
review. You work together every day, you can figure it out! A random
contributor has no chance of parachuting into the middle of that dynamic and
walking out unscathed, and they should never be asked to.



Absolutely agree! In the case that was in mind where it has happened
to me personally, I think it was 10-15 revisions apart, so it becomes
a little hard to identify when your starting to play the game of "make
the cores happy to land it". It is not a fun game for the contributor.
Truthfully it caused me to add the behavior of intentionally waiting
longer between uploads of new revisions... which does not help at all.

The other conundrum is when you disagree and the person has left a -1
which blocks forward progress and any additional reviews since it gets
viewed as "not ready", which makes it even harder and slower to build
consensus. At some point you get into "Oh, what formatting can I
change to clear that -1 because the person is not responding" mode.


This, by the way, is a much broader and interesting question. In case of a 
by-passer leaving a comment ("this link must be https") and disappearing, the 
PTL or any core can remove the reviewer from the review. What to do with a core 
leaving a comment or non-core leaving a potentially useful comment and going to PTO?




At least beginning to shift the review culture should help many of these issues.

__
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] [tc][all] A culture change (nitpicking)

[Julia Kreger]

I don't feel like anyone is proposing to end the use of -1's, but that
we should generally be encouraging, accepting, and trusting. That
means if there are major gaps or issues, then the use of a -1 is
perfectly valid because it needs more work. We also need to be mindful
of context as well, and in the grand scheme not try for something
perfect as many often do. This *does* mean we land something that
needs to be fixed later or reverted later, but neither are things we
should fear. We can't let that fear control us.

There are also the qualifiers of "does this help" or "does this harm",
and neither are nitpicks to me. That is also going to vary from
project to project, and even more so case by case based upon the item
being evaluated. That is where the context is important. Perhaps we
need to also, as the community evolves, consider mindfulness. Granted,
mindfulness is hard and can be even harder with elevated stress. Maybe
this is where we should also pitch something like "Stacker Cruises"
with an intermediate forced vacation for everyone. :)

On Wed, May 30, 2018 at 6:11 AM, Dmitry Tantsur  wrote:
> Hi,
>
> This is a great discussion and a great suggestion overall, but I'd like to
> add a grain of salt here, especially after reading some comments.
>
> Nitpicking is bad, no disagreement. However, I don't like this whole
> discussion to end up marking -1's as offense or aggression. Just as often as
> I see newcomers proposing patches frustrated with many iterations, I see
> newcomers being afraid to -1.
>
> In my personal experience I have two remarkable cases:
> 1. A person asking me (via a private message) to not put -1 on their patches
> because they may have problems with their managers.
> 2. A person proposing a follow-up on *any* comment to their patch, including
> important ones.
>
> Whatever decision the TC takes, I would like it to make sure that we don't
> paint putting -1 as a bad act. Nor do I want "if you care, just follow-up"
> to be an excuse for putting up bad contributions.
>
> Additionally, I would like to have something saying that a -1 is valid and
> appropriate, if a contribution substantially increases the project's
> technical debt. After already spending *days* refactoring ironic unit tests,
> I will -1 the hell out of a patch that will try to bring them back to their
> initial state, I promise :)
>
> Dmitry
>
>
> On 05/29/2018 03:55 PM, Julia Kreger wrote:
>>
>> During the Forum, the topic of review culture came up in session after
>> session. During these discussions, the subject of our use of nitpicks
>> were often raised as a point of contention and frustration, especially
>> by community members that have left the community and that were
>> attempting to re-engage the community. Contributors raised the point
>> of review feedback requiring for extremely precise English, or
>> compliance to a particular core reviewer's style preferences, which
>> may not be the same as another core reviewer.
>>
>> These things are not just frustrating, but also very inhibiting for
>> part time contributors such as students who may also be time limited.
>> Or an operator who noticed something that was clearly a bug and that
>> put forth a very minor fix and doesn't have the time to revise it over
>> and over.
>>
>> While nitpicks do help guide and teach, the consensus seemed to be
>> that we do need to shift the culture a little bit. As such, I've
>> proposed a change to our principles[1] in governance that attempts to
>> capture the essence and spirit of the nitpicking topic as a first
>> step.
>>
>> -Julia
>> -
>> [1]: https://review.openstack.org/570940
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] collect up and down time for deployed openstack resources

[Stefano Canepa]

On 30 May 2018 at 12:57, amal kammoun  wrote:

> Hi,
>
> We aim at collecting inter failures time for the compute and network
> resources (i.e., availability and reliability of each resource).
>
> Is there any mean via Restfull to collect these metrics ?
>
​You can use monasca-api to get measurements stored by Monasca. You can
setup monasca-agent to collect the data needed from the host running the
services.​

If not, which OpenStack/celiometer/heat modules may be extended in order to
> collect this information via the implementation of a prob protocol for
> instance?
>
>
> Thanks in adavance,
>
>
> Regards,
>
>
> Amal
>


​All the best
Stefano

​
​
-- 
Stefano Canepa aka sc s...@linux.it or stef...@canepa.ge.it
www.stefanocanepa.it
Three great virtues of a programmer: laziness, impatience, and hubris.
(Larry Wall)
__
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] [tc][all] A culture change (nitpicking)

[Yolanda Robla Mota]

I see another problem working on patchsets with lots of revisions and
long-lived history, such as specs or a complex change. The opinions of
several reviewers may be different. So first reviewer lefts a comment, the
owner of the change amends the patch according to it. But after time and
iterations pass (and because the history is very long or impossible to
read) another reviewer who has not read the whole history, may come and put
a -1 that contradicts the initial change. Things like that could be sorted
if we keep shorter patchsets, and merge things that are production ready
but not perfect, then we come up with follow-up patches to amend possible
comments, or create enhancements.

On Wed, May 30, 2018 at 4:16 PM, Dmitry Tantsur  wrote:

> On 05/30/2018 03:54 PM, Julia Kreger wrote:
>
>> On Tue, May 29, 2018 at 7:42 PM, Zane Bitter  wrote:
>> [trim]
>>
>>> Since I am replying to this thread, Julia also mentioned the situation
>>> where
>>> two core reviewers are asking for opposite changes to a patch. It is
>>> never
>>> ever ever the contributor's responsibility to resolve a dispute between
>>> two
>>> core reviewers! If you see a core reviewer's advice on a patch and you
>>> want
>>> to give the opposite advice, by all means take it up immediately - with
>>> *the
>>> other core reviewer*. NOT the submitter. Preferably on IRC and not in the
>>> review. You work together every day, you can figure it out! A random
>>> contributor has no chance of parachuting into the middle of that dynamic
>>> and
>>> walking out unscathed, and they should never be asked to.
>>>
>>>
>> Absolutely agree! In the case that was in mind where it has happened
>> to me personally, I think it was 10-15 revisions apart, so it becomes
>> a little hard to identify when your starting to play the game of "make
>> the cores happy to land it". It is not a fun game for the contributor.
>> Truthfully it caused me to add the behavior of intentionally waiting
>> longer between uploads of new revisions... which does not help at all.
>>
>> The other conundrum is when you disagree and the person has left a -1
>> which blocks forward progress and any additional reviews since it gets
>> viewed as "not ready", which makes it even harder and slower to build
>> consensus. At some point you get into "Oh, what formatting can I
>> change to clear that -1 because the person is not responding" mode.
>>
>
> This, by the way, is a much broader and interesting question. In case of a
> by-passer leaving a comment ("this link must be https") and disappearing,
> the PTL or any core can remove the reviewer from the review. What to do
> with a core leaving a comment or non-core leaving a potentially useful
> comment and going to PTO?
>
>
>
>> At least beginning to shift the review culture should help many of these
>> issues.
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>



-- 

Yolanda Robla Mota

Principal Software Engineer, RHCE

Red Hat



C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: +34605641639


__
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