Re: [openstack-dev] Project Navigator Updates - Feedback Request

[Rico Lin]

 The `API Version History` links in all project seems incorrect to me (For
example, `Version v1.0 (Ocata) - LATEST RELEASE` should link to
https://releases.openstack.org/ocata/index.html#ocata-heat not
https://releases.openstack.org/ ).

Some of the groupings seem a little bit strange. It's weird to see Heat and
> Horizon, which are essentially just two different user interfaces to
> OpenStack, in different groups. Also strange to see Senlin in a different
> group to Heat, since they both do autoscaling. I can't imagine why Mistral
> is listed under "Security, Identity and Compliance". There's quite a few
> more that look odd to me as well, mostly as a result of stuff that I might
> have expected to all land together in a catch-all like "Application
> Services" being split into more specific categories, like Freezer going
> under Storage.

Agree, I suggest we can use a group `Application services` or
`Orchestration Services` for all Mistral, Heat, Senlin, etc. seems we
actually have users use OpenStack with that combinations. And we can also
consider use multi-layer grouping.
__
OpenStack Development Mailing 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] Project Navigator Updates - Feedback Request

[Jimmy McArthur]

Brian,

Thanks for the response. This is a tough one. Currently we're pulling 
API data manually for each project. That is no longer tenable when we're 
talking about 40+ projects. Plus, this is info is something that is 
really sought after by the community. Some thoughts below:

Brian Rosmaita 
March 28, 2017 at 10:25 PM
On 3/27/17 5:01 PM, Lauren Sell wrote:
I don't have a helpful recommendation here, but the version history 
for Glance is incorrect as well. We maintain a version history in the 
glance api-ref [0], but that's probably not much help (and, as you 
point out, is idiosyncratic to Glance anyway). At this point, though, 
my primary concern is that it's showing a deprecated API version as 
the latest release. What format would it be useful for you to get this 
data in?

What we really need is the following:

* A project history, including the date of project inception that's 
included in the TC tags.
* An API history in an easily digestible format that all projects share. 
So whether you're doing micro releases or not, just something that 
allows us to show, based on a release timeline, which API versions per 
project are applicable for each OpenStack release. This really needs to 
be consistent from project to project b/c at the moment everyone handles 
it differently.


thanks,
brian

[0]
https://developer.openstack.org/api-ref/image/versions/index.html#version-history

__
OpenStack Development Mailing 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] Project Navigator Updates - Feedback Request

[Brian Rosmaita]

On 3/27/17 5:01 PM, Lauren Sell wrote:
> Hi Matt,
> 
> Thanks for the feedback. 
> 
>> On Mar 24, 2017, at 3:50 PM, Matt Riedemann  wrote:
[snip]
>> 2. The "API Version History" section in the bottom right says:
>>
>> "Version v2.1 (Ocata) - LATEST RELEASE"
>>
>> And links to https://releases.openstack.org/ 
>> . The latest compute microversion in Ocata 
>> was actually 2.42:
>>
>> https://docs.openstack.org/developer/nova/api_microversion_history.html 
>> 
>>
>> I'm wondering how we can better sort that out. I guess "API Version History" 
>> in the navigator is meant more for major versions and wasn't intended to 
>> handle microversions? That seems like something that should be dealt with at 
>> some point as more and more projects are moving to using micro versions.
> 
> Agreed, we could use some guidance here. From what we can tell, each team 
> logs these a little bit differently, so there’s no easy way for us to pull 
> them. Could we output the correct link as a tag for each project, or does 
> anyone have a recommendation?

I don't have a helpful recommendation here, but the version history for
Glance is incorrect as well.  We maintain a version history in the
glance api-ref [0], but that's probably not much help (and, as you point
out, is idiosyncratic to Glance anyway).  At this point, though, my
primary concern is that it's showing a deprecated API version as the
latest release.  What format would it be useful for you to get this data in?

thanks,
brian

[0]
https://developer.openstack.org/api-ref/image/versions/index.html#version-history

__
OpenStack Development Mailing 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] [neutron] What the behavior of AddFixedIp API should be?

[Kevin Benton]

+1. If there is a use case missing from the neutron API that this allows,
we can also expand the API to address it.

On Mar 28, 2017 07:16, "Matt Riedemann"  wrote:

> On 3/27/2017 11:42 PM, Rui Chen wrote:
>
>> Thank you Matt, the background information is important. Seems all the
>> peoples don't know how the add-fixed-ip API works,
>> and there is no exact use case about it. Now neutron port-update API
>> also support to set multiple fixed ip for a port, and
>> the fixed-ip updating will sync to nova side automatically (I had
>> verified it in my latest devstack). Updating fixed-ip for
>> specified port is easier to understand for me in multiple nics case than
>> nova add-fixed-ip API.
>>
>> So if others known the orignal API design or had used nova add/remove
>> fixed-ip API and would like to show your use cases,
>> it's nice for us to understand how the API works and when we should use
>> it, we can update the api-ref and add exact usage,
>> avoid users' confusion about it. Feel free to reply something, thank you.
>>
>>
> If the functionality is available via Neutron APIs, we should just
> deprecate the multinic API like we did for the other network API proxies in
> microversion 2.36. This reminds me that Alex Xu had a blueprint for
> deprecating the multinic API [1] but it needs to be updated for Pike.
>
> [1] https://review.openstack.org/#/c/384261/
>
> --
>
> 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-dev] [infra] lists.openstack.org maintenance Friday, March 31 20:00-23:00 UTC

[Jeremy Stanley]

The Mailman listserv on lists.openstack.org will be offline for an
upgrade-related maintenance for up to 3 hours (but hopefully much
less) starting at 20:00 UTC March 31, this coming Friday. This
activity is scheduled for a relatively low-volume period across our
lists; during this time, most messages bound for the server will
queue at the senders' MTAs until the server is back in service and
so should not result in any obvious disruption.

Apologies for cross-posting so widely, but we wanted to make sure
copies of this announcement went to most of our higher-traffic
lists.
-- 
Jeremy Stanley


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

[openstack-dev] [all][tc] OpenStack is for applications

[Zane Bitter]

Hello OpenStackists,
One of the great strengths of our community is the way our panoply of 
teams can make independent progress towards our goals with a breadth 
that no one person or group could hope to keep track of, let alone 
control. However, for this to work then from time to time we need to pop 
our heads up from our silos to ensure that we are all, in fact, pointed 
in roughly the same direction.


The recent thread on "The future of the App Catalog"[1] (it went waaay 
off-topic) made it clear, I think to everyone involved, that this is one 
such moment. There is a significant disconnect between what application 
developers need OpenStack to be and how our community as a whole has 
conceptualised what OpenStack is and what it's for. To try to close that 
gap, dims asked me to write up a TC resolution that can help us all to 
start pulling in the same direction, and the TC has helped me to tweak 
the wording:


https://review.openstack.org/447031

Now it's your turn. If we can all agree on what the meaning of our 
mission is then we'll get where we're going a lot faster. Please take a 
few minutes to review the resolution to make sure we're all on the same 
page, ask questions, or suggest alternatives.


thanks,
Zane.


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-March/113362.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

Re: [openstack-dev] [os-client-config] get_session_endpoint() and Keystone admin endpoint

[Akira Yoshiyama]

Hi Monty,

Thank you for your reply.

2017年3月28日(火) 23:15 Monty Taylor :

