Re: [openstack-dev] [mogan][valence] Valence integration

[Zhenguo Niu]

Thanks Yang, Lin for the explanation!

The Valence flavor shows a good example for baremetal instances, we do need
such a flavor :D

I will draft a spec for this, you can help to review later. Another
question is whether the Valence client is ready to use or we need to wrap
the REST API ourselves?



On Sat, Mar 25, 2017 at 9:37 AM, Yang, Lin A  wrote:

> Hi Zhenguo,
>
>
>
> Please checkout the latest valence api spec, current it support two ways
> to specify the arguments when composing node via valence api.
>
> 1. Specify flavor for composition -  Specify flavor uuid in ‘flavor_id’
> field {flavor_id: flavor_uuid} besides the name and description fields. An
> example of request body shows as below.
>
>   {‘name’: ‘new_node’,
>
>‘description’: ‘test composition’,
>
>‘flavor_id’: ‘fake_uuid’}
>
>
>
> 2. Specify every hardware details, like cpu, memory, local/remote drive,
> nic, in ‘properties’ field.
>
>   {‘name’: ‘new_node’,
>
>‘description’: ‘test composition’,
>
>‘properties’: {‘processor’: {‘total_cores’:8,
>
> ‘model’:
> ‘fale_model’},
>
> ‘memore’: {‘capacity_mib’: 4096,
>
>   ‘type’: ‘DDR3’}}}
>
> We will update user document to list all available parameters for node
> composition soon.
>
>
>
> [0] https://github.com/openstack/valence/blob/
> 0db8a8e186e25ded2b17460f5ae2ce9abf576851/api-ref/source/
> valence-api-v1-nodes.inc
>
>
>
> Thanks,
>
> Lin.
>
> *From:* Zhenguo Niu [mailto:niu.zgli...@gmail.com]
> *Sent:* Tuesday, March 21, 2017 4:20 AM
> *To:* OpenStack Development Mailing List  openstack.org>
> *Subject:* [openstack-dev] [mogan][valence] Valence integration
>
>
>
> hi guys,
>
>
>
> Here is a spec about Mogan and Valence integration[1], but before this
> happen, I would like to know what information needed when requesting to
> compose a node through Valence. From the API doc[2], I can only find name
> and description parameters, but seems like it's incorrect, I suppose that
> it should at least include cpus, ram, disk or maybe cpuinfo. We need to
> align with this before introducing a new flavor for both RSD nodes and
> generic nodes.
>
>
>
>
>
> [1] https://review.openstack.org/#/c/441790/
>
> [2] https://github.com/openstack/valence/blob/master/
> api-ref/source/valence-api-v1-nodes.inc#request
>
>
>
> --
>
> Best Regards,
>
> Zhenguo Niu
>



-- 
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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] [requirements][keystone][glance] WebOb

[Lance Bragstad]

Following up again. Today we merged the fixes for some WebOb 1.7
compatibility issues we were having [0]. Thanks to David (dstanek) and John
(jdennis) for digging in and getting this squared away.

[0] https://review.openstack.org/#/c/422234/

On Wed, Mar 22, 2017 at 1:37 PM, Lance Bragstad  wrote:

> Posting a keystone update here as well. We are iterating on it in review
> as well as in IRC. There are a few things we're doing within keystone that
> raised some questions as to how we should handle some of the new changes in
> WebOb.
>
> I'll post another update once we make some more progress.
>
> On Wed, Mar 22, 2017 at 12:50 PM, Davanum Srinivas 
> wrote:
>
>> Thanks a ton Brian :)
>>
>> On Wed, Mar 22, 2017 at 1:40 PM, Brian Rosmaita
>>  wrote:
>> > On 3/20/17 6:54 AM, Davanum Srinivas wrote:
>> >> Dear Keystone and Glance teams,
>> >>
>> >> WebOb update of u-c to 1.7.1 is stuck for a while[1]. Can you please
>> >> prioritize reviews (keystone) review [1] and (glance) review [2] for
>> >> this week?
>> >
>> > Hi Dims, quick update on this.  We do have it prioritized, but it's been
>> > pushed back a bit as the eventlet upgrade has caused a few problems.
>> > https://review.openstack.org/#/c/448653/
>> >
>> > Not saying it won't get done this week, but not saying it will, either.
>> > Basically, just wanted you to know that we are paying attention to your
>> > emails!
>> >
>> >>
>> >> Thanks,
>> >> Dims
>> >>
>> >> [1] https://review.openstack.org/#/c/417591/
>> >> [2] https://review.openstack.org/#/c/422234/
>> >> [3] https://review.openstack.org/#/c/423366/
>> >>
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.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: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

Re: [openstack-dev] [mogan][valence] Valence integration

[Yang, Lin A]

Hi Zhenguo,

Please checkout the latest valence api spec, current it support two ways to 
specify the arguments when composing node via valence api.
1. Specify flavor for composition -  Specify flavor uuid in ‘flavor_id’ field 
{flavor_id: flavor_uuid} besides the name and description fields. An example of 
request body shows as below.
  {‘name’: ‘new_node’,
   ‘description’: ‘test composition’,
   ‘flavor_id’: ‘fake_uuid’}

2. Specify every hardware details, like cpu, memory, local/remote drive, nic, 
in ‘properties’ field.
  {‘name’: ‘new_node’,
   ‘description’: ‘test composition’,
   ‘properties’: {‘processor’: {‘total_cores’:8,
‘model’: ‘fale_model’},
‘memore’: {‘capacity_mib’: 4096,
  ‘type’: ‘DDR3’}}}
We will update user document to list all available parameters for node 
composition soon.

[0] 
https://github.com/openstack/valence/blob/0db8a8e186e25ded2b17460f5ae2ce9abf576851/api-ref/source/valence-api-v1-nodes.inc

Thanks,
Lin.
From: Zhenguo Niu [mailto:niu.zgli...@gmail.com]
Sent: Tuesday, March 21, 2017 4:20 AM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [mogan][valence] Valence integration

hi guys,

Here is a spec about Mogan and Valence integration[1], but before this happen, 
I would like to know what information needed when requesting to compose a node 
through Valence. From the API doc[2], I can only find name and description 
parameters, but seems like it's incorrect, I suppose that it should at least 
include cpus, ram, disk or maybe cpuinfo. We need to align with this before 
introducing a new flavor for both RSD nodes and generic nodes.


[1] https://review.openstack.org/#/c/441790/
[2] 
https://github.com/openstack/valence/blob/master/api-ref/source/valence-api-v1-nodes.inc#request

--
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing 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]pike-1 patch prioritization

[joehuang]

Hello,

As we discussed in last weekly meeting, pike-1 is expected to be tagged by the 
end of this month, Mar.31.

These patches are must to have in pike-1:

1. Add multi-region configuration in 
gate_hook.sh: 
https://review.openstack.org/#/c/438382/
2. Cross-pod VxLAN network spec: 
https://review.openstack.org/#/c/429155/
3. Shared VxLAN (Part4: bridge network l3) 
: https://review.openstack.org/#/c/425131/
4. Shared VxLAN (Part5: bulk create shadow 
port): 
https://review.openstack.org/#/c/444112/
5. Update doc and add release note for 
vxlan: 
https://review.openstack.org/#/c/448524/
6. Support WSGI deployment for Tricircle Admin 
API(part1): 
https://review.openstack.org/#/c/440175/

These two patches are nice to have in pike-1
1. Networking Qos service spec： 
https://review.openstack.org/#/c/417947/
2. Update 
networking-guide-single-external-network: 
https://review.openstack.org/#/c/446883/

