Re: [openstack-dev] [Release-job-failures][telemetry][gnocchi] Release of openstack/python-gnocchiclient failed

[Mehdi Abaakouk]

Thanks for the investigation.

I see two things:

* I have forgotten than pushing tag will build the tarball
 automatically.
* I have thought I should do the tagging manually because of [1]

For the second point, if I was wrong and we should continue to use the
release repo, I have prepared two reviews to regularize the already
tagged releases and retag a versions to fix the jobs.

- gnocchiclient: https://review.openstack.org/#/c/456448/
- gnocchi: https://review.openstack.org/#/c/456449/

If I was right, I will manually retag a new version without uploading the
tarballs myself this time and wait for the tooling to do it.

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

On Wed, Apr 12, 2017 at 01:49:54PM -0400, Doug Hellmann wrote:

Gnocchi team,

The client release you tagged had a build failure.  It looks like
the tag was pushed directly, so I will relay the results of the
debugging work but let you decide how to deal with it.

Clark determined that the files on PyPI do not exactly match the files
on our tarballs server. One of the JSON metadata files was regenerated,
and because dictionaries are unordered it came out in a different order.

Clark also checked the MD5 sum on PyPI and found that the signatures
match.

It's not clear why the job failed. Subsequent jobs have passed. One
course of action you could take is to retag the same commit with a new
version number to get new packages, just to be safe.

If you choose to stick with the existing packages, you will need to
manually submit the constraint update, since that job was skipped after
the upload job reported a failure.

Please also file the update in the releases repository, so that
there is a record of the fact that the release was made.

Excerpts from jenkins's message of 2017-04-12 09:29:09 +:

Build failed.

- python-gnocchiclient-tarball 
http://logs.openstack.org/6f/6fd3d262bf88c1b8b8e195aef451cde80a7e7c1d/release/python-gnocchiclient-tarball/61adb8c/
 : SUCCESS in 3m 52s
- python-gnocchiclient-tarball-signing 
http://logs.openstack.org/6f/6fd3d262bf88c1b8b8e195aef451cde80a7e7c1d/release/python-gnocchiclient-tarball-signing/c7dd0a8/
 : SUCCESS in 11s
- python-gnocchiclient-pypi-both-upload 
http://logs.openstack.org/6f/6fd3d262bf88c1b8b8e195aef451cde80a7e7c1d/release/python-gnocchiclient-pypi-both-upload/0ad195d/
 : FAILURE in 48s
- python-gnocchiclient-announce-release python-gnocchiclient-announce-release : 
SKIPPED
- propose-python-gnocchiclient-update-constraints 
propose-python-gnocchiclient-update-constraints : SKIPPED



__
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


--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht


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] Boston Forum Schedule Online

[Tom Fifield]

Hello all,

The schedule for our the Forum is online:

https://www.openstack.org/summit/boston-2017/summit-schedule/#track=146


==> Session moderators, please start advertising your sessions & 
starting pre-discussions, to get the best, most well-informed people 
there possible!



==> Anyone else, please register your interest for sessions by 'ticking' 
them on th schedule. We use that information for room sizing.



Finally, thank you to the many who reviewed the draft. We fixed up those 
duplicates and made some slight changes to one or two sessions where 
there were conflicting talks. We're still working on contacting a couple 
of those marked as 'incomplete' in the tool, but they should be online 
shortly too.




Regards,


Doug, Emilien, Melvin, Mike, Shamail & Tom
Forum Scheduling Committee

__
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] [libvirt] Whether kvm supports NVIDIA VGPU

[文峰sx-9149]

Will the openstack or libvirt (kvm) support NVIDIA VGPU? I am here to see a 
mail introduction libvirt kvm support VGPU. But I do not know the current 
development situation of this feature. Who can tell me about VGPU in 
Openstack?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] [tripleo][deployment][helm][kolla][openstack-ansible] paunch - a library/tool for yaml driven docker configuration

[Emilien Macchi]

[adding more tags to make sure folks can see this thread]

What we would like to hear from Deployment projects (Kolla, OSA, Helm, etc) is:

1) Is there any overlap with some ongoing efforts?
2) Would you be interested by contributing to this effort?

Any feedback is welcome,
Thanks.

On Wed, Apr 12, 2017 at 10:25 PM, Steve Baker  wrote:
> This is just a heads-up that in a week or so I intend to propose a new git
> repo to be hosted by OpenStack and adopted by the TripleO project.
>
> paunch [1] is a python library and CLI tool which forklifts the logic of the
> docker-cmd heat-agents hook[2] into its own project.
>
> The change to switch the docker-cmd hook to paunch[3] deletes a satisfying
> number of lines of code. Typically a hook is a thin wrapper over another
> configuration tool, and the docker-cmd hook was an unfortunate exception.
>
> The YAML format used by paunch is currently driven by the needs of TripleO
> and is derived from the docker compose v1 format. Over time I'd like to
> evolve the format to faithfully implement defacto standard formats,
> specifically to ease the transition for TripleO to orchestrate containers
> with kubernetes.
>
> At this point I wouldn't advocate for the CLI to be a generally used tool
> for single node container orchestration, but it will gain some commands
> aimed at making developing and deploying containerised TripleO easier.
>
> I'll wait for about a week to get feedback on this proposal, in the meantime
> I'll continue to develop and document the format within [1].
>
> cheers
>
> [1] https://github.com/steveb/paunch
> [2]
> https://github.com/openstack/heat-agents/tree/master/heat-config-docker-cmd
> [3] https://review.openstack.org/#/c/455845/
>
> __
> 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
>



-- 
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] [Tacker][OSC] Command naming specs

[Akihiro Motoki]

networking-sfc has many overlapping areas with tacker and the command names
can conflict, so I believe it is worth shared in this thread.

networking-sfc team is now implementing OSC commands (as neutronclient OSC
plugin).
Their command name proposal can be found at
https://review.openstack.org/#/c/409759/
and command names are like
https://review.openstack.org/#/c/409759/30/doc/source/usage/osc/v2/networking-sfc.rst

As of now, networking-sfc commands are like:
  openstack sfc port chain create
  openstack sfc port pair group create
  openstack sfc port pair create
  openstack sfc flow classifier create

We would like to use 'sfc' (or 'network sfc') and
hope the tacker team avoid conflicts and confusions between tacker and
networking-sfc commands.

Personally, 'sfc' is not a well-known abbreviation, but the full spelling
'service function chaining' looks too long.
I don't think users want to type 'openstack service function chaining port
chain group create' :-(  It loses usability significantly.

Thanks,
Akihiro

2017-04-13 8:23 GMT+09:00 Trinath Somanchi :

> But if we don’t prefix, then we are afraid we might confuse users with
> command names and conflict with other projects.
>
>
>
> Example, ‘network-service’ if we follow the existing way, then
>
>
>
> $> openstack network service create
>
>
>
> might confuse the user in context that it’s a neutron/networking command.
> Is that not True?
>
>
>
> Also, for some other commands, like sfc, we might end up conflict with
> networking-sfc.
>
>
>
> Like, $> openstack  sfc show  (or) openstack service function chain show
>
>
>
> With some of the other commands, there are abbreviations like
>
>
>
> $> openstack vnffgd create
>
>
>
> If the above command must be split to words, it spells like,
>
>
>
> $> openstack virtual network function forwarding graph descriptor create
>  
>
>
>
> If we elaborate this way the command itself will be a lengthy string where
> user has a very lengthy command.
>
>
>
> Any suggestions for these?
>
> Thanks,
>
> *Trinath Somanchi.*
>
>
>
> Digital Networking | NXP – Hyderabad – INDIA.
>
> Email: *trinath.soman...@nxp.com *
>
> Mobile: +91 9866235130 <+91%2098662%2035130> | Off: +91 4033504051
> <+91%2040%203350%204051>
>
> [image: cid:image001.png@01D28854.B7934C80]
>
>
>
> *From:* Dean Troyer [mailto:dtro...@gmail.com]
> *Sent:* Wednesday, April 12, 2017 10:17 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [Tacker][OSC] Command naming specs
>
>
>
> On Wed, Apr 12, 2017 at 2:08 AM, Trinath Somanchi <
> trinath.soman...@nxp.com> wrote:
>
> Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the
> prefix.
>
>
>
> Note that OSC itself does not use 'command prefixes', it names resources
> with enough specificity to make them unique.  Sometimes that looks like a
> proefix, but it is not.
>
>
>
>
>
> For the below commands, for readability, we have added ‘-‘ within the
> command names.
>
> Like,
>
>   network-service,  vnf-forwarding-graph, service-function-chain,
>
> network-flow-classifier, network-forwarding-path.
>
>
>
> But the existing OSC commands don’t have a ‘-‘ in between the command
> names.
>
>
>
> The OSC command structure specifically does not use dashes or underscores
> as separators, it uses spaces.  We want commands to be words.  Dashes are
> only used in option names due to option parsing rules.
>
>
>
> Specifically in networking there are a large number of resources that are
> hard to concisely name.  Plugins are of course free to do what they want
> but we encourage them to use the OSC guidelines, and we know that users
> _really_ appreciate staying consistent.
>
>
>
> There are places where you may feel forced to use abbreviations ('vnf' in
> your example above).  Those are discouraged, but we also recognize that
> they are often the most common usage ('IP' in IP address for example) and
> where that usage is common is fine.  Again, networking is an area where
> many things are commonly known only by their abbreviation, and this usage
> is in fact expected by users.  In the end, picking commands that are what
> users would expect to search for is what they appreciate the most.
>
>
>
> dt
>
>
>
> --
>
>
> Dean Troyer
> dtro...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack 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] paunch - a library/tool for yaml driven docker configuration

[Steve Baker]

This is just a heads-up that in a week or so I intend to propose a new git
repo to be hosted by OpenStack and adopted by the TripleO project.

paunch [1] is a python library and CLI tool which forklifts the logic of
the docker-cmd heat-agents hook[2] into its own project.

The change to switch the docker-cmd hook to paunch[3] deletes a satisfying
number of lines of code. Typically a hook is a thin wrapper over another
configuration tool, and the docker-cmd hook was an unfortunate exception.

The YAML format used by paunch is currently driven by the needs of TripleO
and is derived from the docker compose v1 format. Over time I'd like to
evolve the format to faithfully implement defacto standard formats,
specifically to ease the transition for TripleO to orchestrate containers
with kubernetes.

At this point I wouldn't advocate for the CLI to be a generally used tool
for single node container orchestration, but it will gain some commands
aimed at making developing and deploying containerised TripleO easier.

I'll wait for about a week to get feedback on this proposal, in the
meantime I'll continue to develop and document the format within [1].

cheers

[1] https://github.com/steveb/paunch
[2]
https://github.com/openstack/heat-agents/tree/master/heat-config-docker-cmd
[3] https://review.openstack.org/#/c/455845/
__
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] [kolla] Tags, revisions, dockerhub

[Steve Baker]

On Thu, Apr 13, 2017 at 10:59 AM, Michał Jastrzębski 
wrote:

> My dear Kollegues,
>
> Today we had discussion about how to properly name/tag images being
> pushed to dockerhub. That moved towards general discussion on revision
> mgmt.
>
> Problem we're trying to solve is this:
> If you build/push images today, your tag is 4.0
> if you do it tomorrow, it's still 4.0, and will keep being 4.0 until
> we tag new release.
>
> But image built today is not equal to image built tomorrow, so we
> would like something like 4.0.0-1, 4.0.0-2.
> While we can reasonably detect history of revisions in dockerhub,
> local env will be extremely hard to do.
>
> I'd like to ask you for opinions on desired behavior and how we want
> to deal with revision management in general.
>
>
I already have a change which proposes tagging images with a pbr built
version [1]. I think if users want tags which are stable for the duration
of a major release they should switch to using the tag specified by
kolla-build.conf base_tag, which can be set to latest, ocata, pike, etc.
This would leave the version tag to at least track changes to the kolla
repo itself. Since the contents of upstream kolla images come from such
diverse sources, all I could suggest to ensure unique tags are created for
unique images is to append a datestamp to [1] (or have an extra datestamp
based tag). Bonus points for only publishing a new datestamp tag if the
contents of the image really changes.

In the RDO openstack-kolla package we now tag images with the
{Version}-{Release} of the openstack-kolla package which built it[2]. I
realise this doesn't solve the problem of the tag needing to change when
other image contents need to be updated, but I believe this can be solved
within the RDO image build pipeline by incrementing the {Release} whenever
a new image needs to be published.

[1] https://review.openstack.org/#/c/448380/
[2] https://review.rdoproject.org/r/#/c/5923/1/openstack-kolla.spec
__
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][election] Questions for Candidates

[Joshua Hesketh]

On Thu, Apr 13, 2017 at 2:19 AM, Kendall Nelson 
wrote:

> Hello Candidates!
>
> You all have proven yourselves to be crucial parts of the community and I
> just wanted to say good luck to each one of you in the upcoming election!
>
> Also though, I thought it might be good to ask a few more questions. It's
> easy to talk about what you all want to champion on the TC and about the
> ideal breakdown of how you want to spend your time, but it's much harder to
> answer questions that might highlight some of the daily struggles. So!
> Interview time:
>
> -What is one trait you have that makes it difficult to work in groups like
> the TC and how do you counteract it?
>

I think the obvious one is going to be the remoteness and timezones. These
have effects that are being discussed at length in some of the other
threads. However there have been some good suggestions in those threads on
how to mitigate it through utilising other media more effectively.

Another challenge is balancing the needs of the many. I think the community
does a great job at being accommodating to as many individuals, companies
and technologies as they can. However this can often come at the cost of
actually getting things done (perfection is the enemy of progress etc). I
think the TC will need to be pragmatic about its decisions and begin to be
more opinionated in order to be able to be focused and not over burdened.


>
> - What do you see as the biggest roadblock in the upcoming releases for
> the TC?
>

In terms of the releases I think we need to be careful not to bite off more
than we can chew. Recently we've been focusing on making the base layers
more stable, upgrades more seamless etc. and I think these are great. It's
easy to be ambitious with what we want to achieve in a cycle but we also
need to be realistic about our resources as the product matures.



>
> And one lighthearted question:
>
> -What is your favorite thing about OpenStack?
>


The community - it's such a pleasure to work with everybody. Everyone is so
incredibly helpful and always go out of their way as we try to work towards
a common goal.


>
> Thank you for your answers!
>

Thank you for the questions :-)

Cheers,
Josh


>
> -Kendall Nelson
>
> __
> 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] [oslo][infra][pbr] Nominating Stephen Finucane for pbr-core

[Joshua Hesketh]

+1, yay! :-)

On Thu, Apr 13, 2017 at 2:46 AM, Doug Hellmann 
wrote:

> Excerpts from Monty Taylor's message of 2017-04-12 08:14:31 -0500:
> > Hey all,
> >
> > As I'm sure you all know, pbr is both our most pervasively used
> > dependency and our least well understood. Nobody ever wants to look at
> > the code (sorry, I can write ugly code sometimes - but also wow
> > setuptools) or dig in to figure out what happened when things break.
> >
> > Recently Stephen Finucane (sfinucan) has stepped up to the plate to help
> > sort out issues we've been having. He's shown a lack of fear of the
> > codebase and an understanding of what's going on. He's also following
> > through on patches to projects themselves when needed, which is a huge
> > part of the game. And most importantly he knows when to suggest we _not_
> > do something.
> >
> > It's not a HUGE corpus of work we have to go on - but that's a good
> > thing - pbr shouldn't chance much - but it's in keeping with the other
> > active pbr maintainers:
> >
> > http://stackalytics.com/report/contribution/pbr/90
> >
> > Monty
> >
>
> +1 -- Stephen has been doing good work elsewhere, too.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Emails for OpenStack R Release Name voting going out - please be patient

[Sean McGinnis]

On Wed, Apr 12, 2017 at 05:27:13PM -0500, Jay S Bryant wrote:
> I also didn't receive an e-mail.  :-(
> 
I don't think we need to perpetuate this thread for everybody
that didn't get it. I think it's safe to see that a large number
of folks have not recieved the email. (Me included) :)


__
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][elections]questions about one platform vision

[joehuang]

 Interesting to know the idea considering OpenStack as group of constellations. 
Does it mean even
Nova/Cinder/Neutron are not necessary to be tied together in some user cases?

Seems that "one platform" has not been got consensus yet. But the marketing 
material of
OpenStack is claiming "one platform" [1][2]

[1] https://www.openstack.org/assets/marketing/OpenStack-101-Modular-Deck-1.pptx
[2] OpenStack 101,  https://www.openstack.org/marketing/#tab=collateral

Best Regards
Chaoyi Huang (joehuang)


From: John Garbutt [j...@johngarbutt.com]
Sent: 12 April 2017 18:51
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc][elections]questions about one platform
vision

On 12 April 2017 at 03:54, joehuang  wrote:
> What's the one platform will be in your own words? What's your proposal and
> your focus to help one platform vision being achieved?

The more I think about this, the less I like the phrase "one platform".

I like to think of OpenStack as group of constellations. Those
constellations are groups of projects that are built to be used
together around a shared set of use cases and users. Note that many
(all?) of those constellations involve open source projects that were
born and live outside of OpenStack.

I am trying to kick start the "VM and baremetal" working group to get
feedback on a specific constellation as a group of projects. Here I am
thinking about running Nova, Cinder, Neutron, Keystone, etc to give
you (in some sense) a Software Defined Data Center. Many applications
and services need to consume and integrate with that platform, like
Heat, Trove and Magnum, to can get access to the compute, networking
and storage they need to execute their workloads, such as containers.
Its like the next generation of consolidation to get to the next level
of utilization/efficiency. If you look at this constellation the
database and message queue are important non-OpenStack components of
the constellation. Maybe this is a false constellation, and there is a
different set of things that people use together. Thats some of the
feedback I hope we get at the forum.

The work ttx mentions is important. I hope the project maps will help
communicate how users can meet their needs by running various
combinations of OpenStack and non-OpenStack projects together.

To be clear, I am not claiming to have the answers here, this is just
my current thinking. I look forward to all the debate and discussions
around this topic, and all the interesting things I will learn about
along that journey, things that will likely make me change my mind.

Thanks,
johnthetubaguy

__
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][election] Questions for Candidates

[Sean McGinnis]

On Wed, Apr 12, 2017 at 04:19:55PM +, Kendall Nelson wrote:
> Hello Candidates!
> 
> You all have proven yourselves to be crucial parts of the community and I
> just wanted to say good luck to each one of you in the upcoming election!
> 
> Also though, I thought it might be good to ask a few more questions. It's
> easy to talk about what you all want to champion on the TC and about the
> ideal breakdown of how you want to spend your time, but it's much harder to
> answer questions that might highlight some of the daily struggles. So!
> Interview time:
> 
> -What is one trait you have that makes it difficult to work in groups like
> the TC and how do you counteract it?

I like to help facilitate to get things done, but to be honest, sometimes when
a particular topic does not interest me I don't spend as much time as I should
digging into the nitty gritty in order to give deeper and more valuable input.

> 
> - What do you see as the biggest roadblock in the upcoming releases for the
> TC?

Having skimmed through some of the other responses, I'm a bit of a broken
record. I think the biggest roadblock is getting contributors and investment
from companies to get the big issues taken care of. I think the TC can have
an impact on encouraging involvement, and the policies we help form will have
a direct impact on that.

There's been some talk of not being influenced too strongly by vendors. I think
we need to turn that around a little though. I think we need to help vendors,
both to get them involved and to help them meet their goals with OpenStack. At
the end of the day, OpenStack investment is most useful to those trying to make
money from using it. If we can help direct their wants into something commonly
beneficial, then it improves OpenStack, it helps the vendors on the business
side, and in return it increases the odds of continued investment in time and
resources towards getting more done.

I'm definitely not saying we should base technical decisions on the demands of
whoever has the biggest bank account. But if we can make it easier in general
for them and be receptive to what they see as priorities, then _where it makes
sense_, we can all benefit.

> 
> And one lighthearted question:
> 
> -What is your favorite thing about OpenStack?

Broken record again, but the people are my favorite part of OpenStack as well.
This has been the best community I've been invovled in and have learned so
much for being part of it. If everyone here decided to drop this and go off
to produce a ubiquitous Open Source cat picture platform that is easy to use,
simple to implement, etc., I'd be tempted to join them. :)
 
> 
> Thank you for your answers!
> 
> -Kendall Nelson

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


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

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

[Tony Breeds]

On Wed, Apr 12, 2017 at 02:27:22PM +, gordon chung wrote:
> i imagine you can EOL python-aodhclient and ceilometermiddleware. thanks 

Thanks I've added those repos/projects.

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] [all][stable][ptls] Tagging mitaka as EOL

[Tony Breeds]

On Wed, Apr 12, 2017 at 04:06:36PM +0200, Andreas Jaeger wrote:
> Please add openstack-manuals to the list for EOL,

Thanks Added!

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] [all][stable][ptls] Tagging mitaka as EOL

[Tony Breeds]

On Wed, Apr 12, 2017 at 07:53:17AM -0600, Alex Schultz wrote:

> Please EOL the Puppet OpenStack projects that have the stable/mitaka branch.

Thanks Alex!  I've added:
openstack/puppet-aodh
openstack/puppet-ceilometer
openstack/puppet-cinder
openstack/puppet-designate
openstack/puppet-glance
openstack/puppet-gnocchi
openstack/puppet-heat
openstack/puppet-horizon
openstack/puppet-ironic
openstack/puppet-keystone
openstack/puppet-manila
openstack/puppet-mistral
openstack/puppet-murano
openstack/puppet-neutron
openstack/puppet-nova
openstack/puppet-openstack-integration
openstack/puppet-openstack_extras
openstack/puppet-openstack_spec_helper
openstack/puppet-openstacklib
openstack/puppet-sahara
openstack/puppet-swift
openstack/puppet-tempest
openstack/puppet-trove
openstack/puppet-vswitch
openstack/puppet-zaqar
openstack/puppet-midonet

To the list of projects/repos to EOL.  Note openstack/puppet-midonet isn't part
of the "Puppet OpenStack" project but I'm erring on the side of including it.

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] [elections] Available time and top priority

[Sean McGinnis]