On 03/26/2017 02:55 AM, Akira Yoshiyama wrote:
> Hi,
>
> 2017-03-25 4:54 GMT+09:00 Monty Taylor :
>> On 03/24/2017 10:34 AM, Akira Yoshiyama wrote:
>>> Hi Monty,
>>>
>>> Thank you for your reply.
>>>
>>> 2017年3月24日(金) 20:58 Monty Taylor >> >:
>>>
>>> On 03/19/2017 07:18 AM, Akira Yoshiyama wrote:
>>> > Hi all,
>>> >
>>> > I have developed Yakumo, a pythonic unified OpenStack client
library:
>>> >
>>> >   PyPI: https://pypi.python.org/pypi/yakumo
>>> >   Git: https://github.com/yosshy/python-yakumo
>>>
>>> Nice library!
>>>
>>>
>>> Thank you :)
>>>
>>> We use it for our smoke tests.
>>>
>>> > and I found that
>>> > os_client_config.cloud_config.CloudConfig.get_session_endpoint()
>>> > didn't return Keystone admin endpoint because of below:
>>> >
>>> >
>>>
https://github.com/openstack/os-client-config/blob/master/os_client_config/cloud_config.py#L258
>>> >
>>> > Why is it so?
>>>
>>> It's done that way in os-client-config because not doing it that way
>>> breaks python-keystoneclient. Or at least it used to - looking
through
>>> the keystoneclient code it seems jamie has fixed this now.
>>>
>>>
>>> Wonderful!
>>>
>>> I'm going to nudge Morgan or Jamie to respond too - I think we
might be
>>> able to get rid of this conditional (which would make me super
happy)
>>>
>>>
>>> How about an extra option like below?
>>>
>>> def get_session_endpoint(
>>> ., allow_identity_admin=False):
>>
>> I think that's a great idea - you feel like proposing it?
>
> Yes. I'll push a patch for review soon.

Whoops - this is totally my bad. Since we spoke, Jamie Lennox and I
looked at the code and believe that this
https://review.openstack.org/#/c/450259/ is what the code should be
doing. I totally forgot to come back and follow up to this thread. So
your patch is great and exactly what we talked about - but I think we
can just go ahead and fix the behavior and not need a new option.

What do you think? (also, again, sorry for forgetting to follow up)


450259 looks very good; simple and ideal. But I'm afraid of backward
compatibility. We may have to add a version condition to os-client-config
in requirements of old versions of python modules, e.g. python-keystoneauth.

Again, 450259 is ideal. It's ok to abandon 450500.

Regards,
Akira



__
OpenStack Development Mailing 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] Log collection of overcloud nodes

[Alex Schultz]

Hey folks,

So as part of the capture-environment-status-and-logs blueprint[0],
I'm working on adding a single command to perform status and log
collection of the overcloud nodes via the tripleoclient that can be
used on the undercloud.  I would like to bring up switching over to
this as part of our CI log collection activities as many of the
relevant logs we want are already captured via the sosreport tool.
Additionally this is the way many operators are collecting and
reporting their logs when submitting issues.

I think this would benefit us to switch as sosreports also capture
additional status of the services at the time of  the report and we
can improve sosreports via plugins to help diagnose frequent service
related problems.  I believe we're duplicating some of the items
already covered via sosreport in tripleo-quickstart-extras[1] and I
think it would be beneficial to not continue to duplicate this work
but rather use already available tooling.  For CI once we have these
sosreport bundles, it would be fairly straight forward to only extract
relevant information for debugging use.

If you have some time, please review the outstanding reviews[2] and
provide concerns around possibly switching over to relying on
sosreport for our log collection.

Thanks,
-Alex

[0] 
https://blueprints.launchpad.net/tripleo/+spec/capture-environment-status-and-logs
[1] 
https://github.com/openstack/tripleo-quickstart-extras/tree/31dd4b5756b8811a9e2cb9aa0aad81bcceacd653/roles/collect-logs
[2] 
https://review.openstack.org/#/q/topic:bp/capture-environment-status-and-logs

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

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

[Rob Cresswell]

Frankly, it sounds like we can pretty comfortably drop support for nova-net in 
Pike. I'm fine with that, from a Horizon point of view.

Rob

On 28 March 2017 at 21:06, Matt Riedemann 
> wrote:
On 3/28/2017 9:04 AM, Akihiro Motoki wrote:
> Hi,
>
> I would like to raise a topic when horizon nova-network support can be 
> dropped.
> I added [tc] tag as it is related to
> "assert:follows-standard-deprecation" tag in the governance.
>
> Can horizon drop nova-network support based on the deprecation of nova-network
> from the nova team?
> or does horizon need to deprecate nova-network support in horizon explicitly?
>
> Let me summarize the current situation:
> - nova team deprecated nova-network in Newton release. [1]
> - horizon team has not deprecated it so far (just forgot to do it).
> - nova-network security group and floating IP support has been dropped
> from novaclient few days ago [2].
> - When a new release of novaclient comes, horizon security group
> support will be broken (if neutron is not used)
> - Nova microversion also allows to use nova-network but old version of
> novaclient is required for horizon to
>   support it and it is not realistic.

This is the tricky part. You can specify a microversion to use
novaclient with the nova-network behavior. If you're using the python
API bindings in novaclient, which I think Horizon is, then you have to
specify a microversion anyway. The nova-network API bindings in
novaclient will work up until 2.35.

The messy part about this is when we release novaclient 8.0 then that
code is gone and microversions don't matter. So you'd have to use an
older version, 7.1.0 at this point. To do that, we have to essentially
cap novaclient to 7.1.0 in upper-constraints in the requirements repo
for the rest of Pike since Horizon won't work with 8.0.

I don't want to cap novaclient in upper-constraints for the rest of
Pike, but at the same time, it's not great to just drop features out of
a UI without first telling users they are deprecated first. However,
having said that, isn't Horizon really the portal for the tenant user? I
know admins use it also, but the admin/operator should already know
about the nova-network deprecation. If they are just finding out about
this because their Horizon features all of a sudden don't work in Pike,
that's pretty bad on their part, in my opinion anyway. In this
perspective, I think it might be OK to drop nova-network support without
a deprecation period in Horizon for the things we've removed from
novaclient.

>
> It would be nice that horizon team is allowed to drop some feature
> aligning with feature deprecation
> and drop in backend project(s) (without explicit deprecation notices
> in horizon side).
>
> It is not easy that horizon team is aware of all feature deprecations
> in other projects
> and the horizon team tends to be aware of them when the deprecated features 
> are
> actually dropped.
>
> Thought?
>
> There may be things and solutions I am not aware of. Any feedback
> would be appreciated.

Me too. :)

>
> Best Regards,
> Akihiro
>
> [1] https://docs.openstack.org/releasenotes/nova/newton.html#deprecation-notes
> [2] https://review.openstack.org/#/c/447707/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


--

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] [tripleo] rh1 issues post-mortem

[Ben Nemec]

Final (hopefully) update:

All active compute nodes have been rebooted and things seem to be stable 
again.  Jobs are even running a little faster, so I'm thinking this had 
a detrimental effect on performance too.  I've set a reminder for about 
two months from now to reboot again if we're still using this environment.


On 03/24/2017 12:48 PM, Ben Nemec wrote:

To follow-up on this, we've continued to hit this issue on other compute
nodes.  Not surprising, of course.  They've all been up for about the
same period of time and have had largely even workloads.

It has caused problems though because it is cropping up faster than I
can respond (it takes a few hours to cycle all the instances off a
compute node, and I need to sleep sometime :-), so I've started
pre-emptively rebooting compute nodes to get ahead of it.  Hopefully
I'll be able to get all of the potentially broken nodes at least
disabled by the end of the day so we'll have another 3 months before we
have to worry about this again.

On 03/24/2017 11:47 AM, Derek Higgins wrote:

On 22 March 2017 at 22:36, Ben Nemec  wrote:

Hi all (owl?),