Other patches will be merged in best effort. That is, once it was considered 
ready to merge, it can be merged, regardless it's in pike-1 or pike-2.

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

[Zane Bitter]

On 24/03/17 12:57, 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/


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.


Also this trend of not having links, just areas of the screen with 
attached JavaScript to switch to a new page when you click on them, is 
breaking the web. There are 47 things to dig into on this page. I should 
be allowed to open tabs!!!


In list view, everything 'links' (I use the term loosely) to 
http://devbranch.openstack.org/software/releases/ocata/components/undefined 
(nice 404 page btw :)


When hitting the back button after you navigate away - which you have to 
do, because you can't open in a new tab - the display always reverts to 
tiles view.


- ZB


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] [mistral] Using mistral to start a not-to-die task

[Sridhar Ramaswamy]

Renat:

Perfect. A combination of 1 and 2a would fit our needs.

One reason we are venturing toward an async workflow is to address the
scale limitation in tacker. Now, do you've some pointers how well mistral
scales (so that we don't just move our scale problem down to the mistral
dependency). Looking at the mistral architecture [*], is it safe to assume
the individual mistral components like api, engine, scheduler, executor can
be linearly scaled across different hosts ?

- Sridhar

[*] https://docs.openstack.org/developer/mistral/architecture.html

On Wed, Mar 22, 2017 at 11:22 PM, Renat Akhmerov 
wrote:

> Another option:
>
> 1. Run a workflow with a loop (i.e. task calls itself), in order to have a
> delay between task executions you can use either wait-before/wait-after
> task policies
> 2.a The workflow can be stopped via Mistral API by a 3rd party, if needed.
> 2.b The workflow can have a special task that checks if it still needs to
> be running (i.e. making a request to a 3rd party), it can be done using
> conditional transitions
>
>
> Renat Akhmerov
> @Nokia
>
> On 23 Mar 2017, at 09:40, Lingxian Kong  wrote:
>
> Yeah, as Bob said, cron-trigger is what you are looking for.
>
> As our discussion on IRC, currently, Mistral doesn't support to execute
> shell command directly, my suggestion is, you could consider using http
> action (which is supproted by Mistral out of the box) or providing a host
> (physical or virtual) to run 'ping' command and use ssh action in Mistral.
>
>
> Cheers,
> Lingxian Kong (Larry)
>
> On Thu, Mar 23, 2017 at 1:16 PM, gongys2017  wrote:
>
>> Hi mistral stackers,
>>
>> Tacker is using the mistral as its part of system. Now we have a
>> requirement:
>>
>> tacker server registers an openstack as its NFVI, and needs to ping> http-ping) the openstack's management IP,
>> for example the keystone URL until tacker updates or delete the openstack
>> NFVI.
>>
>> Can the mistral be asked to start a workflow which  contains  just such a
>> kind of task:
>> for ever running until extenal tells him to stop.
>>
>>
>> Thanks
>>
>> 
>> __
>> 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
>
>
__
OpenStack Development Mailing 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 Developer Mailing List Digest March 18-24

[Mike Perez]

SuccessBot Says
===
* Yolanda [1]: Wiki problems have been fixed, it's up and running
* johnthetubaguy [2]: First few patches adding real docs for policy have now
* merged in Nova. A much improved sample file [3].
* Tell us yours via OpenStack IRC channels with message “#success ”
* All: [4]

Release Naming for R

* It's time to pick a name for our “R” release.
* The associated summit will be in Vancouver, so the geographic location has
  been chosen as “British Colombia”.
* Rules:
  - Each release name must start with the letter of the ISO basic Latin
alphabet following the initial letter of the previous release, starting
with the initial release of "Austin". After "Z", the next name should start
with "A" again.
  - The name must be composed only of the 26 characters of the ISO basic Latin
alphabet. Names which can be transliterated into this character set are
also acceptable.
  - The name must refer to the physical or human geography of the region
encompassing the location of the OpenStack design summit for the
corresponding release. The exact boundaries of the geographic region under
consideration must be declared before the opening of nominations, as part
of the initiation of the selection process.
  - The name must be a single word with a maximum of 10 characters. Words that
describe the feature should not be included, so "Foo City" or "Foo Peak"
would both be eligible as "Foo".
* Full thread [5]

Moving Gnocchi out 
==
* The project Gnocchi which has been tagged independent since it's inception
  has potential outside of OpenStack.
* Being part of the big tent helped the project be built, but there is a belief
  that it restrains its adoption outside of OpenStack.
* The team has decided to move it out of OpenStack [6].
  - In addition out of the OpenStack infrastructure.
* Gnocchi will continue thrive and be used by OpenStack such as Ceilometer.
* Full thread [7]

POST /api-wg/news
=
* Guides under review:
  - Define pagination guidelines (recently rebooted) [8]
  - Create a new set of api stability guidelines [9]
  - Microversions: add next_min_version field in version body [10]
  - Mention max length limit information for tags [11]
  - Add API capabilities discovery guideline [12]
  - WIP: microversion architecture archival doc (very early; not yet ready for
review) [13]
* Full thread [14]

[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra.2017-03-21.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-03-21.log.html
[3] - https://docs.openstack.org/developer/nova/sample_policy.html
[4] - https://wiki.openstack.org/wiki/Successes
[5] - http://lists.openstack.org/pipermail/openstack-dev/2017-March/114436.html
[6] - https://review.openstack.org/447438
[7] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-March/thread.html#114300
[8] - https://review.openstack.org/#/c/446716/
[9] - https://review.openstack.org/#/c/421846/
[10] - https://review.openstack.org/#/c/446138/
[11] - https://review.openstack.org/#/c/447344/
[12] - https://review.openstack.org/#/c/386555/
[13] - https://review.openstack.org/444892
[14] - http://lists.openstack.org/pipermail/openstack-dev/2017-March/114558.html


pgpAKFER2XpHR.pgp
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] [tripleo] patch abandoment policy

[Alex Schultz]

On Fri, Mar 24, 2017 at 3:16 PM, Dan Prince  wrote:
> On Thu, 2017-03-23 at 16:20 -0600, Alex Schultz wrote:
>> Hey folks,
>>
>> So after looking at the backlog of patches to review across all of
>> the
>> tripleo projects, I noticed we have a bunch of really old stale
>> patches. I think it's time we address when we can abandon these stale
>> patches.
>>
>> Please comment on the proposed policy[0].  I know this has previously
>> been brought up [1] but I would like to formalize the policy so we
>> can
>> reduce the backlog of stale patches.  If you're wondering what would
>> be abandoned by this policy as it currently sits, I have a gerrit
>> dashboard for you[2] (it excludes diskimage-builder) .
>
> I think it is fine to periodically review patches and abandon them if
> need be. Last time this came up I wasn't in fan of auto-abandoning
> though. Rather I just made a pass manually and did it in fairly short
> order. The reason I like the manual approach is a lot of ideas could
> get lost (or silently ignored) if nobody acts on them manually.
>
> Rather then try to automate this would it serve us better to add a link
> to your Gerrit query in [2] below to highlight these patches and
> quickly go through them.
>

I think that's a valid request. I'm not necessarily that we propose
setting up automation day 1 but at least have a policy that we can
start using to go through this cleanup process.  I referenced
automation in the policy proposal to clear the way if we find that
automation is necessary at sometime in the future.  I think it better
if we started not letting stuff sit for 3 months and work on some
tooling to bring up items earlier.