On Wed, Apr 12, 2017 at 07:05:42PM +0900, Ildiko Vancsa wrote:
> 
> As a version of this idea, I was thinking of an #openstack-tc IRC channel, 
> but wanted to give it another thought before bringing it up. :) While I don’t 
> have the intention to necessarily increase the number of IRC channels we 
> have, this would give us the ability to follow the TC related discussion 
> better.
> 
> By being experienced with working remotely, I like channels with smaller well 
> defined scope/purpose as I can prioritize which one to read first and I don’t 
> need to filter that much of the different, sometimes parallel threads to 
> catch up on what happened. Also when I see activity on these channels I get a 
> better indicator whether I need to/want to look into the discussion 
> immediately and be part of it or not. I don’t want to decrease the importance 
> of #openstack-dev (or any other already existing channel), but rather noting 
> that it has a broader scope that might be distracting.
> 

+2!

> My 2 cents.
> 
> Thanks,
> Ildikó
> 

__
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] [kolla][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Matt Riedemann]

On 4/12/2017 3:40 PM, Steven Dake (stdake) wrote:

Matt,

Thanks for the response.  It is helpful.

Regards
-steve

-Original Message-
From: Matt Riedemann 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, April 12, 2017 at 4:36 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship 
program for Kolla deliverables

On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:
> Hey folks,
>
>
>
> In today’s Kolla team meeting, the idea was proposed of adopting nova’s
> “protocore” mentorship program for Kolla.  We would like to know what
> nova has learned from this effort.
>
>
>
> In today’s Kolla meeting we had broad consensus on the following:
>
> 1)   Kolla has participants that want to be core reviewers
>
> 2)   These participants don’t know how to become core reviewers
>
> 3)   The core reviewers in Kolla should mentor “protocore” reviewers
> on how to do good reviews
>
>
>
> From that, we concluded some form of mentorship program for potential
> core reviewers was in order.  We got into some debate about _/how/_ the
> program should be rolled out.  Let’s use this thread to discuss how it
> should be rolled out since that seems to be the sticking point of the
> discussion.  I saw no dissent in the discussion that the basic concepts
> were a negative change.
>
>
>
> I am aware that nova uses a +1 review from a “protocore” and a +2/+w
> from a core reviewer prior to merge.  Nova cores – would you mind
> defining your process (on the ml is fine) more thoroughly and your
> experiences so we can learn from you?
>
>
>
> All kolla contributors, feel free to debate the **how** such a
> mentorship program should be rolled out.  I think we have a lot to learn
> from our peers in the OpenStack community and learning from their
> experiences may be helpful.
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> __
> 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
>

Nova has this thing? That's news to me. :)

I don't think Nova has a formal process for something like this. There
was talk at the BCN summit about giving some people +2 rights on parts
of the tree but not full core on everything. We never implemented that.

Maybe what you're referring to is how we consider a +1 from a domain
expert like a +2, or at least something that's good to have before cores
are looking into the change in more detail? For example, gibi is the
lead for the versioned notifications effort and we/I generally look for
his +1 on a change before digging into it, or approving it. We have
similar unofficial things like this in other parts of Nova, or subteams,
like Timofey and Pawel with the live migration subteam.

To be sure, someone that is leading a subteam effort and is looked to
for their opinion on a whole series of changes eventually gets into the
conversation when we're talking about potential core reviewers, in part
because, at least I personally, am looking for not only strong code
review skills but also leadership/ownership within the project, because
those are also the people that tend to stick around awhile so I'm more
comfortable investing my time into them (and building a trust
relationship with them).

So that's all unofficial non-formal stuff and basically grew up
organically around the subteam efforts that started several releases
ago. I don't know if this helps you or not.

--

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


__
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



By the way, I should add, while we look for a +1 from a subteam or 
domain expert, it does not equate to a +2 so that a core can come along 
and +2/+W. We still require 2 +2s.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [Tacker][OSC] Command naming specs

[Trinath Somanchi]

But if we don’t prefix, then we are afraid we might confuse users with command 
names and conflict with other projects.

Example, ‘network-service’ if we follow the existing way, then

$> openstack network service create

might confuse the user in context that it’s a neutron/networking command. Is 
that not True?

Also, for some other commands, like sfc, we might end up conflict with 
networking-sfc.

Like, $> openstack  sfc show  (or) openstack service function chain show

With some of the other commands, there are abbreviations like

$> openstack vnffgd create

If the above command must be split to words, it spells like,

$> openstack virtual network function forwarding graph descriptor create  


If we elaborate this way the command itself will be a lengthy string where user 
has a very lengthy command.

Any suggestions for these?
Thanks,
Trinath Somanchi.

Digital Networking | NXP – Hyderabad – INDIA.
Email: trinath.soman...@nxp.com
Mobile: +91 9866235130 | Off: +91 4033504051


From: Dean Troyer [mailto:dtro...@gmail.com]
Sent: Wednesday, April 12, 2017 10:17 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Tacker][OSC] Command naming specs

On Wed, Apr 12, 2017 at 2:08 AM, Trinath Somanchi 
> wrote:
Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the prefix.

Note that OSC itself does not use 'command prefixes', it names resources with 
enough specificity to make them unique.  Sometimes that looks like a proefix, 
but it is not.


For the below commands, for readability, we have added ‘-‘ within the command 
names.
Like,
  network-service,  vnf-forwarding-graph, service-function-chain,
network-flow-classifier, network-forwarding-path.

But the existing OSC commands don’t have a ‘-‘ in between the command names.

The OSC command structure specifically does not use dashes or underscores as 
separators, it uses spaces.  We want commands to be words.  Dashes are only 
used in option names due to option parsing rules.

Specifically in networking there are a large number of resources that are hard 
to concisely name.  Plugins are of course free to do what they want but we 
encourage them to use the OSC guidelines, and we know that users _really_ 
appreciate staying consistent.

There are places where you may feel forced to use abbreviations ('vnf' in your 
example above).  Those are discouraged, but we also recognize that they are 
often the most common usage ('IP' in IP address for example) and where that 
usage is common is fine.  Again, networking is an area where many things are 
commonly known only by their abbreviation, and this usage is in fact expected 
by users.  In the end, picking commands that are what users would expect to 
search for is what they appreciate the most.

dt

--

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

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

[Fox, Kevin M]

+1 to revision information in tags. If you don't have it, depending on when 
containers start, you could have different versions of software with/without 
bug fixes running on the same cluster without an easy way to know.

We've seen this with libvirt versions being 1.x in some builds and 2.x in 
fresher builds.

We can still keep around the unrevisioned tags too for folks that don't want to 
deal with the revision numbers. in which case, the unrevisioned 4.0.0 tag would 
map to the newest revisioned tag, say 4.0.0-2 and would have the same behavior 
then as is today.

Thanks,
Kevin

From: Michał Jastrzębski [inc...@gmail.com]
Sent: Wednesday, April 12, 2017 3:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [kolla] Tags, revisions, dockerhub

My dear Kollegues,

Today we had discussion about how to properly name/tag images being
pushed to dockerhub. That moved towards general discussion on revision
mgmt.

Problem we're trying to solve is this:
If you build/push images today, your tag is 4.0
if you do it tomorrow, it's still 4.0, and will keep being 4.0 until
we tag new release.

But image built today is not equal to image built tomorrow, so we
would like something like 4.0.0-1, 4.0.0-2.
While we can reasonably detect history of revisions in dockerhub,
local env will be extremely hard to do.

I'd like to ask you for opinions on desired behavior and how we want
to deal with revision management in general.

Cheers,
Michal

__
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] [kolla] Tags, revisions, dockerhub

[Michał Jastrzębski]

My dear Kollegues,

Today we had discussion about how to properly name/tag images being
pushed to dockerhub. That moved towards general discussion on revision
mgmt.

Problem we're trying to solve is this:
If you build/push images today, your tag is 4.0
if you do it tomorrow, it's still 4.0, and will keep being 4.0 until
we tag new release.

But image built today is not equal to image built tomorrow, so we
would like something like 4.0.0-1, 4.0.0-2.
While we can reasonably detect history of revisions in dockerhub,
local env will be extremely hard to do.

I'd like to ask you for opinions on desired behavior and how we want
to deal with revision management in general.

Cheers,
Michal

__
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] [kolla][all][tc] Starting a core reviewer mentorship program for Kolla deliverables

[Michał Jastrzębski]

I was also thinking of having "cores just for single thing" in Kolla,
but I think that won't really work as most of our code is variation of
other parts with very little unique things to this, it's tuning up
details that takes most of our work (aside of already split
kolla-ansible and kolla-kubernetes).

That being said I fully support any effort to train new core team
members. In fact, I'd like to explore few ideas for that and maybe ask
for opinions of broader community:

1. Mentorship program
Every person who wants to be a core but doesn't feel confident about
his/hers ability can ask core team for mentor. This mentor-mantee
relationship will work in a way that mantee can ask mentor to
re-review his/hers review (+2 of my +1 or -1 with explanation what did
I miss), technical questions and things like that. I would be happy to
act as first point of contact to pair mantees with mentors (once we
establish some mechanism for that).

2. +1 matters
One thing that I see happening is misconception that +1 doesn't
matter. It does, but maybe we need to do something to break that
impression. Frankly I don't have good ideas for that, any experiences
anyone?

I think we, as broader OpenStack community could make this full
fledged cross project discussion and trade experiences (that's why I
broaden subject tags a little:)).

Cheers,
Michal


On 12 April 2017 at 13:40, Steven Dake (stdake)  wrote:
> Matt,
>
> Thanks for the response.  It is helpful.
>
> Regards
> -steve
>
> -Original Message-
> From: Matt Riedemann 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: Wednesday, April 12, 2017 at 4:36 PM
> To: "openstack-dev@lists.openstack.org" 
> Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer 
> mentorship program for Kolla deliverables
>
> On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:
> > Hey folks,
> >
> >
> >
> > In today’s Kolla team meeting, the idea was proposed of adopting nova’s
> > “protocore” mentorship program for Kolla.  We would like to know what
> > nova has learned from this effort.
> >
> >
> >
> > In today’s Kolla meeting we had broad consensus on the following:
> >
> > 1)   Kolla has participants that want to be core reviewers
> >
> > 2)   These participants don’t know how to become core reviewers
> >
> > 3)   The core reviewers in Kolla should mentor “protocore” reviewers
> > on how to do good reviews
> >
> >
> >
> > From that, we concluded some form of mentorship program for potential
> > core reviewers was in order.  We got into some debate about _/how/_ the
> > program should be rolled out.  Let’s use this thread to discuss how it
> > should be rolled out since that seems to be the sticking point of the
> > discussion.  I saw no dissent in the discussion that the basic concepts
> > were a negative change.
> >
> >
> >
> > I am aware that nova uses a +1 review from a “protocore” and a +2/+w
> > from a core reviewer prior to merge.  Nova cores – would you mind
> > defining your process (on the ml is fine) more thoroughly and your
> > experiences so we can learn from you?
> >
> >
> >
> > All kolla contributors, feel free to debate the **how** such a
> > mentorship program should be rolled out.  I think we have a lot to learn
> > from our peers in the OpenStack community and learning from their
> > experiences may be helpful.
> >
> >
> >
> > Regards
> >
> > -steve
> >
> >
> >
> >
> >
> > 
> __
> > 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
> >
>
> Nova has this thing? That's news to me. :)
>
> I don't think Nova has a formal process for something like this. There
> was talk at the BCN summit about giving some people +2 rights on parts
> of the tree but not full core on everything. We never implemented that.
>
> Maybe what you're referring to is how we consider a +1 from a domain
> expert like a +2, or at least something that's good to have before cores
> are looking into the change in more detail? For example, gibi is the
> lead for the versioned notifications effort and we/I generally look for
> his +1 on a change before digging into it, or approving it. We have
> similar unofficial things like this in other parts of Nova, or subteams,
> like Timofey and Pawel with the live migration subteam.
>
> To be sure, someone that is leading a subteam effort and is looked to
> for their opinion on a whole 

Re: [openstack-dev] Emails for OpenStack R Release Name voting going out - please be patient

[Jay S Bryant]

I also didn't receive an e-mail.  :-(


On 4/12/2017 1:33 PM, Kevin Benton wrote:

I haven't received one either.

Perhaps Monty has simply embraced the 'cattle not pets' approach and 
we were the unlucky ones. :)


On Apr 12, 2017 07:49, "Lance Bragstad" > wrote:



On Wed, Apr 12, 2017 at 9:42 AM, Amrith Kumar
> wrote:

Hmm, all the cool kids didn’t receive the email but I did. Now
I feel bad ☹

-amrith

*From:*Morgan Fainberg [mailto:morgan.fainb...@gmail.com
]
*Sent:* Wednesday, April 12, 2017 9:53 AM
*To:* OpenStack Development Mailing List (not for usage
questions) >
*Subject:* Re: [openstack-dev] Emails for OpenStack R Release
Name voting going out - please be patient

I also have not received a poll email.


Same here - I haven't received one.

On Apr 12, 2017 6:13 AM, "Neil Jerram" > wrote:

Nor me.

On Wed, Apr 12, 2017 at 1:55 PM Doug Hellmann
> wrote:

Excerpts from Dulko, Michal's message of 2017-04-12
12:09:30 +:
> On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:
> > On 04/06/2017 07:34 AM, Monty Taylor wrote:
> > >
> > > Hey all!
> > >
> > > I've started the R Release Name poll and
currently am submitting
> > > everyone's email address to the system. In order
to not make our fine
> > > friends at Carnegie Mellon (the folks who run
the CIVS voting service)
> > > upset, I have a script that submits the emails
one at a time with a
> > > half-second delay between each email. That means
at best, since there
> > > are 40k people to process it'll take ~6 hours
for them all to go out.
> > >
> > > Which is to say - emails are on their way - but
if you haven't gotten
> > > yours yet, that's fine. I'll send another email
when they've all gone
> > > out, so don't worry about not receiving one
until I've sent that mail.
> > Well- that took longer than I expected. Because of
some rate limiting,
> > 1/2 second delay was not long enough...
> >
> > Anyway - all of the emails should have gone out
now. Because that took
> > so long, I'm going to hold the poll open until
next Wednesday.
> >
> > Monty
>
> Not sure why, but I haven't received an email yet.
>
> Thanks,
> Michal

Nor I.

Doug


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



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





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


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




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

Re: [openstack-dev] [nova] Contributing support for Netronome Agilio adaptors

[Jan Gutter]

Hi,

Apologies for leaving this to the very last minute.

The blueprint and spec has been submitted for your consideration to:

https://blueprints.launchpad.net/nova/+spec/netronome-smartnic-enablement

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

We're in the final steps of getting the permission to share the
example code, but it might not make it in time for tomorrow.

Please feel free to email me for any questions: I'll try to be on IRC
tomorrow (my timezone is GMT+02:00).

-- 
Jan Gutter
Embedded Networking Software Engineer

Netronome | First Floor Suite 1, Block A, Southdowns Ridge Office Park,
Cnr Nellmapius and John Vorster St, Irene, Pretoria, 0157
Phone: +27 (12) 665-4427 | Skype: jangutter |  www.netronome.com

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

Re: [openstack-dev] [TripleO][Heat] Conditionally passing properties in Heat

[Dan Sneddon]

On 04/12/2017 01:22 PM, Thomas Herve wrote:
> On Wed, Apr 12, 2017 at 9:00 PM, Dan Sneddon  wrote:
>> I'm implementing predictable control plane IPs for spine/leaf, and I'm
>> running into a problem implementing this in the TripleO Heat templates.
>>
>> I have a review in progress [1] that works, but fails on upgrade, so I'm
>> looking for an alternative approach. I'm trying to influence the IP
>> address that is selected for overcloud nodes' Control Plane IP. Here is
>> the current construct:
>>
>>   Controller:
>> type: OS::TripleO::Server
>> metadata:
>>   os-collect-config:
>> command: {get_param: ConfigCommand}
>> properties:
>>   image: {get_param: controllerImage}
>>   image_update_policy: {get_param: ImageUpdatePolicy}
>>   flavor: {get_param: OvercloudControlFlavor}
>>   key_name: {get_param: KeyName}
>>   networks:
>> - network: ctlplane  # <- Here's where the port is created
>>
>> If I add fixed_ip: to the networks element at the end of the above, I
>> can select an IP address from the 'ctlplane' network, like this:
>>
>>   networks:
>> - network: ctlplane
>>   fixed_ip: {get_attr: [ControlPlanePort, ip_address]}
>>
>> But the problem is that if I pass a blank string to fixed_ip, I get an
>> error on deployment. This means that the old behavior of automatically
>> selecting an IP doesn't work.
>>
>> I thought I has solved this by passing an external Neutron port, like this:
>>
>>   networks:
>> - network: ctlplane
>>   port: {get_attr: [ControlPlanePort, port_id]}
>>
>> Which works for deployments, but that fails on upgrades, since the
>> original port was created as part of the Nova::Server resource, instead
>> of being an external resource.
> 
> Can you detail how it fails? I was under the impression we never
> replaced servers no matter what (or we try to do that, at least). Is
> the issue that your new port is not the correct one?
> 
>> I'm now looking for a way to use Heat conditionals to apply the fixed_ip
>> only if the value is not unset. Looking at the intrinsic functions [2],
>> I don't see a way to do this. Is what I'm trying to do with Heat possible?
> 
> You should be able to write something like that (not tested):
> 
> networks:
>   if:
> - 
> - network: ctlplane
>   fixed_ip: {get_attr: [ControlPlanePort, ip_address]}
> - network: ctlplane
> 
> The question is how to define your condition. Maybe:
> 
> conditions:
>   fixed_ip_condition:
>  not:
> equals:
>   - {get_attr: [ControlPlanePort, ip_address]}
>   - ''
> 
> To get back to the problem you stated first.
> 
> 
>> Another option I'm exploring is conditionally applying resources. It
>> appears that would require duplicating the entire TripleO::Server stanza
>> in *-role.yaml so that there is one that uses fixed_ip and one that does
>> not. Which one is applied would be based on a condition that tested
>> whether fixed_ip was blank or not. The downside of that is that it would
>> make the role definition confusing because there would be a large
>> resource that was implemented twice, with only one line difference
>> between them.
> 
> You can define properties with conditions, so you shouldn't need to
> rewrite everything.
> 

Thomas,

Thanks, I will try your suggestions and that should get me closer.

The full error log is available here:
http://logs.openstack.org/78/413278/11/check-tripleo/gate-tripleo-ci-centos-7-ovb-updates/8d91762/console.html

Here are the errors I am getting:

2017-04-12 00:26:34.436655 | 2017-04-12 00:26:29Z
[overcloud-CephStorage-bkucn6ign34i-0-2yq2jbtwuu7k.CephStorage]:
UPDATE_FAILED  RetryError: resources.CephStorage: RetryError[]
2017-04-12 00:26:34.436808 | 2017-04-12 00:26:29Z
[overcloud-CephStorage-bkucn6ign34i-0-2yq2jbtwuu7k]: UPDATE_FAILED
RetryError: resources.CephStorage: RetryError[]
2017-04-12 00:26:34.436903 | 2017-04-12 00:26:29Z
[overcloud-CephStorage-bkucn6ign34i.0]: UPDATE_FAILED  resources[0]:
RetryError: resources.CephStorage: RetryError[]
2017-04-12 00:26:34.436989 | 2017-04-12 00:26:29Z
[overcloud-CephStorage-bkucn6ign34i]: UPDATE_FAILED  resources[0]:
RetryError: resources.CephStorage: RetryError[]
2017-04-12 00:26:34.437078 | 2017-04-12 00:26:30Z
[overcloud-Controller-3lf3jauv4cbc-0-ydowkb3nwsso.Controller]:
UPDATE_FAILED  RetryError: resources.Controller: RetryError[]
2017-04-12 00:26:34.437173 | 2017-04-12 00:26:30Z
[overcloud-Controller-3lf3jauv4cbc-0-ydowkb3nwsso]: UPDATE_FAILED
RetryError: resources.Controller: RetryError[]
2017-04-12 00:26:34.437269 | 2017-04-12 00:26:30Z [CephStorage]:
UPDATE_FAILED  resources.CephStorage: resources[0]: RetryError:
resources.CephStorage: RetryError[]

-- 
Dan Sneddon |  Senior Principal Software Engineer
dsned...@redhat.com |  redhat.com/openstack
dsneddon:irc|  @dxs:twitter

__
OpenStack 

Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Steven Dake (stdake)]

Matt,

Thanks for the response.  It is helpful.

Regards
-steve

-Original Message-
From: Matt Riedemann 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, April 12, 2017 at 4:36 PM
To: "openstack-dev@lists.openstack.org" 
Subject: Re: [openstack-dev] [kolla][nova] Starting a core reviewer mentorship 
program for Kolla deliverables

On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:
> Hey folks,
>
>
>
> In today’s Kolla team meeting, the idea was proposed of adopting nova’s
> “protocore” mentorship program for Kolla.  We would like to know what
> nova has learned from this effort.
>
>
>
> In today’s Kolla meeting we had broad consensus on the following:
>
> 1)   Kolla has participants that want to be core reviewers
>
> 2)   These participants don’t know how to become core reviewers
>
> 3)   The core reviewers in Kolla should mentor “protocore” reviewers
> on how to do good reviews
>
>
>
> From that, we concluded some form of mentorship program for potential
> core reviewers was in order.  We got into some debate about _/how/_ the
> program should be rolled out.  Let’s use this thread to discuss how it
> should be rolled out since that seems to be the sticking point of the
> discussion.  I saw no dissent in the discussion that the basic concepts
> were a negative change.
>
>
>
> I am aware that nova uses a +1 review from a “protocore” and a +2/+w
> from a core reviewer prior to merge.  Nova cores – would you mind
> defining your process (on the ml is fine) more thoroughly and your
> experiences so we can learn from you?
>
>
>
> All kolla contributors, feel free to debate the **how** such a
> mentorship program should be rolled out.  I think we have a lot to learn
> from our peers in the OpenStack community and learning from their
> experiences may be helpful.
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> __
> 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
>

Nova has this thing? That's news to me. :)

I don't think Nova has a formal process for something like this. There 
was talk at the BCN summit about giving some people +2 rights on parts 
of the tree but not full core on everything. We never implemented that.

Maybe what you're referring to is how we consider a +1 from a domain 
expert like a +2, or at least something that's good to have before cores 
are looking into the change in more detail? For example, gibi is the 
lead for the versioned notifications effort and we/I generally look for 
his +1 on a change before digging into it, or approving it. We have 
similar unofficial things like this in other parts of Nova, or subteams, 
like Timofey and Pawel with the live migration subteam.