You may have missed it in all the ci excitement the past couple of
days, but
we had a partial outage of rh1 last night.  It turns out the OVS port
issue
Derek discussed in
http://lists.openstack.org/pipermail/openstack-dev/2016-December/109182.html

reared its ugly head on a few of our compute nodes, which caused them
to be
unable to spawn new instances.  They kept getting scheduled since it
looked
like they were underutilized, which caused most of our testenvs to fail.

I've rebooted the affected nodes, as well as a few more that looked like
they might run into the same problem in the near future.  Everything
looks
to be working well again since sometime this morning (when I disabled
the
broken compute nodes), but there aren't many jobs passing due to the
plethora of other issues we're hitting in ci.  There have been some
stable
job passes though so I believe things are working again.

As far as preventing this in the future, the right thing to do would
probably be to move to a later release of OpenStack (either point or
major)
where hopefully this problem would be fixed.  However, I'm hesitant
to do
that for a few reasons.  First is "the devil you know". Outside of this
issue, we've gotten rh1 pretty rock solid lately.  It's been
overworked, but
has been cranking away for months with no major cloud-related outages.
Second is that an upgrade would be a major process, probably
involving some
amount of downtime.  Since the long-term plan is to move everything
to RDO
cloud I'm not sure that's the best use of our time at this point.


+1 on keeping the status quo until moving to rdo-cloud.



Instead, my plan for the near term is to keep a closer eye on the error
notifications from the services.  We previously haven't had anything
consuming those, but I've dropped a little tool on the controller
that will
dump out error notifications so we can watch for signs of this happening
again.  I suspect the signs were there long before the actual breakage
happened, but nobody was looking for them.  Now I will be.

So that's where things stand with rh1.  Any comments or concerns
welcome.

Thanks.

-Ben

__

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


__

OpenStack Development Mailing 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] [ptls] Project On-Boarding Rooms

[Kendall Nelson]

Done! Zaqar is on the list

- Kendall

On Tue, Mar 28, 2017 at 4:17 PM Fei Long Wang 
wrote:

> Hi Kendall,
>
> Yep， if you can help reserve a lunch slot, it would be great. Thanks.
>
>
>
> On 28/03/17 05:36, Kendall Nelson wrote:
>
> Hello :)
>
> At this point we have a full list, but if you are interested in a lunch
> slot I can put Zaqar down for one of those unless some other project is
> willing to share their space/time?
>
> Thanks for the interest!
>
> -Kendall Nelson(diablo_rojo)
>
> On Tue, Mar 21, 2017 at 4:50 PM Fei Long Wang 
> wrote:
>
> As far as I know, most of Zaqar team members won't be in Boston. But I
> will be there, so pls help put Zaqar on the list if there is one available.
> Thanks.
>
> On 16/03/17 07:20, Kendall Nelson wrote:
>
> Hello All!
>
> As you may have seen in a previous thread [1] the Forum will offer project
> on-boarding rooms! This idea is that these rooms will provide a place for
> new contributors to a given project to find out more about the project,
> people, and code base. The slots will be spread out throughout the whole
> Summit and will be 90 min long.
>
> We have a very limited slots available for interested projects so it will
> be a first come first served process. Let me know if you are interested and
> I will reserve a slot for you if there are spots left.
>
> - Kendall Nelson (diablo_rojo)
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.html
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246 <+64%204-803%202246>
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> --
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246 <+64%204-803%202246>
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> --
>
>
__
OpenStack Development Mailing 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] [deployment][TripleO][kolla][ansible][fuel] Next steps for cross project collaboration

[Ben Nemec]

On 03/02/2017 08:27 PM, Emilien Macchi wrote:

On Mon, Feb 27, 2017 at 11:20 AM, Emilien Macchi  wrote:

On Mon, Feb 27, 2017 at 11:02 AM, Steven Hardy  wrote:

Hi all,

Over the recent PTG, and previously at the design summit in Barcelona,
we've had some productive cross-project discussions amongst the various
deployment teams.

It's clear that we share many common problems, such as patterns for major
version upgrades (even if the workflow isn't identical we've all duplicated
effort e.g around basic nova upgrade workflow recently), container images
and other common building blocks for configuration management.

Here's a non-exhaustive list of sessions where we had some good
cross-project discussion, and agreed a number of common problems where
collaboration may be possible:

https://etherpad.openstack.org/p/ansible-config-mgt


first action: EmilienM + bnemec to write a spec in oslo.config that
aims to generate a file (YAML or JSON) with all parameters.


done (thanks Ben): https://review.openstack.org/#/c/440835

Please review it and give any feedback.


Spec is merged, rough initial implementation is at 
https://review.openstack.org/451081


There are a couple of issues noted in the commit message, at least one 
of which I would like to get more input on before proceeding.  If you're 
interested in this work please leave feedback.


Thanks.

-Ben

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

[openstack-dev] [keystone] [all] [tc] OpenStack mission review request

[Lance Bragstad]

The TC meeting today [0] had some discussion on an interpretation of
OpenStack's mission statement [1]. The purpose of this note is two-fold.
First, it would be great to get some keystone folks to review that change,
especially paragraph four. Second, is an overall request for any last
minute comments, concerns, or reservations about the mission statement as a
whole.

Out goal is to go into the TC meeting next week with enough feedback to
either continue revising the mission statement or accept it.

Thanks and happy Tuesday!


[0]
http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-03-28-20.01.log.html#l-341
[1] https://review.openstack.org/#/c/447031/
__
OpenStack Development Mailing 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] [ptls] Project On-Boarding Rooms

[Fei Long Wang]

Hi Kendall,

Yep， if you can help reserve a lunch slot, it would be great. Thanks.


On 28/03/17 05:36, Kendall Nelson wrote:
> Hello :)
>
> At this point we have a full list, but if you are interested in a
> lunch slot I can put Zaqar down for one of those unless some other
> project is willing to share their space/time?
>
> Thanks for the interest!
>
> -Kendall Nelson(diablo_rojo)
>
> On Tue, Mar 21, 2017 at 4:50 PM Fei Long Wang  > wrote:
>
> As far as I know, most of Zaqar team members won't be in Boston.
> But I will be there, so pls help put Zaqar on the list if there is
> one available. Thanks.
>
>
> On 16/03/17 07:20, Kendall Nelson wrote:
>> Hello All!
>>
>> As you may have seen in a previous thread [1] the Forum will
>> offer project on-boarding rooms! This idea is that these rooms
>> will provide a place for new contributors to a given project to
>> find out more about the project, people, and code base. The slots
>> will be spread out throughout the whole Summit and will be 90 min
>> long.
>>
>> We have a very limited slots available for interested projects so
>> it will be a first come first served process. Let me know if you
>> are interested and I will reserve a slot for you if there are
>> spots left.
>>
>> - Kendall Nelson (diablo_rojo)
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.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
>
> -- 
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246 
> Email: flw...@catalyst.net.nz 
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> 
> -- 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 

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