Thanks,
-Alex

> Dan
>
>>
>> Thanks,
>> -Alex
>>
>> [0] https://review.openstack.org/#/c/449332/
>> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-October/0
>> 7.html
>> [2] https://goo.gl/XC9Hy7
>>
>> _
>> _
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
>> cribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] patch abandoment policy

[Dan Prince]

On Thu, 2017-03-23 at 16:20 -0600, Alex Schultz wrote:
> Hey folks,
> 
> So after looking at the backlog of patches to review across all of
> the
> tripleo projects, I noticed we have a bunch of really old stale
> patches. I think it's time we address when we can abandon these stale
> patches.
> 
> Please comment on the proposed policy[0].  I know this has previously
> been brought up [1] but I would like to formalize the policy so we
> can
> reduce the backlog of stale patches.  If you're wondering what would
> be abandoned by this policy as it currently sits, I have a gerrit
> dashboard for you[2] (it excludes diskimage-builder) .

I think it is fine to periodically review patches and abandon them if
need be. Last time this came up I wasn't in fan of auto-abandoning
though. Rather I just made a pass manually and did it in fairly short
order. The reason I like the manual approach is a lot of ideas could
get lost (or silently ignored) if nobody acts on them manually.

Rather then try to automate this would it serve us better to add a link
to your Gerrit query in [2] below to highlight these patches and
quickly go through them.

Dan

> 
> Thanks,
> -Alex
> 
> [0] https://review.openstack.org/#/c/449332/
> [1] http://lists.openstack.org/pipermail/openstack-dev/2015-October/0
> 7.html
> [2] https://goo.gl/XC9Hy7
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

[Matt Riedemann]

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



Overall I like the groupings of the projects in the main page. When I 
drill into Nova, a couple of things:


1. The link for the install guide goes to the home page for docs.o.o 
rather than https://docs.openstack.org/project-install-guide/ocata/ - is 
that intentional?


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


--

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-dev] [glance] priorities for the coming week (03/24-03/30)

[Brian Rosmaita]

Here are the priorities for Glance this week.  I'm keeping the list
short so we can focus.

0. Unblocking requirements
Hemanth is working on the WebOb 1.7 incompatibilities issue, so keep an
eye out for updates to his patch:
- https://review.openstack.org/#/c/423366/

Also keep an eye on the gate in general, the earlier monkey_patching for
eventlet 0.20.1 caused a breakage that we caught mid-week, but there may
be more surprises.

1. Image import refactor
Highest priority:
- https://review.openstack.org/#/c/391442/
- https://review.openstack.org/#/c/391441/
As time allows:
- https://review.openstack.org/#/c/443636/
- https://review.openstack.org/#/c/443632/
- https://review.openstack.org/#/c/443633/


Finally, don't forget that the spec proposal freeze is rapidly
approaching at 13:59 on Thursday 30 March.  Once the proposal freeze is
in effect, any new specs must be proposed for Queens.

__
OpenStack Development Mailing 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] Arrivederci

[Brian Rosmaita]

On 3/22/17 8:06 AM, Ian Cordasco wrote:
> Friday 24 March 2017 will be my last day working on OpenStack.

Well, I was hoping for divine intervention, but it's almost the close of
business today and it hasn't happened.  So I guess I'll have to say, on
behalf of myself and the entire Glance team, that we're going to miss
your many contributions to Glance (and also just having you around in
IRC).  We all wish you good luck on your next adventure, and sincerely
hope that we may work with you again either individually or collectively
at some point in the future.

hasta la vista,
brian



__
OpenStack Development Mailing 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

[Lauren Sell]

Yes, definitely. We’ve started updating the sample configs with web apps and 
big data (primarily driven by the Enterprise Working Group and Kathy Cacciatore 
on the Foundation team) and are about to publish eCommerce. We could pull down 
HTC or some of the other outdated ones for now until we’re able to update them. 


> On Mar 24, 2017, at 12:08 PM, Tim Bell  wrote:
> 
> Lauren,
>  
> Can we also update the sample configurations? We should certainly have 
> Neutron now in the HTC (since nova-network deprecation)
>  
> Tim
>  
> From: Lauren Sell >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> Date: Friday, 24 March 2017 at 17:57
> 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 
> 

__
OpenStack Development Mailing 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/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?


__
OpenStack Development Mailing 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] Last call for Leadership Training April 11-13

[Colette Alexander]

Hi everyone,

Just wanted to poke a bit, since there are still two slots available for
leadership training in Ann Arbor for April 11/12/13. You can sign up here:
https://etherpad.openstack.org/p/Leadershiptraining

I promise delicious food and a busy daily schedule with lots of learning
with some great members of the community. Training costs are covered by the
Foundation, but attendees are responsible for their own travel and
incidentals.

Please include your IRC nick and/or email address when you sign up.

I've begun the process of sending out logistics emails for everyone signed
up. If you *haven't* received an email from me, that means I probably
haven't been able to find one for you via the usual channels - please write
me at colettealexan...@gmail.com and we'll get that sorted. (If anyone else
on the -dev list has them, I'm particularly looking to contact Armstrong
Foundjem and Vinith Kumar.

Feel free to respond here, or ping me on IRC (I'm gothicmindfood) if you
have any questions at all.

Thank you!

-colette
__
OpenStack Development Mailing 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] [Rally] Open HTML Task report in other machine

[Boris Pavlovic]

Fernando,

Yes of course.

``rally task report`` generates standalone report that you can open
anywhere.

By default it will require internet (for js libs) but you can use
--html-static
https://github.com/openstack/rally/blob/master/rally/cli/commands/task.py#L627
this is going to merge js libs in HTML report (which makes it work without
internet)


Best regards,
Boris Pavlovic

On Fri, Mar 24, 2017 at 6:27 AM, Fernando López 
wrote:

> Dear all,
>
> I just started to play with Rally and I wonder if I could get the output
> html file with the results of a executed task and open in other machine. Is
> it possible?
>
> Best regards,
> Fernando
>
> __
> OpenStack Development Mailing 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]

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

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

[Neil Jerram]

Thanks, Sebastian, it looks good now.

On Fri, Mar 24, 2017 at 5:12 PM Sebastian Marcet  wrote:

> Neil sorry about that, problem solved, please re test
> regards
>
> 2017-03-24 14:02 GMT-03:00 Neil Jerram :
>
> If I start typing something in the search box, I get an "Authentication
> Required" popup that captures the remaining keystrokes that I intended to
> type into the search box.
>
> Then if I do manage to type a complete search term into the box, and press
> Enter, that "Authentication Required" popup pops up again, and the search
> doesn't happen.
>
> (I'm guessing it's probably a mistake and you didn't intend this to be
> authentication-protected...)
>
> Neil
>
>
>
> On Fri, Mar 24, 2017 at 4:58 PM 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
>
>
>
>
> --
> Sebastian Marcet
> https://ar.linkedin.com/in/smarcet
> SKYPE: sebastian.marcet
> __
> OpenStack Development Mailing 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][nova] Config drive claims ipv6_dhcp, neutron api says slaac

[Clark Boylan]