To be sure, someone that is leading a subteam effort and is looked to 
for their opinion on a whole series of changes eventually gets into the 
conversation when we're talking about potential core reviewers, in part 
because, at least I personally, am looking for not only strong code 
review skills but also leadership/ownership within the project, because 
those are also the people that tend to stick around awhile so I'm more 
comfortable investing my time into them (and building a trust 
relationship with them).

So that's all unofficial non-formal stuff and basically grew up 
organically around the subteam efforts that started several releases 
ago. I don't know if this helps you or not.

-- 

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


__
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] [kolla][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Matt Riedemann]

On 4/12/2017 11:59 AM, Steven Dake (stdake) wrote:

Hey folks,



In today’s Kolla team meeting, the idea was proposed of adopting nova’s
“protocore” mentorship program for Kolla.  We would like to know what
nova has learned from this effort.



In today’s Kolla meeting we had broad consensus on the following:

1)   Kolla has participants that want to be core reviewers

2)   These participants don’t know how to become core reviewers

3)   The core reviewers in Kolla should mentor “protocore” reviewers
on how to do good reviews



From that, we concluded some form of mentorship program for potential
core reviewers was in order.  We got into some debate about _/how/_ the
program should be rolled out.  Let’s use this thread to discuss how it
should be rolled out since that seems to be the sticking point of the
discussion.  I saw no dissent in the discussion that the basic concepts
were a negative change.



I am aware that nova uses a +1 review from a “protocore” and a +2/+w
from a core reviewer prior to merge.  Nova cores – would you mind
defining your process (on the ml is fine) more thoroughly and your
experiences so we can learn from you?



All kolla contributors, feel free to debate the **how** such a
mentorship program should be rolled out.  I think we have a lot to learn
from our peers in the OpenStack community and learning from their
experiences may be helpful.



Regards

-steve





__
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



Nova has this thing? That's news to me. :)

I don't think Nova has a formal process for something like this. There 
was talk at the BCN summit about giving some people +2 rights on parts 
of the tree but not full core on everything. We never implemented that.


Maybe what you're referring to is how we consider a +1 from a domain 
expert like a +2, or at least something that's good to have before cores 
are looking into the change in more detail? For example, gibi is the 
lead for the versioned notifications effort and we/I generally look for 
his +1 on a change before digging into it, or approving it. We have 
similar unofficial things like this in other parts of Nova, or subteams, 
like Timofey and Pawel with the live migration subteam.


To be sure, someone that is leading a subteam effort and is looked to 
for their opinion on a whole series of changes eventually gets into the 
conversation when we're talking about potential core reviewers, in part 
because, at least I personally, am looking for not only strong code 
review skills but also leadership/ownership within the project, because 
those are also the people that tend to stick around awhile so I'm more 
comfortable investing my time into them (and building a trust 
relationship with them).


So that's all unofficial non-formal stuff and basically grew up 
organically around the subteam efforts that started several releases 
ago. I don't know if this helps you or not.


--

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] Ocata - Ubuntu 16.04 - OVN does not work with DPDK

[Martinx - ジェームズ]

On 11 April 2017 at 11:08, Russell Bryant  wrote:

>
>
> On Mon, Apr 10, 2017 at 4:49 PM, Martinx - ジェームズ <
> thiagocmarti...@gmail.com> wrote:
>
>>
>>
>> On 8 April 2017 at 00:37, Martinx - ジェームズ 
>> wrote:
>>
>>> Guys,
>>>
>>>  I manage to deploy Ocata on Ubuntu 16.04 with OVN for the first time
>>> ever, today!
>>>
>>>  It looks very, very good... OVN L3 Router is working, OVN DHCP
>>> working... bridge mappings "br-ex" on each compute node... All good!
>>>
>>>  Then, I've said: time for DPDK!
>>>
>>>  I manage to use OVS with DPDK easily on top of Ubuntu (plus Ocata Cloud
>>> Archive) with plain KVM, no OpenStack, so, I have experience about how to
>>> setup DPDK, OVS+DPDK, Libvirt vhostuser, KVM and etc...
>>>
>>>  After configuring DPDK on a compute node, I tried the following
>>> instructions:
>>>
>>>  https://docs.openstack.org/developer/networking-ovn/dpdk.html
>>>
>>>  It looks quite simple!
>>>
>>>  To make things even simpler, I have just 1 controller, and 1 compute
>>> node, to begin with, before enabling DPDK at the compute node and changing
>>> the "br-int" datapath, I deleted all OVN Routers and all Neutron Networks
>>> and Subnets, that was previously working with regular OVS (no DPDK).
>>>
>>>  Then, after enabling DPDK and updating the "br-int" and the "br-ex"
>>> interfaces, right after connecting the "OVN L3 Router" into the "ext-net /
>>> br-ex" network, the following errors appeared on OpenvSwitch logs of the
>>> related compute node (OpenFlow error):
>>>
>>>
>>>  * After connecting OVN L3 Router against the "ext-net / br-ex" Flat /
>>> VLAN Network:
>>>
>>>  ovs-vswitchd.log:
>>>
>>>  http://paste.openstack.org/show/605800/
>>>
>>>  ovn-controller.log:
>>>
>>>  http://paste.openstack.org/show/605801/
>>>
>>>
>>>  Also, after connecting the OVN L3 Router into the local (GENEVE)
>>> network, very similar error messages appeared on OpenvSwitch logs...
>>>
>>>
>>>  * After connecting OVN L3 Router on a "local" GENEVE Network:
>>>
>>>  ovs-vswitchd.log:
>>>
>>>  http://paste.openstack.org/show/605804/
>>>
>>>  ovn-controller.log:
>>>
>>>  http://paste.openstack.org/show/605805/
>>>
>>>
>>>  * Output of "ovs-vsctl show" at the single compute node, after plugging
>>> the OVN L3 Router against the two networks (external / GENEVE):
>>>
>>>  http://paste.openstack.org/show/605806/
>>>
>>>
>>>  Then, I tried to launch an Instance anyway and, for my surprise, the
>>> Instance was created! Using vhostuser OVS+DPDK socket!
>>>
>>>  Also, the Instance got its IP! Which is great!
>>>
>>>  However, the Instance can not ping its OVN L3 Router (its default
>>> gateway), with or without any kind of security groups applied, no deal...
>>> :-(
>>>
>>>  BTW, the Instance did not received the ARP stuff of the OVN L3 Router,
>>> I mean, for the instance, the gateway IP on "arp -an" shows "".
>>>
>>>
>>>  * The ovs-vswitchd.log after launching an Instance on top of
>>> OVN/OVS+DPDK:
>>>
>>>  http://paste.openstack.org/show/605807/
>>>
>>>  * The output of "ovs-vsctl show" after launching the above instance:
>>>
>>>  http://paste.openstack.org/show/605809/ - Line 33 is the dpdkvhostuser
>>>
>>>
>>>  Just to give another try, I started a second Instance, to see if the
>>> Instances can ping each other... Also did not worked, the Instances can not
>>> ping each other.
>>>
>>>
>>>  So, from what I'm seeing, OVN on top of DPDK does not work.
>>>
>>>  Any tips?
>>>
>>>
>>>  NOTE:
>>>
>>>  I tried to enable "hugepages" on my OpenStack's flavor, just in case...
>>> Then, I found another bug, it doesn't even boot the Instance:
>>>
>>>  https://bugs.launchpad.net/cloud-archive/+bug/1680956
>>>
>>>
>>>  For now, I'll deploy Ocata with regular OVN, no DPDK, but, my goal with
>>> this cloud is for high performance networks, so, I need DPDK, and I also
>>> need GENEVE and Provider Networks, everything on top of DPDK.
>>>
>>> ---
>>>  After researching more about this "high perf networks", I found this:
>>>
>>>  * DPDK-like performance in Linux kernel with XDP !
>>>
>>>  http://openvswitch.org/support/ovscon2016/7/0930-pettit.pdf
>>>
>>>  https://www.iovisor.org/technology/xdp
>>>  https://www.iovisor.org/technology/ebpf
>>>
>>>  https://qmonnet.github.io/whirl-offload/2016/09/01/dive-into-bpf/
>>>
>>>  But I have no idea about how to use OpenvSwitch with this thing,
>>> however, if I can achieve DPDK-Like performance, without DPDK, using just
>>> plain Linux, I'm a 100% sure that I'll prefer it!
>>>
>>>  I'm okay to give OpenvSwitch + DPDK another try, even knowing that it
>>> [OVS] STILL have serious problems (https://bugs.launchpad.net/ub
>>> untu/+source/openvswitch/+bug/1577088)...
>>> ---
>>>
>>>  OpenStack on Ubuntu rocks!   :-D
>>>
>>> Thanks!
>>> Thiago
>>>
>>
>> I just realized how cool IO Visor is!
>>
>> Sorry about mixing subjects, let's keep this one clear for OVN on top of
>> DPDK.
>>
>> I found a opened bug on RedHat's Bugzilla, I updated it with the info
>> 

Re: [openstack-dev] [TripleO][Heat] Conditionally passing properties in Heat

[Thomas Herve]

On Wed, Apr 12, 2017 at 9:00 PM, Dan Sneddon  wrote:
> I'm implementing predictable control plane IPs for spine/leaf, and I'm
> running into a problem implementing this in the TripleO Heat templates.
>
> I have a review in progress [1] that works, but fails on upgrade, so I'm
> looking for an alternative approach. I'm trying to influence the IP
> address that is selected for overcloud nodes' Control Plane IP. Here is
> the current construct:
>
>   Controller:
> type: OS::TripleO::Server
> metadata:
>   os-collect-config:
> command: {get_param: ConfigCommand}
> properties:
>   image: {get_param: controllerImage}
>   image_update_policy: {get_param: ImageUpdatePolicy}
>   flavor: {get_param: OvercloudControlFlavor}
>   key_name: {get_param: KeyName}
>   networks:
> - network: ctlplane  # <- Here's where the port is created
>
> If I add fixed_ip: to the networks element at the end of the above, I
> can select an IP address from the 'ctlplane' network, like this:
>
>   networks:
> - network: ctlplane
>   fixed_ip: {get_attr: [ControlPlanePort, ip_address]}
>
> But the problem is that if I pass a blank string to fixed_ip, I get an
> error on deployment. This means that the old behavior of automatically
> selecting an IP doesn't work.
>
> I thought I has solved this by passing an external Neutron port, like this:
>
>   networks:
> - network: ctlplane
>   port: {get_attr: [ControlPlanePort, port_id]}
>
> Which works for deployments, but that fails on upgrades, since the
> original port was created as part of the Nova::Server resource, instead
> of being an external resource.

Can you detail how it fails? I was under the impression we never
replaced servers no matter what (or we try to do that, at least). Is
the issue that your new port is not the correct one?

> I'm now looking for a way to use Heat conditionals to apply the fixed_ip
> only if the value is not unset. Looking at the intrinsic functions [2],
> I don't see a way to do this. Is what I'm trying to do with Heat possible?

You should be able to write something like that (not tested):

networks:
  if:
- 
- network: ctlplane
  fixed_ip: {get_attr: [ControlPlanePort, ip_address]}
- network: ctlplane

The question is how to define your condition. Maybe:

conditions:
  fixed_ip_condition:
 not:
equals:
  - {get_attr: [ControlPlanePort, ip_address]}
  - ''

To get back to the problem you stated first.


> Another option I'm exploring is conditionally applying resources. It
> appears that would require duplicating the entire TripleO::Server stanza
> in *-role.yaml so that there is one that uses fixed_ip and one that does
> not. Which one is applied would be based on a condition that tested
> whether fixed_ip was blank or not. The downside of that is that it would
> make the role definition confusing because there would be a large
> resource that was implemented twice, with only one line difference
> between them.

You can define properties with conditions, so you shouldn't need to
rewrite everything.

-- 
Thomas

__
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][cinder] Can all non-Ironic compute drivers handle volume size extension?

[Mathieu Gagné]

On Wed, Apr 12, 2017 at 2:54 PM, Matt Riedemann  wrote:
>
> Correct, I thought about this yesterday too. And this should be a detail in
> the Cinder spec for sure, but Cinder should probably have a specific policy
> check for attempting to extend an attached volume. Having said this, I see
> that Cinder has a "volume:extend" policy rule but I don't see it actually
> checked in the code, is that a bug?
>
> But the idea is, you, as a deployer, could allow extending volumes that are
> not attached (using the existing volume:extend policy) but disable the
> ability to extend attached volumes (maybe new rule volume:extend_attached?).
> Then if you're running older computes, or not running libvirt/hyperv
> computes, etc, then you just disable the API entrypoint for the entire
> operation on the Cinder side.
>
> ^ should all be captured in the Cinder spec.
>

It has been added to Cinder spec:
https://review.openstack.org/#/c/453286/

--
Mathieu

__
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][election] Questions for Candidates

[Chris Dent]

On Wed, 12 Apr 2017, Kendall Nelson wrote:


-What is one trait you have that makes it difficult to work in groups like
the TC and how do you counteract it?


There are many, I'm sure. But one that is frequent and embarrassing
is that I have a serious problem with homophones, contractions (or
word combinations that could be), and apostrophes when typing --
especially in IRC. The worst expression of this is leaving out "not"
in a sentence like "The cow should jump off the cliff" when
actually, I like cows and would prefer they not jump to
they're^wthere^their deaths. As you can imagine this is dire when
trying to state a position or express an opinion in a group like the
TC where stating positions and expressing opinions, in IRC, is a big
chunk of what you do.

As with so many things the method to counteract this is to stop
being so urgent, be conscious, and breathe a bit; it'll keep.


- What do you see as the biggest roadblock in the upcoming releases for the
TC?


Like others, I'm concerned about the amount and direction of
corporate interests. We're currently seeing a great deal of interest
and investment from Telcos and the NFV community. This is
simultaneously exciting and concerning. There will be a clash of
cultures that will be both difficult and productive.


-What is your favorite thing about OpenStack?


You asked this in a lighthearted way, but I feel pretty serious
about this: The thing I like most about OpenStack is that the people
I work with everyday -- the people I regularly call my coworkers
(and friends!) when mentioning them to (other) friends and family --
are not all paid by the same company as me. That is _awesome_.

--
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] [shade] help wanted - tons to do, not enough people

[Monty Taylor]

On 04/12/2017 01:15 PM, Sean Dague wrote:

On 04/12/2017 01:38 PM, Monty Taylor wrote:

On 04/12/2017 11:21 AM, Joshua Harlow wrote:

Just a question, not meant as anything bad against shade,

But would effort be better spent on openstacksdk?


tl;dr - great in practice, falls apart in the details

I don't think so - but it was an original thought, so it's certainly a
reasonable question.

openstacksdk is an SDK exposing the OpenStack APIs. It does not hide
differences between APIs, nor abstract into different concepts. shade
does. So I think they have different audiences and different intends in
mind.


Take the good parts of shade and just move it to openstacksdk, perhaps
as a 'higher level api' available in openstacksdk?

Then ansible openstack components (which I believe use shade) could then
switch to openstacksdk and all will be merry...


The thing is - for shade's needs, openstacksdk is both too much and not
enough simultaneously. (this is not intended to be a dig against sdk -
their goal in life is not to be a rest layer for shade, it's to be an
SDK for the OpenStack APIs)

To handle nodepool scale, shade needs to do some really specific things
related to exactly when and how remote interactions happen. In services
of its users, openstacksdk hides those interactions - which I think is a
nice feature for its users, but unfortunately removes shade's ability to
control those interactions in the way it needs to.

At the same time, the object model wrapper with magic generators and
whatnot doesn't add much value to shade past "get('/servers').json()" to
be quite honest.

So - I think handling our needs would be very annoying to the SDK folks,
and it would just unnecessarily make things complex for both sides.

In any case, like I said, it's a completely fair and legit question -
but as of right now I don't think it would actually make anyone's lives
better.


Just to provide a different though related perspective.

This is what success looks like. Lots of different people writing
different stuff, in different ways, talking to your API (which is the
REST API, not a library). Everyone implementing the slices that are
important for their consumers, and providing the fidelity that their
consumers need.

We should never think this is a bad thing.


++


__
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][Heat] Conditionally passing properties in Heat

[Dan Sneddon]

I'm implementing predictable control plane IPs for spine/leaf, and I'm
running into a problem implementing this in the TripleO Heat templates.

I have a review in progress [1] that works, but fails on upgrade, so I'm
looking for an alternative approach. I'm trying to influence the IP
address that is selected for overcloud nodes' Control Plane IP. Here is
the current construct:

  Controller:
type: OS::TripleO::Server
metadata:
  os-collect-config:
command: {get_param: ConfigCommand}
properties:
  image: {get_param: controllerImage}
  image_update_policy: {get_param: ImageUpdatePolicy}
  flavor: {get_param: OvercloudControlFlavor}
  key_name: {get_param: KeyName}
  networks:
- network: ctlplane  # <- Here's where the port is created

If I add fixed_ip: to the networks element at the end of the above, I
can select an IP address from the 'ctlplane' network, like this:

  networks:
- network: ctlplane
  fixed_ip: {get_attr: [ControlPlanePort, ip_address]}

But the problem is that if I pass a blank string to fixed_ip, I get an
error on deployment. This means that the old behavior of automatically
selecting an IP doesn't work.

I thought I has solved this by passing an external Neutron port, like this:

  networks:
- network: ctlplane
  port: {get_attr: [ControlPlanePort, port_id]}

Which works for deployments, but that fails on upgrades, since the
original port was created as part of the Nova::Server resource, instead
of being an external resource.

I'm now looking for a way to use Heat conditionals to apply the fixed_ip
only if the value is not unset. Looking at the intrinsic functions [2],
I don't see a way to do this. Is what I'm trying to do with Heat possible?

Another option I'm exploring is conditionally applying resources. It
appears that would require duplicating the entire TripleO::Server stanza
in *-role.yaml so that there is one that uses fixed_ip and one that does
not. Which one is applied would be based on a condition that tested
whether fixed_ip was blank or not. The downside of that is that it would
make the role definition confusing because there would be a large
resource that was implemented twice, with only one line difference
between them.

Does anyone have any ideas how to go about this?

[1] - https://review.openstack.org/#/c/413278/
[2] -
https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#intrinsic-functions

-- 
Dan Sneddon |  Senior Principal Software Engineer
dsned...@redhat.com |  redhat.com/openstack
dsneddon:irc|  @dxs:twitter

__
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][cinder] Can all non-Ironic compute drivers handle volume size extension?

[Matt Riedemann]

On 4/12/2017 12:30 PM, Mathieu Gagné wrote:

Thanks for starting this discussion. There is a lot to cover/answer.

On Tue, Apr 11, 2017 at 6:35 PM, Matt Riedemann  wrote:


This is not discoverable at the moment, for the end user or cinder, so I'm
trying to figure out what the failure mode looks like.

This all starts on the cinder side to extend the size of the attached
volume. Cinder is going to have to see if Nova is new enough to handle this
(via the available API versions) before accepting the request and resizing
the volume. Then Cinder sends the event to Nova. This is where it gets
interesting.

On the Nova side, if all of the computes aren't new enough, we could just
fail the request outright with a 409. What does Cinder do then? Rollback the
volume resize?


This means an extend volume operation would need to check for Nova
support first.
This also means adding a new API call to fetch and discover such
capabilities per instance (from associated compute node).
If we want to catch errors in volume size extension in Nova, we will
need to find an other way, external events are async.


Today cinder can GET /versions from the compute API and tell if it 
should even start attempting volume extend or not for an attached 
volume. If the microversion support isn't there in the compute side, 
cinder should fail fast in the API. That's a detail for the cinder spec.


Once the request reaches nova, we could technically lookup the service 
version for the compute from the API and tell if it's new enough to 
support this capability and fail fast if it won't. I don't know if we'll 
do that, but we have it in our pocket. Either way, the Cinder side 
should handle an error response from Nova and proceed accordingly 
(rollback the volume extend).





But let's say the computes are new enough, but the instance is on a compute
that does not support the operation. Then what? Do we register an instance
fault and put the instance into ERROR state? Then the admin would need to
intervene.

Are there other ideas? Until we have capabilities (info) exposed out of the
API we're stuck with questions like this.



Like TommyLike mentioned in a review, AWS introduced Live Volume
Modifications available on some instance types.
On instance types with limited support, you need to stop/start the
instance or detach/attach the volume.
On instances started before a certain date, you need to stop/start the
instance or detach/attach the volume at least once.
In all cases, the end user needs to extend the partition/filesystem in
the instance.

They have the luxury to fully control the environment and synchronize
the compute service with the volume service.
Even (speculatively) having bidirectional
orchestration/synchronization/communications or what.

I have that same luxury since I only support one volume backend and
virt driver combination.
But I now start to grasp the extend of what adding such feature
requires, especially when it implies cross-services support...


Yeah it's super fun isn't it. :) This is why it takes a long time to get 
some features into Nova.




We have a matrix of compute drivers and volume backends to support
with some combinations which might never support online volume
extension.
There is the desire for OpenStack to be interoperable between clouds
so there is a strong incentive to make it work for all combinations.

I will still take the liberty to ask:

Would it be in the realm of possibilities for a deployer to have to
explicitly enable this feature?
A deployer would be able to enable such feature once all
services/components it choose to deployed fully support online volume
extension.


Correct, I thought about this yesterday too. And this should be a detail 
in the Cinder spec for sure, but Cinder should probably have a specific 
policy check for attempting to extend an attached volume. Having said 
this, I see that Cinder has a "volume:extend" policy rule but I don't 
see it actually checked in the code, is that a bug?


But the idea is, you, as a deployer, could allow extending volumes that 
are not attached (using the existing volume:extend policy) but disable 
the ability to extend attached volumes (maybe new rule 
volume:extend_attached?). Then if you're running older computes, or not 
running libvirt/hyperv computes, etc, then you just disable the API 
entrypoint for the entire operation on the Cinder side.


^ should all be captured in the Cinder spec.



I know it won't address cases where a mixed of volume backends and
virt drivers are deployed.
So we would still need capabilities discoverability. This includes
volume type capabilities discoverability which I'm not sure exists
today.

Lets not start about how Horizon will discover such capabilities per
instance/volume. That's an other can of worms. =)

--
Mathieu

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [keystone] Adding foreign keys between subsystems