Re: [openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

[Matt Riedemann]

On 3/28/2017 9:04 AM, Akihiro Motoki wrote:

Hi,

I would like to raise a topic when horizon nova-network support can be dropped.
I added [tc] tag as it is related to
"assert:follows-standard-deprecation" tag in the governance.

Can horizon drop nova-network support based on the deprecation of nova-network
from the nova team?
or does horizon need to deprecate nova-network support in horizon explicitly?

Let me summarize the current situation:
- nova team deprecated nova-network in Newton release. [1]
- horizon team has not deprecated it so far (just forgot to do it).
- nova-network security group and floating IP support has been dropped
from novaclient few days ago [2].
- When a new release of novaclient comes, horizon security group
support will be broken (if neutron is not used)
- Nova microversion also allows to use nova-network but old version of
novaclient is required for horizon to
  support it and it is not realistic.


This is the tricky part. You can specify a microversion to use 
novaclient with the nova-network behavior. If you're using the python 
API bindings in novaclient, which I think Horizon is, then you have to 
specify a microversion anyway. The nova-network API bindings in 
novaclient will work up until 2.35.


The messy part about this is when we release novaclient 8.0 then that 
code is gone and microversions don't matter. So you'd have to use an 
older version, 7.1.0 at this point. To do that, we have to essentially 
cap novaclient to 7.1.0 in upper-constraints in the requirements repo 
for the rest of Pike since Horizon won't work with 8.0.


I don't want to cap novaclient in upper-constraints for the rest of 
Pike, but at the same time, it's not great to just drop features out of 
a UI without first telling users they are deprecated first. However, 
having said that, isn't Horizon really the portal for the tenant user? I 
know admins use it also, but the admin/operator should already know 
about the nova-network deprecation. If they are just finding out about 
this because their Horizon features all of a sudden don't work in Pike, 
that's pretty bad on their part, in my opinion anyway. In this 
perspective, I think it might be OK to drop nova-network support without 
a deprecation period in Horizon for the things we've removed from 
novaclient.




It would be nice that horizon team is allowed to drop some feature
aligning with feature deprecation
and drop in backend project(s) (without explicit deprecation notices
in horizon side).

It is not easy that horizon team is aware of all feature deprecations
in other projects
and the horizon team tends to be aware of them when the deprecated features are
actually dropped.

Thought?

There may be things and solutions I am not aware of. Any feedback
would be appreciated.


Me too. :)



Best Regards,
Akihiro

[1] https://docs.openstack.org/releasenotes/nova/newton.html#deprecation-notes
[2] https://review.openstack.org/#/c/447707/

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




--

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] [kolla] Deployment Guide Documentation for kolla-kubernetes

[Andreas Jaeger]

On 03/28/2017 04:51 PM,  Steven Dake (stdake)  wrote:

Hey folks,



The deployment guide is shaping up nicely here:

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



If folks are interested giving the review a try:



git clone http://github.com/openstack/kolla-kubernetes

git fetch git://git.openstack.org/openstack/kolla-kubernetes
refs/changes/56/447356/10 && git cherry-pick FETCH_HEAD

cd kolla-kubernetes

tox –e docs



Then open the docs in your web browser by opening
kolla-kubernets/doc/build/html/index.html.



Note that fetch command will only work for the 10^th iteration of the
patch, whereas there may be a new rev in the review.


git review -d 4473456 is much easier than the git fetch line above and 
will give you the latest version,


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] [TripleO] spec-lite process for tripleo

[Emilien Macchi]

Bringing an old topic on the table.

We might have noticed:

1. Some tripleo-specs take huge amount of time before getting merged
(or even reviewed). We have been asking folks to review them every
week but unfortunately they don't get much attraction (# of core
reviewers versus # of folks actually reviewing specs).
2. Some folks spend a lot of time writing TripleO specs and wait for
feedback before starting some implementation (like proof of concept).

Because TripleO like innovation and also moving fast, I think it's
time to bring the tripleo-specs topic on the table:

1. If you have an idea, don't feel obliged to write a specs. Create a
blueprint on launchpad, announce it on the ML and start writing code
(can be real implementation or just a simple PoC). Feedback will be
given in the classic code review.
2. If you still want to write a spec, please make it readable and
communicate about it. If your spec is 900 lines long and not announced
anywhere, there is an high change that it will never been reviewed.
3. If you still want to write a spec, please don't stop your work
after the specs. Please engage some PoC and prototypes to get feedback
directly on the implementation.

I think these proposals are realistic with the regard of how TripleO
project works now.
Please bring any feedback or question.

Thanks,

On Fri, Jan 29, 2016 at 3:26 AM, Dougal Matthews  wrote:
>
>
> On 27 January 2016 at 16:21, Derek Higgins  wrote:
>>
>> Hi All,
>>
>> We briefly discussed feature tracking in this weeks tripleo meeting. I
>> would like to provide a way for downstream consumers (and ourselves) to
>> track new features as they get implemented. The main things that came out of
>> the discussion is that people liked the spec-lite process that the glance
>> team are using.
>>
>> I'm proposing we would start to use the same process, essentially small
>> features that don't warrant a blueprint would instead have a wishlist bug
>> opened against them and get marked with the spec-lite tag. This bug could
>> then be referenced in the commit messages. For larger features blueprints
>> can still be used. I think the process documented by glance[1] is a good
>> model to follow so go read that and see what you think
>>
>> The general feeling at the meeting was +1 to doing this[2] so I hope we
>> can soon start enforcing it, assuming people are still happy to proceed?
>
>
> +1 sounds good.
>
>>
>>
>> thanks,
>> Derek.
>>
>> [1]
>> http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite
>> [2]
>> http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01-26-14.02.log.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
>
>
>
> __
> OpenStack Development Mailing 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

[openstack-dev] [horizon][nova][tc] nova-network deprecation in horizon

[Akihiro Motoki]

Hi,

I would like to raise a topic when horizon nova-network support can be dropped.
I added [tc] tag as it is related to
"assert:follows-standard-deprecation" tag in the governance.

Can horizon drop nova-network support based on the deprecation of nova-network
from the nova team?
or does horizon need to deprecate nova-network support in horizon explicitly?

Let me summarize the current situation:
- nova team deprecated nova-network in Newton release. [1]
- horizon team has not deprecated it so far (just forgot to do it).
- nova-network security group and floating IP support has been dropped
from novaclient few days ago [2].
- When a new release of novaclient comes, horizon security group
support will be broken (if neutron is not used)
- Nova microversion also allows to use nova-network but old version of
novaclient is required for horizon to
  support it and it is not realistic.

It would be nice that horizon team is allowed to drop some feature
aligning with feature deprecation
and drop in backend project(s) (without explicit deprecation notices
in horizon side).

It is not easy that horizon team is aware of all feature deprecations
in other projects
and the horizon team tends to be aware of them when the deprecated features are
actually dropped.

Thought?

There may be things and solutions I am not aware of. Any feedback
would be appreciated.

Best Regards,
Akihiro

[1] https://docs.openstack.org/releasenotes/nova/newton.html#deprecation-notes
[2] https://review.openstack.org/#/c/447707/

__
OpenStack Development Mailing 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] Deployment Guide Documentation for kolla-kubernetes

[Steven Dake (stdake)]

Hey folks,

The deployment guide is shaping up nicely here:
https://review.openstack.org/#/c/447356/

If folks are interested giving the review a try:

git clone http://github.com/openstack/kolla-kubernetes
git fetch git://git.openstack.org/openstack/kolla-kubernetes 
refs/changes/56/447356/10 && git cherry-pick FETCH_HEAD
cd kolla-kubernetes
tox –e docs

Then open the docs in your web browser by opening 
kolla-kubernets/doc/build/html/index.html.

Note that fetch command will only work for the 10th iteration of the patch, 
whereas there may be a new rev in the review.

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] Project Navigator Updates - Feedback Request

[Jay S Bryant]

Lauren,

I am taking a look at the Cinder page.  All-in-all this looks nice.  
Couple of thoughts/questions:


 * The install guide doesn't go to the guide for Cinder, just to the
   docs.openstack.org website.  Is that intentional?
 * The "Find this service in the Marketplace" goes off to the devbranch
   right now and requires authentication.
 * I like the Most Active contributors section.  Would it be possible
   to get the names in the same format ( ) and
   possibly include the IRC nick?  I am guessing you are getting
   different formats due to the way it is queried.  If you can't fix
   that, at least associating it with the IRC nick would be good.