On Fri, Mar 24, 2017, at 05:24 AM, Jens Rosenboom wrote:
> 2017-03-24 9:48 GMT+00:00 Jens Rosenboom :
> > 2017-03-24 9:30 GMT+00:00 Simon Leinen :
> >> Clark Boylan writes:
> >> [...]
> >>> {
> >>> "id": "network1",
> >>> "link": "tap14b906ba-8c",
> >>> "network_id": "7ee08c00-7323-4f18-94bb-67e081520e70",
> >>> "type": "ipv6_dhcp"
> >>> }
> >>> ],
> >>> "services": []
> >>> }
> >>
> >>> You'll notice that the network1 entry has a type of ipv6_dhcp; however,
> >>> if you ask the neutron api it tells slaac is the ipv6_address_mode and
> >>> ipv6_ra_mode. But enable_dhcp is also set to True. So which is it? Is
> >>> there a bug here or am I missing something obvious? At the very least it
> >>> appears that the config drive info is incomplete and does not include
> >>> the slaac info.
> >
> > Two small notes:
> >
> > 1. The enable_dhcp must be true also for slaac, its real meaning
> > is not "dhcp is enabled", but "neutron will take care of address 
> > assignments".
> >
> > 2. The situation is not specific to the config drive being used, the 
> > identical
> > information is presented at
> > http://169.254.169.254/openstack/latest/network_data.json
> >
> >> Here's my hypothesis... "type ipvX_dhcp" really means "Neutron will
> >> manage ipvX addresses", not necessarily that it will use the DHCP
> >> protocol.
> >
> > Right, this is the code part that produces the info:
> > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/netutils.py#n267
> 
> Actually, there seems to be a bug here, or maybe two.
> 
> There is a dhcp_server address set in the info for the subnet even when
> it
> has type slaac, which cause the logic above to output type "ipv6_dhcp"
> instead
> of "ipv6". Either that is a bug in Neutron or there is some hidden reason
> to
> also have a DHCP server address for slaac.
> 
> It certainly is a bug in Nova to rely on that attribute in order to
> decide upon
> the network type, as for dhcpv6-stateless we would certainly have a
> dhcp_server
> defined additional information, but still the address configuration
> type is slaac
> and so the network type should be "ipv6" and the address for that subnet
> be included in the metadata.
> 
> P.S.: I vaguely remember a discussion that the dhcp_server should also
> send RAs in case of networks not having a router, maybe that is the
> reason
> for the behaviour above. Though I consider that scenario broken, RAs are
> "*router* advertisements" and thus should only be sent by routers. If
> people decide to deploy IPv6 on an isolated subnet, they should either
> be using DHCP or no auto-configuration at all.

Thank you for looking into this. As mentioned earlier in the thread
glean needs to be able to configure the Linux interfaces explicitly for
auto or dhcp so ideally the metadata info would also be explicit. I
think that setting the type to "ipv6_dhcp" when using slaac has to be a
bug when considering this because it means glean and other tools like
cloud init will not be able to configure Linux interfaces properly.

Are you going to be filing the bugs against nova and/or neutron? I think
you understand the fine details better than I do, but I am happy to help
out filing and pushing things as this would affect our use case quite a
bit. Just let me know how I can help.

Thanks,
Clark



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

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

[Sebastian Marcet]

Neil sorry about that, problem solved, please re test
regards

2017-03-24 14:02 GMT-03:00 Neil Jerram :

> If I start typing something in the search box, I get an "Authentication
> Required" popup that captures the remaining keystrokes that I intended to
> type into the search box.
>
> Then if I do manage to type a complete search term into the box, and press
> Enter, that "Authentication Required" popup pops up again, and the search
> doesn't happen.
>
> (I'm guessing it's probably a mistake and you didn't intend this to be
> authentication-protected...)
>
> Neil
>
>
>
> On Fri, Mar 24, 2017 at 4:58 PM 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
>
>


-- 
Sebastian Marcet
https://ar.linkedin.com/in/smarcet
SKYPE: sebastian.marcet
__
OpenStack Development Mailing 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

[Tim Bell]

Lauren,

Can we also update the sample configurations? We should certainly have Neutron 
now in the HTC (since nova-network deprecation)

Tim

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

Date: Friday, 24 March 2017 at 17:57
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] Project Navigator Updates - Feedback Request

[Neil Jerram]

If I start typing something in the search box, I get an "Authentication
Required" popup that captures the remaining keystrokes that I intended to
type into the search box.

Then if I do manage to type a complete search term into the box, and press
Enter, that "Authentication Required" popup pops up again, and the search
doesn't happen.

(I'm guessing it's probably a mistake and you didn't intend this to be
authentication-protected...)

Neil



On Fri, Mar 24, 2017 at 4:58 PM 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

[openstack-dev] Project Navigator Updates - Feedback Request

[Lauren Sell]

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] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

[Monty Taylor]

On 03/24/2017 11:22 AM, Graham Hayes wrote:
> On 24/03/17 08:46 -0700, Antoni Segura Puimedon wrote:
>>
>>
>> On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:
>>
>>On 24/03/17 10:27 -0400, Davanum Srinivas wrote:
>>>Folks,
>>>
>>>As discussed in the etherpad:
>>>https://etherpad.openstack.org/p/go-and-containers
>>>
>>>Here's a request for a repo in OpenStack:
>>>https://review.openstack.org/#/c/449641/
>>>
>>>This request pulls in the existing code from kubernetes/kubernetes
>>>repo and preserves the git history too
>>>https://github.com/dims/k8s-cloud-provider
>>>
>>>Anyone interested? please ping me on Slack or IRC and we can
>> continue this
>>work.
>>
>>Yeah - I would love to continue the provider work on gerrit :)
>>
>>Is there a way for us to make sure changes in the k8 master don't
>>break our plugin? Or do we need to periodic jobs on the provider repo
>>to catch breakages in the plugin interface?
>>
>>
>> I suppose the options are either:
>>
>> ask k8s to add select external cloud providers in the CI
>> Have a webhook in the k8s repo that triggered CI on the OSt infra 
>>  
> 
> Yup - I just want to have us get our ducks in a row before we make a
> move.
> 
> From our side, we should look at the support matrix of what OpenStack
> versions we support, and how we plan on testing them in -infra.

We will have better first-class support for this in a few months as part
of rolling out zuul v3. Once the github branch lands and we get v3
rolled out for non-infra projects, we'll be able to cross-test things in
gerrit with things not in gerrit (we have a similar need to be able to
test that ansible PRs don't break zuul)

For now, if you can make sure that you have a test that can install the
k8s repo from source, and also that is structured such that if it
discovers that the k8s repo is there that it will not re-clone, we
should be able to upgrade that in the future to having zuul manage the
triggering and cloning.


__
OpenStack Development Mailing 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

[Derek Higgins]

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

Re: [openstack-dev] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

[Graham Hayes]

On 24/03/17 08:46 -0700, Antoni Segura Puimedon wrote:



On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:

   On 24/03/17 10:27 -0400, Davanum Srinivas wrote:
   >Folks,
   >
   >As discussed in the etherpad:
   >https://etherpad.openstack.org/p/go-and-containers
   >
   >Here's a request for a repo in OpenStack:
   >https://review.openstack.org/#/c/449641/
   >
   >This request pulls in the existing code from kubernetes/kubernetes
   >repo and preserves the git history too
   >https://github.com/dims/k8s-cloud-provider
   >
   >Anyone interested? please ping me on Slack or IRC and we can continue this
   work.

   Yeah - I would love to continue the provider work on gerrit :)

   Is there a way for us to make sure changes in the k8 master don't
   break our plugin? Or do we need to periodic jobs on the provider repo
   to catch breakages in the plugin interface?


I suppose the options are either:

ask k8s to add select external cloud providers in the CI
Have a webhook in the k8s repo that triggered CI on the OSt infra 
 


Yup - I just want to have us get our ducks in a row before we make a
move.