[David Stanek]

On 12-Apr 15:25, Rodrigo Duarte wrote:
> On Wed, Apr 12, 2017 at 2:47 PM, David Stanek  wrote:
> 
> > On 12-Apr 14:30, Rodrigo Duarte wrote:
> > > Just to illustrate the discussion, we have a bug fix that currently tries
> > > to drop a FK between the federation and identity subsystems [1].
> > >
> > > [1] https://review.openstack.org/#/c/445505/
> >
> > I think this highlights one of my problems with the current architecture.
> > I see that
> > you've removed the FK and added delete logic to do what the data layer
> > would be doing
> > for you. I didn't see any added get_user() checks to make sure the user_id
> > being used
> > in creates/updates is valid. Are we already checking that somewhere else
> > or is this
> > introducing a new bug?
> >
> 
> The review [1] is dropping the idp_id and idp_id + protocol_id FKs, not the
> user_id one.
> 

Right, misremembered. Just run s/user_id/idp_id/ and s/get_user/get_idp/ and 
you'll
have the same issues.

-- 
david stanek
web: https://dstanek.com
twitter: https://twitter.com/dstanek

__
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] Emails for OpenStack R Release Name voting going out - please be patient

[Kevin Benton]

I haven't received one either.

Perhaps Monty has simply embraced the 'cattle not pets' approach and we
were the unlucky ones. :)

On Apr 12, 2017 07:49, "Lance Bragstad"  wrote:

>
> On Wed, Apr 12, 2017 at 9:42 AM, Amrith Kumar 
> wrote:
>
>> Hmm, all the cool kids didn’t receive the email but I did. Now I feel bad
>> ☹
>>
>>
>>
>> -amrith
>>
>>
>>
>> *From:* Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
>> *Sent:* Wednesday, April 12, 2017 9:53 AM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] Emails for OpenStack R Release Name
>> voting going out - please be patient
>>
>>
>>
>> I also have not received a poll email.
>>
>
> Same here - I haven't received one.
>
>
>>
>>
>> On Apr 12, 2017 6:13 AM, "Neil Jerram"  wrote:
>>
>> Nor me.
>>
>>
>>
>> On Wed, Apr 12, 2017 at 1:55 PM Doug Hellmann 
>> wrote:
>>
>> Excerpts from Dulko, Michal's message of 2017-04-12 12:09:30 +:
>> > On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:
>> > > On 04/06/2017 07:34 AM, Monty Taylor wrote:
>> > > >
>> > > > Hey all!
>> > > >
>> > > > I've started the R Release Name poll and currently am submitting
>> > > > everyone's email address to the system. In order to not make our
>> fine
>> > > > friends at Carnegie Mellon (the folks who run the CIVS voting
>> service)
>> > > > upset, I have a script that submits the emails one at a time with a
>> > > > half-second delay between each email. That means at best, since
>> there
>> > > > are 40k people to process it'll take ~6 hours for them all to go
>> out.
>> > > >
>> > > > Which is to say - emails are on their way - but if you haven't
>> gotten
>> > > > yours yet, that's fine. I'll send another email when they've all
>> gone
>> > > > out, so don't worry about not receiving one until I've sent that
>> mail.
>> > > Well- that took longer than I expected. Because of some rate
>> limiting,
>> > > 1/2 second delay was not long enough...
>> > >
>> > > Anyway - all of the emails should have gone out now. Because that
>> took
>> > > so long, I'm going to hold the poll open until next Wednesday.
>> > >
>> > > Monty
>> >
>> > Not sure why, but I haven't received an email yet.
>> >
>> > Thanks,
>> > Michal
>>
>> Nor I.
>>
>> Doug
>>
>> 
>> __
>> 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: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: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] [keystone] Adding foreign keys between subsystems

[Rodrigo Duarte]

On Wed, Apr 12, 2017 at 2:47 PM, David Stanek  wrote:

> On 12-Apr 14:30, Rodrigo Duarte wrote:
> > Just to illustrate the discussion, we have a bug fix that currently tries
> > to drop a FK between the federation and identity subsystems [1].
> >
> > [1] https://review.openstack.org/#/c/445505/
>
> I think this highlights one of my problems with the current architecture.
> I see that
> you've removed the FK and added delete logic to do what the data layer
> would be doing
> for you. I didn't see any added get_user() checks to make sure the user_id
> being used
> in creates/updates is valid. Are we already checking that somewhere else
> or is this
> introducing a new bug?
>

The review [1] is dropping the idp_id and idp_id + protocol_id FKs, not the
user_id one.


>
> --
> david stanek
> web: https://dstanek.com
> twitter: https://twitter.com/dstanek
>
> __
> 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
>



-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [shade] help wanted - tons to do, not enough people

[Sean Dague]

On 04/12/2017 01:38 PM, Monty Taylor wrote:
> On 04/12/2017 11:21 AM, Joshua Harlow wrote:
>> Just a question, not meant as anything bad against shade,
>>
>> But would effort be better spent on openstacksdk?
> 
> tl;dr - great in practice, falls apart in the details
> 
> I don't think so - but it was an original thought, so it's certainly a
> reasonable question.
> 
> openstacksdk is an SDK exposing the OpenStack APIs. It does not hide
> differences between APIs, nor abstract into different concepts. shade
> does. So I think they have different audiences and different intends in
> mind.
> 
>> Take the good parts of shade and just move it to openstacksdk, perhaps
>> as a 'higher level api' available in openstacksdk?
>>
>> Then ansible openstack components (which I believe use shade) could then
>> switch to openstacksdk and all will be merry...
> 
> The thing is - for shade's needs, openstacksdk is both too much and not
> enough simultaneously. (this is not intended to be a dig against sdk -
> their goal in life is not to be a rest layer for shade, it's to be an
> SDK for the OpenStack APIs)
> 
> To handle nodepool scale, shade needs to do some really specific things
> related to exactly when and how remote interactions happen. In services
> of its users, openstacksdk hides those interactions - which I think is a
> nice feature for its users, but unfortunately removes shade's ability to
> control those interactions in the way it needs to.
> 
> At the same time, the object model wrapper with magic generators and
> whatnot doesn't add much value to shade past "get('/servers').json()" to
> be quite honest.
> 
> So - I think handling our needs would be very annoying to the SDK folks,
> and it would just unnecessarily make things complex for both sides.
> 
> In any case, like I said, it's a completely fair and legit question -
> but as of right now I don't think it would actually make anyone's lives
> better.

Just to provide a different though related perspective.

This is what success looks like. Lots of different people writing
different stuff, in different ways, talking to your API (which is the
REST API, not a library). Everyone implementing the slices that are
important for their consumers, and providing the fidelity that their
consumers need.

We should never think this is a bad thing.

-Sean


-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [tc][election] Questions for Candidates

[Ed Leafe]

On Apr 12, 2017, at 11:19 AM, Kendall Nelson  wrote:

> -What is one trait you have that makes it difficult to work in groups like 
> the TC and how do you counteract it?

My natural tendency is to speak bluntly, which can often come across as 
dismissive of other points of view. As I've gotten older I've learned a few 
tricks to soften my words, but it's a constant effort.

> - What do you see as the biggest roadblock in the upcoming releases for the 
> TC?

The pull of corporate interests, both to steer development in directions that 
will benefit their business, and also by pulling developers off of OpenStack 
work. Neither of these is new, but they certainly seem to be increasing lately 
with no sign of letting up.

> And one lighthearted question:
> 
> -What is your favorite thing about OpenStack?

I'm sure everyone will write pretty much the same thing here: the community, 
getting to interact with so many talented and interesting people. Because it 
certainly is! So I'll throw in my *second* favorite thing: being a part of 
creating something that can change the world of computing. It's already played 
a role in the discovery of the Higgs boson, and I'm sure that someday it will 
enable technologies that haven't yet been dreamed up. Being able to look back 
someday and say "I helped to build that" will be pretty satisfying.


-- 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] [Release-job-failures][tricircle] Release of openstack/python-tricircleclient failed

[Doug Hellmann]

Tricircle team,

The client library release 0.1.0 had a build failure that left the
release artifacts in an indeterminate state. I have retagged the same
commit as 0.1.1 and am processing the new release right now. I will
monitor the jobs to ensure they all succeed, or that we address any
failures.

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

Doug

Excerpts from jenkins's message of 2017-04-12 08:20:23 +:
> Build failed.
> 
> - python-tricircleclient-docs-ubuntu-xenial 
> http://logs.openstack.org/a5/a52ae17a85b4743a41bf104e1d621d29cc345185/release/python-tricircleclient-docs-ubuntu-xenial/34b3833/
>  : SUCCESS in 1m 55s
> - python-tricircleclient-tarball 
> http://logs.openstack.org/a5/a52ae17a85b4743a41bf104e1d621d29cc345185/release/python-tricircleclient-tarball/c7fe8b3/
>  : SUCCESS in 1m 55s
> - python-tricircleclient-tarball-signing 
> http://logs.openstack.org/a5/a52ae17a85b4743a41bf104e1d621d29cc345185/release/python-tricircleclient-tarball-signing/362b979/
>  : SUCCESS in 10s
> - python-tricircleclient-pypi-both-upload 
> http://logs.openstack.org/a5/a52ae17a85b4743a41bf104e1d621d29cc345185/release/python-tricircleclient-pypi-both-upload/b0633cb/
>  : FAILURE in 10s
> - python-tricircleclient-announce-release 
> python-tricircleclient-announce-release : SKIPPED
> - propose-python-tricircleclient-update-constraints 
> propose-python-tricircleclient-update-constraints : SKIPPED
> 

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

Re: [openstack-dev] [Release-job-failures][telemetry][gnocchi] Release of openstack/python-gnocchiclient failed

[Doug Hellmann]

Excerpts from Doug Hellmann's message of 2017-04-12 13:49:54 -0400:
> Gnocchi team,
> 
> The client release you tagged had a build failure.  It looks like
> the tag was pushed directly, so I will relay the results of the
> debugging work but let you decide how to deal with it.
> 
> Clark determined that the files on PyPI do not exactly match the files
> on our tarballs server. One of the JSON metadata files was regenerated,
> and because dictionaries are unordered it came out in a different order.
> 
> Clark also checked the MD5 sum on PyPI and found that the signatures
> match.
> 
> It's not clear why the job failed. Subsequent jobs have passed. One
> course of action you could take is to retag the same commit with a new
> version number to get new packages, just to be safe.
> 
> If you choose to stick with the existing packages, you will need to
> manually submit the constraint update, since that job was skipped after
> the upload job reported a failure.
> 
> Please also file the update in the releases repository, so that
> there is a record of the fact that the release was made.
> 
> Excerpts from jenkins's message of 2017-04-12 09:29:09 +:
> > Build failed.
> > 
> > - python-gnocchiclient-tarball 
> > http://logs.openstack.org/6f/6fd3d262bf88c1b8b8e195aef451cde80a7e7c1d/release/python-gnocchiclient-tarball/61adb8c/
> >  : SUCCESS in 3m 52s
> > - python-gnocchiclient-tarball-signing 
> > http://logs.openstack.org/6f/6fd3d262bf88c1b8b8e195aef451cde80a7e7c1d/release/python-gnocchiclient-tarball-signing/c7dd0a8/
> >  : SUCCESS in 11s
> > - python-gnocchiclient-pypi-both-upload 
> > http://logs.openstack.org/6f/6fd3d262bf88c1b8b8e195aef451cde80a7e7c1d/release/python-gnocchiclient-pypi-both-upload/0ad195d/
> >  : FAILURE in 48s
> > - python-gnocchiclient-announce-release 
> > python-gnocchiclient-announce-release : SKIPPED
> > - propose-python-gnocchiclient-update-constraints 
> > propose-python-gnocchiclient-update-constraints : SKIPPED
> > 

The Gnocchi server release had a similar issue, and should be treated
the same way.

- gnocchi-tarball 
http://logs.openstack.org/9e/9e376560e686dc604cdf35b365db24b0cf16d12d/release/gnocchi-tarball/ebe62a3/
 : SUCCESS in 2m 48s
- gnocchi-tarball-signing 
http://logs.openstack.org/9e/9e376560e686dc604cdf35b365db24b0cf16d12d/release/gnocchi-tarball-signing/280d8cc/
 : SUCCESS in 15s
- gnocchi-pypi-both-upload 
http://logs.openstack.org/9e/9e376560e686dc604cdf35b365db24b0cf16d12d/release/gnocchi-pypi-both-upload/f059ec3/
 : FAILURE in 15s
- gnocchi-announce-release gnocchi-announce-release : SKIPPED
- propose-gnocchi-update-constraints propose-gnocchi-update-constraints : 
SKIPPED

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

Re: [openstack-dev] [Release-job-failures][telemetry][gnocchi] Release of openstack/python-gnocchiclient failed

[Doug Hellmann]

Gnocchi team,

The client release you tagged had a build failure.  It looks like
the tag was pushed directly, so I will relay the results of the
debugging work but let you decide how to deal with it.

Clark determined that the files on PyPI do not exactly match the files
on our tarballs server. One of the JSON metadata files was regenerated,
and because dictionaries are unordered it came out in a different order.

Clark also checked the MD5 sum on PyPI and found that the signatures
match.

It's not clear why the job failed. Subsequent jobs have passed. One
course of action you could take is to retag the same commit with a new
version number to get new packages, just to be safe.

If you choose to stick with the existing packages, you will need to
manually submit the constraint update, since that job was skipped after
the upload job reported a failure.

Please also file the update in the releases repository, so that
there is a record of the fact that the release was made.

Excerpts from jenkins's message of 2017-04-12 09:29:09 +:
> Build failed.
> 
> - python-gnocchiclient-tarball 
> http://logs.openstack.org/6f/6fd3d262bf88c1b8b8e195aef451cde80a7e7c1d/release/python-gnocchiclient-tarball/61adb8c/
>  : SUCCESS in 3m 52s
> - python-gnocchiclient-tarball-signing 
> http://logs.openstack.org/6f/6fd3d262bf88c1b8b8e195aef451cde80a7e7c1d/release/python-gnocchiclient-tarball-signing/c7dd0a8/
>  : SUCCESS in 11s
> - python-gnocchiclient-pypi-both-upload 
> http://logs.openstack.org/6f/6fd3d262bf88c1b8b8e195aef451cde80a7e7c1d/release/python-gnocchiclient-pypi-both-upload/0ad195d/
>  : FAILURE in 48s
> - python-gnocchiclient-announce-release python-gnocchiclient-announce-release 
> : SKIPPED
> - propose-python-gnocchiclient-update-constraints 
> propose-python-gnocchiclient-update-constraints : SKIPPED
> 

__
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] Adding foreign keys between subsystems

[David Stanek]

On 12-Apr 14:30, Rodrigo Duarte wrote:
> Just to illustrate the discussion, we have a bug fix that currently tries
> to drop a FK between the federation and identity subsystems [1].
> 
> [1] https://review.openstack.org/#/c/445505/

I think this highlights one of my problems with the current architecture. I see 
that
you've removed the FK and added delete logic to do what the data layer would be 
doing
for you. I didn't see any added get_user() checks to make sure the user_id 
being used
in creates/updates is valid. Are we already checking that somewhere else or is 
this
introducing a new bug?

-- 
david stanek
web: https://dstanek.com
twitter: https://twitter.com/dstanek

__
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] pike-1 release

[Lance Bragstad]

I've proposed keystone's pike-1 release [0]. If there is anything that we
need to wait on for pike-1 that hasn't merged yet, please let me know at
your earliest convenience.


[0] https://review.openstack.org/#/c/456319/
__
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] [shade] help wanted - tons to do, not enough people

[Monty Taylor]

On 04/12/2017 11:21 AM, Joshua Harlow wrote:

Just a question, not meant as anything bad against shade,

But would effort be better spent on openstacksdk?


tl;dr - great in practice, falls apart in the details

I don't think so - but it was an original thought, so it's certainly a 
reasonable question.


openstacksdk is an SDK exposing the OpenStack APIs. It does not hide 
differences between APIs, nor abstract into different concepts. shade 
does. So I think they have different audiences and different intends in 
mind.



Take the good parts of shade and just move it to openstacksdk, perhaps
as a 'higher level api' available in openstacksdk?

Then ansible openstack components (which I believe use shade) could then
switch to openstacksdk and all will be merry...


The thing is - for shade's needs, openstacksdk is both too much and not 
enough simultaneously. (this is not intended to be a dig against sdk - 
their goal in life is not to be a rest layer for shade, it's to be an 
SDK for the OpenStack APIs)


To handle nodepool scale, shade needs to do some really specific things 
related to exactly when and how remote interactions happen. In services 
of its users, openstacksdk hides those interactions - which I think is a 
nice feature for its users, but unfortunately removes shade's ability to 
control those interactions in the way it needs to.


At the same time, the object model wrapper with magic generators and 
whatnot doesn't add much value to shade past "get('/servers').json()" to 
be quite honest.


So - I think handling our needs would be very annoying to the SDK folks, 
and it would just unnecessarily make things complex for both sides.


In any case, like I said, it's a completely fair and legit question - 
but as of right now I don't think it would actually make anyone's lives 
better.



Thoughts?

Monty Taylor wrote:

Hey everybody!

This isn't the most normal thing I've done, but whatever.