Let me know if you have any questions.  Looks like a good thing for 
OpenStack to have.


Thanks!

Jay




On 3/24/2017 11:57 AM, Lauren Sell wrote:

Hi everyone,

We’ve been talking for some time about updating the project navigator, 
and we have a draft ready to share for community feedback before we 
launch and publicize it. One of the big goals coming out of the joint 
TC/UC/Board meeting a few weeks ago[1] was to help better communicate 
‘what is openstack?’ and this is one step in that direction.


A few goals in mind for the redesign:
- Represent all official, user-facing projects and deployment services 
in the navigator
- Better categorize the projects by function in a way that makes sense 
to prospective users (this may evolve over time as we work on mapping 
the OpenStack landscape)

- Help users understand which projects are mature and stable vs emerging
- Highlight popular project sets and sample configurations based on 
different use cases to help users get started


For a bit of context, we’re working to give each OpenStack official 
project a stronger platform as we think of OpenStack as a framework of 
composable infrastructure services that can be used individually or 
together as a powerful system. This includes the project mascots (so 
we in effect have logos to promote each component separately), updates 
to the project navigator, and bringing back the “project updates” 
track at the Summit to give each PTL/core team a chance to provide an 
update on their project roadmap (to be recorded and promoted in the 
project navigator among other places!).


We want your feedback on the project navigator v2 before it launches. 
Please take a look at the current version on the staging site and 
provide feedback on this thread.


http://devbranch.openstack.org/software/project-navigator/

Please review the overall concept and the data and description for 
your project specifically. The data is primarily pulled from TC 
tags[2] and Ops tags[3]. You’ll notice some projects have more 
information available than others for various reasons. That’s one 
reason we decided to downplay the maturity metric for now and the data 
on some pages is hidden. If you think your project is missing data, 
please check out the repositories and submit changes or again respond 
to this thread.


Also know this will continue to evolve and we are open to feedback. As 
I mentioned, a team that formed at the joint strategy session a few 
weeks ago is tackling how we map OpenStack projects, which may be 
reflected in the categories. And I suspect we’ll continue to build out 
additional tags and better data sources to be incorporated.


Thanks for your feedback and help.

Best,
Lauren

[1] 
http://superuser.openstack.org/articles/community-leadership-charts-course-openstack/

[2] https://governance.openstack.org/tc/reference/tags/
[3] https://wiki.openstack.org/wiki/Operations/Tags



__
OpenStack Development Mailing 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] [os-client-config] get_session_endpoint() and Keystone admin endpoint

[Monty Taylor]

On 03/26/2017 02:55 AM, Akira Yoshiyama wrote:
> Hi,
> 
> 2017-03-25 4:54 GMT+09:00 Monty Taylor :
>> On 03/24/2017 10:34 AM, Akira Yoshiyama wrote:
>>> Hi Monty,
>>>
>>> Thank you for your reply.
>>>
>>> 2017年3月24日(金) 20:58 Monty Taylor >> >:
>>>
>>> On 03/19/2017 07:18 AM, Akira Yoshiyama wrote:
>>> > Hi all,
>>> >
>>> > I have developed Yakumo, a pythonic unified OpenStack client library:
>>> >
>>> >   PyPI: https://pypi.python.org/pypi/yakumo
>>> >   Git: https://github.com/yosshy/python-yakumo
>>>
>>> Nice library!
>>>
>>>
>>> Thank you :)
>>>
>>> We use it for our smoke tests.
>>>
>>> > and I found that
>>> > os_client_config.cloud_config.CloudConfig.get_session_endpoint()
>>> > didn't return Keystone admin endpoint because of below:
>>> >
>>> >
>>>  
>>> https://github.com/openstack/os-client-config/blob/master/os_client_config/cloud_config.py#L258
>>> >
>>> > Why is it so?
>>>
>>> It's done that way in os-client-config because not doing it that way
>>> breaks python-keystoneclient. Or at least it used to - looking through
>>> the keystoneclient code it seems jamie has fixed this now.
>>>
>>>
>>> Wonderful!
>>>
>>> I'm going to nudge Morgan or Jamie to respond too - I think we might be
>>> able to get rid of this conditional (which would make me super happy)
>>>
>>>
>>> How about an extra option like below?
>>>
>>> def get_session_endpoint(
>>> ., allow_identity_admin=False):
>>
>> I think that's a great idea - you feel like proposing it?
> 
> Yes. I'll push a patch for review soon.

Whoops - this is totally my bad. Since we spoke, Jamie Lennox and I
looked at the code and believe that this
https://review.openstack.org/#/c/450259/ is what the code should be
doing. I totally forgot to come back and follow up to this thread. So
your patch is great and exactly what we talked about - but I think we
can just go ahead and fix the behavior and not need a new option.

What do you think? (also, again, sorry for forgetting to follow up)


__
OpenStack Development Mailing 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] [neutron] What the behavior of AddFixedIp API should be?

[Matt Riedemann]

On 3/27/2017 11:42 PM, Rui Chen wrote:

Thank you Matt, the background information is important. Seems all the
peoples don't know how the add-fixed-ip API works,
and there is no exact use case about it. Now neutron port-update API
also support to set multiple fixed ip for a port, and
the fixed-ip updating will sync to nova side automatically (I had
verified it in my latest devstack). Updating fixed-ip for
specified port is easier to understand for me in multiple nics case than
nova add-fixed-ip API.

So if others known the orignal API design or had used nova add/remove
fixed-ip API and would like to show your use cases,
it's nice for us to understand how the API works and when we should use
it, we can update the api-ref and add exact usage,
avoid users' confusion about it. Feel free to reply something, thank you.



If the functionality is available via Neutron APIs, we should just 
deprecate the multinic API like we did for the other network API proxies 
in microversion 2.36. This reminds me that Alex Xu had a blueprint for 
deprecating the multinic API [1] but it needs to be updated for Pike.


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

--

Thanks,

Matt

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

Re: [openstack-dev] OpenStack Bug Smash for Pike Release

[Sean McGinnis]

I can say from my experience being involved in the last event that these
can be very productive. It was great seeing a room full of devs just
focused on getting bugs fixed!

I highly encourage anyone interested to attend. I would also recommend
cores for each project to pay some attention to getting these reviewed.
It can be a great way to build up momentum and really get a lot fixed in
a short amount of time.

Sean

On Tue, Mar 28, 2017 at 07:15:02AM +, Liyongle (Fred) wrote:
> Hi all,
> 
> We are planning to have the Bug Smash for Pike release from Wednesday to 
> Friday, May 17 to 19 in Suzhou, China. 
> After considering summit Boston (May 8 to 11) and Pike-2 milestone (Jun 5 to 
> 9), we finalized the schedule.
> 
> Bug Smash China will probably cover Nova, Neutron, Cinder, Keystone, Manila, 
> Heat, Telemetry, Karbor, Tricircle, which finally depends on the attendees.
> 
> If you want to set up bug smash in your city, please share the information at 
> [1]. 
> If you are planning to join the 6th Bug Smash in China, please register at 
> [2]. 
> 
> [1] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Pike
> [2] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Pike-Suzhou
> 
> Fred (李永乐)
> 
> 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
> 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
> 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from HUAWEI, 
> which 
> is intended only for the person or entity whose address is listed above. Any 
> use of the 
> information contained herein in any way (including, but not limited to, total 
> or partial 
> disclosure, reproduction, or dissemination) by persons other than the 
> intended 
> recipient(s) is prohibited. If you receive this e-mail in error, please 
> notify the sender by 
> phone or email immediately and delete it!
> 
> __
> OpenStack Development Mailing 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] [OpenStack-docs] Project Navigator Updates - Feedback Request