From our side, we should look at the support matrix of what OpenStack

versions we support, and how we plan on testing them in -infra.



   Thanks, Graham

   >__
   >OpenStack Development Mailing 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] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

[Antoni Segura Puimedon]

On Friday, March 24, 2017 at 3:59:18 PM UTC+1, Graham Hayes wrote:
>
> On 24/03/17 10:27 -0400, Davanum Srinivas wrote: 
> >Folks, 
> > 
> >As discussed in the etherpad: 
> >https://etherpad.openstack.org/p/go-and-containers 
> > 
> >Here's a request for a repo in OpenStack: 
> >https://review.openstack.org/#/c/449641/ 
> > 
> >This request pulls in the existing code from kubernetes/kubernetes 
> >repo and preserves the git history too 
> >https://github.com/dims/k8s-cloud-provider 
> > 
> >Anyone interested? please ping me on Slack or IRC and we can continue 
> this work. 
>
> Yeah - I would love to continue the provider work on gerrit :) 
>
> Is there a way for us to make sure changes in the k8 master don't 
> break our plugin? Or do we need to periodic jobs on the provider repo 
> to catch breakages in the plugin interface? 
>

I suppose the options are either:

ask k8s to add select external cloud providers in the CI
Have a webhook in the k8s repo that triggered CI on the OSt infra 
 

>
> Thanks, Graham 
>
> >__ 
>
> >OpenStack Development Mailing 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

[Akira Yoshiyama]

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

Monty
>

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

Re: [openstack-dev] [openstack-docs] [tripleo] Creating official Deployment guide for TripleO

[Emilien Macchi]

On Wed, Mar 22, 2017 at 2:25 PM, Emilien Macchi  wrote:
> Thanks to these who volunteered, it's appreciated.
>
> I'm going to kick-off initial work here:
>
> 1. Create CI job that build deploy-guide on tripleo-docs repo (when
> required) - https://review.openstack.org/448740

Step 1 done.

> 2. In tripleo-docs, modify tox.ini and create initial structure for
> deployment guide (I'll kick it off once we have the CI job)

Step 2, done and ready for review: https://review.openstack.org/#/c/449684/

> 3. Start moving deployment related bits from doc/source/ to
> deploy-guide/source/ (I'll need your help for this step). We also need
> to include Alexendra and her team to make sure we're moving the right
> bits.

Keep posted, that will be the next step.

> 4. Expose TripleO deployment guide to deployment guides front page and
> drink a gin tonic.
>
> I'll give an update when 2. is done so we can start working on the content.
>
> Thanks,
>
> On Wed, Mar 22, 2017 at 8:22 AM, Flavio Percoco  wrote:
>> On 20/03/17 08:01 -0400, Emilien Macchi wrote:
>>>
>>> I proposed a blueprint to track the work done:
>>>
>>> https://blueprints.launchpad.net/tripleo/+spec/tripleo-deploy-guide
>>> Target: pike-3
>>>
>>> Volunteers to work on it with me, please let me know.
>>
>>
>> It'd be awesome to have some input from the containers squad on this effort
>> too.
>> Put me on the list for now while we find another volunteer in the containers
>> DFG.
>>
>> Flavio
>>
>>> Thanks,
>>>
>>> On Tue, Mar 14, 2017 at 7:00 AM, Alexandra Settle 
>>> wrote:

 Hey Emilien,

 You pretty much covered it all! Docs team is happy to provide guidance,
 but in reality, it should be a fairly straight forward process.

 The Kolla team just completed their deploy-guide patches and were able to
 help refine the process a bit further. Hopefully this should help the
 TripleO team :)

 Reach out if you have any questions at all :)

 Thanks,

 Alex

 On 3/13/17, 10:32 PM, "Emilien Macchi"  wrote:

 Team,

 [adding Alexandra, OpenStack Docs PTL]

 It seems like there is a common interest in pushing deployment guides
 for different OpenStack Deployment projects: OSA, Kolla.
 The landing page is here:
 https://docs.openstack.org/project-deploy-guide/newton/

 And one example:

 https://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/

 I think this is pretty awesome and it would bring more visibility for
 TripleO project, and help our community to find TripleO documentation
 from a consistent place.

 The good news, is that openstack-docs team built a pretty solid
 workflow to make that happen:

 https://docs.openstack.org/contributor-guide/project-deploy-guide.html
 And we don't need to create new repos or do any crazy changes. It
 would probably be some refactoring and sphinx things.

 Alexandra, please add any words if I missed something obvious.

 Feedback from the team would be welcome here before we engage any
 work,

 Thanks!
 --
 Emilien Macchi


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



-- 
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] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

[Graham Hayes]

On 24/03/17 10:27 -0400, Davanum Srinivas wrote:

Folks,

As discussed in the etherpad:
https://etherpad.openstack.org/p/go-and-containers

Here's a request for a repo in OpenStack:
https://review.openstack.org/#/c/449641/

This request pulls in the existing code from kubernetes/kubernetes
repo and preserves the git history too
https://github.com/dims/k8s-cloud-provider

Anyone interested? please ping me on Slack or IRC and we can continue this work.


Yeah - I would love to continue the provider work on gerrit :)

Is there a way for us to make sure changes in the k8 master don't
break our plugin? Or do we need to periodic jobs on the provider repo
to catch breakages in the plugin interface?

Thanks, Graham


__
OpenStack Development Mailing 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] [QA][blazar][intel-nfv-ci-tests][nova-lxd][octavia][tap-as-a-service][vmware-nsx][barbican] Refactor of Tempest scenario base classes

[Andrea Frittoli]

Status update on the scenario manager base class:

- 13 patches merged
- 6 patches ready (on master)
- 2 patches ready (on stable branches)

Details: https://etherpad.openstack.org/p/tempest-manager-plugins

I changed the subject to include only the projects that have outstanding
patches related to this.

thank you

andrea

On Sat, Mar 18, 2017 at 12:04 PM Andrea Frittoli 
wrote:

> Status update.
>
> Thanks to all your work, we are getting close to finishing this work!
>
> - 12 patches merged
> - 7 patches ready, pending approval
> - 2 patches (on stable branches) with a pep8 failure to be fixed
>
> Details: https://etherpad.openstack.org/p/tempest-manager-plugins
>
> There are still a few patches that need a review, any help
> would be much appreciated!
>
> Thank you
>
> andrea
>
> On Wed, Mar 15, 2017 at 3:56 PM Andrea Frittoli 
> wrote:
>
> On Wed, Mar 15, 2017 at 11:38 AM Dmitry Tantsur 
> wrote:
>
> On 02/27/2017 12:34 PM, Andrea Frittoli wrote:
> > Hello folks,
> >
> > TL;DR: if today you import manager,py from tempest.scenario please
> maintain a
> > copy of [0] in tree until further notice.
>
> Hi!
>
> I hope it is pretty obvious, but just to be clear. Anything that this
> copied
> file uses should be treated more or less as a stable API by the QA team
> during
> the whole transition period. The last thing we want to happen is for this
> file
> to break all the time because its dependencies (imports, functions,
> classes it
> uses) are not stable.
>
> If it's not the case, please update it, and let us know the git hash to
> use to
> grab the final version of the file.
>
>
> Your code depends on manager.py and its dependencies today,
> and copying that in-tree removes at least one of the dependencies.
>
> The only case were you're in a worse situation is if one of the imports is
> removed / renamed,
> and we'll do our best to avoid that.
>
> My recommendation would be to trim down your copy of manager.py to the
> bare minimum you
> need, which is likely to be much smaller than the whole module.
>
>
> Thanks for understanding!
>
> __
> OpenStack Development Mailing 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] [kubernetes][go] External OpenStack Cloud Provider for Kubernetes