We've got this great library, shade, which people love to use to
interact with their OpenStack clouds (even when they don't know they're
using it, like when they're using Ansible) - and which we use in Infra
behind nodepool to get test nodes for everyone's test jobs.

Unfortunately, we have a somewhat ludicrously small contributor base
right now (primarily me) Now, I'm pretty darned good and can produce a
constant stream of patches - so you might not _think_ there's not a ton
of developers, but I am, in the end, only one person, and that's not
great. Shrews has been the other primary developer, but he's been
focusing his attention on zuulv3 (which is a very good thing)

In any case - I'd love some more folks to come in and do some things -
and maybe none of you knew we were looking for new people! So come have
fun with us! We have an IRC channel: #openstack-shade - and bugs are
tracked in Storyboard (https://storyboard.openstack.org/#!/project/760)

There is a worklist for bugs that have been triaged as important - that
is, there is a clearly broken behavior out in production for someone:

https://storyboard.openstack.org/#!/worklist/194

The most important project (that's not terrible to get started on) is
one I'm calling "restification" - which is that we're replacing our use
of python-*client with making direct REST calls via keystoneauth. This
is important so that we can ensure that we're supporting backwards
compat for our users, while maintaining co-installability with OpenStack
releases.

https://storyboard.openstack.org/#!/worklist/195

The process is as follows:

- Pick a call or calls to migrate
- Make a patch changing the unittests to use requests-mock instead of
mocking the client object (this changes the test to validate the HTTP
calls we're making, but shows that using the currently known to be
working client calls)
- Make a patch that replaces the submit_task call in
shade/openstackclient.py (and removes the Task class from
shade/_tasks.py) with a rest call using the appropriate
self._{servicename}_client - this should not change any unit tests -
that shows that the new call does the same things as the old call.

Once you get the hang of it, it's fun - and it's a fun way to learn a
ton about OpenStack's REST APIs.

After that's done, we have some deeper tasks that need done related to
caching and client-side rate limiting (we support these already, but we
need to support them the same way everywhere) - and we have a whole
mult-cloud/multi-threaded facade class to write that should be a ton of
fun - but we need to finish restification before we do a ton of new
things.

If you want to start hacking with us - I recommend coming in and saying
hi before you dive in to huge restification patches - and also start
small - do one call and figure out the flow - going off and doing
multi-day patches often leads to pain and suffering.

Anyway - I hope some of you think interop client libraries are fun like
I do - and would love to have you play with us!

Thanks!
Monty

Re: [openstack-dev] [keystone] Adding foreign keys between subsystems

[Rodrigo Duarte]

Just to illustrate the discussion, we have a bug fix that currently tries
to drop a FK between the federation and identity subsystems [1].

The previous fix for this bug (which has been merged and had the backport
abandoned) took advantage of the FK in order to cascade delete federated
users when a protocol or an identity provider is deleted [2].

[1] https://review.openstack.org/#/c/445505/
[2] https://review.openstack.org/#/c/420893/

On Wed, Apr 12, 2017 at 11:58 AM, Lance Bragstad 
wrote:

>
>
> On Wed, Apr 12, 2017 at 9:28 AM, David Stanek  wrote:
>
>> [tl;dr I want to remove the artificial restriction of not allowing FKs
>> between
>> subsystems and I want to stop FK enforcement in code.]
>>
>> The keystone code architecture is pretty simple. The data and
>> functionality are
>> divided up into subsystems. Each subsystem can be configured to use a
>> different
>> backend datastore. Of course, there are always exceptions to the rule
>> like how
>> the federation and identity subsystems are highly coupled in the data
>> model.
>>
>> On the surface this flexible model sounds good, but there are some
>> interesting
>> consequences. First, you can't tell from looking at the data model that
>> there
>> actually is a lot of coupling between the subsystems. So instead of
>> looking at
>> our sqlalchemy models to see relationships, we must look throughout the
>> code
>> for where a particular primary key is used and look for enforcement.
>> (Hopefully
>> we enforce it in all of the right places.) Additionally, a DBA/data
>> architect/
>> whenever can't see the relationship at all by looking at the database.
>>
>> Second, this has polluted our code and causes erroneous API errors. We
>> have added
>> lots of get_*() calls in our code that checks for the existence of IDs in
>> another subsystem. In some cases we probably don't do the check and thus
>> would
>> allow bad data to be stored. The check often causes 404s instead of 400s
>> when
>> bad data is provided.
>>
>
> Having these cleaned up would be awesome. I imagine we'd also see some
> sort of performance benefit as a result, too.
>
>
>>
>> So I'd like us to be more deliberate in defining which parts of the data
>> model
>> are truly independent and a separate backend datastore would make sense.
>> For
>> instance, we know we want to support LDAP for identity (although this
>> still puts
>> identity info into a SQL database) and catalog is very isolated from the
>> rest of
>> the data model.
>>
>> As a side effect this means that if deployers wished to use a separate
>> backend
>> for something they would need to also implement it for the other highly
>> coupled
>> subsystems. They would also have to provide any FK enforcement that their
>> own
>> datastore does not provide.
>>
>
> So for deployers, this would mean that if today they only deploy keystone
> backed with LDAP for *only* identity, tomorrow they will have to ensure
> that LDAP has all the proper things for other subsystems that use to have
> an in-code constraint with identity (i.e. assignment). I wonder how many
> folks that would be? What would an upgrade look like for deployments
> wishing to stick to LDAP? I imagine we'd be raising the bar for that
> particular upgrade.
>
>
>>
>> Thoughts?
>>
>> --
>> david stanek
>> web: https://dstanek.com
>> twitter: https://twitter.com/dstanek
>>
>> 
>> __
>> 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
>
>


-- 
Rodrigo Duarte Sousa
Senior Quality Engineer @ Red Hat
MSc in Computer Science
http://rodrigods.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Can all non-Ironic compute drivers handle volume size extension?

[Mathieu Gagné]

Thanks for starting this discussion. There is a lot to cover/answer.

On Tue, Apr 11, 2017 at 6:35 PM, Matt Riedemann  wrote:
>
> This is not discoverable at the moment, for the end user or cinder, so I'm
> trying to figure out what the failure mode looks like.
>
> This all starts on the cinder side to extend the size of the attached
> volume. Cinder is going to have to see if Nova is new enough to handle this
> (via the available API versions) before accepting the request and resizing
> the volume. Then Cinder sends the event to Nova. This is where it gets
> interesting.
>
> On the Nova side, if all of the computes aren't new enough, we could just
> fail the request outright with a 409. What does Cinder do then? Rollback the
> volume resize?

This means an extend volume operation would need to check for Nova
support first.
This also means adding a new API call to fetch and discover such
capabilities per instance (from associated compute node).
If we want to catch errors in volume size extension in Nova, we will
need to find an other way, external events are async.

> But let's say the computes are new enough, but the instance is on a compute
> that does not support the operation. Then what? Do we register an instance
> fault and put the instance into ERROR state? Then the admin would need to
> intervene.
>
> Are there other ideas? Until we have capabilities (info) exposed out of the
> API we're stuck with questions like this.
>

Like TommyLike mentioned in a review, AWS introduced Live Volume
Modifications available on some instance types.
On instance types with limited support, you need to stop/start the
instance or detach/attach the volume.
On instances started before a certain date, you need to stop/start the
instance or detach/attach the volume at least once.
In all cases, the end user needs to extend the partition/filesystem in
the instance.

They have the luxury to fully control the environment and synchronize
the compute service with the volume service.
Even (speculatively) having bidirectional
orchestration/synchronization/communications or what.

I have that same luxury since I only support one volume backend and
virt driver combination.
But I now start to grasp the extend of what adding such feature
requires, especially when it implies cross-services support...

We have a matrix of compute drivers and volume backends to support
with some combinations which might never support online volume
extension.
There is the desire for OpenStack to be interoperable between clouds
so there is a strong incentive to make it work for all combinations.

I will still take the liberty to ask:

Would it be in the realm of possibilities for a deployer to have to
explicitly enable this feature?
A deployer would be able to enable such feature once all
services/components it choose to deployed fully support online volume
extension.

I know it won't address cases where a mixed of volume backends and
virt drivers are deployed.
So we would still need capabilities discoverability. This includes
volume type capabilities discoverability which I'm not sure exists
today.

Lets not start about how Horizon will discover such capabilities per
instance/volume. That's an other can of worms. =)

--
Mathieu

__
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][election] Questions for Candidates

[German Eichberger]

-What is one trait you have that makes it difficult to work in groups like the 
TC and how do you counteract it?
I am probably overly fascinated by new technology and would be the first to 
re-invent the wheel. I am probably in good company with that at the TC but I 
have internalized the lean startup mantra and started asking even if the 
technology is shiny does it really help our users? Does it enable new features? 
Does it take care of some tech debt?

- What do you see as the biggest roadblock in the upcoming releases for the TC?
I have seen budgets and priorities shift for companies sponsoring work on 
OpenStack. I see this as the biggest road block and as a community we need to 
do a better job to attract contributors and sponsors.

-What is your favorite thing about OpenStack?
The people. I have never met nicer and more dedicated people then the 
developers in OpenStack. This is also a main reason for running to give back 
and help them.

German

From: Kendall Nelson 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, April 12, 2017 at 12:19 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [tc][election] Questions for Candidates

Hello Candidates!

You all have proven yourselves to be crucial parts of the community and I just 
wanted to say good luck to each one of you in the upcoming election!

Also though, I thought it might be good to ask a few more questions. It's easy 
to talk about what you all want to champion on the TC and about the ideal 
breakdown of how you want to spend your time, but it's much harder to answer 
questions that might highlight some of the daily struggles. So! Interview time:

-What is one trait you have that makes it difficult to work in groups like the 
TC and how do you counteract it?

- What do you see as the biggest roadblock in the upcoming releases for the TC?
And one lighthearted question:

-What is your favorite thing about OpenStack?

Thank you for your answers!

-Kendall Nelson
__
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] [shade] help wanted - tons to do, not enough people

[Aqsa Malik]

Hi Monty

I would be interested in working for this. The p

On Wed, Apr 12, 2017 at 5:47 PM, Monty Taylor  wrote:

> Hey everybody!
>
> This isn't the most normal thing I've done, but whatever.
>
> We've got this great library, shade, which people love to use to interact
> with their OpenStack clouds (even when they don't know they're using it,
> like when they're using Ansible) - and which we use in Infra behind
> nodepool to get test nodes for everyone's test jobs.
>
> Unfortunately, we have a somewhat ludicrously small contributor base right
> now (primarily me) Now, I'm pretty darned good and can produce a constant
> stream of patches - so you might not _think_ there's not a ton of
> developers, but I am, in the end, only one person, and that's not great.
> Shrews has been the other primary developer, but he's been focusing his
> attention on zuulv3 (which is a very good thing)
>
> In any case - I'd love some more folks to come in and do some things - and
> maybe none of you knew we were looking for new people! So come have fun
> with us! We have an IRC channel: #openstack-shade - and bugs are tracked in
> Storyboard (https://storyboard.openstack.org/#!/project/760)
>
> There is a worklist for bugs that have been triaged as important - that
> is, there is a clearly broken behavior out in production for someone:
>
>   https://storyboard.openstack.org/#!/worklist/194
>
> The most important project (that's not terrible to get started on) is one
> I'm calling "restification" - which is that we're replacing our use of
> python-*client with making direct REST calls via keystoneauth. This is
> important so that we can ensure that we're supporting backwards compat for
> our users, while maintaining co-installability with OpenStack releases.
>
>   https://storyboard.openstack.org/#!/worklist/195
>
> The process is as follows:
>
> - Pick a call or calls to migrate
> - Make a patch changing the unittests to use requests-mock instead of
> mocking the client object (this changes the test to validate the HTTP calls
> we're making, but shows that using the currently known to be working client
> calls)
> - Make a patch that replaces the submit_task call in
> shade/openstackclient.py (and removes the Task class from shade/_tasks.py)
> with a rest call using the appropriate self._{servicename}_client - this
> should not change any unit tests - that shows that the new call does the
> same things as the old call.
>
> Once you get the hang of it, it's fun - and it's a fun way to learn a ton
> about OpenStack's REST APIs.
>
> After that's done, we have some deeper tasks that need done related to
> caching and client-side rate limiting (we support these already, but we
> need to support them the same way everywhere) - and we have a whole
> mult-cloud/multi-threaded facade class to write that should be a ton of fun
> - but we need to finish restification before we do a ton of new things.
>
> If you want to start hacking with us - I recommend coming in and saying hi
> before you dive in to huge restification patches - and also start small -
> do one call and figure out the flow - going off and doing multi-day patches
> often leads to pain and suffering.
>
> Anyway - I hope some of you think interop client libraries are fun like I
> do - and would love to have you play with us!
>
> Thanks!
> Monty
>
> __
> 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
>



-- 
Aqsa Malik

visit my blog at
http://www.techiworld4u.blogspot.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][cinder] Can all non-Ironic compute drivers handle volume size extension?

[Mathieu Gagné]

On Wed, Apr 12, 2017 at 12:58 PM, Matt Riedemann  wrote:
>
> I guess we also have the instance action events. So we could avoid putting
> the instance into ERROR state but record an instance action event that the
> extend volume event failed on the compute, so at least the user/admin could
> figure out why it didn't change on the nova side.
>
> What they do after that I'm not sure. Would detaching and then re-attaching
> the now resized volume fix it?
>

There are 2 steps to the volume size extension: iscsi --rescan and
virsh blockresize.
As an admin, you could call the same API endpoint to retrigger all of
those steps.
If iscsi --rescan succeeds but virsh blockresize fails, stopping and
starting the instance will fix the issue.
This is the step we asked our customer to perform before virsh
blockresize was added to our implementation.

--
Mathieu

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

[openstack-dev] [kolla][nova] Starting a core reviewer mentorship program for Kolla deliverables

[Steven Dake (stdake)]

Hey folks,

In today’s Kolla team meeting, the idea was proposed of adopting nova’s 
“protocore” mentorship program for Kolla.  We would like to know what nova has 
learned from this effort.

In today’s Kolla meeting we had broad consensus on the following:

1)   Kolla has participants that want to be core reviewers

2)   These participants don’t know how to become core reviewers

3)   The core reviewers in Kolla should mentor “protocore” reviewers on how 
to do good reviews

From that, we concluded some form of mentorship program for potential core 
reviewers was in order.  We got into some debate about _how_ the program should 
be rolled out.  Let’s use this thread to discuss how it should be rolled out 
since that seems to be the sticking point of the discussion.  I saw no dissent 
in the discussion that the basic concepts were a negative change.

I am aware that nova uses a +1 review from a “protocore” and a +2/+w from a 
core reviewer prior to merge.  Nova cores – would you mind defining your 
process (on the ml is fine) more thoroughly and your experiences so we can 
learn from you?

All kolla contributors, feel free to debate the *how* such a mentorship program 
should be rolled out.  I think we have a lot to learn from our peers in the 
OpenStack community and learning from their experiences may be helpful.

Regards
-steve

__
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][cinder] Can all non-Ironic compute drivers handle volume size extension?

[Matt Riedemann]

On 4/11/2017 5:35 PM, Matt Riedemann wrote:

I'm reading through mgagne's spec to support attached volume size
extension callbacks in Nova [1] and the question that comes up is what
happens when the backend compute does not support this, either because
it's too old (Ocata) or the virt driver does not support the event?

The spec is targeted at libvirt to use os-brick, but the hyper-v driver
is also using os-brick since Ocata, and the Windows connector support
the extend_volume operation, so that should work.

I don't know about powervm, vmware or xen though.

This is not discoverable at the moment, for the end user or cinder, so
I'm trying to figure out what the failure mode looks like.

This all starts on the cinder side to extend the size of the attached
volume. Cinder is going to have to see if Nova is new enough to handle
this (via the available API versions) before accepting the request and
resizing the volume. Then Cinder sends the event to Nova. This is where
it gets interesting.

On the Nova side, if all of the computes aren't new enough, we could
just fail the request outright with a 409. What does Cinder do then?
Rollback the volume resize?

But let's say the computes are new enough, but the instance is on a
compute that does not support the operation. Then what? Do we register
an instance fault and put the instance into ERROR state? Then the admin
would need to intervene.

Are there other ideas? Until we have capabilities (info) exposed out of
the API we're stuck with questions like this.

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



I guess we also have the instance action events. So we could avoid 
putting the instance into ERROR state but record an instance action 
event that the extend volume event failed on the compute, so at least 
the user/admin could figure out why it didn't change on the nova side.


What they do after that I'm not sure. Would detaching and then 
re-attaching the now resized volume fix it?


--

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] [tc] [elections] Available time and top priority

[Dean Troyer]

On Wed, Apr 12, 2017 at 4:07 AM, Thierry Carrez  wrote:
> One idea I've been considering is eliminating the one and only sacred
> one-hour weekly TC meeting, and encouraging ad-hoc discussions (on
> #openstack-dev for example) between change proposers and smaller groups
> of TC members present in the same timezone. That would give us a good
> feel of what everyone thinks, reduce noise, and happen at various times
> during the day on a public forum, giving an opportunity for more people
> to jump in the discussion. The informal nature of those discussions
> would make the governance reviews the clear focal point for coordination
> and final decision.

This sounds like a form of 'office hours' format, and I like the idea.
We could even try to get come semi-firm commitments from TC members to
be present at particular times (spread out TZ-wise) to ensure some
planning is possible.

dt

-- 

Dean Troyer
dtro...@gmail.com

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

Re: [openstack-dev] [oslo][infra][pbr] Nominating Stephen Finucane for pbr-core

[Doug Hellmann]

Excerpts from Monty Taylor's message of 2017-04-12 08:14:31 -0500:
> Hey all,
> 
> As I'm sure you all know, pbr is both our most pervasively used 
> dependency and our least well understood. Nobody ever wants to look at 
> the code (sorry, I can write ugly code sometimes - but also wow 
> setuptools) or dig in to figure out what happened when things break.
> 
> Recently Stephen Finucane (sfinucan) has stepped up to the plate to help 
> sort out issues we've been having. He's shown a lack of fear of the 
> codebase and an understanding of what's going on. He's also following 
> through on patches to projects themselves when needed, which is a huge 
> part of the game. And most importantly he knows when to suggest we _not_ 
> do something.
> 
> It's not a HUGE corpus of work we have to go on - but that's a good 
> thing - pbr shouldn't chance much - but it's in keeping with the other 
> active pbr maintainers:
> 
> http://stackalytics.com/report/contribution/pbr/90
> 
> Monty
> 

+1 -- Stephen has been doing good work elsewhere, too.

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] [Tacker][OSC] Command naming specs

[Dean Troyer]

On Wed, Apr 12, 2017 at 2:08 AM, Trinath Somanchi 
wrote:

> Tacker being NFVO+VNFM - an NFV component, we have taken ‘nfv’ as the
> prefix.
>

Note that OSC itself does not use 'command prefixes', it names resources
with enough specificity to make them unique.  Sometimes that looks like a
proefix, but it is not.

For the below commands, for readability, we have added ‘-‘ within the
> command names.
>
> Like,
>
>   network-service,  vnf-forwarding-graph, service-function-chain,
>
> network-flow-classifier, network-forwarding-path.
>
>
>
> But the existing OSC commands don’t have a ‘-‘ in between the command
> names.
>

The OSC command structure specifically does not use dashes or underscores
as separators, it uses spaces.  We want commands to be words.  Dashes are
only used in option names due to option parsing rules.

Specifically in networking there are a large number of resources that are
hard to concisely name.  Plugins are of course free to do what they want
but we encourage them to use the OSC guidelines, and we know that users
_really_ appreciate staying consistent.

There are places where you may feel forced to use abbreviations ('vnf' in
your example above).  Those are discouraged, but we also recognize that
they are often the most common usage ('IP' in IP address for example) and
where that usage is common is fine.  Again, networking is an area where
many things are commonly known only by their abbreviation, and this usage
is in fact expected by users.  In the end, picking commands that are what
users would expect to search for is what they appreciate the most.

dt

-- 

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

[openstack-dev] [glance] reminder: spec freeze happens Friday!

[Brian Rosmaita]

All Glance, python-glanceclient, and glance_store specs must be merged
into the glance-specs repository by 23:59 on Friday 14 April 2017.

I've just updated the etherpad with the status of the various patches:
  https://etherpad.openstack.org/p/glance-pike-specs-review

If you're a glance core, please check whether specs you've reviewed have
been updated; if you're a spec proposer, please check to make sure
you've responded to revision requests.

After the spec freeze, I'll officially post the Pike priorities.  We
agreed on a preliminary list at the PTG [0], and I'll be completely
honest: I haven't seen anything proposed that will change the Glance
priorities for Pike.

So what does this mean for other specs accepted into Pike?  The glance
cores will do what they can to provide timely reviews, but keep in mind
that they're committed to reviewing the priorities first.  Other patches
will be reviewed as bandwidth allows.  (Hint: The best way to facilitate
getting your code looked at is to review other peoples' patches.)


cheers,
brian

[0] https://etherpad.openstack.org/p/glance-pike-ptg-roadmap-prelim


__
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] What is the difference between default_schedule_zone and default_availability_zone?

[Matt Riedemann]

I'm hoping someone more learned can teach me. These two options sound 
very similar, and are thus very confusing. They are also both in the 
[DEFAULT] config option group, but defined in different places [1][2].


The help text for one says:

"This option determines the availability zone to be used when it is not
specified in the VM creation request."

The help text for the other says:

"Availability zone to use when user doesn't specify one.
This option is used by the scheduler to determine which availability
zone to place a new VM instance into if the user did not specify one
at the time of VM boot request."

It looks like one goes on the instance record itself, and the other goes 
into an aggregate metadata if the zone is specified for the aggregate.


So while they sound the exact same, they are not? Or are they in the 
end? See how this is terrible?


[1] 
https://github.com/openstack/nova/blob/5a556a720f5a7394cab4c84fa6202976c6190b23/nova/conf/availability_zone.py#L34
[2] 
https://github.com/openstack/nova/blob/5a556a720f5a7394cab4c84fa6202976c6190b23/nova/conf/compute.py#L49


--

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] [shade] help wanted - tons to do, not enough people

[Joshua Harlow]

Just a question, not meant as anything bad against shade,

But would effort be better spent on openstacksdk?

Take the good parts of shade and just move it to openstacksdk, perhaps 
as a 'higher level api' available in openstacksdk?


Then ansible openstack components (which I believe use shade) could then 
switch to openstacksdk and all will be merry...


Thoughts?

Monty Taylor wrote:

Hey everybody!

This isn't the most normal thing I've done, but whatever.

We've got this great library, shade, which people love to use to
interact with their OpenStack clouds (even when they don't know they're
using it, like when they're using Ansible) - and which we use in Infra
behind nodepool to get test nodes for everyone's test jobs.

Unfortunately, we have a somewhat ludicrously small contributor base
right now (primarily me) Now, I'm pretty darned good and can produce a
constant stream of patches - so you might not _think_ there's not a ton
of developers, but I am, in the end, only one person, and that's not
great. Shrews has been the other primary developer, but he's been
focusing his attention on zuulv3 (which is a very good thing)

In any case - I'd love some more folks to come in and do some things -
and maybe none of you knew we were looking for new people! So come have
fun with us! We have an IRC channel: #openstack-shade - and bugs are
tracked in Storyboard (https://storyboard.openstack.org/#!/project/760)

There is a worklist for bugs that have been triaged as important - that
is, there is a clearly broken behavior out in production for someone:

https://storyboard.openstack.org/#!/worklist/194

The most important project (that's not terrible to get started on) is
one I'm calling "restification" - which is that we're replacing our use
of python-*client with making direct REST calls via keystoneauth. This
is important so that we can ensure that we're supporting backwards
compat for our users, while maintaining co-installability with OpenStack
releases.

https://storyboard.openstack.org/#!/worklist/195

The process is as follows:

- Pick a call or calls to migrate
- Make a patch changing the unittests to use requests-mock instead of
mocking the client object (this changes the test to validate the HTTP
calls we're making, but shows that using the currently known to be
working client calls)
- Make a patch that replaces the submit_task call in
shade/openstackclient.py (and removes the Task class from
shade/_tasks.py) with a rest call using the appropriate
self._{servicename}_client - this should not change any unit tests -
that shows that the new call does the same things as the old call.

Once you get the hang of it, it's fun - and it's a fun way to learn a
ton about OpenStack's REST APIs.

After that's done, we have some deeper tasks that need done related to
caching and client-side rate limiting (we support these already, but we
need to support them the same way everywhere) - and we have a whole
mult-cloud/multi-threaded facade class to write that should be a ton of
fun - but we need to finish restification before we do a ton of new things.

If you want to start hacking with us - I recommend coming in and saying
hi before you dive in to huge restification patches - and also start
small - do one call and figure out the flow - going off and doing
multi-day patches often leads to pain and suffering.

Anyway - I hope some of you think interop client libraries are fun like
I do - and would love to have you play with us!

Thanks!
Monty

__
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] [tc][election] Questions for Candidates

[Kendall Nelson]

Hello Candidates!

You all have proven yourselves to be crucial parts of the community and I
just wanted to say good luck to each one of you in the upcoming election!

Also though, I thought it might be good to ask a few more questions. It's
easy to talk about what you all want to champion on the TC and about the
ideal breakdown of how you want to spend your time, but it's much harder to
answer questions that might highlight some of the daily struggles. So!
Interview time:

-What is one trait you have that makes it difficult to work in groups like
the TC and how do you counteract it?

- What do you see as the biggest roadblock in the upcoming releases for the
TC?

And one lighthearted question:

-What is your favorite thing about OpenStack?

Thank you for your answers!

-Kendall Nelson
__
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] [oslo][infra][pbr] Nominating Stephen Finucane for pbr-core

[Ben Nemec]

+1

On 04/12/2017 08:14 AM, Monty Taylor wrote:

Hey all,

As I'm sure you all know, pbr is both our most pervasively used
dependency and our least well understood. Nobody ever wants to look at
the code (sorry, I can write ugly code sometimes - but also wow
setuptools) or dig in to figure out what happened when things break.

Recently Stephen Finucane (sfinucan) has stepped up to the plate to help
sort out issues we've been having. He's shown a lack of fear of the
codebase and an understanding of what's going on. He's also following
through on patches to projects themselves when needed, which is a huge
part of the game. And most importantly he knows when to suggest we _not_
do something.

It's not a HUGE corpus of work we have to go on - but that's a good
thing - pbr shouldn't chance much - but it's in keeping with the other
active pbr maintainers:

http://stackalytics.com/report/contribution/pbr/90

Monty

__
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] [shade] help wanted - tons to do, not enough people

[Monty Taylor]

Hey everybody!

This isn't the most normal thing I've done, but whatever.