[Alexandra Settle]

On 3/28/17, 2:10 PM, "Jeremy Stanley"  wrote:

On 2017-03-28 12:51:44 + (+), Alexandra Settle wrote:
[...]
> Is it possible to get docs and I18N represented here? I know we
> don’t make up a ‘project’ of OpenStack, but we play an important
> part, and I would be nice to be represented. Especially seeing as
> I18n work on translating a lot of the dev components as well,
> making OpenStack available to more countries across the world.
[...]

My understanding is that the Project Navigator is aimed at helping
operators/deployers figure out what software they should be
downloading and running, not as a place to celebrate the awesome
work in which all our official teams participate. If we add separate
sections for Docs and I18n, then do we also include Release
Management, Stable Branch Maintenance, Quality Assurance,
Requirements, et cetera? At what point does it just become yet
another copy of our governance site with different theming?
-- 
Jeremy Stanley

Makes sense, that’s good perspective :)

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


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

Re: [openstack-dev] [Tripleo] Status of monitoring tools

[Steven Hardy]

On Tue, Mar 28, 2017 at 04:34:09PM +0530, Sanjay Upadhyay wrote:
>Hi Folks,
>I recently started work with a requirement to integrate a security tool
>with monitoring framework for alerting and logging. I fail to  find
>relevant docs in this direction. After looking around for more
>information, it seems we do not have the server side implementation at
>all. 
>I have created a bug for
>this https://bugs.launchpad.net/tripleo/+bug/1676407. IMO,
>architecturally we have no place for opstools in the tripleo deployment,
>yet. 

I think we are mixing two different problems here - one is the current
composable services integration for fluentd and sensu isn't documented, we
should fix that.

>Ideally, there could be a role like MonServer, which can be a specific
>role for all the monitoring services (server side). If one wants to reduce
>the no of nodes can probably have all the monitoring services on the
>controller node. 

This is a different problem, and IIRC we agreed that only client side
support for monitoring tools was in-scope for TripleO.  The expectation is
that folks will stand up a separate logging/monitoring environment, or that
they will have existing servers to integrate with.

There have been discussions around how to deploy such services, and AFAIK
the suggestion is to use this ansible solution:

https://github.com/centos-opstools/opstools-ansible

AFAIK there is no plan to deploy these tools via TripleO (and IMO that's
correct, we don't really want to duplicate efforts here).

Thanks!

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] [TripleO] How to Preview the Overcloud Stack?

[Steven Hardy]

On Mon, Mar 27, 2017 at 01:43:39PM -0700, Dan Sneddon wrote:
> I've been trying to figure out a workflow for previewing the results of
> importing custom templates in an overcloud deployment (without actually
> deploying). For instance, I am overriding some parameters using custom
> templates, and I want to make sure those parameters will be expressed
> correctly when I deploy.
> 
> I know about "heat stack-preview", but between the complexity of the
> overcloud stack and the jinja2 template processing, I can't figure out a
> way to preview the entire overcloud stack.
> 
> Is this possible? If not, any hints on what would it take to write a
> script that would accomplish this?

Yes this is possible, but when I tested it I ran into this bug:

https://bugs.launchpad.net/heat/+bug/1676823

Which it seems from IRC discussion may be a duplicate of:

https://bugs.launchpad.net/heat/+bug/1669571

I'll re-test later with the patch proposed applied, but the basic steps
are:

1. Get a rendered copy of the tripleo-heat-templates

There are two ways to do this, either run ./tools/process-templates.py
in a local t-h-t tree, or create a plan (either via openstack overcloud
plan create, or openstack overcloud plan deploy --update-plan-only).

If you do this via creating a plan you can download the rendered files from
swift, e.g mkdir tmp-tht; cd tmp-tht; swift download overcloud

2. Run the stack preview

To do this, you need to generate an environment file with all the passwords
normally created by tripleo-common.  The easiest way to do it is to look
at an existing deployment and run "mistral environment-get overcloud", then
copy/paste and sed an environment like: http://paste.openstack.org/show/604475/

Then you just run the preview like:

openstack stack create test --dry-run -t overcloud.yaml -e 
overcloud-resource-registry-puppet.yaml -e dummy_passwords.yaml

This will break due to the bug above, but in the past it's worked fine for
me, and as mentioned by Saravanan it's also possible to do a template
validate:

openstack orchestration template validate --show-nested -t overcloud.yaml -e 
overcloud-resource-registry-puppet.yaml -e dummy_passwords.yaml

Hopefully we can confirm the heat bugfix later then you'll be able to use
one of the above to do what you need.

Thanks,

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] [OpenStack-docs] Project Navigator Updates - Feedback Request

[Jeremy Stanley]

On 2017-03-28 12:51:44 + (+), Alexandra Settle wrote:
[...]
> Is it possible to get docs and I18N represented here? I know we
> don’t make up a ‘project’ of OpenStack, but we play an important
> part, and I would be nice to be represented. Especially seeing as
> I18n work on translating a lot of the dev components as well,
> making OpenStack available to more countries across the world.
[...]

My understanding is that the Project Navigator is aimed at helping
operators/deployers figure out what software they should be
downloading and running, not as a place to celebrate the awesome
work in which all our official teams participate. If we add separate
sections for Docs and I18n, then do we also include Release
Management, Stable Branch Maintenance, Quality Assurance,
Requirements, et cetera? At what point does it just become yet
another copy of our governance site with different theming?
-- 
Jeremy Stanley

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

Re: [openstack-dev] Project Navigator Updates - Feedback Request

[Alexandra Settle]

Hey Lauren,

It looks great with the new mascots :)

Is it possible to get docs and I18N represented here? I know we don’t make up a 
‘project’ of OpenStack, but we play an important part, and I would be nice to 
be represented. Especially seeing as I18n work on translating a lot of the dev 
components as well, making OpenStack available to more countries across the 
world.

Maybe we could go under a simple banner “Documentation & Translation”?

I know we are technically visible here: 
https://www.openstack.org/software/start/ but we’re kind of shunted down the 
line.

Also, OpenStack-Ansible should be edited with the hyphen if possible :)

Thanks,

Alex

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

Date: Friday, March 24, 2017 at 4:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] Project Navigator Updates - Feedback Request

Hi everyone,

We’ve been talking for some time about updating the project navigator, and we 
have a draft ready to share for community feedback before we launch and 
publicize it. One of the big goals coming out of the joint TC/UC/Board meeting 
a few weeks ago[1] was to help better communicate ‘what is openstack?’ and this 
is one step in that direction.

A few goals in mind for the redesign:
- Represent all official, user-facing projects and deployment services in the 
navigator
- Better categorize the projects by function in a way that makes sense to 
prospective users (this may evolve over time as we work on mapping the 
OpenStack landscape)
- Help users understand which projects are mature and stable vs emerging
- Highlight popular project sets and sample configurations based on different 
use cases to help users get started

For a bit of context, we’re working to give each OpenStack official project a 
stronger platform as we think of OpenStack as a framework of composable 
infrastructure services that can be used individually or together as a powerful 
system. This includes the project mascots (so we in effect have logos to 
promote each component separately), updates to the project navigator, and 
bringing back the “project updates” track at the Summit to give each PTL/core 
team a chance to provide an update on their project roadmap (to be recorded and 
promoted in the project navigator among other places!).

We want your feedback on the project navigator v2 before it launches. Please 
take a look at the current version on the staging site and provide feedback on 
this thread.

http://devbranch.openstack.org/software/project-navigator/

Please review the overall concept and the data and description for your project 
specifically. The data is primarily pulled from TC tags[2] and Ops tags[3]. 
You’ll notice some projects have more information available than others for 
various reasons. That’s one reason we decided to downplay the maturity metric 
for now and the data on some pages is hidden. If you think your project is 
missing data, please check out the repositories and submit changes or again 
respond to this thread.