[Davanum Srinivas]

Folks,

As discussed in the etherpad:
https://etherpad.openstack.org/p/go-and-containers

Here's a request for a repo in OpenStack:
https://review.openstack.org/#/c/449641/

This request pulls in the existing code from kubernetes/kubernetes
repo and preserves the git history too
https://github.com/dims/k8s-cloud-provider

Anyone interested? please ping me on Slack or IRC and we can continue this work.

Thanks,
Dims

-- 
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] [neutron][networking-odl][qa] What's the recommended behavior for SG Rules with ethertype='IPv6' and protocol='icmp' ?

[Brian Haley]

On 03/24/2017 06:41 AM, Ghanshyam Mann wrote:

Hi All,

Tempest is testing SG rule creation and pinging scenario tests with
ethertype='IPv6' and protocol='icmp' [0].
In case of ethertype='IPv6', currently neutron accept protocol type
as 'icmp', 'icmpv6' and 'ipv6-icmp' which again seems like duplication
of SG rules bug on neutron side but not sure [1]

But it seems like some driver does not work with 'icmp' on IPv6, at
least ODL as mentioned in bug [2]. Where few others like ML2/OVS
iptables driver convert 'icmp' to 'icmpv6' when ethertype='IPv6' and had
no issue with 'icmp'.

IMO neutron should keep accepting 'icmp' for IPv6 for backward
compatibility and legacy usage and tempest should test 'icmp' also along
with other protocol type.
But we need more feedback on that what is right way (as per backward
compatibility pov) and recommended way for having best behaviour for SG
rules on IPv6. What best can work for all plugins also?


Thanks for raising this issue.  Let me just restate it a little so it's 
clear.


1. One can create an IPv6 rule using protocol value "icmp" today, and 
the base security group code does the right thing changing the rule to 
be correct for the underlying implementation, for example, "ipv6-icmp" 
for iptables.  It doesn't look like all other drivers handle this properly.


2. The neutron API will accept multiple values - "icmp", "ipv6-icmp" and 
"icmpv6" for an IPv6 rule, but it will create unique database entries 
for each (I just verified that).  While that shouldn't create multiple 
entries in the base iptables code, it will probably generate a warning 
in the logs about a duplicate being suppressed.



So there are a few things that could be done:

1. Drivers need to accept "icmp" in order to be backwards-compatible 
with the current code.


2. Duplicates should be detected and generate 409 (?) errors.

3. We should add a migration (IMO) where any duplicates are squashed.

The open question is, do we want to change the DB to have a different 
value here, like "icmpv6" ?  We could obviously add a migration where we 
update the value.  The problem is that flag day could pose a problem if 
out-of-tree drivers don't support the new value.  I think we should 
leave it "icmp" for that reason, thoughts from others?


-Brian

__
OpenStack Development Mailing 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] [Rally] Open HTML Task report in other machine

[Fernando López]

Dear all,

I just started to play with Rally and I wonder if I could get the output 
html file with the results of a executed task and open in other machine. 
Is it possible?


Best regards,
Fernando

__
OpenStack Development Mailing 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] placement/resource providers update 16

[Chris Dent]

Here's your weekly dose of resource provides and placement news.

# What Matters Most

Traits are still top of the priority stack. Links below. There's
some need to start thinking about claims. More on that, also below.

# What's Changed

The `nova.api.openstack.placement.microversion.version_handler`
decorator now accepts only strings. It was accepting floats and
inputs and processing strings as input and that's wrong:

   https://bugs.launchpad.net/nova/+bug/1675143

On the client side, for now the plan is to not create a
python-placementclient (as simple wraps of keystoneauth1 work well)
but instead to have an OSC plugin for command line calls. The infra
and governance changes for that are at:

https://review.openstack.org/#/c/448115/
https://review.openstack.org/#/c/448117/

Other than that we're making incremental progress across the board.

# Help Wanted

dims suggested that this document needed a help wanted section, to
highlight areas where volunteers are needed. That seems like a good
idea. This section will adapt over time, depending on how people
react to it. There are three main areas where help would be very
useful:

* General attention to bugs tagged placement:
  https://bugs.launchpad.net/nova/+bugs?field.tag=placement

* Helping to create api documentation for placement (see the Docs
  section below).

* Helping to create and evaluate functional tests of the resource
  tracker and the ways in which it and nova-scheduler use the
  reporting client. For some info see
  https://etherpad.openstack.org/p/nova-placement-functional
  and talk to edleafe.

# Main Themes

## Traits

The work to implement the traits API in placement is happening at

 
https://review.openstack.org/#/q/status:open+topic:bp/resource-provider-traits

It's getting close. The sooner we get that happy, the sooner we can
make progress on the rest of the themes.

## Ironic/Custom Resource Classes

The main work to support this was merged, but then some tripleo (I
think?) testing exposed an issue with how min_unit was being
managed, fixed in:

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

The original code was assuming there would never be
under-subscription. This, turns out, is a bad assumption.

A spec for "custom resource classes in flavors" that describes the
stuff that will actually make use of this functionality has merged:

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

Over in ironic some functional and integration tests have started:

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

## Claims in the Scheduler

This topic was briefly touched upon in the scheduler team meeting
and then again in the full nova meeting. The gist is that we need to
be sure we are all talking about the same thing(s) when we use the
phrase "Claims in the Scheduler", because it is a broad topic and we
want to be sure that when we write a spec it accurately discusses
what the overarching processes are, not simply how to satisfy them.
The hope is that by doing that we'll ensure we get everyone on the
same page, one that happens to be correct.

A "Super WIP" spec for claims in the scheduler was started at

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

## Shared Resource Providers

https://blueprints.launchpad.net/nova/+spec/shared-resources-pike

Progress on this will continue once traits and claims have moved forward.

## Nested Resource Providers

https://review.openstack.org/#/q/status:open+topic:bp/nested-resource-providers

or

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

According to mriedem, the nested-resource provider spec
 should be updated to
reflect the flipboard discussion from the PTG (reported in this
space two weeks ago) about multi-parent providers and how they
aren't going to happen. Previous email:

http://lists.openstack.org/pipermail/openstack-dev/2017-March/113332.html

## Docs

https://review.openstack.org/#/q/topic:cd/placement-api-ref

The start of creating an API ref for the placement API. Not a lot
there yet as I haven't had much of an opportunity to move it along.
There is, however, enough there for additional content to be
started, if people have the opportunity to do so. Check with me
(cdent) if you'd like to contribute.

Andrey Volkov has volunteered to help with some of this, but more
help is needed on two fronts:

* Figuring out how to set up api-ref publishing infra jobs for
  placement when the existing jobs for that sort of thing assume any
  given repo will only have one api-ref. Andrey has just this very
  minute made something for that (yay!):

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

* Adding content for each of the several resource handlers in the
  placement service.

## Performance

We're aware that there are some redundancies in the resource tracker
that we'd like to clean up

http://lists.openstack.org/pipermail/openstack-dev/2017-January/110953.html

but it's also the case that we've done no performance testing on the
placement service 

Re: [openstack-dev] [mogan] Nominating liusheng for Mogan core

[Feng, Shaohe]

Liusheng deserved it for his great contribution.

＋１
Thanks.

BR
Ｓｈａｏｈｅ