We've got this great library, shade, which people love to use to 
interact with their OpenStack clouds (even when they don't know they're 
using it, like when they're using Ansible) - and which we use in Infra 
behind nodepool to get test nodes for everyone's test jobs.


Unfortunately, we have a somewhat ludicrously small contributor base 
right now (primarily me) Now, I'm pretty darned good and can produce a 
constant stream of patches - so you might not _think_ there's not a ton 
of developers, but I am, in the end, only one person, and that's not 
great. Shrews has been the other primary developer, but he's been 
focusing his attention on zuulv3 (which is a very good thing)


In any case - I'd love some more folks to come in and do some things - 
and maybe none of you knew we were looking for new people! So come have 
fun with us! We have an IRC channel: #openstack-shade - and bugs are 
tracked in Storyboard (https://storyboard.openstack.org/#!/project/760)


There is a worklist for bugs that have been triaged as important - that 
is, there is a clearly broken behavior out in production for someone:


  https://storyboard.openstack.org/#!/worklist/194

The most important project (that's not terrible to get started on) is 
one I'm calling "restification" - which is that we're replacing our use 
of python-*client with making direct REST calls via keystoneauth. This 
is important so that we can ensure that we're supporting backwards 
compat for our users, while maintaining co-installability with OpenStack 
releases.


  https://storyboard.openstack.org/#!/worklist/195

The process is as follows:

- Pick a call or calls to migrate
- Make a patch changing the unittests to use requests-mock instead of 
mocking the client object (this changes the test to validate the HTTP 
calls we're making, but shows that using the currently known to be 
working client calls)
- Make a patch that replaces the submit_task call in 
shade/openstackclient.py (and removes the Task class from 
shade/_tasks.py) with a rest call using the appropriate 
self._{servicename}_client - this should not change any unit tests - 
that shows that the new call does the same things as the old call.


Once you get the hang of it, it's fun - and it's a fun way to learn a 
ton about OpenStack's REST APIs.


After that's done, we have some deeper tasks that need done related to 
caching and client-side rate limiting (we support these already, but we 
need to support them the same way everywhere) - and we have a whole 
mult-cloud/multi-threaded facade class to write that should be a ton of 
fun - but we need to finish restification before we do a ton of new things.


If you want to start hacking with us - I recommend coming in and saying 
hi before you dive in to huge restification patches - and also start 
small - do one call and figure out the flow - going off and doing 
multi-day patches often leads to pain and suffering.


Anyway - I hope some of you think interop client libraries are fun like 
I do - and would love to have you play with us!


Thanks!
Monty

__
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] policy meeting 2017-4-12

[Lance Bragstad]

Just a reminder that we will be having the policy meeting in 45 minutes in
#openstack-meeting-cp [0]. It was cancelled last week due to tight
schedules.

See you there!


[0] https://etherpad.openstack.org/p/keystone-policy-meeting
__
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] [elections] Available time and top priority

[Ed Leafe]

On Apr 12, 2017, at 9:44 AM, gordon chung  wrote:

>> If there was ONE thing, one
>> initiative, one change you will actively push in the six months between
>> this election round and the next, what would it be ?
> 
> this is a really good question! if we're all honest with ourselves, most
> of the rhetoric in the self-nominations are far to grand to be
> accomplished in multiple terms let alone one term which is normal for
> campaigning. it's good to consider what you would consider a success at
> the end of your term(s), whether or you succeed at it or not (i swear
> i'm not a manager).

Very good point. In my case, I presented the goal, knowing that at best I might 
be able to nudge the OpenStack world a bit closer in that direction.

-- 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] [tripleo] pike-1 was released - thank you

[Jason E. Rist]

On 04/11/2017 09:32 PM, Emilien Macchi wrote:
> Just a heads-up (while it was mentioned during the TripleO weekly meeting):
>
> We managed to release TripleO pike-1 early this week. This is really
> awesome to see the progress we have made and that we continue to do on
> the release side. We are continuously improving ourselves and I think
> we can be proud of that.
> We implemented 8 blueprints and fixed 145 bugs in ~40 days.
>
> I just wanted to thank *you* for this outstanding work and I'm looking
> forward to ship the next version of TripleO.
>
> Note: I also want to mention that it wouldn't be possible to achieve
> this goal without the external contributors outside TripleO (Infra,
> Release management, and other projects in OpenStack). Kudos to them
> :-)
>
Thanks Emilien and thanks to the entire OpenStack team for the release.

__
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] Adding foreign keys between subsystems

[Lance Bragstad]

On Wed, Apr 12, 2017 at 9:28 AM, David Stanek  wrote:

> [tl;dr I want to remove the artificial restriction of not allowing FKs
> between
> subsystems and I want to stop FK enforcement in code.]
>
> The keystone code architecture is pretty simple. The data and
> functionality are
> divided up into subsystems. Each subsystem can be configured to use a
> different
> backend datastore. Of course, there are always exceptions to the rule like
> how
> the federation and identity subsystems are highly coupled in the data
> model.
>
> On the surface this flexible model sounds good, but there are some
> interesting
> consequences. First, you can't tell from looking at the data model that
> there
> actually is a lot of coupling between the subsystems. So instead of
> looking at
> our sqlalchemy models to see relationships, we must look throughout the
> code
> for where a particular primary key is used and look for enforcement.
> (Hopefully
> we enforce it in all of the right places.) Additionally, a DBA/data
> architect/
> whenever can't see the relationship at all by looking at the database.
>
> Second, this has polluted our code and causes erroneous API errors. We
> have added
> lots of get_*() calls in our code that checks for the existence of IDs in
> another subsystem. In some cases we probably don't do the check and thus
> would
> allow bad data to be stored. The check often causes 404s instead of 400s
> when
> bad data is provided.
>

Having these cleaned up would be awesome. I imagine we'd also see some sort
of performance benefit as a result, too.


>
> So I'd like us to be more deliberate in defining which parts of the data
> model
> are truly independent and a separate backend datastore would make sense.
> For
> instance, we know we want to support LDAP for identity (although this
> still puts
> identity info into a SQL database) and catalog is very isolated from the
> rest of
> the data model.
>
> As a side effect this means that if deployers wished to use a separate
> backend
> for something they would need to also implement it for the other highly
> coupled
> subsystems. They would also have to provide any FK enforcement that their
> own
> datastore does not provide.
>

So for deployers, this would mean that if today they only deploy keystone
backed with LDAP for *only* identity, tomorrow they will have to ensure
that LDAP has all the proper things for other subsystems that use to have
an in-code constraint with identity (i.e. assignment). I wonder how many
folks that would be? What would an upgrade look like for deployments
wishing to stick to LDAP? I imagine we'd be raising the bar for that
particular upgrade.


>
> Thoughts?
>
> --
> david stanek
> web: https://dstanek.com
> twitter: https://twitter.com/dstanek
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][infra] Upcoming changes to nodepool images

[Paul Belanger]

Greetings,

As you have likely seen over the last few days, openstack-infra has slowly
started making some changes to our nodepool images we use for jobs. With the
help of cmurphy, we've started removing the puppet dependency from the images.

For the most part, this should be seamless for your projects how we are finding
some edge cases.  So, if your job starts failing because of a missing package,
you likely need to add said package to your bindep.txt file.

Additionally, we are moving forward again with our virtualenv changes again.
Last time, xenial and centos switched to python3, however if your tox
environments only support a specific version of python you should be sure to set
'basepython=pythonfoo' in your tox.ini. We have fixed the issue, and virtualenvs
should still be python2.

As always, please join us in #openstack-infra if you have problems or questions.

-PB

__
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] Emails for OpenStack R Release Name voting going out - please be patient

[Lance Bragstad]

On Wed, Apr 12, 2017 at 9:42 AM, Amrith Kumar 
wrote:

> Hmm, all the cool kids didn’t receive the email but I did. Now I feel bad
> ☹
>
>
>
> -amrith
>
>
>
> *From:* Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
> *Sent:* Wednesday, April 12, 2017 9:53 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] Emails for OpenStack R Release Name voting
> going out - please be patient
>
>
>
> I also have not received a poll email.
>

Same here - I haven't received one.


>
>
> On Apr 12, 2017 6:13 AM, "Neil Jerram"  wrote:
>
> Nor me.
>
>
>
> On Wed, Apr 12, 2017 at 1:55 PM Doug Hellmann 
> wrote:
>
> Excerpts from Dulko, Michal's message of 2017-04-12 12:09:30 +:
> > On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:
> > > On 04/06/2017 07:34 AM, Monty Taylor wrote:
> > > >
> > > > Hey all!
> > > >
> > > > I've started the R Release Name poll and currently am submitting
> > > > everyone's email address to the system. In order to not make our fine
> > > > friends at Carnegie Mellon (the folks who run the CIVS voting
> service)
> > > > upset, I have a script that submits the emails one at a time with a
> > > > half-second delay between each email. That means at best, since there
> > > > are 40k people to process it'll take ~6 hours for them all to go out.
> > > >
> > > > Which is to say - emails are on their way - but if you haven't gotten
> > > > yours yet, that's fine. I'll send another email when they've all gone
> > > > out, so don't worry about not receiving one until I've sent that
> mail.
> > > Well- that took longer than I expected. Because of some rate limiting,
> > > 1/2 second delay was not long enough...
> > >
> > > Anyway - all of the emails should have gone out now. Because that took
> > > so long, I'm going to hold the poll open until next Wednesday.
> > >
> > > Monty
> >
> > Not sure why, but I haven't received an email yet.
> >
> > Thanks,
> > Michal
>
> Nor I.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> 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] Emails for OpenStack R Release Name voting going out - please be patient

[Amrith Kumar]

Hmm, all the cool kids didn’t receive the email but I did. Now I feel bad ☹

 

-amrith

 

From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com] 
Sent: Wednesday, April 12, 2017 9:53 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] Emails for OpenStack R Release Name voting going 
out - please be patient

 

I also have not received a poll email.

 

On Apr 12, 2017 6:13 AM, "Neil Jerram"  
> wrote:

Nor me.

 

On Wed, Apr 12, 2017 at 1:55 PM Doug Hellmann  > wrote:

Excerpts from Dulko, Michal's message of 2017-04-12 12:09:30 +:
> On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:
> > On 04/06/2017 07:34 AM, Monty Taylor wrote:
> > >
> > > Hey all!
> > >
> > > I've started the R Release Name poll and currently am submitting
> > > everyone's email address to the system. In order to not make our fine
> > > friends at Carnegie Mellon (the folks who run the CIVS voting service)
> > > upset, I have a script that submits the emails one at a time with a
> > > half-second delay between each email. That means at best, since there
> > > are 40k people to process it'll take ~6 hours for them all to go out.
> > >
> > > Which is to say - emails are on their way - but if you haven't gotten
> > > yours yet, that's fine. I'll send another email when they've all gone
> > > out, so don't worry about not receiving one until I've sent that mail.
> > Well- that took longer than I expected. Because of some rate limiting, 
> > 1/2 second delay was not long enough...
> >
> > Anyway - all of the emails should have gone out now. Because that took 
> > so long, I'm going to hold the poll open until next Wednesday.
> >
> > Monty
>
> Not sure why, but I haven't received an email yet.
>
> Thanks,
> Michal

Nor I.

Doug

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


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

__
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] [elections] Available time and top priority

[gordon chung]

On 10/04/17 05:16 AM, Thierry Carrez wrote:
> If there was ONE thing, one
> initiative, one change you will actively push in the six months between
> this election round and the next, what would it be ?

this is a really good question! if we're all honest with ourselves, most 
of the rhetoric in the self-nominations are far to grand to be 
accomplished in multiple terms let alone one term which is normal for 
campaigning. it's good to consider what you would consider a success at 
the end of your term(s), whether or you succeed at it or not (i swear 
i'm not a manager).

best of luck to the candidates.

cheers,

-- 
gord
__
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] [trove] weekly meeting canceled today

[Amrith Kumar]

I've not seen anything new on the agenda and I have a late scheduling
conflict today. Let's catch up on IRC if there is anything that needs
discussing. 

--
Amrith Kumar
amrith.ku...@gmail.com




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

[openstack-dev] [keystone] Adding foreign keys between subsystems

[David Stanek]

[tl;dr I want to remove the artificial restriction of not allowing FKs between
subsystems and I want to stop FK enforcement in code.]

The keystone code architecture is pretty simple. The data and functionality are
divided up into subsystems. Each subsystem can be configured to use a different
backend datastore. Of course, there are always exceptions to the rule like how
the federation and identity subsystems are highly coupled in the data model.

On the surface this flexible model sounds good, but there are some interesting
consequences. First, you can't tell from looking at the data model that there
actually is a lot of coupling between the subsystems. So instead of looking at
our sqlalchemy models to see relationships, we must look throughout the code
for where a particular primary key is used and look for enforcement. (Hopefully
we enforce it in all of the right places.) Additionally, a DBA/data architect/
whenever can't see the relationship at all by looking at the database. 

Second, this has polluted our code and causes erroneous API errors. We have 
added
lots of get_*() calls in our code that checks for the existence of IDs in
another subsystem. In some cases we probably don't do the check and thus would
allow bad data to be stored. The check often causes 404s instead of 400s when
bad data is provided.

So I'd like us to be more deliberate in defining which parts of the data model
are truly independent and a separate backend datastore would make sense. For
instance, we know we want to support LDAP for identity (although this still puts
identity info into a SQL database) and catalog is very isolated from the rest of
the data model.

As a side effect this means that if deployers wished to use a separate backend
for something they would need to also implement it for the other highly coupled
subsystems. They would also have to provide any FK enforcement that their own
datastore does not provide.

Thoughts?

-- 
david stanek
web: https://dstanek.com
twitter: https://twitter.com/dstanek

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

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

[gordon chung]

On 12/04/17 02:47 AM, Tony Breeds wrote:
> Please look over both lists by 2017-04-17 00:00 UTC and let me know if:
> - A project is in list 1 and *really* *really* wants to opt *OUT* of EOLing 
> and
>   why.  Note doing this will amost certainly reduce the testing coverage you
>   have in the gate.
> - A project is in list 2 that would like to opt *IN* to tagging/EOLing

i imagine you can EOL python-aodhclient and ceilometermiddleware. thanks 
Tony!

cheers,

-- 
gord
__
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] [elections] Available time and top priority

[German Eichberger]

I have read very good ideas in this thread but I somehow can’t shake the 
feeling that people who are quite comfortable with the irc meeting are looking 
for a solution for people who are not.  So, before we do any changes I would 
send out a survey and see what the developers we are serving actually want. 

In my experience interacting with the TC it has always been tough to get in 
touch with people and I will therefore institute (at least for me) office hours 
where you can interact with me each week and bring me your issues. 

To close, the other day I was listening to somebody describing how she picked 
mentors. Not being a native English speaker she picked her mentors based on if 
they would speak in her native language with her. This really drives home the 
point about diversity and how important it is to recruit and sponsor people 
from different backgrounds for the TC. 

Thanks,
German

On 4/12/17, 7:30 AM, "Flavio Percoco"  wrote:

On 12/04/17 11:07 +0200, Thierry Carrez wrote:
>Ildiko Vancsa wrote:
>>> On 2017. Apr 12., at 3:18, Monty Taylor >> > wrote:
>>> [...]
>>> Email allows someone to compose an actual structured narrative, and
>>> for replies to do the same. Some of us are loquatious and I imagine
>>> can be hard to follow even with time to read.
>>>
>>> IRC allows someone to respond quickly, and for someone to be like "yo,
>>> totes sorry, I didn't mean that at all LOL" and to walk things back
>>> before a pile of people become mortally insulted.
>>>
>>> Like now - hopefully you'll give me a smiley in IRC ... but you might
>>> not, and I'm stuck worrying that my tone came across wrong. Then if
>>> you just don't respond because ZOMG-EMAIL, I might start day drinking.
>>
>> Big +1 on balance.
>>
>> I agree in general that we need to revisit how to be more inclusive and
>> how to provide as equal conditions to people all around the globe as
>> possible.
>>
>> That said I still would like to keep the ability to have allocated time
>> for synchronous communication and allow the TC to be more of a team as
>> opposed to a group of people driving their own and some shared missions.
>> I think it helps with seeing maybe different parts but still the same
>> big picture and making the group more efficient with decision making and
>> bringing the community forward.
>> [...]
>
>Agree with you Ildiko and Monty, we still need sync communication to get
>a better feel of everyone's feelings on a particular issue, especially
>on complex issues. At the same time, a unique weekly meeting is actively
>preventing people from participating. It is also very active and noisy,
>the timebox can be painful, and its weekly cadence makes a good reason
>for procrastinating in reviews until the topic is raised in meeting,
>where final decision is made. Creating multiple official meetings
>spreads the pain instead of eliminating it. It makes it easier for more
>people to join, but more difficult for any given member to participate
>to every meeting. Our ability to quickly process changes might be affected.
>
>One idea I've been considering is eliminating the one and only sacred
>one-hour weekly TC meeting, and encouraging ad-hoc discussions (on
>#openstack-dev for example) between change proposers and smaller groups
>of TC members present in the same timezone. That would give us a good
>feel of what everyone thinks, reduce noise, and happen at various times
>during the day on a public forum, giving an opportunity for more people
>to jump in the discussion. The informal nature of those discussions
>would make the governance reviews the clear focal point for coordination
>and final decision.
>
>It's clearly not the perfect silver bullet though, so I'd very much like
>to hear other ideas :)


I believe I shared this with you on one of our conversations over dinner one
night. I'm glad to see you're more convinced now. I've talked about this 
with
you and other folks among the TC and I'm growing more convinced that it's 
the
right thing to do.

I've toyed with this idea for a bit already and I also mentioned it in my 
reply
to Matt[0] yesterday. As I mentioned in my email, I believe most can be 
achieved
on gerrit and we can instead focus on having a better way for ad-hoc
conversations and mentoring of people that need support from the TC.

[0] 
http://lists.openstack.org/pipermail/openstack-dev/2017-April/115255.html

Flavio

-- 
@flaper87
Flavio Percoco


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

[Andreas Jaeger]

Please add openstack-manuals to the list for EOL,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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][elections]questions about one platform vision

[German Eichberger]

Hi,

Though I haven’t attended the operator summit in person a them which has been 
mentioned to me is that we need to offer better reference architectures. I use 
the plural here on purpose because I don’t think there will be one 
architecture/combination of projects which works for everybody. As a community 
(and the TC can help) we should write up guides for reference architectures for 
containers, vms, and bare metal. But we  don’t need to offer just one project – 
there are a couple of ways to get there and we should offer choice. But we owe 
it to the operators that we have tested whatever we write up at some scale.

The second meaning for a “one platform” vision would be a unified API for 
Containers, VMs, and bare metal. I have talked to several people who would like 
to write software which doesn’t need to distinguish between different APIs to 
accomplish that. But I still feel that we should adhere to the Unix philosophy 
and make the best API for each technology and then have the orchestration 
platform or higher level abstractions (e.g. cloud native) worry about it.

This leads me to one of my gripes with the way we work. We sort of accepted 
that it is the projects responsibility to write tests and documentation but 
when it comes who is writing the Heat integration, the Open Stack Ansible part, 
or the Gophercloud part – things get real murky. I don’t iike to add another 
burden to some of the small projects but we also need to figure out a way that 
those things are current and compete. I am hoping that having reference 
architectures can guide us in this regard and I think we need to add more 
visibility what those solution supports and where the gaps are.

Thanks,
German


From: joehuang 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, April 11, 2017 at 10:54 PM
To: openstack-dev 
Subject: [openstack-dev] [tc][elections]questions about one platform vision

Hello,

I heard the one platform vision in OpenStack now and then: One platform for 
virtual machines, containers and bare metal.

I also learned that there are some groups working on making Kubernets being 
able to manage virtual machines. Except running containers in virtual machine, 
there is also the need for running containers in bare metal.

There are several projects connecting OpenStack to container world: Zun, 
Magnum, Kuryr, Fuxi... Projects to deal with bare metal like Ironic, Morgan, ...

Can all these efforts lead us to one platform vision? We have to think over the 
question.

What's the one platform will be in your own words? What's your proposal and 
your focus to help one platform vision being achieved?


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

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

[Alex Schultz]

On Wed, Apr 12, 2017 at 12:47 AM, Tony Breeds  wrote:
> Hi all,
> I'm late in sending this announement, but I'm glad to see several projects
> have already requested EOL releases to make it trivial and obvious where to
> apply the tag.
>
> I'm proposing to EOL all projects that meet one or more of the following
> criteria:
>
> - The project is openstack-dev/devstack, openstack-dev/grenade or
>   openstack/requirements
> - The project has the 'check-requirements' job listed as a template in
>   project-config:zuul/layout.yaml
> - The project gates with either devstack or grenade jobs
> - The project is listed in governance:reference/projects.yaml and is tagged
>   with 'stable:follows-policy'.
>
> Some statistics:
> All Repos  : 1584 (covered in zuul/layout.yaml)
> Checked Repos  :  416 (match one or more of the above 
> criteria)
> Repos with mitaka branches :  409
> EOL Repos  :  199 (repos that match the criteria *and* 
> have
>a mitaka branch) [1]
> NOT EOL Repos  :  210 (repos with a mitaka branch but
>otherwise do not match) [2]
> DSVM Repos (staying)   :   68 (repos that use dsvm but don't have
>mitaka branches)
> Tagged Repos   :0
> Open Reviews   :  159 (reviews to close)
>
> Please look over both lists by 2017-04-17 00:00 UTC and let me know if:
> - A project is in list 1 and *really* *really* wants to opt *OUT* of EOLing 
> and
>   why.  Note doing this will amost certainly reduce the testing coverage you
>   have in the gate.
> - A project is in list 2 that would like to opt *IN* to tagging/EOLing
>

Please EOL the Puppet OpenStack projects that have the stable/mitaka branch.

Thanks,
-Alex

> Any projects that will be EOL'd will need all open reviews abandoned before it
> can be processed.  I'm very happy to do this, or if I don't have permissios to
> do it ask a gerrit admin to do it.
>
> Yours Tony.
>
> [1] 
> https://gist.github.com/tbreeds/c99e62bf8da19380e4eb130be8783be7#file-mitaka_eol_data-txt-L1
> [2] 
> https://gist.github.com/tbreeds/c99e62bf8da19380e4eb130be8783be7#file-mitaka_eol_data-txt-L209
>
> __
> 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] Emails for OpenStack R Release Name voting going out - please be patient

[Morgan Fainberg]

I also have not received a poll email.

On Apr 12, 2017 6:13 AM, "Neil Jerram"  wrote:

> Nor me.
>
> On Wed, Apr 12, 2017 at 1:55 PM Doug Hellmann 
> wrote:
>
>> Excerpts from Dulko, Michal's message of 2017-04-12 12:09:30 +:
>> > On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:
>> > > On 04/06/2017 07:34 AM, Monty Taylor wrote:
>> > > >
>> > > > Hey all!
>> > > >
>> > > > I've started the R Release Name poll and currently am submitting
>> > > > everyone's email address to the system. In order to not make our
>> fine
>> > > > friends at Carnegie Mellon (the folks who run the CIVS voting
>> service)
>> > > > upset, I have a script that submits the emails one at a time with a
>> > > > half-second delay between each email. That means at best, since
>> there
>> > > > are 40k people to process it'll take ~6 hours for them all to go
>> out.
>> > > >
>> > > > Which is to say - emails are on their way - but if you haven't
>> gotten
>> > > > yours yet, that's fine. I'll send another email when they've all
>> gone
>> > > > out, so don't worry about not receiving one until I've sent that
>> mail.
>> > > Well- that took longer than I expected. Because of some rate
>> limiting,
>> > > 1/2 second delay was not long enough...
>> > >
>> > > Anyway - all of the emails should have gone out now. Because that
>> took
>> > > so long, I'm going to hold the poll open until next Wednesday.
>> > >
>> > > Monty
>> >
>> > Not sure why, but I haven't received an email yet.
>> >
>> > Thanks,
>> > Michal
>>
>> Nor I.
>>
>> Doug
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
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] Removes the extra URL routes in Nova API

[Matt Riedemann]

On 3/30/2017 12:22 AM, Alex Xu wrote:

Currently I'm working on removing the stevedore [0], and move the URL
routes mapping into a plain list [1].

But actually, the original URL mappings which Nova created [2] are more
than that list.
Due to the interface 'routes.Mapper.resources' create a set routes
conforming to the Atom publish protocol.[3]

So there are some URL mapping we never documented at somewhere (at least
I don't know):

POST /servers.:(format)
GET /servers/detail.:(format)

GET /servers/new.:(format)  (the API doesn't work, return 404)
GET /servers/new (the API doesn't work, return 404)
GET /servers/:(id)/edit.:(format) (the API doesn't work, return 404)


I plan to remove the support for those URL mappings in the patch [1],
and it will fix the bug https://bugs.launchpad.net/nova/+bug/1615475.

But I want to send this email to ensure we are ok to remove those URL
mappings.

Thanks
Alex

[0] https://review.openstack.org/#/c/445864/
[1] 
https://review.openstack.org/#/c/445864/7/nova/api/openstack/compute/routes.py@119
[2] 
https://github.com/openstack/nova/blob/master/nova/api/openstack/__init__.py#L174
[3] https://routes.readthedocs.io/en/latest/restful.html


__
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



I'm fine with removing those undocumented, frankly unknown to most of 
us, URL mappings. We don't support them, document them, or test them. 
They are basically an accident as far as I know, so +1 for removal.


--

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] [oslo][infra][pbr] Nominating Stephen Finucane for pbr-core

[ChangBo Guo]

+1, we really need more people who know pbr well :-)

2017-04-12 21:14 GMT+08:00 Monty Taylor :

> Hey all,
>
> As I'm sure you all know, pbr is both our most pervasively used dependency
> and our least well understood. Nobody ever wants to look at the code
> (sorry, I can write ugly code sometimes - but also wow setuptools) or dig
> in to figure out what happened when things break.
>
> Recently Stephen Finucane (sfinucan) has stepped up to the plate to help
> sort out issues we've been having. He's shown a lack of fear of the
> codebase and an understanding of what's going on. He's also following
> through on patches to projects themselves when needed, which is a huge part
> of the game. And most importantly he knows when to suggest we _not_ do
> something.
>
> It's not a HUGE corpus of work we have to go on - but that's a good thing
> - pbr shouldn't chance much - but it's in keeping with the other active pbr
> maintainers:
>
> http://stackalytics.com/report/contribution/pbr/90
>
> Monty
>
> __
> 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
>



-- 
ChangBo Guo(gcb)
__
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][infra][pbr] Nominating Stephen Finucane for pbr-core

[Monty Taylor]

Hey all,

As I'm sure you all know, pbr is both our most pervasively used 
dependency and our least well understood. Nobody ever wants to look at 
the code (sorry, I can write ugly code sometimes - but also wow 
setuptools) or dig in to figure out what happened when things break.


Recently Stephen Finucane (sfinucan) has stepped up to the plate to help 
sort out issues we've been having. He's shown a lack of fear of the 
codebase and an understanding of what's going on. He's also following 
through on patches to projects themselves when needed, which is a huge 
part of the game. And most importantly he knows when to suggest we _not_ 
do something.


It's not a HUGE corpus of work we have to go on - but that's a good 
thing - pbr shouldn't chance much - but it's in keeping with the other 
active pbr maintainers:


http://stackalytics.com/report/contribution/pbr/90

Monty

__
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] Emails for OpenStack R Release Name voting going out - please be patient

[Neil Jerram]

Nor me.

On Wed, Apr 12, 2017 at 1:55 PM Doug Hellmann  wrote:

> Excerpts from Dulko, Michal's message of 2017-04-12 12:09:30 +:
> > On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:
> > > On 04/06/2017 07:34 AM, Monty Taylor wrote:
> > > >
> > > > Hey all!
> > > >
> > > > I've started the R Release Name poll and currently am submitting
> > > > everyone's email address to the system. In order to not make our fine
> > > > friends at Carnegie Mellon (the folks who run the CIVS voting
> service)
> > > > upset, I have a script that submits the emails one at a time with a
> > > > half-second delay between each email. That means at best, since there
> > > > are 40k people to process it'll take ~6 hours for them all to go out.
> > > >
> > > > Which is to say - emails are on their way - but if you haven't gotten
> > > > yours yet, that's fine. I'll send another email when they've all gone
> > > > out, so don't worry about not receiving one until I've sent that
> mail.
> > > Well- that took longer than I expected. Because of some rate limiting,
> > > 1/2 second delay was not long enough...
> > >
> > > Anyway - all of the emails should have gone out now. Because that took
> > > so long, I'm going to hold the poll open until next Wednesday.
> > >
> > > Monty
> >
> > Not sure why, but I haven't received an email yet.
> >
> > Thanks,
> > Michal
>
> Nor I.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release] pausing releases due to pypi upload issues

[Doug Hellmann]

Earlier today several of the release jobs failed when uploading
artifacts to PyPI. We're going to hold off tagging any other releases
until we've confirmed that the problem is resolved.

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] Emails for OpenStack R Release Name voting going out - please be patient

[Doug Hellmann]

Excerpts from Dulko, Michal's message of 2017-04-12 12:09:30 +:
> On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:
> > On 04/06/2017 07:34 AM, Monty Taylor wrote:
> > > 
> > > Hey all!
> > > 
> > > I've started the R Release Name poll and currently am submitting
> > > everyone's email address to the system. In order to not make our fine
> > > friends at Carnegie Mellon (the folks who run the CIVS voting service)
> > > upset, I have a script that submits the emails one at a time with a
> > > half-second delay between each email. That means at best, since there
> > > are 40k people to process it'll take ~6 hours for them all to go out.
> > > 
> > > Which is to say - emails are on their way - but if you haven't gotten
> > > yours yet, that's fine. I'll send another email when they've all gone
> > > out, so don't worry about not receiving one until I've sent that mail.
> > Well- that took longer than I expected. Because of some rate limiting, 
> > 1/2 second delay was not long enough...
> > 
> > Anyway - all of the emails should have gone out now. Because that took 
> > so long, I'm going to hold the poll open until next Wednesday.
> > 
> > Monty
> 
> Not sure why, but I haven't received an email yet.
> 
> Thanks,
> Michal

Nor I.

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][elections]questions about one platform vision

[Chris Dent]

On Wed, 12 Apr 2017, joehuang wrote:


Can all these efforts lead us to one platform vision? We have to
think over the question.

What's the one platform will be in your own words? What's your
proposal and your focus to help one platform vision being
achieved?


These are tough questions. It's great to have a vision of one
platform, but if there are multiple understandings of what that
platform is (even when everyone thinks they are agreeing it's often
the case that they are not), it will be very hard to make progress.
At the same time inertia has enormous power to keep people,
projects, and companies doing the same old thing.

As usual, I think spending more effort to write down ideas, such as
the TC Vision draft and its concept of constellations[1] and the
resolution on cloud applications[2], are an important (but not
fully sufficient) step. The documents provide a focus around which
discussion can happen. While disagreement and enthusiasm are
important indicators, at least as important is the degree to which
people squirm about the assumptions being made. Writing helps to
expose those assumptions and once exposed we can decide what to do
with them.

In order for us to move forward on the one platform idea we need to
take the time and effort first to articulate the multiple approaches
and second to convince people of their merit. This second step will
require consistent engagement with not just project members but with
the companies that are funding most contributors. Those companies
have to be convinced of the merit of change. There's no doubt this
will be challenging, especially in these times when some companies
are willing to declare that OpenStack is "broken".

Making progress will require a TC that is proactive. In the last
election in October there were questions around whether the TC
should be a "a reactive council" or "a proactive committee that
initiates change"[3]. I'm firmly in the latter camp but believe the
action must be driven by a very active feedback loop with the entire
OpenStack community.

In any case, I do have a personal vision. It could very well be far
too pie in the sky and require too much change, but if approached
incrementally could provide benefit. My hope is that lots of people
would have a chance to express their vision and from all of them we
would choose the best bits to form the vision that we pursue. Any
vision will have many dependent tasks that must be satisfied
before the vision can even start. For example common policy
scenarios[4] and application user accounts[5] are global issues we
will need to address.

Essentially the idea is to change or expand the layers at which
humans and external applications interact with OpenStack, in the
style of oaktree[5] or enamel[6], where the outer layer is a single
API service driven by use cases (give me a vm, give me a bare metal
server, give me a pod representing elastic application X,
orchestrate the assemblage of Y). That layer speaks to the service
APIs to achieve its needs. Complex use cases (NFV perhaps?) might
skip the outer layer when they require functionality that the outer
layer does not expose. If the constellation metaphor catches on then
it is also possible that different constellations might have
different outer layers.

Like so many technology solutions, this is "simply" introducing
another layer of indirection. Doing so would enable each layer to
evolve with some independence and, critically, would allow different
implementations of the same service type to leapfrog an
incumbent[7]. To use that hackneyed cliché: skate to where the puck
will be.

If we are going to be thinking of OpenStack as one platform, then we
need to evaluate its various pieces with regard to how they support
that platform and each other as a whole. The needs and goals of the
individual services need to be secondary to the needs and goals of
OpenStack at large. That's a huge change in behavior and attitude,
one that might not be achievable, but worth trying.

I've been around long enough to know that there are many objections
to these kinds of changes, both technical and social. I think,
however, that it is important to at least consider them so we can
discover what improvements are possible. We're starting to recognize
that OpenStack must evolve more quickly. In order to do that we must
figure out ways to work around or loosen the constraints we've built
into our process and ways of engaging new audiences.

None of this is possible, however, unless the OpenStack community in
general and the TC in particular is able to come up with an
effective way to effectively publicize and manage the need for
contributors and other resources. The increased writing described
above will provide some help with that, but another important part
will involve being very clear with all stakeholders about the
sheer volume of work required to create and maintain OpenStack.

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

Re: [openstack-dev] Emails for OpenStack R Release Name voting going out - please be patient

[Dulko, Michal]

On Wed, 2017-04-12 at 06:57 -0500, Monty Taylor wrote:
> On 04/06/2017 07:34 AM, Monty Taylor wrote:
> > 
> > Hey all!
> > 
> > I've started the R Release Name poll and currently am submitting
> > everyone's email address to the system. In order to not make our fine
> > friends at Carnegie Mellon (the folks who run the CIVS voting service)
> > upset, I have a script that submits the emails one at a time with a
> > half-second delay between each email. That means at best, since there
> > are 40k people to process it'll take ~6 hours for them all to go out.
> > 
> > Which is to say - emails are on their way - but if you haven't gotten
> > yours yet, that's fine. I'll send another email when they've all gone
> > out, so don't worry about not receiving one until I've sent that mail.
> Well- that took longer than I expected. Because of some rate limiting, 
> 1/2 second delay was not long enough...
> 
> Anyway - all of the emails should have gone out now. Because that took 
> so long, I'm going to hold the poll open until next Wednesday.
> 
> Monty

Not sure why, but I haven't received an email yet.

Thanks,
Michal
__
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] [elections] Available time and top priority

[Matthew Treinish]

On Mon, Apr 10, 2017 at 11:16:57AM +0200, Thierry Carrez wrote:
> Hi everyone,
> 
> New in this TC election round, we have a few days between nominations
> and actual voting to ask questions and get to know the candidates a bit
> better. I'd like to kick off this new "campaigning period" with a basic
> question on available time and top priority.
> 
> All the candidates are top community members with a lot of
> responsibilities on their shoulders already. My experience tells me that
> it is easy to overestimate the time we can dedicate to Technical
> Committee matters, and how much we can push and get done in six months
> or one year. At the same time, our most efficient way to make progress
> is always when someone "owns" a particular initiative and pushes it
> through the governance process.
> 
> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing
> proposed changes and pushing your own) ? If there was ONE thing, one
> initiative, one change you will actively push in the six months between
> this election round and the next, what would it be ?

I know personally I'm planning to dedicate more time over the next cycle to TC
activities. Something for me personally that came out of doing the visioning
exercise last month was that it did give me an opportunity to reflect on what
I viewed as priorities for the next 2 years.

So I think for me, as I outlined in the candidacy email, the one initiative I'd
really like to make a push for over the next 6 months is to start working on
trying build up the systems in place to support both part time contributors and
working on growing new leaders in the community. Realistically I don't think
either is completely accomplishable in 6 months, but getting a good start and
making initial progress is.

Thanks,

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

Re: [openstack-dev] Emails for OpenStack R Release Name voting going out - please be patient

[Monty Taylor]

On 04/06/2017 07:34 AM, Monty Taylor wrote:

Hey all!

I've started the R Release Name poll and currently am submitting
everyone's email address to the system. In order to not make our fine
friends at Carnegie Mellon (the folks who run the CIVS voting service)
upset, I have a script that submits the emails one at a time with a
half-second delay between each email. That means at best, since there
are 40k people to process it'll take ~6 hours for them all to go out.

Which is to say - emails are on their way - but if you haven't gotten
yours yet, that's fine. I'll send another email when they've all gone
out, so don't worry about not receiving one until I've sent that mail.


Well- that took longer than I expected. Because of some rate limiting, 
1/2 second delay was not long enough...


Anyway - all of the emails should have gone out now. Because that took 
so long, I'm going to hold the poll open until next Wednesday.


Monty



__
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] [elections] Available time and top priority

[Flavio Percoco]

On 12/04/17 11:07 +0200, Thierry Carrez wrote:

Ildiko Vancsa wrote:

On 2017. Apr 12., at 3:18, Monty Taylor > wrote:
[...]
Email allows someone to compose an actual structured narrative, and
for replies to do the same. Some of us are loquatious and I imagine
can be hard to follow even with time to read.

IRC allows someone to respond quickly, and for someone to be like "yo,
totes sorry, I didn't mean that at all LOL" and to walk things back
before a pile of people become mortally insulted.

Like now - hopefully you'll give me a smiley in IRC ... but you might
not, and I'm stuck worrying that my tone came across wrong. Then if
you just don't respond because ZOMG-EMAIL, I might start day drinking.


Big +1 on balance.

I agree in general that we need to revisit how to be more inclusive and
how to provide as equal conditions to people all around the globe as
possible.

That said I still would like to keep the ability to have allocated time
for synchronous communication and allow the TC to be more of a team as
opposed to a group of people driving their own and some shared missions.
I think it helps with seeing maybe different parts but still the same
big picture and making the group more efficient with decision making and
bringing the community forward.
[...]


Agree with you Ildiko and Monty, we still need sync communication to get
a better feel of everyone's feelings on a particular issue, especially
on complex issues. At the same time, a unique weekly meeting is actively
preventing people from participating. It is also very active and noisy,
the timebox can be painful, and its weekly cadence makes a good reason
for procrastinating in reviews until the topic is raised in meeting,
where final decision is made. Creating multiple official meetings
spreads the pain instead of eliminating it. It makes it easier for more
people to join, but more difficult for any given member to participate
to every meeting. Our ability to quickly process changes might be affected.

One idea I've been considering is eliminating the one and only sacred
one-hour weekly TC meeting, and encouraging ad-hoc discussions (on
#openstack-dev for example) between change proposers and smaller groups
of TC members present in the same timezone. That would give us a good
feel of what everyone thinks, reduce noise, and happen at various times
during the day on a public forum, giving an opportunity for more people
to jump in the discussion. The informal nature of those discussions
would make the governance reviews the clear focal point for coordination
and final decision.

It's clearly not the perfect silver bullet though, so I'd very much like
to hear other ideas :)



I believe I shared this with you on one of our conversations over dinner one
night. I'm glad to see you're more convinced now. I've talked about this with
you and other folks among the TC and I'm growing more convinced that it's the
right thing to do.

I've toyed with this idea for a bit already and I also mentioned it in my reply
to Matt[0] yesterday. As I mentioned in my email, I believe most can be achieved
on gerrit and we can instead focus on having a better way for ad-hoc
conversations and mentoring of people that need support from the TC.

[0] http://lists.openstack.org/pipermail/openstack-dev/2017-April/115255.html

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [tc][elections]questions about one platform vision

[John Garbutt]

On 12 April 2017 at 12:04, Davanum Srinivas  wrote:
> On Wed, Apr 12, 2017 at 6:51 AM, John Garbutt  wrote:
>> On 12 April 2017 at 03:54, joehuang  wrote:
>>> What's the one platform will be in your own words? What's your proposal and
>>> your focus to help one platform vision being achieved?
>>
>> The more I think about this, the less I like the phrase "one platform".
>>
>> I like to think of OpenStack as group of constellations. Those
>> constellations are groups of projects that are built to be used
>> together around a shared set of use cases and users. Note that many
>> (all?) of those constellations involve open source projects that were
>> born and live outside of OpenStack.
>
> +1 for us to publish sets of projects that work together for specific
> scenarios. I heard this idea first from Allison Randall and it
> immediately struck a chord. To be fair folks like Jay Pipes have
> always said (paraphrasing) "OpenStack is a toolbox". So it's the next
> step i guess. Lauren Sell was mentioning yesterday about hearing
> confusion around "Big Tent", i do feel that when we put forth a set of
> constellations we can start deprecating the "Big Tent" terminology if
> appropriate.

Right, I have tools for hanging pictures, and tools for putting
together flat pack furniture. They all live in my tool box, and it
turns out I use the hammer for almost everything. (I don't generally
use the hammer when repairing my Tuba, and my wife prefers those
sticky hook things for hanging up pictures, but thats all fine) ... I
maybe stretched that a bit :)

Thanks,
johnthetubaguy

__
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] [elections] Available time and top priority

[John Garbutt]

On 12 April 2017 at 10:07, Thierry Carrez  wrote:
> Ildiko Vancsa wrote:
>>> On 2017. Apr 12., at 3:18, Monty Taylor >> > wrote:
>>> [...]
>>> Email allows someone to compose an actual structured narrative, and
>>> for replies to do the same. Some of us are loquatious and I imagine
>>> can be hard to follow even with time to read.
>>>
>>> IRC allows someone to respond quickly, and for someone to be like "yo,
>>> totes sorry, I didn't mean that at all LOL" and to walk things back
>>> before a pile of people become mortally insulted.
>>>
>>> Like now - hopefully you'll give me a smiley in IRC ... but you might
>>> not, and I'm stuck worrying that my tone came across wrong. Then if
>>> you just don't respond because ZOMG-EMAIL, I might start day drinking.
>>
>> Big +1 on balance.
>>
>> I agree in general that we need to revisit how to be more inclusive and
>> how to provide as equal conditions to people all around the globe as
>> possible.
>>
>> That said I still would like to keep the ability to have allocated time
>> for synchronous communication and allow the TC to be more of a team as
>> opposed to a group of people driving their own and some shared missions.
>> I think it helps with seeing maybe different parts but still the same
>> big picture and making the group more efficient with decision making and
>> bringing the community forward.
>> [...]
>
> Agree with you Ildiko and Monty, we still need sync communication to get
> a better feel of everyone's feelings on a particular issue, especially
> on complex issues. At the same time, a unique weekly meeting is actively
> preventing people from participating. It is also very active and noisy,
> the timebox can be painful, and its weekly cadence makes a good reason
> for procrastinating in reviews until the topic is raised in meeting,
> where final decision is made. Creating multiple official meetings
> spreads the pain instead of eliminating it. It makes it easier for more
> people to join, but more difficult for any given member to participate
> to every meeting. Our ability to quickly process changes might be affected.
>
> One idea I've been considering is eliminating the one and only sacred
> one-hour weekly TC meeting, and encouraging ad-hoc discussions (on
> #openstack-dev for example) between change proposers and smaller groups
> of TC members present in the same timezone. That would give us a good
> feel of what everyone thinks, reduce noise, and happen at various times
> during the day on a public forum, giving an opportunity for more people
> to jump in the discussion. The informal nature of those discussions
> would make the governance reviews the clear focal point for coordination
> and final decision.

+1 on eliminating the meeting.

+1 on the need for the synchronous discussions, that are documented
and linked back to the gerrit review.

One idea that came up talking about the SWG, was a wiki page with a
weekly status update, that gets emailed out each week by the TC
chairperson. The chair has to chase folks who don't update it, ping
folks for their vote on patches they are ignoring, etc. Maybe it would
end up looking like the API-WG emails that cdent sends out, which
links to reviews that are the current focus as possible merge
candidates.

We often only merge things in the meeting, but if we went more towards
expecting a +1 from all members then as soon as all the required +1s
are present the chairperson is free to merge (and maybe timeouts using
the weekly email in API-WG style).

I strongly believe we need to try not having the meeting, and be more
globally inclusive in the TCs activities. I see the TC as a core team,
rather than the only people working on governance type activities. We
all need to work together to maintain and improve the community
vibrant we have. I think success is when we have people from all
around the globe involved in TC related activities and reviews.

Many thanks,
johnthetubaguy

__
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][elections]questions about one platform vision

[Davanum Srinivas]

On Wed, Apr 12, 2017 at 6:51 AM, John Garbutt  wrote:
> On 12 April 2017 at 03:54, joehuang  wrote:
>> What's the one platform will be in your own words? What's your proposal and
>> your focus to help one platform vision being achieved?
>
> The more I think about this, the less I like the phrase "one platform".
>
> I like to think of OpenStack as group of constellations. Those
> constellations are groups of projects that are built to be used
> together around a shared set of use cases and users. Note that many
> (all?) of those constellations involve open source projects that were
> born and live outside of OpenStack.

+1 for us to publish sets of projects that work together for specific
scenarios. I heard this idea first from Allison Randall and it
immediately struck a chord. To be fair folks like Jay Pipes have
always said (paraphrasing) "OpenStack is a toolbox". So it's the next
step i guess. Lauren Sell was mentioning yesterday about hearing
confusion around "Big Tent", i do feel that when we put forth a set of
constellations we can start deprecating the "Big Tent" terminology if
appropriate.


> I am trying to kick start the "VM and baremetal" working group to get
> feedback on a specific constellation as a group of projects. Here I am
> thinking about running Nova, Cinder, Neutron, Keystone, etc to give
> you (in some sense) a Software Defined Data Center. Many applications
> and services need to consume and integrate with that platform, like
> Heat, Trove and Magnum, to can get access to the compute, networking
> and storage they need to execute their workloads, such as containers.
> Its like the next generation of consolidation to get to the next level
> of utilization/efficiency. If you look at this constellation the
> database and message queue are important non-OpenStack components of
> the constellation. Maybe this is a false constellation, and there is a
> different set of things that people use together. Thats some of the
> feedback I hope we get at the forum.
>
> The work ttx mentions is important. I hope the project maps will help
> communicate how users can meet their needs by running various
> combinations of OpenStack and non-OpenStack projects together.
>
> To be clear, I am not claiming to have the answers here, this is just
> my current thinking. I look forward to all the debate and discussions
> around this topic, and all the interesting things I will learn about
> along that journey, things that will likely make me change my mind.
>
> Thanks,
> johnthetubaguy
>
> __
> 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] [elections] Available time and top priority

[John Garbutt]

On 11 April 2017 at 09:58, Thierry Carrez  wrote:
> Matt Riedemann wrote:
>> Lots of projects have alternating meeting times to accommodate
>> contributors in different time zones, especially Europe and Asia.
>>
>> The weekly TC meeting, however, does not.
>>
>> I have to assume this has come up before and if so, why hasn't the TC
>> adopted an alternating meeting schedule?
>>
>> For example, it's 4am in Beijing when the TC meeting happens. It's
>> already hard to get people from Asia into leadership roles within
>> projects and especially across the community, in large part because of
>> the timezone barrier.
>>
>> How will the TC grow a diverse membership if it's not even held, at
>> least every other week, in a timezone where the other half of the world
>> can attend?
>
> The current meeting time is more a consequence of the current membership
> composition than a hard rule. There is, however (as you point out) much
> chicken-and-egg effect at play here -- it's easier to get involved in
> the TC if you can regularly attend meetings, so we can't really wait
> until someone is elected to change the time.

+1 on the chicken-and-egg problem here.

If elected I plan on not attending the meetings, to help with this, please see:
https://git.openstack.org/cgit/openstack/election/tree/candidates/pike/TC/johnthetubaguy.txt

> Alternating meeting times would certainly improve the situation, but I'm
> not sure they are the best solution. Personally I would rather try to
> decrease our dependency on meetings.

+1 this.

I think finding better ways of working that don't need synchronous
meetings that naturally exclude someone is the way forward here. We
have the tooling for most of this already, we just need to find better
patterns to keep making progress.

IRC meeting also have lots of the issues documented as mentioned on
this thread. Been working with the SWG group to bring ideas together
here:
https://review.openstack.org/#/c/441923/

Thanks,
johnthetubaguy

__
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][elections]questions about one platform vision

[John Garbutt]

On 12 April 2017 at 03:54, joehuang  wrote:
> What's the one platform will be in your own words? What's your proposal and
> your focus to help one platform vision being achieved?

The more I think about this, the less I like the phrase "one platform".

I like to think of OpenStack as group of constellations. Those
constellations are groups of projects that are built to be used
together around a shared set of use cases and users. Note that many
(all?) of those constellations involve open source projects that were
born and live outside of OpenStack.

I am trying to kick start the "VM and baremetal" working group to get
feedback on a specific constellation as a group of projects. Here I am
thinking about running Nova, Cinder, Neutron, Keystone, etc to give
you (in some sense) a Software Defined Data Center. Many applications
and services need to consume and integrate with that platform, like
Heat, Trove and Magnum, to can get access to the compute, networking
and storage they need to execute their workloads, such as containers.
Its like the next generation of consolidation to get to the next level
of utilization/efficiency. If you look at this constellation the
database and message queue are important non-OpenStack components of
the constellation. Maybe this is a false constellation, and there is a
different set of things that people use together. Thats some of the
feedback I hope we get at the forum.

The work ttx mentions is important. I hope the project maps will help
communicate how users can meet their needs by running various
combinations of OpenStack and non-OpenStack projects together.

To be clear, I am not claiming to have the answers here, this is just
my current thinking. I look forward to all the debate and discussions
around this topic, and all the interesting things I will learn about
along that journey, things that will likely make me change my mind.

Thanks,
johnthetubaguy

__
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][api] quota-class-show not sync toquota-show

[Chen CH Ji]

ok, thanks for the info,  I will submit the spec and wait for more response
from the spec

Best Regards!

Kevin (Chen) Ji 纪 晨

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



From:   Lance Bragstad 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   04/12/2017 03:09 AM
Subject:Re: [openstack-dev] [nova][api] quota-class-show not sync to
quota-show





On Tue, Apr 11, 2017 at 1:21 PM, Matt Riedemann 
wrote:
  On 4/11/2017 2:52 AM, Alex Xu wrote:
   We talked about remove the quota-class API for multiple times
   (
   http://lists.openstack.org/pipermail/openstack-dev/2016-July/099218.html
   )

   I guess we can deprecate the entire quota-class API directly.


  I had a spec proposed to deprecate the os-quota-class-sets API [1] but it
  was abandoned since we discussed it at the Pike PTG and decided we would
  just leave it alone until Nova was getting limits information from
  Keystone [2].

FWIW - in addition to merging the conceptual document [0], Sean recently
proposed the limits interface [1] for the keystone bits.

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.htm
[1] https://review.openstack.org/#/c/455709/


  I think the reason we probably missed this API was because of the really
  roundabout way that the information is provided in the response. It calls
  the quota engine driver [3] to get the class quotas. For the DB driver if
  nothing is overridden then nothing comes back here [4]. And the resources
  in the quota driver have a default property which is based on the config
  options [5]. So we'll return quotas on floating_ips and other proxy
  resources simply because of how abstract this all is.

  To fix it, the os-quota-class-sets API would have to maintain a blacklist
  of resources to exclude from the response, like what we do for limits
  [6].

  So yeah, I guess we'd need a new spec and microversion for this.

  [1] https://review.openstack.org/#/c/411035/
  [2] https://review.openstack.org/#/c/440815/
  [3]
  
https://github.com/openstack/nova/blob/15.0.0/nova/api/openstack/compute/quota_classes.py#L67

  [4] https://github.com/openstack/nova/blob/15.0.0/nova/quota.py#L92
  [5] https://github.com/openstack/nova/blob/15.0.0/nova/quota.py#L1069
  [6]
  
https://github.com/openstack/nova/blob/15.0.0/nova/api/openstack/compute/views/limits.py#L20


  --

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


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

Re: [openstack-dev] [heat] New resource implementation workflow

[Peter Razumovsky]

>
> I also remember that Heat has smth like 'hidden' in resource plugin
> declaration. Usually it is used to hide deprecated resource types so that
> new stacks with those can not be created but old ones can be at least
> deleted. May be you could use that flag while developing until you think
> that resource is already usable, although it might complicate your own
> testing of those resources.


In addition, I advice you to use UNSUPPORTED status untill resource will
not be fully implemented. For details, suggest to read resource support
status page

.

2017-04-11 17:27 GMT+04:00 Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com>:

> Hi Norbert,
>
> my biggest concern with the workflow you've shown is that in the meantime
> it would be possible to create undeletable stacks / stacks that leave
> resources behind after being deleted. As the biggest challenge is usually
> in updates (if it is not UpdateReplace) I'd suggest implementing create and
> delete together. To ease development you could start with only basic
> properties for the resource if it is possible to figure out their set (with
> some sane defaults if those are absent in API) and add more tunable
> resource properties later.
>
> I also remember that Heat has smth like 'hidden' in resource plugin
> declaration. Usually it is used to hide deprecated resource types so that
> new stacks with those can not be created but old ones can be at least
> deleted. May be you could use that flag while developing until you think
> that resource is already usable, although it might complicate your own
> testing of those resources.
>
> Cheers,
>
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.com
>
> On Tue, Apr 11, 2017 at 3:33 PM, Norbert Illés <
> norbert.e.il...@ericsson.com> wrote:
>
>> Hi everyone,
>>
>> Me and two of my colleagues are working on adding Neutron Trunk support
>> to Heat. One of us working on the resource implementation, one on the unit
>> tests and one on the functional tests. But all of these looks like a big
>> chunk of work so I'm wondering how can we divide them into smaller parts.
>>
>> One idea is to split them along life cycle methods (create, update,
>> delete, etc.), for example:
>>  * Implement the resource creation + the relevant unit tests + the
>> relevant functional tests, review and merge these
>>  * implementing the delete operation + the relevant unit tests + the
>> relevant functional tests, review and merge these
>>  * move on to implementing the update operation + tests... and so on.
>>
>> Lastly, when the last part of the code and tests merged, we can document
>> the new resource, create templates in the heat-templates etc.
>>
>> Is this workflow sounds feasible?
>>
>> I mostly concerned about the fact that there will be a time period when
>> only a half-done feature merged into the Heat codebase, and I'm not sure if
>> this is acceptable?
>>
>> Has anybody implemented a new resource with a team? I would love to hear
>> some experiences about how others have organized this kind of work.
>>
>> Cheers,
>> Norbert
>>
>> 
>> __
>> 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
>
>


-- 
Best regards,
Peter Razumovsky
__
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] [elections] Available time and top priority

[Ildiko Vancsa]

> […]
> One idea I've been considering is eliminating the one and only sacred
> one-hour weekly TC meeting, and encouraging ad-hoc discussions (on
> #openstack-dev for example) between change proposers and smaller groups
> of TC members present in the same timezone. That would give us a good
> feel of what everyone thinks, reduce noise, and happen at various times
> during the day on a public forum, giving an opportunity for more people
> to jump in the discussion. The informal nature of those discussions
> would make the governance reviews the clear focal point for coordination
> and final decision.
> 
> It's clearly not the perfect silver bullet though, so I'd very much like
> to hear other ideas :)

Sold! As far as I’m concerned. :)

As a version of this idea, I was thinking of an #openstack-tc IRC channel, but 
wanted to give it another thought before bringing it up. :) While I don’t have 
the intention to necessarily increase the number of IRC channels we have, this 
would give us the ability to follow the TC related discussion better.

By being experienced with working remotely, I like channels with smaller well 
defined scope/purpose as I can prioritize which one to read first and I don’t 
need to filter that much of the different, sometimes parallel threads to catch 
up on what happened. Also when I see activity on these channels I get a better 
indicator whether I need to/want to look into the discussion immediately and be 
part of it or not. I don’t want to decrease the importance of #openstack-dev 
(or any other already existing channel), but rather noting that it has a 
broader scope that might be distracting.

My 2 cents.

Thanks,
Ildikó


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


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

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[SUZUKI, Kazuhiro]

Hi,

> I think (a) is also good from TaaS dashboard.

This opinion is agreed as a TaaS project.

Regards,
Kaz


From: "SUZUKI, Kazuhiro" 
Subject: Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would 
we like to have horizon dashboard for neutron stadium projects?
Date: Wed, 12 Apr 2017 09:19:42 +0900 (JST)

> Hi,
> 
> I think (a) is also good from TaaS dashboard.
> 
> Regards,
> Kaz
> 
> 
> From: Akihiro Motoki 
> Subject: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we 
> like to have horizon dashboard for neutron stadium projects?
> Date: Tue, 11 Apr 2017 00:09:10 +0900
> 
>> Hi neutrinos (and horizoners),
>> 
>> As the title says, where would we like to have horizon dashboard for
>> neutron stadium projects?
>> There are several projects under neutron stadium and they are trying
>> to add dashboard support.
>> 
>> I would like to raise this topic again. No dashboard support lands since 
>> then.
>> Also Horizon team would like to move in-tree neutron stadium dashboard
>> (VPNaaS and FWaaS v1 dashboard) to outside of horizon repo.
>> 
>> Possible approaches
>> 
>> 
>> Several possible options in my mind:
>> (a) dashboard repository per project
>> (b) dashboard code in individual project
>> (c) a single dashboard repository for all neutron stadium projects
>> 
>> Which one sounds better?
>> 
>> Pros and Cons
>> 
>> 
>> (a) dashboard repository per project
>>   example, networking-sfc-dashboard repository for networking-sfc
>>   Pros
>>- Can use existing horizon related project convention and knowledge
>>  (directory structure, testing, translation support)
>>- Not related to the neutron stadium inclusion. Each project can
>> provide its dashboard
>>  support regardless of neutron stadium inclusion.
>>  Cons
>>- An additional repository is needed.
>> 
>> (b) dashboard code in individual project
>>   example, dashboard module for networking-sfc
>>   Pros:
>>- No additional repository
>>- Not related to the neutron stadium inclusion. Each project can
>> provide its dashboard
>>  support regardless of neutron stadium inclusion.
>>  Cons:
>>- Requires extra efforts to support neutron and horizon codes in a
>> single repository
>>  for testing and translation supports. Each project needs to
>> explore the way.
>> 
>> (c) a single dashboard repository for all neutron stadium projects
>>(something like neutron-advanced-dashboard)
>>   Pros:
>> - No additional repository per project
>>   Each project do not need a basic setup for dashboard and
>> possible makes things simple.
>>   Cons:
>> - Inclusion criteria depending on the neutron stadium inclusion/exclusion
>>   (Similar discussion happens as for neutronclient OSC plugin)
>>   Project before neutron stadium inclusion may need another 
>> implementation.
>> 
>> 
>> My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a 
>> repo).
>> 
>> Note that as dashboard supports for feature in the main neutron repository
>> are implemented in the horizon repository as we discussed several months ago.
>> As an example, trunk support is being development in the horizon repo.
>> 
>> Thanks,
>> Akihiro
>> 
>> __
>> 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][elections]questions about one platform vision

[Thierry Carrez]

joehuang wrote:
> [...]
> What's the one platform will be in your own words? What's your proposal
> and your focus to help one platform vision being achieved?

OpenStack is "one platform", one open infrastructure platform. It can
provide various resources (VMs, bare metal machines, container
orchestration engines, single container hosts, object storage...) with
shared services. You can use your Keystone authentication across the
board. You get "one platform" for compute resources of different types,
and within that platform they can share networks, block storage or
filesystems. This "open stack" can integrate components that are not
developed by the OpenStack community, but for those that are, we aim to
simplify the operational experience by using the same set of base
services, log formats or configuration style.

We need to produce maps of OpenStack that will make it clearer how
everything fits together, and expose the open nature of the stack. I'm
leading a Board+TC+UC group working on that mapping effort. We need to
make it easier for infrastructure pieces produced outside of our
community to be plugged into the open infrastructure platform, and I'm
reaching out to those communities to preach the word, but also support
Keystone, Cinder and Neutron efforts to serve a wider set of consumer
services. Finally, over the past cycle I pushed a clear definition of
the notion of base services. Over the coming cycle we should refine and
expand the set to include new services that every component in the
OpenStack family could take advantage of, like etcd.

Thanks for raising that question!

-- 
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] [tripleo][ui] another i18n proposal for heat templates 'description' help strings

[Peng Wu]

Hi Julie,

  Please see the comments in line.


On Mon, 2017-04-10 at 16:13 +0100, Julie Pichon wrote:
> Hi Peng,
> 
> I added some thoughts in-line, let me know what you think.
> 
> On 10 April 2017 at 08:10, Peng Wu  wrote:
> > Hi,
> > 
> >   In TripleO UI project users requested translation of the web UI.
> > But
> > some web UI strings are displayed from heat template files in
> > tripleo-
> > heat-templates project.
> > 
> >   In order to get translated templates displayed in tripleo-ui, we
> > propose another solution as follows, which needs to change code in
> > tripleo-heat-templates and tripleo-ui projects.
> > 
> >   I18n proposal for Heat templates 'description' help strings
> > 
> >   1. Update tripleo-heat-templates to generate the javascript files
> > to
> > include all translation strings, like "tripleo-heat-templates.js"
> > 
> >  a. Need to write python script to extract "title" and
> > "description" field from yaml files and generate "tripleo-heat-
> > templates.js" for react-intl usage in tripleo-ui
> 
> I think extracting the strings directly into js/json format may be
> not
> be a viable option, because it isn't a format supported by
> Zanata [1].
> 
> For tripleo-ui itself we use react-intl which expects json, and work
> with scripts to convert to/from pot and po (see [2]) which are fully
> supported by Zanata.
> 
> Or is the idea that we'd also generate pot/po as intermediary steps
> and
> only store json in the repo?
> 

I think we will just generate one javascript file which contains all
translatable strings, and copy the javascript file to tripleo-ui, and 
translations will only happens in tripleo-ui as other strings from
tripleo-ui project.

The generated javascript file is like:
const messages = defineMessages({
  root_template_description: {
id: 'Base Resources Configuration',
defaultMessage: 'Base Resources Configuration'
  }
},
...
);


> >  b. Use default message as message id or consider nodejs-i18n
> > for
> > tripleo-ui
> 
> I'm wary of considering a library change considering the amount of
> churn it would cause in the code base for all the existing strings,
> plus that would then make backports more difficult. It really needs
> to
> be considered carefully.
> 

To use nodejs-i18n is just a backup plan, from reply of react-intl we
may just use default message as message id only for translatable
strings from tripleo-heat-templates project.

> > 
> >   2. Update tripleo-ui to use "tripleo-heat-templates.js"
> > 
> >  a. Write some script to sync "tripleo-heat-templates.js" from
> > tripleo-heat-templates
> > 
> >  b. Call formatMessage function for "title" and "description"
> > field
> > with message id (use default message) and default message or
> > consider
> > nodejs-i18n for tripleo-ui
> > 
> >   Refer URL for message id: https://github.com/yahoo/react-intl/iss
> > ues/
> > 912
> 
> Could you explain a bit more the issue with the ids? I see us
> defining
> an id in every message [3] and this is how they are referenced in the
> locale json [4] (the mapping is not done by message, but by ID).
> 
> When it comes to the THT message, I think they all have a hierarchy
> that perhaps could be used as a key to map between the original
> string
> and the translation? Something along the lines of
> OS::TripleO::Services::Apache::ApacheMaxRequestWorkers::description,
> whichever form the API gives us at the moment.
> 

Actually I didn't find an message id like
"OS::TripleO::Services::Apache::ApacheMaxRequestWorkers::description"
when checking the tripleo-ui source code.

And I can't find "OS::TripleO::Services" in capabilities-map.yaml of
tripleo-heat-templates project. 

If both tripleo-heat-templates and tripleo-ui projects could generate
the same message id, it could be used.
But it seems only default message is sent to tripleo-ui project when I
am checking.

Feel free to comment it! Thanks!

Regards,
  Peng


> >   Please evaluate it, thanks!
> 
> Thank you!
> 
> Julie
> 
> [1] http://docs.zanata.org/en/release/user-guide/projects/project-typ
> es/#supported-types
> [2] https://github.com/openstack/tripleo-ui/blob/master/docs/translat
> ion.rst#extracting-messages-from-components
> [3] https://github.com/openstack/tripleo-ui/blob/master/src/js/compon
> ents/nodes/Nodes.js#L17
> [4] https://github.com/openstack/tripleo-ui/blob/master/i18n/locales/
> es.json#L3

__
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] [elections] Available time and top priority

[Thierry Carrez]

Ildiko Vancsa wrote:
>> On 2017. Apr 12., at 3:18, Monty Taylor > > wrote:
>> [...]
>> Email allows someone to compose an actual structured narrative, and
>> for replies to do the same. Some of us are loquatious and I imagine
>> can be hard to follow even with time to read.
>>
>> IRC allows someone to respond quickly, and for someone to be like "yo,
>> totes sorry, I didn't mean that at all LOL" and to walk things back
>> before a pile of people become mortally insulted.
>>
>> Like now - hopefully you'll give me a smiley in IRC ... but you might
>> not, and I'm stuck worrying that my tone came across wrong. Then if
>> you just don't respond because ZOMG-EMAIL, I might start day drinking.
> 
> Big +1 on balance.
> 
> I agree in general that we need to revisit how to be more inclusive and
> how to provide as equal conditions to people all around the globe as
> possible.
> 
> That said I still would like to keep the ability to have allocated time
> for synchronous communication and allow the TC to be more of a team as
> opposed to a group of people driving their own and some shared missions.
> I think it helps with seeing maybe different parts but still the same
> big picture and making the group more efficient with decision making and
> bringing the community forward.
> [...]

Agree with you Ildiko and Monty, we still need sync communication to get
a better feel of everyone's feelings on a particular issue, especially
on complex issues. At the same time, a unique weekly meeting is actively
preventing people from participating. It is also very active and noisy,
the timebox can be painful, and its weekly cadence makes a good reason
for procrastinating in reviews until the topic is raised in meeting,
where final decision is made. Creating multiple official meetings
spreads the pain instead of eliminating it. It makes it easier for more
people to join, but more difficult for any given member to participate
to every meeting. Our ability to quickly process changes might be affected.

One idea I've been considering is eliminating the one and only sacred
one-hour weekly TC meeting, and encouraging ad-hoc discussions (on
#openstack-dev for example) between change proposers and smaller groups
of TC members present in the same timezone. That would give us a good
feel of what everyone thinks, reduce noise, and happen at various times
during the day on a public forum, giving an opportunity for more people
to jump in the discussion. The informal nature of those discussions
would make the governance reviews the clear focal point for coordination
and final decision.

It's clearly not the perfect silver bullet though, so I'd very much like
to hear other ideas :)

-- 
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] [tricircle]weekly meeting of Apr.12

[joehuang]

Hello, team,

Agenda of Apr.12 weekly meeting:

  1.  feature implementation review
  2.  Pike-1.5 (May.2) preparation
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 14:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

Best Regards
Chaoyi Huang (joehuang)
__
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