Also know this will continue to evolve and we are open to feedback. As I 
mentioned, a team that formed at the joint strategy session a few weeks ago is 
tackling how we map OpenStack projects, which may be reflected in the 
categories. And I suspect we’ll continue to build out additional tags and 
better data sources to be incorporated.

Thanks for your feedback and help.

Best,
Lauren

[1] 
http://superuser.openstack.org/articles/community-leadership-charts-course-openstack/
[2] https://governance.openstack.org/tc/reference/tags/
[3] https://wiki.openstack.org/wiki/Operations/Tags

__
OpenStack Development Mailing 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] Status of monitoring tools

[Emilien Macchi]

On Tue, Mar 28, 2017 at 7:04 AM, Sanjay Upadhyay  wrote:
> Hi Folks,
>
> I recently started work with a requirement to integrate a security tool with
> monitoring framework for alerting and logging. I fail to  find relevant docs
> in this direction. After looking around for more information, it seems we do
> not have the server side implementation at all.
>
> I have created a bug for this
> https://bugs.launchpad.net/tripleo/+bug/1676407. IMO, architecturally we
> have no place for opstools in the tripleo deployment, yet.

I see a perfect fit for using the future TripleO Deployment guide that
we are starting:
https://review.openstack.org/#/c/449684/

We're going to move the content from tripleo-docs/doc/source/ (only
bits for deployments), so you could start from there and push the bits
in the deploy/ foler.

What do you think?

> Ideally, there could be a role like MonServer, which can be a specific role
> for all the monitoring services (server side). If one wants to reduce the no
> of nodes can probably have all the monitoring services on the controller
> node.

Wait, the monitoring server isn't managed by TripleO right? So you
want to document how to deploy OpsTools applications (server side) in
TripleO Doc?
Please correct me if I'm wrong.

> I am still looking at directions on monitoring services.
> regards
> /sanjay
>
> __
> OpenStack Development Mailing 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] [TripleO] How to Preview the Overcloud Stack?

[Saravanan KR]

It is possible to perform a stack validate after jinja2 processing.
There is already an action existing [1] do it and get the results. But
the results are not easy to consume, so it required to flatten the
heat resource tree and parameters. This has been done already in UI,
and i have added a patch for doing it in tripleo-common [2]. The
output of this flattening will look like [3][4].

I am not sure if this is what you are expecting.

Regards,
Saravanan KR

[1] 
https://github.com/openstack/tripleo-common/blob/master/tripleo_common/actions/parameters.py#L71
[2] https://review.openstack.org/#/c/450021/
[3] http://paste.openstack.org/show/600292/
[4] http://paste.openstack.org/show/600293/

On Tue, Mar 28, 2017 at 2:13 AM, Dan Sneddon  wrote:
> I've been trying to figure out a workflow for previewing the results of
> importing custom templates in an overcloud deployment (without actually
> deploying). For instance, I am overriding some parameters using custom
> templates, and I want to make sure those parameters will be expressed
> correctly when I deploy.
>
> I know about "heat stack-preview", but between the complexity of the
> overcloud stack and the jinja2 template processing, I can't figure out a
> way to preview the entire overcloud stack.
>
> Is this possible? If not, any hints on what would it take to write a
> script that would accomplish this?
>
> --
> 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

__
OpenStack Development Mailing 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] [openstack-ansible] Need a new owner for the Thursday meeting

[Major Hayden]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey folks,

My responsibilities at work are changing slightly and I need to find a new 
owner for Thursday's OpenStack-Ansible weekly meeting[0]. I'll still be working 
with OpenStack-Ansible on a regular basis, but my calendar is a disaster on 
most Thursdays. ;)

If you're new to running meetings and you want some tips on how to run a good 
meeting, please let me know.  I'll be happy to do some brief training!

Thanks!

[0] https://wiki.openstack.org/wiki/Meetings/openstack-ansible

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJY2lm3AAoJEHNwUeDBAR+xYnsQAILn4NdU3iuHq9Mb2mYmQGLA
y0t48/uf9h8LSbz1cSK70Each2qo3tFN4P59g/hgddRgL5Y+mBkCu81wL4vsxv51
JqJJiNYKPl0N420unUDumQYDZolYGHD4F33LWIY9M4b2qOujWCR+J1zJ+Tse4CHZ
J3qT+eu9SEVHQG6s8CAQOrZJpaerQjHx+p3eIxTqhwg9PBag3t5oray4ZvUXkUzs
9Ak4ymKzsLBOyYzcel9fvuA8fAUNgWDy/yYXRDR8oM/D7XV5HIIahMRUC5zMef4a
OeGo2pN/f//Oxb+paHF6cNaZyoJGlN4AQ4v7/SsS8Exj/OtoS6HNXtWvzus5JfGd
UdBFU5+lPT1nTtjrEJ/dJlT3HVY8XHHGN53vM+tU5tSg2Jjo+5VcAsyhNlvcWrPB
J9UciyEAb1yYzws7nGT5L+7Dt5hQrJRXYoSQRfkwmJsKkczrRnrLjr0UucHm4KNe
19u0kuPfbEnkWH8q2lr0tWwSNUtWlcw0iLcYEzVlDZ7WQ7II4uNbSOU5gy1G+tPZ
wguYWU+r1pyik2zSxFRzGFhlmiTIkzYRYdOiQJyqnKJIAyWFxLwgStdDb2WN53Mh
Mfb3c2VB+aGMgKK1EZhZiiowvYcido77t+Yoh7bpqt6uwi+D0cyPs1XjcuAGhZQE
oZ2MjuUNihlYL4b2InVG
=dJ5t
-END PGP SIGNATURE-

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

Re: [openstack-dev] [TripleO] Propose Attila Darazs and Gabriele Cerami for tripleo-ci core

[Emilien Macchi]

I went ahead and added you to tripleo-core Gerrit group.
Keep in mind we expect you to only use the +2 on
openstack-infra/tripleo-ci repository for now.

Thanks for your hard work!

On Tue, Mar 21, 2017 at 12:23 PM, Julie Pichon  wrote:
> On 15 March 2017 at 15:44, John Trowbridge  wrote:
>> Both Attila and Gabriele have been rockstars with the work to transition
>> tripleo-ci to run via quickstart, and both have become extremely
>> knowledgeable about how tripleo-ci works during that process. They are
>> both very capable of providing thorough and thoughtful reviews of
>> tripleo-ci patches.
>>
>> On top of this Attila has greatly increased the communication from the
>> tripleo-ci squad as the liason, with weekly summary emails of our
>> meetings to this list.
>
> +1
>
> __
> OpenStack Development Mailing 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

[openstack-dev] [Openstack-operators] [MassivelyDistributed] IRC Meeting tomorrow 15:00 UTC

[lebre . adrien]

Dear all, 

A gentle reminder for our meeting tomorrow. 
As usual, the agenda is available at: 
https://etherpad.openstack.org/p/massively_distributed_ircmeetings_2017 (line 
378)
Please feel free to add items.

Best, 
Ad_rien_

__
OpenStack Development Mailing 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] Status of monitoring tools

[Sanjay Upadhyay]

Hi Folks,

I recently started work with a requirement to integrate a security tool
with monitoring framework for alerting and logging. I fail to  find
relevant docs in this direction. After looking around for more information,
it seems we do not have the server side implementation at all.

I have created a bug for this
https://bugs.launchpad.net/tripleo/+bug/1676407. IMO, architecturally we
have no place for opstools in the tripleo deployment, yet.