On Mon, Mar 20, 2017 at 4:19 PM, Zhenguo Niu > wrote:


   Hi team,

   I would like to nominate liusheng to Mogan core. Liusheng has been a
   significant code contributor since the project's creation providing
   high quality reviews.

   Please feel free to respond in public or private your support or any
   concerns.


   Thanks,
   Zhenguo

   __
   OpenStack Development Mailing 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][nova] Config drive claims ipv6_dhcp, neutron api says slaac

[Jens Rosenboom]

2017-03-24 9:48 GMT+00:00 Jens Rosenboom :
> 2017-03-24 9:30 GMT+00:00 Simon Leinen :
>> Clark Boylan writes:
>> [...]
>>> {
>>> "id": "network1",
>>> "link": "tap14b906ba-8c",
>>> "network_id": "7ee08c00-7323-4f18-94bb-67e081520e70",
>>> "type": "ipv6_dhcp"
>>> }
>>> ],
>>> "services": []
>>> }
>>
>>> You'll notice that the network1 entry has a type of ipv6_dhcp; however,
>>> if you ask the neutron api it tells slaac is the ipv6_address_mode and
>>> ipv6_ra_mode. But enable_dhcp is also set to True. So which is it? Is
>>> there a bug here or am I missing something obvious? At the very least it
>>> appears that the config drive info is incomplete and does not include
>>> the slaac info.
>
> Two small notes:
>
> 1. The enable_dhcp must be true also for slaac, its real meaning
> is not "dhcp is enabled", but "neutron will take care of address assignments".
>
> 2. The situation is not specific to the config drive being used, the identical
> information is presented at
> http://169.254.169.254/openstack/latest/network_data.json
>
>> Here's my hypothesis... "type ipvX_dhcp" really means "Neutron will
>> manage ipvX addresses", not necessarily that it will use the DHCP
>> protocol.
>
> Right, this is the code part that produces the info:
> http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/netutils.py#n267

Actually, there seems to be a bug here, or maybe two.

There is a dhcp_server address set in the info for the subnet even when it
has type slaac, which cause the logic above to output type "ipv6_dhcp" instead
of "ipv6". Either that is a bug in Neutron or there is some hidden reason to
also have a DHCP server address for slaac.

It certainly is a bug in Nova to rely on that attribute in order to decide upon
the network type, as for dhcpv6-stateless we would certainly have a dhcp_server
defined additional information, but still the address configuration
type is slaac
and so the network type should be "ipv6" and the address for that subnet
be included in the metadata.

P.S.: I vaguely remember a discussion that the dhcp_server should also
send RAs in case of networks not having a router, maybe that is the reason
for the behaviour above. Though I consider that scenario broken, RAs are
"*router* advertisements" and thus should only be sent by routers. If
people decide to deploy IPv6 on an isolated subnet, they should either
be using DHCP or no auto-configuration at all.

__
OpenStack Development Mailing 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/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!

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

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)

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] [mogan] Nominating liusheng for Mogan core

[JF Ding]

ping Shaohe Feng


On Mon, Mar 20, 2017 at 4:19 PM, Zhenguo Niu  wrote:

> Hi team,
>
> I would like to nominate liusheng to Mogan core. Liusheng has been a
> significant code contributor since the project's creation providing high
> quality reviews.
>
> Please feel free to respond in public or private your support or any
> concerns.
>
>
> Thanks,
> Zhenguo
>
> __
> OpenStack Development Mailing 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-odl][qa] What's the recommended behavior for SG Rules with ethertype='IPv6' and protocol='icmp' ?

[Ghanshyam Mann]

Hi All,

Tempest is testing SG rule creation and pinging scenario tests with
ethertype='IPv6' and protocol='icmp' [0].
In case of ethertype='IPv6', currently neutron accept protocol type
as 'icmp', 'icmpv6' and 'ipv6-icmp' which again seems like duplication of
SG rules bug on neutron side but not sure [1]

But it seems like some driver does not work with 'icmp' on IPv6, at least
ODL as mentioned in bug [2]. Where few others like ML2/OVS iptables driver
convert 'icmp' to 'icmpv6' when ethertype='IPv6' and had no issue with
'icmp'.

IMO neutron should keep accepting 'icmp' for IPv6 for backward
compatibility and legacy usage and tempest should test 'icmp' also along
with other protocol type.
But we need more feedback on that what is right way (as per backward
compatibility pov) and recommended way for having best behaviour for SG
rules on IPv6. What best can work for all plugins also?

.. 0

https://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/network/test_security_groups.py

https://git.openstack.org/cgit/openstack/tempest/tree/tempest/scenario/manager.py#n1116

.. 1 https://bugs.launchpad.net/neutron/+bug/1582500

.. 2 https://bugs.launchpad.net/tempest/+bug/1671366

.. 3
https://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/linux/iptables_firewall.py#n378


-gmann
__
OpenStack Development Mailing 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]:triple-o undercloud installation error on CentOS7.3

[pranab boruah]

facing this issue  when using Git checkouts of the puppet modules
instead of packages.

Using packages instead of git checkouts solved the problem. :) :)

On 23 March 2017 at 19:13, pranab boruah  wrote:
> Hi, I am trying to install triple-o undercloud on a physical machine.
> The installation fails every time. I have reinstalled the OS and tried
> starting from scratch but got the same error.
>
> System Details :
>
> DELL t620 with IPMI support.
> Different network for Internet Connectivity and PXE respectively.
> OS version : CentOS 7.3.1611, kernel : 3.10.0-514.10.2.el7.x86_64
> 192.168.10.0/24 is for PXE boot network
>
> My undercloud.conf looks like this:
>
> http://paste.openstack.org/show/603918/
>
> Error details:
>
> dib-run-parts Thu Mar 23 18:35:53 IST 2017 Running
> /usr/libexec/os-refresh-config/configure.d/50-puppet-stack-config
> + set -o pipefail
> + puppet_apply puppet apply --detailed-exitcodes
> /etc/puppet/manifests/puppet-stack-config.pp
> + set +e
> + puppet apply --detailed-exitcodes
> /etc/puppet/manifests/puppet-stack-config.pp
> + awk '{print strftime("%Y-%m-%d %H:%M:%S") " - "$0; fflush()}'
> 2017-03-23 18:35:57 - Error: Syntax error at 'Boolean'; expected
> ')' at /etc/puppet/modules/rabbitmq/manifests/init.pp:3
> on node undercloud.in.caveonetworks.com
> 2017-03-23 18:35:57 - Error: Syntax error at 'Boolean'; expected
> ')' at /etc/puppet/modules/rabbitmq/manifests/init.pp:3 on node
> undercloud.in.caveonetworks.com
> + rc=1
> + set -e
> + echo 'puppet apply exited with exit code 1'
> puppet apply exited with exit code 1
> + '[' 1 '!=' 2 -a 1 '!=' 0 ']'
> + exit 1
> [2017-03-23 18:35:57,659] (os-refresh-config) [ERROR] during
> configure phase. [Command '['dib-run-parts',
> '/usr/libexec/os-refresh-config/configure.d']' returned non-zero exit
> status 1]
>
> [2017-03-23 18:35:57,660] (os-refresh-config) [ERROR] Aborting...
>
> Desperately need some help. Please let me know if you  need any other details.
>
> -pjb

__
OpenStack Development Mailing 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][nova] Config drive claims ipv6_dhcp, neutron api says slaac

[Jens Rosenboom]

2017-03-24 9:30 GMT+00:00 Simon Leinen :
> Clark Boylan writes:
> [...]
>> {
>> "id": "network1",
>> "link": "tap14b906ba-8c",
>> "network_id": "7ee08c00-7323-4f18-94bb-67e081520e70",
>> "type": "ipv6_dhcp"
>> }
>> ],
>> "services": []
>> }
>
>> You'll notice that the network1 entry has a type of ipv6_dhcp; however,
>> if you ask the neutron api it tells slaac is the ipv6_address_mode and
>> ipv6_ra_mode. But enable_dhcp is also set to True. So which is it? Is
>> there a bug here or am I missing something obvious? At the very least it
>> appears that the config drive info is incomplete and does not include
>> the slaac info.

Two small notes:

1. The enable_dhcp must be true also for slaac, its real meaning
is not "dhcp is enabled", but "neutron will take care of address assignments".

2. The situation is not specific to the config drive being used, the identical
information is presented at
http://169.254.169.254/openstack/latest/network_data.json

> Here's my hypothesis... "type ipvX_dhcp" really means "Neutron will
> manage ipvX addresses", not necessarily that it will use the DHCP
> protocol.

Right, this is the code part that produces the info:
http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/netutils.py#n267

> For IPv4 it will always imply DHCP, but for IPv6 the method
> to tell the port user (instance) the address might be SLAAC (for the
> "slaac" and "dhcpv6-stateless" modes) or Stateful DHCPv6 (for the
> "dhcpv6-stateful" mode).
>
> I think it would indeed be useful to convey the ipv6_address_mode (and
> maybe also ipv6_ra_mode) in the metadata; but in principle a system
> should be able to infer the supported mode by looking at the flags in
> the RAs (Router Advertisements).  It's just that most GNU/Linux
> distributions ignore what the RAs say :-(

Which is sad but true indeed, but IMO would be the correct solution in
the long run,
that's we the flags are there in the first place. FWIW there is a beta
version of cirros
that tries to implement this, but it has not been released yet.

__
OpenStack Development Mailing 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][nova] Config drive claims ipv6_dhcp, neutron api says slaac

[Simon Leinen]

Clark Boylan writes:
[...]
> {
> "id": "network1",
> "link": "tap14b906ba-8c",
> "network_id": "7ee08c00-7323-4f18-94bb-67e081520e70",
> "type": "ipv6_dhcp"
> }
> ],
> "services": []
> }

> You'll notice that the network1 entry has a type of ipv6_dhcp; however,
> if you ask the neutron api it tells slaac is the ipv6_address_mode and
> ipv6_ra_mode. But enable_dhcp is also set to True. So which is it? Is
> there a bug here or am I missing something obvious? At the very least it
> appears that the config drive info is incomplete and does not include
> the slaac info.

Here's my hypothesis... "type ipvX_dhcp" really means "Neutron will
manage ipvX addresses", not necessarily that it will use the DHCP
protocol.  For IPv4 it will always imply DHCP, but for IPv6 the method
to tell the port user (instance) the address might be SLAAC (for the
"slaac" and "dhcpv6-stateless" modes) or Stateful DHCPv6 (for the
"dhcpv6-stateful" mode).

I think it would indeed be useful to convey the ipv6_address_mode (and
maybe also ipv6_ra_mode) in the metadata; but in principle a system
should be able to infer the supported mode by looking at the flags in
the RAs (Router Advertisements).  It's just that most GNU/Linux
distributions ignore what the RAs say :-( so you need to configure
/etc/network/interfaces explicitly for either "auto" (SLAAC) or "dhcp"
(DHCPv6).)
-- 
Simon.

__
OpenStack Development Mailing 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][networking-l2gw] Unable to create release tag

[Gary Kotton]

Thanks!

From: Yolanda Robla Mota 
Reply-To: OpenStack List 
Date: Thursday, March 23, 2017 at 6:33 PM
To: OpenStack List 
Subject: Re: [openstack-dev] [neutron][networking-l2gw] Unable to create 
release tag

Hi, seems the ACL is not correctly applied. infra-root as looking at it
Best
Yolanda

On Thu, Mar 23, 2017 at 5:18 PM, Gary Kotton 
> wrote:
Hi,
I have tried updating my gpg key and still nothing works:

gkotton@ubuntu:~/networking-l2gw$ git push gerrit tag 10.0.0
Enter passphrase for key '/home/gkotton/.ssh/id_rsa':
Counting objects: 1, done.
Writing objects: 100% (1/1), 531 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
remote: Processing changes: refs: 1, done
To 
ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git
 ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
error: failed to push some refs to 
'ssh://ga...@review.openstack.org:29418/openstack/networking-l2gw.git'

Any idea here?
This is blocking people who want to package…
Thanks
Gary

On 3/21/17, 7:18 PM, "Gary Kotton" 
> wrote:

Hi,
I am still unable to do this – this is after 
https://review.openstack.org/#/c/447279/ landed.
Any ideas?
Thanks
Gary

On 3/14/17, 3:04 PM, "Jeremy Stanley" 
> wrote:

On 2017-03-14 05:39:35 + (+), Gary Kotton wrote:
> I was asked to create a release tag for stable/ocata. This fails with:
[...]
>  ! [remote rejected] 10.0.0 -> 10.0.0 (prohibited by Gerrit)
[...]

The ACL for that repo doesn't seem to be configured to allow it
(yet):


http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/networking-l2gw.config

The Infra Manual section documenting that permission is:

https://docs.openstack.org/infra/manual/creators.html#creation-of-tags

It also may be helpful to review the section on manually tagging
releases:

https://docs.openstack.org/infra/manual/drivers.html#tagging-a-release

Hope that helps!
--
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


__
OpenStack Development Mailing 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



--

Yolanda Robla Mota

Principal Software Engineer, RHCSA

Red Hat



C/Avellana 213

Urb Portugal

yrobl...@redhat.comM: 
+34605641639
[https://www.redhat.com/profiles/rh/themes/redhatdotcom/img/logo-red-hat-black.png]
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Data centric hyper-convergence with Openstack Swift and Storlets

[Eran Rom]

Hi All,
If you care about unstructured data processing, and face bandwidth difficulties 
don’t miss this talk!

On March 30th (next Thursday) I will give a web talk on the above subject. 
Abstract below.
The talk will be given twice that day. Details below.

If you wish to, but cannot make it please let me know and I will try to arrange 
an additional slot.
My mail is: e...@itsonlyme.name

Thanks very much!
Eran
Storlets PTL

Abstract:

Storlets and Swift allow to physically co-locate storage and compute, and 
essentially implement
- what I call - data centric hyper convergence.
In the talk I will give the essential intro to Swift and Storlets and 
demonstrate an
End-to-End deep learning on unstructured data.
The deep learning problem demonstrated is face recognition.
I will demonstrate that all the steps from data preparation via model training 
to
model testing can be done using storlets.

When:
———
Thursday March 30th in:
* 09:00 UTC
* 19:00 UTC

Note that in some time zones the hours difference
from UTC may change until March 30th.

Call Technicalities

The talk will be given using Zoom video conferencing. Connecting will require
a browser plugin installation. The link to the call is:
https://zoom.us/j/7922255193
__
OpenStack Development Mailing 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][all] Remove deprecated config option `sqlite_db` from oslo.db

[ChangBo Guo]

Hi ALL,

config option 'sqlite_db'  is not used in some projects but shows up in
config files, it's confusing to our users. We deprecated it in July, 2016
[1]. and we plan to remove it in [2]
Just let you know the change,  If project still use it , you can regiester
config option 'sqlite_db' in the project.

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

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