Ideally, there could be a role like MonServer, which can be a specific role
for all the monitoring services (server side). If one wants to reduce the
no of nodes can probably have all the monitoring services on the controller
node.

I am still looking at directions on monitoring services.

regards
/sanjay
__
OpenStack Development Mailing 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] [monasca] Grafana "app" for Monasca

[Steve Simpson]

Hi Roland,

That's great to hear. Initially it was only an experiment to see what
could be done inside Grafana with its "app plugin" concept, but
progressed quite fast into something quite usable, so thought we'd
share it early on.

Yes I've been following the Grafana progress quite closely. So as it
happens, because of the way the plugin makes requests (via the
datasource), it takes advantage of the current Keystone fork, so will
hopefully be ready to take advantage of any future development in this
area.

To get parity with the Horizon UI (which we think is great BTW -
deploying it is just a hard sell in our environment), there's a few
things left to do at a minimum:

- Alarm history page
- "Show series" dashboard/link
- Paging/filtering/sorting options
- Better alarm definition editor

I'm sure there's plenty of UI improvements to be had too - we're not
particularly wedded to the design and would appreciate feedback. We'd
love some help getting it into shape - even if it's just tyre kicking,
bug finding, or code review/refactoring.

Cheers,
Steve

On Mon, Mar 27, 2017 at 11:59 PM, Hochmuth, Roland M
 wrote:
> Hi Steve, This is awesome. We are very interested in this work! I was just 
> talking to Grafana Labs about this.
>
> I should also mention that we are in the process of getting Keystone 
> authentication built-in to Grafana so that we don't have to maintain a 
> separate fork. I'm assuming that work will proceed, but it is contingent on a 
> contract that I'm working through. Grafana Labs needed to be involved on the 
> authentication plugin that is being added to Grafana.
>
> How much work do you believe is remaining to complete this? I would also be 
> very interested in reviewing this and helping out where I can on code. We 
> could potentially create an upstream repo in the openstack org.
>
> Regards --Roland
>
>
>
>
> On 3/27/17, 4:40 PM, "Brandt, Ryan"  wrote:
>
>>
>>
>>On 3/27/17, 10:01 AM, "Steve Simpson"  wrote:
>>
>>>Hi,
>>>
>>>We have been working on prototyping an "app" for Grafana which can be
>>>used to view/configure alarm definitions, notifications and alarms.
>>>This is still work-in-progress (insert normal disclaimer here), but is
>>>usable enough to get a feel for what we would like to achieve. We
>>>would like some feedback on whether this is something Monasca would be
>>>interested in collaborating on or adopting upstream. If so, we may be
>>>able to commit more development resource to get it polished.
>>>
>>>https://github.com/stackhpc/monasca-grafana-app
>>>
>>>In particular what spurred this was a discussion at the mid-cycle
>>>around using Monasca outside an OpenStack environment or for
>>>monitoring bare-metal. As it happens this aligns with our
>>>requirements; in the environment we will be deploying in, we will
>>>likely not be able to deploy the Horizon UI component.
>>>
>>>Cheers,
>>>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
>>
> __
> OpenStack Development Mailing 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] OpenStack Bug Smash for Pike Release

[Liyongle (Fred)]

Hi all,

We are planning to have the Bug Smash for Pike release from Wednesday to 
Friday, May 17 to 19 in Suzhou, China. 
After considering summit Boston (May 8 to 11) and Pike-2 milestone (Jun 5 to 
9), we finalized the schedule.

Bug Smash China will probably cover Nova, Neutron, Cinder, Keystone, Manila, 
Heat, Telemetry, Karbor, Tricircle, which finally depends on the attendees.

If you want to set up bug smash in your city, please share the information at 
[1]. 
If you are planning to join the 6th Bug Smash in China, please register at [2]. 

[1] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Pike
[2] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Pike-Suzhou

Fred (李永乐)

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which 
is intended only for the person or entity whose address is listed above. Any 
use of the 
information contained herein in any way (including, but not limited to, total 
or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by 
phone or email immediately and delete it!

__
OpenStack Development Mailing 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] [barbican][castellan] How to share secrets in barbican

[yanxin...@cmss.chinamobile.com]

 Hello, folks:
As i known, the secrets are saved in a user's domain, and other 
project/user can not retrieve the secrets.
   But i have a situation that many users need retrieve a same secret.

   After looking into the castellan usage,  I see the method that saving the 
credentials in configuration,
then all operators use this pre-created user to create/retrieve secrets. 
I want to know, is this way typical and easy-accepted? Does other projects face 
this issue?

Thanks.
Yan Xing'an__
OpenStack Development Mailing 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] [neutron] What the behavior of AddFixedIp API should be?

[Rui Chen]

Thank you Matt, the background information is important. Seems all the
peoples don't know how the add-fixed-ip API works,
and there is no exact use case about it. Now neutron port-update API also
support to set multiple fixed ip for a port, and
the fixed-ip updating will sync to nova side automatically (I had verified
it in my latest devstack). Updating fixed-ip for
specified port is easier to understand for me in multiple nics case than
nova add-fixed-ip API.

So if others known the orignal API design or had used nova add/remove
fixed-ip API and would like to show your use cases,
it's nice for us to understand how the API works and when we should use it,
we can update the api-ref and add exact usage,
avoid users' confusion about it. Feel free to reply something, thank you.

2017-03-27 23:36 GMT+08:00 Matt Riedemann :

> On 3/27/2017 7:23 AM, Rui Chen wrote:
>
>> Hi:
>>
>> A question about nova AddFixedIp API, nova api-ref[1] describe the
>> API as "Adds a fixed IP address to a server instance, which associates
>> that address with the server.", the argument of API is network id, so if
>> there are two or more subnets in a network, which one is lucky to
>> associate ip address to the instance? and the API behavior is always
>> consistent? I'm not sure.
>> The latest code[2] get all of the instance's ports and subnets of
>> the specified network, then loop them, but it return when the first
>> update_port success, so the API behavior depends on the order of subnet
>> and port list that return by neutron API. I have no idea about what
>> scenario we should use the API in, and the original design, anyone know
>> that?
>>
>> [1]: https://developer.openstack.org/api-ref/compute/#add-associa
>> te-fixed-ip-addfixedip-action
>> [2]: https://github.com/openstack/nova/blob/master/nova/network/n
>> eutronv2/api.py#L1366
>>
>>
>> 
>> __
>> 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
>>
>>
> I wondered about this API implementation myself awhile ago, see this bug
> report for details:
>
> https://bugs.launchpad.net/nova/+bug/1430512
>
> There was a related change for this from garyk:
>
> https://review.openstack.org/#/c/163864/
>
> But that was abandoned.
>
> I'm honestly not really sure what the direction is here. From what I
> remember when I reported that bug, this was basically a feature-parity
> implementation in the compute API for the multinic API with nova-network.
> However, I'm not sure it's very usable. There is a Tempest test for this
> API, but I think all it does is attach an interface and make sure that does
> not blow up, it does not try to use the interface to ssh into the guest,
> for example.
>
> --
>
> 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-dev] [neutron][networking-l2gw] Project update

[Gary Kotton]

Hi,
Please see below for a current update on the status of the project.

1.   stable/ocata:

a.   a tag 10.0.0 has been created

b.   code has been updated to pass unit tests (there was a breakage as it 
was pulling master neutron)

2.   master:

a.   Due to the tag above being created we created a dummy tag to ensure 
that later versions will be used

b.   Thanks to xuqihou for kicking the wheels for the log translations 
(https://review.openstack.org/#/c/447949/)

c.   There are a few other patches that need some review cycles 
(https://review.openstack.org/#/q/project:openstack/networking-l2gw)
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev