Re: [openstack-dev] [vitrage] stable/pike branch for vitrage

[Afek, Ifat (Nokia - IL/Kfar Sava)]

On 09/08/2017, 3:41, "Tony Breeds"  wrote:

On Tue, Aug 08, 2017 at 08:17:48AM +, Afek, Ifat (Nokia - IL/Kfar Sava) 
wrote:
> Hi,
> 
> I’m going to create stable/pike branches for vitrage and 
vitrage-dashboard tomorrow or the day after.
> If you have changes that should enter Pike, try to push them today. After 
that, we will be able to fix Pike bugs on top of stable/pike for two more weeks.
> Please do not merge changes that should enter Queens until the 
stable/pike branches are created.

Are you going to use the branch creation process in openstack/releases
or do it yourself?

Yours Tony.


Of course I’m going to use the openstack/releases process.

Best Regards,
Ifat.


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

[openstack-dev] [tacker] Self-nomination for PTL in Queens

[gongys2017]

Hi everyone,

This is my self-nomination to continue running as Takcer PTL for the 
Queens cycle.

In Pike cycle, tacker team is focusing on stablebility and scaling. We 
haveintrotroduced Barbican to keep VIM credentials and Mistral to do 
VIMmonitoring and policies. These are great steps to let Tacker to be stableand 
scalable. In addition, the team has been active in promoting tacker.We have 
joined OPNFV meeting, OpenStack days China and OpenStackdesign summit in 
Boston.  There are some topic sessions which areproposed to Syndey Summit by 
team.

In Queen cycle, I plan to

- Continue to stablize tacker and make it of production quality.
- Complete tacker document.- Provide kolla way to install tacker. I think 
tacker will be installed in kolla which put  tacker in containers. The 
container way will make tacker easier to use,  help many guys to use tacker in 
short way, compared to devstack installation.
- introduce more kinds of VIMs- Promote tacker into other community.

Lets make tacker roll together.
Thanks for your consideration.

-- 

Thanks,

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

Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes

[Fox, Kevin M]

Down that path lies tears. :/

From: joehuang [joehu...@huawei.com]
Sent: Tuesday, August 08, 2017 10:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: kubernetes-sig-openst...@googlegroups.com
Subject: Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone 
based Authentication and Authorization for Kubernetes

Except webhook, how about custom module(call keystone API directly from custom 
module) for authorization? ( 
https://kubernetes.io/docs/admin/authorization/#custom-modules )

Webhook:
Pros.: http calling, loose coupling, more flexible configuration.
Cons.: Degraded performance, one more hop
custom module:
Pros.: direct function call, better performance, less process to 
maintain.
Cons.: coupling, built-in module.

Best Regards
Chaoyi Huang (joehuang)


From: Morgan Fainberg [morgan.fainb...@gmail.com]
Sent: 09 August 2017 12:26
To: OpenStack Development Mailing List (not for usage questions)
Cc: kubernetes-sig-openst...@googlegroups.com
Subject: Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone 
based Authentication and Authorization for Kubernetes

I shall take a look at the webhooks and see if I can help on this front.

--Morgan

On Tue, Aug 8, 2017 at 6:34 PM, joehuang  wrote:
> Dims,
>
> Integration of keystone and kubernetes is very cool and in high demand. Thank 
> you very much.
>
> Best Regards
> Chaoyi Huang (joehuang)
>
> 
> From: Davanum Srinivas [dava...@gmail.com]
> Sent: 01 August 2017 18:03
> To: kubernetes-sig-openst...@googlegroups.com; OpenStack Development Mailing 
> List (not for usage questions)
> Subject: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone 
> based Authentication and Authorization for Kubernetes
>
> Team,
>
> Having waded through the last 4 attempts as seen in kubernetes PR(s)
> and Issues and talked to a few people on SIG-OpenStack slack channel,
> the consensus was that we should use the Webhook mechanism to
> integrate Keystone and Kubernetes.
>
> Here's the experiment : https://github.com/dims/k8s-keystone-auth
>
> Anyone interested in working on / helping with this? Do we want to
> create a repo somewhere official?
>
> 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
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

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

Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes

[joehuang]

Except webhook, how about custom module(call keystone API directly from custom 
module) for authorization? ( 
https://kubernetes.io/docs/admin/authorization/#custom-modules )

Webhook:
Pros.: http calling, loose coupling, more flexible configuration.
Cons.: Degraded performance, one more hop
custom module:
Pros.: direct function call, better performance, less process to 
maintain.
Cons.: coupling, built-in module.

Best Regards
Chaoyi Huang (joehuang)


From: Morgan Fainberg [morgan.fainb...@gmail.com]
Sent: 09 August 2017 12:26
To: OpenStack Development Mailing List (not for usage questions)
Cc: kubernetes-sig-openst...@googlegroups.com
Subject: Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone 
based Authentication and Authorization for Kubernetes

I shall take a look at the webhooks and see if I can help on this front.

--Morgan

On Tue, Aug 8, 2017 at 6:34 PM, joehuang  wrote:
> Dims,
>
> Integration of keystone and kubernetes is very cool and in high demand. Thank 
> you very much.
>
> Best Regards
> Chaoyi Huang (joehuang)
>
> 
> From: Davanum Srinivas [dava...@gmail.com]
> Sent: 01 August 2017 18:03
> To: kubernetes-sig-openst...@googlegroups.com; OpenStack Development Mailing 
> List (not for usage questions)
> Subject: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone 
> based Authentication and Authorization for Kubernetes
>
> Team,
>
> Having waded through the last 4 attempts as seen in kubernetes PR(s)
> and Issues and talked to a few people on SIG-OpenStack slack channel,
> the consensus was that we should use the Webhook mechanism to
> integrate Keystone and Kubernetes.
>
> Here's the experiment : https://github.com/dims/k8s-keystone-auth
>
> Anyone interested in working on / helping with this? Do we want to
> create a repo somewhere official?
>
> 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
>
> __
> OpenStack Development Mailing 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] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes

[Morgan Fainberg]

I shall take a look at the webhooks and see if I can help on this front.

--Morgan

On Tue, Aug 8, 2017 at 6:34 PM, joehuang  wrote:
> Dims,
>
> Integration of keystone and kubernetes is very cool and in high demand. Thank 
> you very much.
>
> Best Regards
> Chaoyi Huang (joehuang)
>
> 
> From: Davanum Srinivas [dava...@gmail.com]
> Sent: 01 August 2017 18:03
> To: kubernetes-sig-openst...@googlegroups.com; OpenStack Development Mailing 
> List (not for usage questions)
> Subject: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone 
> based Authentication and Authorization for Kubernetes
>
> Team,
>
> Having waded through the last 4 attempts as seen in kubernetes PR(s)
> and Issues and talked to a few people on SIG-OpenStack slack channel,
> the consensus was that we should use the Webhook mechanism to
> integrate Keystone and Kubernetes.
>
> Here's the experiment : https://github.com/dims/k8s-keystone-auth
>
> Anyone interested in working on / helping with this? Do we want to
> create a repo somewhere official?
>
> 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
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova] Self-nomination for PTL in Queens

[Nicolas Bock]

On Tue, Aug 08, 2017 at 03:58:20PM -0500, Matt Riedemann wrote:

Hi everyone,

This is my self-nomination to continue running as Nova PTL for the 
Queens cycle.


+1 !

If elected, this would be my fourth term as Nova PTL. While I try to 
continually improve, at this point I have a fairly steady way of doing 
things and most people are probably used to that by now. That's not to 
say it's the best way of doing things, so I'm always open to getting 
feedback on what people would like to see more (or less) of from me.


I really see this as a service role and I'm happy to continue being of 
service for another release, which includes preparing for the PTG and 
Forum, being aware of the schedule and communicating major changes or 
plans to various groups (developers, operators, Foundation staff, 
etc).


I'm also happy to say that I'm fortunate enough to have an employer that
supports me doing this again and the amount of time it takes working 
mostly full time in the community.


As for Queens content, we made a lot of progress again in Pike but 
some things are left undone and that's what I'd like to focus on in 
Queens. Specifically:


- Continue to evolve and solidify Nova's interaction with the Placement
 service, which includes getting the allocations code out of the
 compute service, fully supporting shared storage providers (and
 testing that in the Ceph CI job), and finally adding the nested
 resource providers support which will enable other features like vGPUs
 and other hardware-accelerated configurations.
- Close some gaps in our multi-cell support, mainly related to up-calls
 for reschedules during build and affinity/anti-affinity sanity checks,
 and also work on real multi-cell deployment testing in a multi-node CI
 job.
- Finish the Cinder 3.27 API integration early (before the PTG) so we
 can finally get volume multi-attach support.
- Cleanup the documentation now that it has moved in-tree.

Finally, a personal goal for me is going to be working on helping 
mentor someone into the PTL role for the Rocky release, so if you are 
interested in this role, please reach out.


Thanks for your consideration.

--

Thanks,

Matt

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


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

[openstack-dev] [ara] Best practices on what to return from REST API ?

[David Moreau Simard]

Hi,

So I'm making what I think is good progress towards the python and
REST API implementation for ARA but now I have a question.
I've made the following API "GET" endpoints:

- files (saved Ansible files)
- hosts (hosts involved in playbooks and their facts, if available)
- playbooks (data about the actual playbook and ansible parameters)
- plays (data about plays)
- results (actual results like 'ok', 'changed' as well as the data
from the Ansible module output)
- tasks (data about the task, like name, action and file path)

Each endpoint is self-sufficient and allows consumers to search
individual endpoints as required, for example:
(See attached links for actual and real output)

- GET /api/v1/plays # [1] List all plays
- GET /api/v1/plays?id=1 # [2] Get play with id 1
- GET /api/v1/plays?playbook_id=1 # [3] List all plays for playbook_id 1

The mechanism and logic is the same for all endpoints.
Where I get a bit doubtful is because some components have
relationships, like the following:

- files have file contents (file.content) [4]
- hosts have facts (host.facts) [5]
- tasks have results (task.results) [6]
- playbooks basically aggregate everything (playbook.files,
playbook.hosts, playbook.plays, playbook.results, playbook.tasks) so
it's potentially huge.

So, what is the best practice here ?
I'm thinking that returning all the available data on a LIST call (GET
/api/v1/playbooks) is nuts because of the potential amount of data
involved.

I'm torn between two different approaches but I would be happy to be
convinced there's a better way.

1) Only return "child" resources on specific call
So, when doing a GET on something that is expected to return a list
(GET /api/v1/playbooks), do not return child resources.
And, when doing a GET on the specific resource (GET
/api/v1/playbooks?id=1), display all the child resources.
This would be sort of analogous to how python-openstackclient has
different fields when doing "openstack server list" and "openstack
server show".

However, the amount of data for even a single playbook is likely very
significant at scale.

2) Require sub calls for different components
In this method, we would not return child resources when doing a list
call (GET /api/v1/playbooks) or when doing a specific call (GET
/api/v1/playbooks?id=1).
To get child resources, you would need to pick them up one by one, ex:

for playbook in playbooks:
   files = FileApi.get(playbook_id=playbook['id']
   hosts = HostApi.get(playbook_id=playbook['id']
   plays = PlayApi.get(playbook_id=playbook['id']
   [...]

I feel like approach #2 would be best -- for running at scale but also
in the context of loading data asynchronously and concurrently.

Any opinions ?

Thanks !

[1]: http://paste.openstack.org/raw/617868/
[2]: http://paste.openstack.org/raw/617869/
[3]: http://paste.openstack.org/raw/617870/
[4]: http://paste.openstack.org/raw/617871/
[5]: http://paste.openstack.org/raw/617872/
[6]: http://paste.openstack.org/raw/617873/

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]

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

Re: [openstack-dev] [elections] [puppet] Candidacy for Puppet OpenStack PTL (Queens)

[Emilien Macchi]

On Wed, Aug 2, 2017 at 6:19 AM, Mohammed Naser  wrote:
> I would like to nominate myself for the PTL role for the Puppet OpenStack team
> for the Queens release cycle.

I'm super happy to see someone stepping up on this one, specially a
Puppet OpenStack user & contributor coming from operator world.
You can count on the Puppet OpenStack team, Alex and me to assist you
in any thing we can help.

Thanks,
-- 
Emilien Macchi

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

Re: [openstack-dev] [TripleO] FFE for OVN container support

[Emilien Macchi]

On Tue, Aug 8, 2017 at 7:05 AM, Numan Siddique  wrote:
> I would like to request FFE exception for OVN containerized support. OVN is
> an optional feature and should be a low risk.
>
> The patches can be found here -
> https://review.openstack.org/#/q/topic:bug/1699085

I checked all the patches and indeed they aren't intrusive enough to
break anything. I think this is fine.
Give us a bonus and bring-up scenario007 working on containers (
https://review.openstack.org/#/c/490622 ) - it would be *awesome* :-)

Anyway, +1 on my side for this code to land in Pike. Any feedback from
the team is welcome though.
-- 
Emilien Macchi

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

[openstack-dev] [chef] Proposing Lance Albertson (Ramareth) for openstack-chef-core

[Samuel Cassiba]

Ohai!

In openstack-chef-land, we generally don't use the ML very often,
being so few; thus, when there's an occasion to send something, it
better be worth it.

I am proposing adding Lance Albertson (otherwise known as Ramareth on
IRC and most other places I frequent) to openstack-chef-core. In
another life, he is the Director of the OSU Open Source Lab.

That would bring our core count up to four, but it's just a mirage.
None of us can dedicate our full, or even quarter time to this
project, which already requires a certain level of exposure to not
only the nuances of Chef and Ruby, but the quirks of OpenStack and
Python. However, we do what we can, when we can, how we can.

Any feedback is welcome. If there are no reasons otherwise, Lance will
be added to the core group in a few days.

-- 
Best,
Samuel Cassiba

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

Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes

[joehuang]

Dims,

Integration of keystone and kubernetes is very cool and in high demand. Thank 
you very much.

Best Regards
Chaoyi Huang (joehuang)


From: Davanum Srinivas [dava...@gmail.com]
Sent: 01 August 2017 18:03
To: kubernetes-sig-openst...@googlegroups.com; OpenStack Development Mailing 
List (not for usage questions)
Subject: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone based 
Authentication and Authorization for Kubernetes

Team,

Having waded through the last 4 attempts as seen in kubernetes PR(s)
and Issues and talked to a few people on SIG-OpenStack slack channel,
the consensus was that we should use the Webhook mechanism to
integrate Keystone and Kubernetes.

Here's the experiment : https://github.com/dims/k8s-keystone-auth

Anyone interested in working on / helping with this? Do we want to
create a repo somewhere official?

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

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

Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes

[feisky]

Cool. Which keystone version is supported? v2.0 or v3? or both?

在 2017年8月1日星期二 UTC+8下午6:03:10，Davanum Srinivas写道：
>
> Team, 
>
> Having waded through the last 4 attempts as seen in kubernetes PR(s) 
> and Issues and talked to a few people on SIG-OpenStack slack channel, 
> the consensus was that we should use the Webhook mechanism to 
> integrate Keystone and Kubernetes. 
>
> Here's the experiment : https://github.com/dims/k8s-keystone-auth 
>
> Anyone interested in working on / helping with this? Do we want to 
> create a repo somewhere official? 
>
> 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

[openstack-dev] [keystone] office hours report 2017-08-08

[Lance Bragstad]

Hi all,

Today we had good focus on RC1 bugs. We spent most of the keystone
meeting and all of office hours discussing or reviewing fixes. Full logs
can be found at the bottom of the note [0]. Here's a summary of what we
accomplished:


Bug #1674676 in OpenStack Identity (keystone): "The URL listed against
the details of identity resources returns 404 Not Found error"
https://bugs.launchpad.net/keystone/+bug/1674676
gagehugo picked up this work and submitted a patch for review.

Bug #1689644 in OpenStack Identity (keystone): "Keystone does not report
microversion headers"
https://bugs.launchpad.net/keystone/+bug/1689644
Since keystone doesn't support microversions, it was determined that it
doesn't make sense for keystone to emit microversion headers and mislead
users. We documented the outcome of this discussion in the bug and we're
going to pick it back up in Denver at the PTG.

Bug #1694525 in OpenStack Identity (keystone): "keystone reports 404
User Not Found during grenade tests"
https://bugs.launchpad.net/keystone/+bug/1694525
This issue hasn't surfaced in a while and we decided to mark it as
Invalid. In the event it resurfaces, we will reopen and investigate, but
for now this isn't something we're going to hold the release up over.

Bug #1705072 in OpenStack Identity (keystone): "clearing default
project_id from users using wrong driver implementation"
https://bugs.launchpad.net/keystone/+bug/1705072
Proposed a fix to close this issue, ready for review.

Bug #1673157 in OpenStack Identity (keystone): "type: local must be set
in order to get domain parsed when mapping federated users"
https://bugs.launchpad.net/keystone/+bug/1673157
Reviewed and merged a fix to close this issue.

Bug #1692090 in OpenStack Identity (keystone): "_dn_to_id ignores
user_id_attribute"
https://bugs.launchpad.net/keystone/+bug/1692090
Discussed and determined this is likely an issue that can be fixed with
configuration. Responded asking for more configuration information.

Bug #1696308 in OpenStack Identity (keystone): "list revoked tokens API
returns 500 when pki_setup is not run"
https://bugs.launchpad.net/keystone/+bug/1696308
Linked to a fix in review.

Bug #1700852 in OpenStack Identity (keystone): "Slow listing projects
for user with many role assignments"
https://bugs.launchpad.net/keystone/+bug/1700852
Proposed a fix and updated based on reviews.

With that, every reproducible issue that we've targeted to rc1 has a fix
in flight. By the EOD tomorrow we should be nearly ready to cut rc1.

[0]
http://eavesdrop.openstack.org/meetings/keystone_office_hours/2017/keystone_office_hours.2017-08-08-19.00.log.html



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

[openstack-dev] [all][pack-deb][storlets][tacker][telemetry] Last day for PTL candidate announcements

[Emmet Hikory]

This is the last reminder of the impending conclusion of the PTL candidate
announcement period.  This is now the last day for nominations.

If you want to stand for PTL, follow the posted instructions [1]
before 23:45 UTC, 9th August to make sure the community knows your
intentions.  To ensure your candidacy is merged by the deadline, you
may wish to allow some time for reviews after submission.

Those four projects still without nominated candidates at the conclusion of
this period will be subject to the Technical Committee procedures for
leaderless projects [2].

Thank you.

-- 
Emmet HIKORY

1: http://governance.openstack.org/election/#how-to-submit-your-candidacy
2: 
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html

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

Re: [openstack-dev] [vitrage] stable/pike branch for vitrage

[Tony Breeds]

On Tue, Aug 08, 2017 at 08:17:48AM +, Afek, Ifat (Nokia - IL/Kfar Sava) 
wrote:
> Hi,
> 
> I’m going to create stable/pike branches for vitrage and vitrage-dashboard 
> tomorrow or the day after.
> If you have changes that should enter Pike, try to push them today. After 
> that, we will be able to fix Pike bugs on top of stable/pike for two more 
> weeks.
> Please do not merge changes that should enter Queens until the stable/pike 
> branches are created.

Are you going to use the branch creation process in openstack/releases
or do it yourself?

Yours Tony.


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

Re: [openstack-dev] [refstack][interop-wg] Candidacy for RefStack PTL

[Chris Hoge]

Catherine, 

Thank you for the amazing work you’ve done over the last two years. As we 
discussed
in the RefStack meeting today, I’ve submitted my candidacy for RefStack PTL to 
the
election repository. I will consider myself lucky to be even a fraction of the 
leader you
were for this project. Thank you.

-Chris

—

I am submitting my self nomination to serve as the RefStack PTL for
the Queens development cycle. RefStack is in a period of transition,
with much of the core team being assigned to other projects, including
the long-standing PTL. While I have few contributions to the project,
I have been an active participant and advisor to the project since I
began working with the Interop Working Group (formerly DefCore).

For the Queens cycle, I will focus on rebuilding a core team of
developers, and looking to the future of RefStack as an OpenStack
project and how it fits into the larger ecosystem. With many of the
features of RefStack complete, we will investigate the possibility
of moving the project into a mainteance state under the governance of
the Interop Working Group.

Thank you,

Chris Hoge
Interop Engineer
OpenStack Foundation

> On Aug 2, 2017, at 12:15 PM, Catherine Cuong Diep  wrote:
> 
> Hi Everyone,
> 
> As I had announced in the RefStack IRC meeting a few weeks ago, I will not 
> run for RefStack PTL in the upcoming cycle. I have been PTL for the last 2 
> years and it is time to pass the torch to a new leader.
> 
> I would like to thanks everyone for your support and contribution to make the 
> RefStack project and interoperability testing a reality. We would not be 
> where we are today without your
> commitment and dedication.
> 
> I will still be around to help the project and to work with the next PTL for 
> a smooth transition. 
> 
> Catherine Diep
> 
> __
> OpenStack Development Mailing 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][vpnaas] pike rc

[Armando M.]

On 8 August 2017 at 14:21, Takashi Yamamoto  wrote:

> On Wed, Aug 9, 2017 at 12:35 AM, Armando M.  wrote:
> >
> >
> > On 8 August 2017 at 02:34, Akihiro Motoki  wrote:
> >>
> >> I proposed a project-config patch to allow us to release neutron-vpnaas.
> >> https://review.openstack.org/#/c/491670/
> >> There is a missing configuration when neutron-vpnaas was pushed out
> >> from the neutron stadium.
> >> Once the patch is merged and -release group are setup, we can release
> >> neutron-vpnaas by ourselves.
> >
> >
> > Is this strictly necessary? I don't see these in other gerrit ACLs
> > (irrespective of whether they are part of neutron or not). My
> understanding
> > is that the release can be fully managed by the openstack release team
> once
> > a patch like [1] is posted to the openstack/releases project.
> >
> > [1] https://review.openstack.org/#/c/491429/
>
> my understanding is it's necessary for hosted projects
> because they are not managed by openstack/releases.
> unlike neutron-vpnaas, networking-hyperv is an official project. [2]
>
> [2] https://github.com/openstack/governance/commit/
> c84d0a702f536a43324212f803e0a43a640c9b56
>
>
Yes, I ended up picking up a bad example, fault of my stale knowledge of
the governance repo.


> >
> >
> >>
> >>
> >> Akihiro
> >>
> >> 2017-08-08 10:46 GMT+09:00 Takashi Yamamoto :
> >> > hi,
> >> >
> >> > can anyone with an appropriate permission create a stable/pike
> >> > and pike rc1 for neutron-vpnaas?
> >> >
> >> > stable/pike
> >> > 11.0.0.0rc1
> >> > openstack/neutron-vpnaas
> >> > 8278615c1f35f98447a3f9692a78ab45e90ee8c6
> >> >
> >> > thank you.
> >> >
> >> >
> >> > 
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing 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] [neutron][vpnaas] pike rc

[Takashi Yamamoto]

On Wed, Aug 9, 2017 at 12:35 AM, Armando M.  wrote:
>
>
> On 8 August 2017 at 02:34, Akihiro Motoki  wrote:
>>
>> I proposed a project-config patch to allow us to release neutron-vpnaas.
>> https://review.openstack.org/#/c/491670/
>> There is a missing configuration when neutron-vpnaas was pushed out
>> from the neutron stadium.
>> Once the patch is merged and -release group are setup, we can release
>> neutron-vpnaas by ourselves.
>
>
> Is this strictly necessary? I don't see these in other gerrit ACLs
> (irrespective of whether they are part of neutron or not). My understanding
> is that the release can be fully managed by the openstack release team once
> a patch like [1] is posted to the openstack/releases project.
>
> [1] https://review.openstack.org/#/c/491429/

my understanding is it's necessary for hosted projects
because they are not managed by openstack/releases.
unlike neutron-vpnaas, networking-hyperv is an official project. [2]

[2] 
https://github.com/openstack/governance/commit/c84d0a702f536a43324212f803e0a43a640c9b56

>
>
>>
>>
>> Akihiro
>>
>> 2017-08-08 10:46 GMT+09:00 Takashi Yamamoto :
>> > hi,
>> >
>> > can anyone with an appropriate permission create a stable/pike
>> > and pike rc1 for neutron-vpnaas?
>> >
>> > stable/pike
>> > 11.0.0.0rc1
>> > openstack/neutron-vpnaas
>> > 8278615c1f35f98447a3f9692a78ab45e90ee8c6
>> >
>> > thank you.
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing 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] [docs] importing openstack-manuals questions, looking for strategies

[Sean Dague]

When trying to import
https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/compute/hypervisor-vmware.rst#L2
into the Nova admin config reference
(https://review.openstack.org/#/c/491853), a couple of interesting
challenges popped up. These pop up in a couple of other places, but this
one file nicely contains both of them.

The first is the common autogenerated files (like
https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/tables/nova-vmware.rst#L11).
To the best of my knowledge we don't have that autogeneration tooling in
the projects. Should we just be copy/pasting this content in? Is there
another better strategy there?

The second is cross references that don't yet exist. In this case -
https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/compute/hypervisor-vmware.rst#L981.
Which is :ref:`block_storage_vmdk_driver`, that would be in the cinder
manual, but does not seem to yet be there. I'm not sure what the best
strategy is here. Just a TODO to find the right cinder ref once it shows up?

If anyone has thoughts on the best resolutions here, that would be great.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [nova] Self-nomination for PTL in Queens

[Matt Riedemann]

Hi everyone,

This is my self-nomination to continue running as Nova PTL for the 
Queens cycle.


If elected, this would be my fourth term as Nova PTL. While I try to 
continually improve, at this point I have a fairly steady way of doing 
things and most people are probably used to that by now. That's not to 
say it's the best way of doing things, so I'm always open to getting 
feedback on what people would like to see more (or less) of from me.


I really see this as a service role and I'm happy to continue being of 
service for another release, which includes preparing for the PTG and 
Forum, being aware of the schedule and communicating major changes or 
plans to various groups (developers, operators, Foundation staff, etc).


I'm also happy to say that I'm fortunate enough to have an employer that
supports me doing this again and the amount of time it takes working 
mostly full time in the community.


As for Queens content, we made a lot of progress again in Pike but some 
things are left undone and that's what I'd like to focus on in Queens. 
Specifically:


- Continue to evolve and solidify Nova's interaction with the Placement
  service, which includes getting the allocations code out of the
  compute service, fully supporting shared storage providers (and
  testing that in the Ceph CI job), and finally adding the nested
  resource providers support which will enable other features like vGPUs
  and other hardware-accelerated configurations.
- Close some gaps in our multi-cell support, mainly related to up-calls
  for reschedules during build and affinity/anti-affinity sanity checks,
  and also work on real multi-cell deployment testing in a multi-node CI
  job.
- Finish the Cinder 3.27 API integration early (before the PTG) so we
  can finally get volume multi-attach support.
- Cleanup the documentation now that it has moved in-tree.

Finally, a personal goal for me is going to be working on helping mentor 
someone into the PTL role for the Rocky release, so if you are 
interested in this role, please reach out.


Thanks for your consideration.

--

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] [tc] [all] TC Report 32

[Chris Dent]

(Rendered Version: https://anticdent.org/tc-report-32.html )

As we are still in the heady peak of the release cycle, there's not a
great deal of Technical Committee activity to report, but I've dredged
through some IRC logs to find a couple of bits that might be relevant
to the slicke of governance activity that might actually be interesting to
a broader audience.

# Continuous Deployment

In a thread on [Backwards incompatible changes based on
config](http://lists.openstack.org/pipermail/openstack-dev/2017-August/120678.html),
Joshua Harlow chose to ask one of those questions it's worth asking
every now and again: [Who are these continuous
deployers?](http://lists.openstack.org/pipermail/openstack-dev/2017-August/120705.html).
If they still exist, where are they, how do we get them to step up and
participate? If nobody is doing it any more, can we stop and make
between-release adjustments more easily?

The mailing list thread petered out, as they are wont to do, but the
topic carried over to IRC. In the [#openstack-tc
channel](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-08-07.log.html#t2017-08-07T12:47:11)
the conversation went long and wide:

* Even if there aren't people who do real deploys from trunk, the
  constraints imposed by behaving as if they do may be beneficial.
* If we stop the behavior, it is very hard to go back.
* Some people say we historically supported CD. Other people say that
  sure, some people say that, but only _some_ people.
* Or maybe the divisions are between projects?
* APIs and database migrations are in a different class from
  everything else and they themselves are different from one another.
* Whatever the behaviors have been, they've never been official (for
  all projects?).
* Whatever the behavior should be, it needs to be official (for all
  projects?).

For each of these strongly asserted opinions, there was at least one
person who disagreed, at least in part. Fun times.

As far as I could tell, there was no resolution or forward plan. The status quo
of benign (?) ambiguity will maintain for the time being. When it hurts,
something will happen.

# Forthcoming Meetings With the Board

A [Foundation list
posting](http://lists.openstack.org/pipermail/foundation/2017-August/002512.html)
asked for agenda items for the combined Board and Leadership (TC and
UC) [meeting happening before the
PTG](https://wiki.openstack.org/wiki/Governance/Foundation/10Sep2017BoardMeeting).
Details about a similar meeting [in
Sydney](https://wiki.openstack.org/wiki/Governance/Foundation/5Nov2017BoardMeeting)
are also starting to cohere.

Yet as far as I can tell, very little has yet been gathered in terms
of substantive agenda items. Given how often different members of the
community state that we need to be more activist with the board, and
the board with member companies -- especially with regard to making
sure corporate engagement is not just strong but focused in the right
place -- I'm surprised there's not more. [I fished around a bit in
IRC](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-08-08.log.html#t2017-08-08T11:14:06)
but I think there's more to be done here.

As a community we've become over adapted to the idea that people who
wish to discuss problems should come prepared with solutions, or if
not that, at least a detailed description of the failure scenario.
This is incredibly limiting. Community interactions aren't software.
We can't always create a minimal test case and iterate towards a
solution. Sometimes what we need is to sit around as peers and
reflect. In person is the ideal time for this; we don't get the
opportunity all that much.

What I'd like to see with the board, the TC, the UC, and anyone else
who wants to participate is a calm retrospective of the last three,
six or twelve months. So we can see where we need to go from here. We
can share some accolades and, if necessary, air some grievances.
Someone can say "there's a rough edge here" so someone else with a lot
of spare sandpaper they thought was useless can say "I can help with
that". We might even sing Kum ba yah.

If you're not going to be at the PTG, or you don't feel comfortable
raising an issue, feel free to contact me with anything you think is
important and relevant to the ongoing health of OpenStack and I will
try to bring it up at one of the meetings.

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [election][horizon][ptl] Queens PTL candidacy

[Ying Zuo (yinzuo)]

Hi everyone,

I would like to announce my candidacy for PTL of Horizon for Queens; Rob 
Cresswell will be supporting me as co-PTL.

I have been actively contributing to Horizon for over two years and became a 
core developer during the Pike cycle, as well as maintaining downstream 
customizations for Horizon. This gives me a good understanding of both upstream 
and downstream concerns.

As PTL of Horizon, I would like to drive Horizon’s development in the following 
areas:

- Complete work on the Angular overview and instances panel that has been 
started, as these currently suffer from poor performance
- Ensure Horizon continues to be a robust and highly customizable dashboard
- Keep up with the updates in other OpenStack projects; during Pike, we began 
work on adding support for Neutron QoS and Trunk ports, which we should 
complete early in the Queens cycle.
- Maintain an accurate blueprint list and invest more time in bug triage

I am grateful for Rob’s help in taking on this responsibility and I look 
forward to working with you all to make Horizon a better OpenStack dashboard in 
the Queens release.


Regards,
Ying

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

Re: [openstack-dev] [release][ptl] tools for creating new releases

[Doug Hellmann]

Excerpts from Armando M.'s message of 2017-08-08 08:48:34 -0700:
> On 8 August 2017 at 06:30, Doug Hellmann  wrote:
> 
> > We realized recently that we haven't publicized some of the tools
> > in the releases repository very well. One tool that will be useful
> > this week as you prepare your release candidates is the 'new-release'
> > command, which edits a deliverable file to add a new release from
> > HEAD of the given branch, automatically computing the next verison
> > number based on the inputs.
> >
> > Use the ``venv`` tox environment to run the tool, like this:
> >
> >$ tox -e venv -- new-release SERIES DELIVERABLE TYPE
> >
> > The SERIES value should be the release series, such as "pike".
> >
> > The DELIVERABLE value should be the deliverable name, such as
> > "oslo.config" or "cinder".
> >
> > The TYPE value should be one of "bugfix", "feature", "major",
> > "milestone", or "rc".
> >
> > If the most recent release of cinder during the pike series is
> > 11.0.0.0b3 then running:
> >
> >$ tox -e venv -- new-release pike cinder rc
> >
> > detects that this is the first release candidate and updates the
> > file deliverables/pike/cinder.yaml with the new release 11.0.0.0rc1
> > and instructions to create a new stable branch at that tag.
> >
> > There are some more details in the README.rst file in the releases
> > repository, and as usual you'll find us in #openstack-release if you
> > have questions.
> >
> 
> I tried it and it works like a charm, though I noticed some harmless side
> effects in that changes [1] in my patch showed up unsolicited.

Changing booleans from true/false to yes/no is a side-effect of
some of the settings in the YAML formatter.

Doug

> 
> Cheers,
> Armando
> 
> [1]
> https://review.openstack.org/#/c/491560/1/deliverables/pike/networking-bgpvpn.yaml@7
> 
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >

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

Re: [openstack-dev] [python-openstackclient][python-openstacksdk][neutron] supporting resource extensions with our CLI

[Boden Russell]

On 8/8/17 10:29 AM, Akihiro Motoki wrote:
> My reply applies to 'resource' extension but does not apply to
> 'attribute extension'

My apologies for using confusing terminology; as you pointed out we
don't currently have a good solution for attribute extensions with OSC
and I've tried to outline the technicals in the RFE style bug [1] where
I hope we can continue this discussion.

python-neutronclient does support these attribute extensions, but as of
today neutronclient gives deprecation warnings when used; so users are
"concerned" when they see this and we don't have a complete story for
OSC. Perhaps we can suppress those deprecations until we figure out a
path forward?

Thanks


[1] https://bugs.launchpad.net/neutron/+bug/1705755

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

Re: [openstack-dev] [api] [tc] Nominatimg Eric Fried for service-types-authority core

[Doug Hellmann]

Excerpts from Chris Dent's message of 2017-08-08 16:35:18 +0100:
> 
> I don't believe we have an established procedure for core
> nominations in the service-types-authority group, so I'll just go
> ahead and take the initiative. I think we should make Eric Fried
> (efried on IRC) a core in that group. He's been doing a great deal
> of work related to service types and service catalog, is around all the
> time, and would be a worthy addition.
> 
> If you don't like this idea but would like to say so privately,
> please contact me. Otherwise I'll give a few days and make it so.

+1 for adding Eric.

> 
> The [tc] tag is on here because the repo is considered "owned by the
> technical committee".
> 
> We may also wish to consider removing Anne Gentle and Brant Knudson
> who are less available these days.
> 

I don't have a problem with removing them, but it would be good to
confirm whether they expect to have more time in queens before we do.

Doug

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

Re: [openstack-dev] [Cyborg]Queens PTL candidacy

[Harm Sluiman]

Howard, I guess you will need some +1 votes and I certainly support you
based on our joint early work on these projects.
I regret not having time to participate actively this year. However your
contribution has been great for the project and the OpenStack community

On Thu, Aug 3, 2017 at 3:55 AM, Zhipeng Huang  wrote:

> Yes tony I was intended to refer to the official procedure for the
> self-nomination period, which would be 5 buiz days.
>
> Thx for the offer to help with the civs poll :)
>
> On Thu, Aug 3, 2017 at 3:11 PM, Tony Breeds 
> wrote:
>
>> On Thu, Aug 03, 2017 at 11:59:55AM +0800, Zhipeng Huang wrote:
>> > Hi Team,
>> >
>> > Even though Cyborg is not an official project yet, however with an
>> ultimate
>> > goal of becoming one it is necessary to conduct our project governance
>> with
>> > compliance of OpenStack community general requirements/culture.
>>
>> You didn't specify how long the self-nomination period is.  I assume
>> you're going for 5 business days?
>>
>> So any self nominations need to be in within a week from now
>>
>> Yours Tony.
>>
>> 
>> __
>> 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
>>
>>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Product Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [api] [tc] Nominatimg Eric Fried for service-types-authority core

[Jeremy Stanley]

On 2017-08-08 16:35:18 +0100 (+0100), Chris Dent wrote:
> I don't believe we have an established procedure for core
> nominations in the service-types-authority group, so I'll just go
> ahead and take the initiative. I think we should make Eric Fried
> (efried on IRC) a core in that group. He's been doing a great deal
> of work related to service types and service catalog, is around all the
> time, and would be a worthy addition.
[...]

Agreed, I've witnessed it first hand and feel like he has a good
handle on what's going on with that.

> We may also wish to consider removing Anne Gentle and Brant Knudson
> who are less available these days.

This makes sense, and I expect they're welcome back any time if they
wish to resume their involvement on it in the future.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

[Akihiro Motoki]

2017-08-08 23:12 GMT+09:00 Akihiro Motoki :
> 2017-08-08 22:41 GMT+09:00 Boden Russell :
>> On 8/7/17 10:39 PM, Clint Byrum wrote:
>>> If the thing you're doing doesn't fit in the mainline API, then what
>>> you're doing is making a new API. Extensions just bypass the important
>>> part where that API gets designed and thought through.
>>
>> Irrespective of opinions as to if API extensions are good or not, the
>> fact of the matter is we support them in neutron today and as a result
>> we have users that rely on them as well as the ability to interface
>> (CLI) with such extensions via python-neutronclient. That said, I think
>> this concern has been heard [1] and we will work to address it
>> short-to-mid term.
>
> I totally agree with other comments that all API features should be 
> upstreamed.
>
> Replying to Boden's question on the short-term solution.
> If you need CLI support, you can implement OSC plugin to support your
> API extensions
> rather than extending OSC or OSC plugin provided by python-neutronclient.
> If you need SDK support, you can provide your own python bindings
> (perhaps it will be most stable)
> or continue to use the python-neutronclient CLI extension mechanism
> (which extends methods
> based on "neutronclient.extension" entry points.
>
> Does it answer to you, Boden?

My above reply does not answer the original question.
The subject of the thread says "resource extension" but this is
actually on attribute extension.
My reply applies to 'resource' extension but does not apply to
'attribute extension'

>
> Akihiro
>
>> As to neutron's longer-term goals W/R/T API extensions; I can't speak to
>> that.
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-August/120759.html
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] 503 Errors for PUT and POST calls....

[Clay Gerrard]

Probably the "devices" option in the object server is misconfigured?

On my lab and production servers I configure the object-server.conf with

[DEFAULT]
devices = /srv/node

And then I make sure my mounted devices appear at:

/srv/node/d1
/srv/node/d2
/srv/node/d3

etc

The path in the error message:

/srv/xvdb1/node/xvdb1/

Looks like the object-server.conf is configured with:

devices = /srv/xvdb1/node

And the ring has devices like "xvdb1"

But as the error states: "No such file or directory at"

devices + device => /srv/xvdb1/node/xvdb1/...

And I trust the error that the path doesn't exist (or if it does maybe the
swift processes don't have permissions?)

Hope you can get it squared.  You might jump in IRC and join
#openstack-swift on Freenode for some more iterative feedback (I'd
recommend irccloud.com if you're new to IRC).

GL,

-Clay


On Tue, Aug 8, 2017 at 2:54 AM, Shyam Prasad N 
wrote:
>
> Hi,
>
> In my openstack swift cluster, I'm seeing a lot of 503 errors as a
> result of tracebacks in swift logs with "No such file or directory"
> exceptions...
> # grep -Rnw txdaba05e70c6b4dfaa5884-0059895aca /var/log/swift/*
> /var/log/swift/proxy.error:31030:Aug  7 23:31:39
> BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c proxy-server: ERROR 500
> Traceback (most recent call last):#012  File
> "/usr/lib/python2.7/dist-packages/swift/obj/server.py", line 1032, in
> __call__#012res = method(req)#012  File
> "/usr/lib/python2.7/dist-packages/swift/common/utils.py", line 1412,
> in _timing_stats#012resp = func(ctrl, *args, **kwargs)#012  File
> "/usr/lib/python2.7/dist-packages/swift/obj/server.py", line 751, in
> PUT#012writer.put(metadata)#012  File
> "/usr/lib/python2.7/dist-packages/swift/obj/diskfile.py", line 2451,
> in put#012super(DiskFileWriter, self)._put(metadata, True)#012
> File "/usr/lib/python2.7/dist-packages/swift/obj/diskfile.py", line
> 1476, in _put#012self._finalize_put, metadata, target_path,
> cleanup)#012  File
> "/usr/lib/python2.7/dist-packages/swift/common/utils.py", line 3342,
> in force_run_in_thread#012return self._run_in_eventlet_tpool(func,
> *args, **kwargs)#012  File
> "/usr/lib/python2.7/dist-packages/swift/common/utils.py", line 3322,
> in _run_in_eventlet_tpool#012raise result#012OSError: [Errno 2] No
> such file or directory#012 From Object Server re:
>
/v1/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1
> 10.3.60.8:6010/xvdb1 (txn: txdaba05e70c6b4dfaa5884-0059895aca)
> (client_ip: 10.3.60.11)
> /var/log/swift/proxy.error:31031:Aug  7 23:31:39
> BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c proxy-server: Object
> PUT returning 503 for [500, 201] (txn:
> txdaba05e70c6b4dfaa5884-0059895aca) (client_ip: 10.3.60.11)
> /var/log/swift/proxy.error:31032:Aug  7 23:31:39
> BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c proxy-server: STDERR:
> 10.3.60.11 - - [08/Aug/2017 06:31:39] "PUT
>
/v1/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1
> HTTP/1.1" 503 346 1.553481 (txn: txdaba05e70c6b4dfaa5884-0059895aca)
> /var/log/swift/proxy.log:27701:Aug  7 23:31:39
> BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c proxy-server:
> 10.3.60.11 10.3.60.11 08/Aug/2017/06/31/39 PUT
>
/v1/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1
> HTTP/1.0 503 - - AUTH_tke6014ecd5... 16777216 118 -
> txdaba05e70c6b4dfaa5884-0059895aca - 1.5526 - - 1502173898.383203983
> 1502173899.935844898 0
> /var/log/swift/storage1.log:41634:Aug  7 23:31:39
> BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c object-server:
> 10.3.60.8 - - [08/Aug/2017:06:31:39 +] "PUT
>
/xvdb1/118/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1"
> 500 981 "PUT
http://10.3.60.8:8080/v1/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1
"
> "txdaba05e70c6b4dfaa5884-0059895aca" "proxy-server 2117" 1.0534 "-"
> 2127 0
> /var/log/swift/storage2.log:128852:Aug  7 23:31:39
> BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c container-server:
> 10.3.60.9 - - [08/Aug/2017:06:31:39 +] "PUT
>
/xvdb2/972/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1"
> 201 - "PUT
http://10.3.60.8:8080/xvdb2/118/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1
"
> "txdaba05e70c6b4dfaa5884-0059895aca" "object-server 1728" 0.0006 "-"
> 2099 0
>
> I'm also seeing some errors removing tempfile errors in storage logs
also...
> Aug  8 02:28:15 BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c
> object-server: Error removing tempfile:
> /srv/xvdb1/node/xvdb1/tmp/tmpFouKzU: #012Traceback (most recent call
> last):#012  File
> "/usr/lib/python2.7/dist-packages/swift/obj/diskfile.py", line 2396,
> in create#012os.unlink(tmppath)#012OSError: [Errno 2] No such file
> or directory: '/srv/xvdb1/node/xvdb1/tmp/tmpFouKzU' (txn:
> tx860a415e4c454baeab4fc-005989842e)
>

Re: [openstack-dev] [requirements][mistral][heat][tripleo][trove][murano][solum][tacker] Releasing python-mistralclient 3.1.2

[Matthew Thode]

On 17-08-08 08:03:42, Matthew Thode wrote:
> On 17-08-08 16:11:53, Renat Akhmerov wrote:
> > Hi,
> > 
> > We recently sent a patch [1] to release the version 3.1.2 of 
> > python-mistralclient out of Pike branch. It was done after the date of 
> > final client library releases so we’d like to discuss if we can allow such 
> > an exception. All the projects mentioned in the subject may be affected so 
> > please share if the change is acceptable for you or not. Details are below.
> > 
> > When using Mistral CLI in real deployments we found that some of the list 
> > commands may be extremely heavy (mostly memory footprint) when called w/o 
> > the “limit” parameter that constrains the result set by the specified 
> > value. For example, “mistral execution-list”, “mistral task-list” and 
> > “mistral action-execution-list”. We saw a number of times that machines 
> > went out of memory after running such a command, sometimes it was done by 
> > mistake by operators. So we decided to set a default value for this 
> > parameter, which is currently 100, to prevent from unintentional execution 
> > of such heavy commands. The corresponding patch [2] was sent on July 11 and 
> > was included in the release 3.1.1. For “action-execution-list”, before this 
> > patch “limit" parameter didn’t exist at all so we added it too. However, 
> > the change wasn’t made properly so that “limit” parameter was just ignored 
> > at all times. We fixed that in [3] and decided to release 3.1.2.
> > 
> > So long story short, this change will affect your project only if you use 
> > “mistral action-execution-list” CLI command because now this command will 
> > be returning by default only 100 entries (to return all “--limit=-1” needs 
> > to be passed).
> > 
> > We at Nokia need this fix released in Pike because we need to trigger 
> > updates of RDO packages used in our system.
> > 
> > 
> > The question: can we afford to make this release now?
> > 
> > More details on requirements updates etc. you can see in the discussion in 
> > [1].
> > 
> > [1] https://review.openstack.org/#/c/491269
> > [2] https://review.openstack.org/#/c/476110/
> > [3] https://review.openstack.org/#/c/489217/
> > 
> > Thanks
> > 
> > Renat Akhmerov
> > @Nokia
> 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> It sounds like you will need a requirements update as well, both UC and
> maybe GR.  GR would suck at this VERY late point.  The current minimum
> is 3.1.0 will that not work just like 3.1.1 doesn't work?
> 
> -- 
> Matthew Thode (prometheanfire)

ok, after discussing in irc...

3.1.2 has a user interface only change fixing a regression in 3.1.1 that doesn't
not exist in 3.1.0, so no GR bump is needed.

I'm fine with requirements doing a UC only bump here.

FFE allowed for requirements for UC only (my vote)

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [neutron] - FFE for networking-bagpipe, support for MPLS-over-GRE

[Kevin Benton]

This change looks good to me since it's quite small. Make sure you leave
feedback on Armando's release patch to update the hash for the this repo
before Thursday.

On Tue, Aug 8, 2017 at 8:16 AM,  wrote:

> Hi PTL/all,
>
> I would like to request an exception for inclusion in Pike, of MPLS/GRE
> support in networking-bagpipe.
>
> The feature consists in allowing the use of a new OVS tunnel option
> added in the very recently released OVS 2.8.
>
> The code is ready, the only piece preventing the merge is that the
> fullstack functional test is not fully ready yet (but should be soon).
>
> The change: https://review.openstack.org/#/c/482571
> The RFE: https://bugs.launchpad.net/networking-bagpipe/+bug/1709338
>
> Thanks,
>
> -Thomas
>
>
> (not waiting for a confirmation that the process applies to stadium
> projects, because I'm already late to fill this in, being just back
> from PTO)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] - FFE requests for Pike

[Kevin Benton]

Yeah, the FFE process applies to stadium projects as well.

On Tue, Aug 8, 2017 at 8:07 AM,  wrote:

> Hi Kevin,
>
> Am I right to assume this applies to stadium projects as well ?
> (since they now are all under cycle-with-milestones)
>
> -Thomas
>
>
> Kevin Benton, 2017-07-30 23:52:
> > Hi all,
> >
> > If you have any Neutron-related FFE requests for Pike please send an
> > email to the dev list with [neutron] in the tag and FFE in the
> > subject like in [1]. We will discuss them in the drivers meetings.
> >
> >
> > 1. http://lists.openstack.org/pipermail/openstack-dev/2017-July/12031
> > 0.html
> >
> > Thanks,
> > Kevin Benton
> > _
> > _
> > 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
>
> 
> _
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] support for various glance image reference formats - do we need them all?

[Dmitry Tantsur]

Hi!

Thanks for raising this.

On 08/07/2017 02:47 PM, Pavlo Shchelokovskyy wrote:

Hi all,

currently our GlanceImageService seems to support several ways of defining a 
reference to glance image:


1) simple image UUID [0]
2) image UUID prefixed with 'glance://' protocol [1] (well, actually anything 
starting with 'glance://' and ending with '/')
3) full REST path to the image (as in 
http:///v2/images/), also used to extract the glance API 
address [2]


Support for #3 must surely be removed, as we are moving to API endpoint 
discovery from keystone catalog.
Besides I am pretty sure this code path can not actually be reached currently, 
as the 'is_glance_image' will ignore such image refs and return False for those 
[3], and 'get_image_service' would also not return the GlanceImageService 
instance for such image refs [4].
Hence the question - if it is unusable anyway now, should we execute the 
standard deprecation process when removing support for it or just remove right away?


If unsure, always use the standard process ;) Unless somebody is ready to set up 
DevStack, and try it out, and prove that it's completely and hopelessly broken.




As for the #1 and #2 I do not see any big difference between those, and proposed 
deprecating and eventually removing support for #2 ('glance://' scheme) as part 
of [5]. Two people in review already raised a concern about removing such support.


To be honest, I like glance:// more, as it makes it obvious where the 
image is coming from vs http://. I don't mind removing it too much, but I guess 
supporting it is not a lot of code, right?




Thus I'd like to ask a broader audience - do we need support for glance image 
references in 'glance://*' form? Is it actually used somewhere? What are 
the benefits of having it besides simple UUID?


[0] 
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/glance_service/service_utils.py#n149
[1] 
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/glance_service/service_utils.py#n155
[2] 
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/glance_service/service_utils.py#n160
[3] 
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/glance_service/service_utils.py#n208
[4] 
http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/image_service.py#n267

[5] https://review.openstack.org/#/c/467728

Cheers,

--
Dr. Pavlo Shchelokovskyy
Senior Software Engineer
Mirantis Inc
www.mirantis.com 


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




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

Re: [openstack-dev] [api] [tc] Nominatimg Eric Fried for service-types-authority core

[Davanum Srinivas]

+1 from me

On Tue, Aug 8, 2017 at 11:35 AM, Chris Dent  wrote:
>
> I don't believe we have an established procedure for core
> nominations in the service-types-authority group, so I'll just go
> ahead and take the initiative. I think we should make Eric Fried
> (efried on IRC) a core in that group. He's been doing a great deal
> of work related to service types and service catalog, is around all the
> time, and would be a worthy addition.
>
> If you don't like this idea but would like to say so privately,
> please contact me. Otherwise I'll give a few days and make it so.
>
> The [tc] tag is on here because the repo is considered "owned by the
> technical committee".
>
> We may also wish to consider removing Anne Gentle and Brant Knudson
> who are less available these days.
>
> --
> Chris Dent  (⊙＿⊙') https://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

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

Re: [openstack-dev] [release][ptl] tools for creating new releases

[Armando M.]

On 8 August 2017 at 06:30, Doug Hellmann  wrote:

> We realized recently that we haven't publicized some of the tools
> in the releases repository very well. One tool that will be useful
> this week as you prepare your release candidates is the 'new-release'
> command, which edits a deliverable file to add a new release from
> HEAD of the given branch, automatically computing the next verison
> number based on the inputs.
>
> Use the ``venv`` tox environment to run the tool, like this:
>
>$ tox -e venv -- new-release SERIES DELIVERABLE TYPE
>
> The SERIES value should be the release series, such as "pike".
>
> The DELIVERABLE value should be the deliverable name, such as
> "oslo.config" or "cinder".
>
> The TYPE value should be one of "bugfix", "feature", "major",
> "milestone", or "rc".
>
> If the most recent release of cinder during the pike series is
> 11.0.0.0b3 then running:
>
>$ tox -e venv -- new-release pike cinder rc
>
> detects that this is the first release candidate and updates the
> file deliverables/pike/cinder.yaml with the new release 11.0.0.0rc1
> and instructions to create a new stable branch at that tag.
>
> There are some more details in the README.rst file in the releases
> repository, and as usual you'll find us in #openstack-release if you
> have questions.
>

I tried it and it works like a charm, though I noticed some harmless side
effects in that changes [1] in my patch showed up unsolicited.

Cheers,
Armando

[1]
https://review.openstack.org/#/c/491560/1/deliverables/pike/networking-bgpvpn.yaml@7



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

[openstack-dev] [networking-sfc] Add extension to DB UT

[Vikash Kumar]

Hi All,

 I have added tap extension for https://blueprints.launchpad.
net/networking-sfc/+spec/sfc-tap-port-pair.

 I wanted to add extension for DB validation. Where should i add the
extension ? I tried adding extension here:

https://github.com/openstack/networking-sfc/blob/master/
networking_sfc/tests/unit/db/test_sfc_db.py#L281

  but seems thats not working.


I have validated the extension on devstack setup and it works as
expected.

   Any pointers ?

Regards,
Vikash
__
OpenStack Development Mailing 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][vpnaas] pike rc

[Armando M.]

On 8 August 2017 at 02:34, Akihiro Motoki  wrote:

> I proposed a project-config patch to allow us to release neutron-vpnaas.
> https://review.openstack.org/#/c/491670/
> There is a missing configuration when neutron-vpnaas was pushed out
> from the neutron stadium.
> Once the patch is merged and -release group are setup, we can release
> neutron-vpnaas by ourselves.
>

Is this strictly necessary? I don't see these in other gerrit ACLs
(irrespective of whether they are part of neutron or not). My understanding
is that the release can be fully managed by the openstack release team once
a patch like [1] is posted to the openstack/releases project.

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



>
> Akihiro
>
> 2017-08-08 10:46 GMT+09:00 Takashi Yamamoto :
> > hi,
> >
> > can anyone with an appropriate permission create a stable/pike
> > and pike rc1 for neutron-vpnaas?
> >
> > stable/pike
> > 11.0.0.0rc1
> > openstack/neutron-vpnaas
> > 8278615c1f35f98447a3f9692a78ab45e90ee8c6
> >
> > thank you.
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [api] [tc] Nominatimg Eric Fried for service-types-authority core

[Chris Dent]

I don't believe we have an established procedure for core
nominations in the service-types-authority group, so I'll just go
ahead and take the initiative. I think we should make Eric Fried
(efried on IRC) a core in that group. He's been doing a great deal
of work related to service types and service catalog, is around all the
time, and would be a worthy addition.

If you don't like this idea but would like to say so privately,
please contact me. Otherwise I'll give a few days and make it so.

The [tc] tag is on here because the repo is considered "owned by the
technical committee".

We may also wish to consider removing Anne Gentle and Brant Knudson
who are less available these days.

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] - FFE for networking-bagpipe, support for MPLS-over-GRE

[thomas.morin]

Hi PTL/all,

I would like to request an exception for inclusion in Pike, of MPLS/GRE
support in networking-bagpipe.

The feature consists in allowing the use of a new OVS tunnel option
added in the very recently released OVS 2.8.

The code is ready, the only piece preventing the merge is that the
fullstack functional test is not fully ready yet (but should be soon).

The change: https://review.openstack.org/#/c/482571
The RFE: https://bugs.launchpad.net/networking-bagpipe/+bug/1709338

Thanks,

-Thomas


(not waiting for a confirmation that the process applies to stadium
projects, because I'm already late to fill this in, being just back
from PTO)






























































































_

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

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


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

Re: [openstack-dev] [neutron] - FFE requests for Pike

[thomas.morin]

Hi Kevin,

Am I right to assume this applies to stadium projects as well ?
(since they now are all under cycle-with-milestones)

-Thomas


Kevin Benton, 2017-07-30 23:52:
> Hi all,
> 
> If you have any Neutron-related FFE requests for Pike please send an
> email to the dev list with [neutron] in the tag and FFE in the
> subject like in [1]. We will discuss them in the drivers meetings.
> 
> 
> 1. http://lists.openstack.org/pipermail/openstack-dev/2017-July/12031
> 0.html
> 
> Thanks,
> Kevin Benton
> _
> _
> 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

_

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

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


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

Re: [openstack-dev] [Openstack][horizon][ceilometer][gnocchi]Viewing gnocchi statistics on Dashboard

[gordon chung]

On 08/08/17 02:17 AM, pearl.dsil...@wipro.com wrote:
> I would like to know if there exists support to view the statistics
> fetched by gnocchi on Horizon(dashboard). If so, please let me know how
> to configure it in Newton release.

i don't know if there's plans for this in Horizon. this definitely does 
not exist in Newton.

Gnocchi does have visualisation functionality provided by Grafana:
http://gnocchi.xyz/grafana.html

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

Re: [openstack-dev] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

[Akihiro Motoki]

2017-08-08 22:41 GMT+09:00 Boden Russell :
> On 8/7/17 10:39 PM, Clint Byrum wrote:
>> If the thing you're doing doesn't fit in the mainline API, then what
>> you're doing is making a new API. Extensions just bypass the important
>> part where that API gets designed and thought through.
>
> Irrespective of opinions as to if API extensions are good or not, the
> fact of the matter is we support them in neutron today and as a result
> we have users that rely on them as well as the ability to interface
> (CLI) with such extensions via python-neutronclient. That said, I think
> this concern has been heard [1] and we will work to address it
> short-to-mid term.

I totally agree with other comments that all API features should be upstreamed.

Replying to Boden's question on the short-term solution.
If you need CLI support, you can implement OSC plugin to support your
API extensions
rather than extending OSC or OSC plugin provided by python-neutronclient.
If you need SDK support, you can provide your own python bindings
(perhaps it will be most stable)
or continue to use the python-neutronclient CLI extension mechanism
(which extends methods
based on "neutronclient.extension" entry points.

Does it answer to you, Boden?

Akihiro

> As to neutron's longer-term goals W/R/T API extensions; I can't speak to
> that.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2017-August/120759.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [FEMDC][MassivelyDistributed] Strawman proposal for message bus analysis

[Matthieu Simonin]

Hello,

As discussed in the last meeting, I started to formalize the content of the 
etherpad in the performance WG documentation :

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

I've set some co-authorship according to what I saw in the etherpad. I guess 
this list can be shrunk/expanded on demand :)

Best,

Matt


- Mail original -
> De: "Matthieu Simonin" 
> À: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Envoyé: Jeudi 6 Juillet 2017 16:31:46
> Objet: Re: [openstack-dev] [FEMDC][MassivelyDistributed] Strawman proposal 
> for message bus analysis
> 
> - Mail original -
> > De: "Paul-Andre Raymond" 
> > À: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Envoyé: Mercredi 5 Juillet 2017 21:48:29
> > Objet: Re: [openstack-dev] [FEMDC][MassivelyDistributed] Strawman proposal
> > for message bus analysis
> > 
> > Thank you Matt,
> > 
> > This is very insightful. It helps.
> > 
> > The second link did not work for me.
> 
> Oh yeah that's probably because of the on-going doc migration[1].
> 
> [1]:
> http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html
> 
> > 
> > In the presentation, it mentioned that the load consisted “Boot and List”
> > operations through Rally.
> > Did I understand well?
> 
> Yes.
> 
> > Were those hitting the Openstack UI?
> 
> Rally benchmarks put loads the various APIs and gather some metrics about
> the execution (time, failures...)
> 
> > Was keystone involved? Was it using Fernet or another sort of token?
> 
> Keystone is indeed involved and the token was at that time UUID token.
> 
> > 
> > Intuitively, I expected
> > - the big driver for performance on mariadb would be authentication tokens.
> > And fernet would allow to control that.
> > - The big driver for performance on rabbitmq would be ceilometer, and it is
> > not clear from your presentation that any telemetry data hit the message
> > queue.
> 
> Telemetry wasn't set up, I guess this would have killed Rabbit earlier in the
> tests.
> The split between notification and RPC messaging is interesting in this area.
> 
> Bye,
> 
> Matt
> 
> > 
> > Regards,
> > 
> > Paul-Andre
> > 
> > 
> > 
> > -Original Message-
> > From: Matthieu Simonin 
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Date: Saturday, July 1, 2017 at 4:42 AM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Subject: Re: [openstack-dev] [FEMDC][MassivelyDistributed] Strawman
> > proposal
> > for message bus analysis
> > 
> > Hi Paul-André,
> > 
> > This was without ceilometer. Nova + Neutron were consuming a lot of
> > connections.
> > Some charts are available in the Barcelona presentation[1] and the
> > performance docs[2].
> > In the latter you'll find some telemetry related tests.
> > 
> > [1]:
> > 
> > https://www.openstack.org/assets/presentation-media/Chasing-1000-nodes-scale.pdf
> > [2]: https://docs.openstack.org/developer/performance-docs/
> > 
> > Best,
> > 
> > Matt
> > 
> > - Mail original -
> > > De: "Paul-Andre Raymond" 
> > > À: "OpenStack Development Mailing List (not for usage questions)"
> > > 
> > > Envoyé: Vendredi 30 Juin 2017 18:42:04
> > > Objet: Re: [openstack-dev] [FEMDC][MassivelyDistributed] Strawman
> > > proposal for message bus analysis
> > > 
> > > Hi Matthieu,
> > > 
> > > You mentioned 15000 connections with 1000 compute nodes.
> > > Was that mostly Nova? Was ceilometer involved?
> > > I would be curious to know how much AMQP traffic is Control
> > > related
> > > (e.g. spinning up VMs) vs how much is telemetry related in a
> > > typical
> > > openstack deployment.
> > > Do we know that?
> > > 
> > > I have also left some comments in the doc.
> > > 
> > > Paul-Andre
> > > 
> > > 
> > > -Original Message-
> > > From: Matthieu Simonin 
> > > Reply-To: "OpenStack Development Mailing List (not for usage
> > > questions)"
> > > 
> > > Date: Wednesday, June 21, 2017 at 6:54 PM
> > > To: "OpenStack Development Mailing List (not for usage
> > > questions)"
> > > 
> > > Subject: Re: [openstack-dev] [FEMDC][MassivelyDistributed]
> > > Strawman
> > > proposal for  message bus analysis
> > > 
> > >  

[openstack-dev] [TripleO] FFE for OVN container support

[Numan Siddique]

Hello,

I would like to request FFE exception for OVN containerized support. OVN is
an optional feature and should be a low risk.

The patches can be found here -
https://review.openstack.org/#/q/topic:bug/1699085

Thanks
Numan
__
OpenStack Development Mailing 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] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

[Boden Russell]

On 8/7/17 10:39 PM, Clint Byrum wrote:
> If the thing you're doing doesn't fit in the mainline API, then what
> you're doing is making a new API. Extensions just bypass the important
> part where that API gets designed and thought through.

Irrespective of opinions as to if API extensions are good or not, the
fact of the matter is we support them in neutron today and as a result
we have users that rely on them as well as the ability to interface
(CLI) with such extensions via python-neutronclient. That said, I think
this concern has been heard [1] and we will work to address it
short-to-mid term.

As to neutron's longer-term goals W/R/T API extensions; I can't speak to
that.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120759.html

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

[openstack-dev] [release][ptl] tools for creating new releases

[Doug Hellmann]

We realized recently that we haven't publicized some of the tools
in the releases repository very well. One tool that will be useful
this week as you prepare your release candidates is the 'new-release'
command, which edits a deliverable file to add a new release from
HEAD of the given branch, automatically computing the next verison
number based on the inputs.

Use the ``venv`` tox environment to run the tool, like this:

   $ tox -e venv -- new-release SERIES DELIVERABLE TYPE

The SERIES value should be the release series, such as "pike".

The DELIVERABLE value should be the deliverable name, such as
"oslo.config" or "cinder".

The TYPE value should be one of "bugfix", "feature", "major",
"milestone", or "rc".

If the most recent release of cinder during the pike series is
11.0.0.0b3 then running:

   $ tox -e venv -- new-release pike cinder rc

detects that this is the first release candidate and updates the
file deliverables/pike/cinder.yaml with the new release 11.0.0.0rc1
and instructions to create a new stable branch at that tag.

There are some more details in the README.rst file in the releases
repository, and as usual you'll find us in #openstack-release if you
have questions.

Doug

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

Re: [openstack-dev] Is shade (and os_client_config) thread safe?

[David Shrewsbury]

And I see that you've already submitted a patch to this very portion of
code! Thanks!

On Tue, Aug 8, 2017 at 9:14 AM, David Shrewsbury 
wrote:

> This looks more like an os_client_config problem. That key should always
> be defined as it is set in the defaults. However, now that I look at the
> default handling code, I see it uses a global variable (in defaults.py),
> which probably isn't going to play well in a threaded environment. I highly
> suspect this portion of code needs fixing.
>
> -Dave
>
> On Mon, Aug 7, 2017 at 4:52 PM, Joshua Harlow 
> wrote:
>
>> Hi there folks,
>>
>> I'm doing various scans of our clouds here at godaddy and using shade to
>> do some of the calls.
>>
>> Though when I do stuff like the following sometimes it has issues...
>>
>> http://paste.openstack.org/show/617712/
>>
>> Typically this causes the following error:
>>
>> Traceback (most recent call last):
>>   File "tools/fetch_flavors.py", line 72, in 
>> main()
>>   File "tools/fetch_flavors.py", line 61, in main
>> results.append(fut.result())
>>   File 
>> "/Users/jxharlow/.venv/lib/python2.7/site-packages/concurrent/futures/_base.py",
>> line 422, in result
>> return self.__get_result()
>>   File 
>> "/Users/jxharlow/.venv/lib/python2.7/site-packages/concurrent/futures/thread.py",
>> line 62, in run
>> result = self.fn(*self.args, **self.kwargs)
>>   File "tools/fetch_flavors.py", line 24, in extract_cloud
>> client = shade.openstack_cloud(cloud=cloud_name)
>>   File "/Users/jxharlow/.venv/lib/python2.7/site-packages/shade/__init__.py",
>> line 106, in openstack_cloud
>> return OpenStackCloud(cloud_config=cloud_config, strict=strict)
>>   File 
>> "/Users/jxharlow/.venv/lib/python2.7/site-packages/shade/openstackcloud.py",
>> line 156, in __init__
>> self.image_api_use_tasks = cloud_config.config['image_api_use_tasks']
>> KeyError: 'image_api_use_tasks'
>>
>> Though if I add a lock around the following then things go better:
>>
>> with SHADE_LOCK:
>> client = shade.openstack_cloud(cloud=cloud_name)
>>
>> So that makes me wonder, is ummm, this library (or one of its
>> dependencies not thread-safe?); has anyone else seen similar things,
>> perhaps they've already been fixed?
>>
>> -Josh
>>
>> 
>> __
>> 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
>>
>
>
>
> --
> David Shrewsbury (Shrews)
>



-- 
David Shrewsbury (Shrews)
__
OpenStack Development Mailing 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] Is shade (and os_client_config) thread safe?

[David Shrewsbury]

This looks more like an os_client_config problem. That key should always be
defined as it is set in the defaults. However, now that I look at the
default handling code, I see it uses a global variable (in defaults.py),
which probably isn't going to play well in a threaded environment. I highly
suspect this portion of code needs fixing.

-Dave

On Mon, Aug 7, 2017 at 4:52 PM, Joshua Harlow  wrote:

> Hi there folks,
>
> I'm doing various scans of our clouds here at godaddy and using shade to
> do some of the calls.
>
> Though when I do stuff like the following sometimes it has issues...
>
> http://paste.openstack.org/show/617712/
>
> Typically this causes the following error:
>
> Traceback (most recent call last):
>   File "tools/fetch_flavors.py", line 72, in 
> main()
>   File "tools/fetch_flavors.py", line 61, in main
> results.append(fut.result())
>   File 
> "/Users/jxharlow/.venv/lib/python2.7/site-packages/concurrent/futures/_base.py",
> line 422, in result
> return self.__get_result()
>   File 
> "/Users/jxharlow/.venv/lib/python2.7/site-packages/concurrent/futures/thread.py",
> line 62, in run
> result = self.fn(*self.args, **self.kwargs)
>   File "tools/fetch_flavors.py", line 24, in extract_cloud
> client = shade.openstack_cloud(cloud=cloud_name)
>   File "/Users/jxharlow/.venv/lib/python2.7/site-packages/shade/__init__.py",
> line 106, in openstack_cloud
> return OpenStackCloud(cloud_config=cloud_config, strict=strict)
>   File 
> "/Users/jxharlow/.venv/lib/python2.7/site-packages/shade/openstackcloud.py",
> line 156, in __init__
> self.image_api_use_tasks = cloud_config.config['image_api_use_tasks']
> KeyError: 'image_api_use_tasks'
>
> Though if I add a lock around the following then things go better:
>
> with SHADE_LOCK:
> client = shade.openstack_cloud(cloud=cloud_name)
>
> So that makes me wonder, is ummm, this library (or one of its dependencies
> not thread-safe?); has anyone else seen similar things, perhaps they've
> already been fixed?
>
> -Josh
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
David Shrewsbury (Shrews)
__
OpenStack Development Mailing 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][tap-as-a-service] pike branch/release

[Takashi Yamamoto]

hi,

On Tue, Aug 8, 2017 at 9:14 PM, Doug Hellmann  wrote:
> Excerpts from Takashi Yamamoto's message of 2017-08-08 10:49:09 +0900:
>> hi
>>
>> i'll create stable/pike (and probably a release) for tap-as-a-service
>> in this week.
>>
>
> We have a bunch of tools that expect stable branches to only be created
> from releases, so please do tag before branching.

ok.  thank you!

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

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

Re: [openstack-dev] [requirements][mistral][heat][tripleo][trove][murano][solum][tacker] Releasing python-mistralclient 3.1.2

[Matthew Thode]

On 17-08-08 16:11:53, Renat Akhmerov wrote:
> Hi,
> 
> We recently sent a patch [1] to release the version 3.1.2 of 
> python-mistralclient out of Pike branch. It was done after the date of final 
> client library releases so we’d like to discuss if we can allow such an 
> exception. All the projects mentioned in the subject may be affected so 
> please share if the change is acceptable for you or not. Details are below.
> 
> When using Mistral CLI in real deployments we found that some of the list 
> commands may be extremely heavy (mostly memory footprint) when called w/o the 
> “limit” parameter that constrains the result set by the specified value. For 
> example, “mistral execution-list”, “mistral task-list” and “mistral 
> action-execution-list”. We saw a number of times that machines went out of 
> memory after running such a command, sometimes it was done by mistake by 
> operators. So we decided to set a default value for this parameter, which is 
> currently 100, to prevent from unintentional execution of such heavy 
> commands. The corresponding patch [2] was sent on July 11 and was included in 
> the release 3.1.1. For “action-execution-list”, before this patch “limit" 
> parameter didn’t exist at all so we added it too. However, the change wasn’t 
> made properly so that “limit” parameter was just ignored at all times. We 
> fixed that in [3] and decided to release 3.1.2.
> 
> So long story short, this change will affect your project only if you use 
> “mistral action-execution-list” CLI command because now this command will be 
> returning by default only 100 entries (to return all “--limit=-1” needs to be 
> passed).
> 
> We at Nokia need this fix released in Pike because we need to trigger updates 
> of RDO packages used in our system.
> 
> 
> The question: can we afford to make this release now?
> 
> More details on requirements updates etc. you can see in the discussion in 
> [1].
> 
> [1] https://review.openstack.org/#/c/491269
> [2] https://review.openstack.org/#/c/476110/
> [3] https://review.openstack.org/#/c/489217/
> 
> Thanks
> 
> Renat Akhmerov
> @Nokia

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

It sounds like you will need a requirements update as well, both UC and
maybe GR.  GR would suck at this VERY late point.  The current minimum
is 3.1.0 will that not work just like 3.1.1 doesn't work?

-- 
Matthew Thode (prometheanfire)


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

[openstack-dev] [neutron] [classifier] CCF Meeting

[Duarte Cardoso, Igor]

Hi all,

Reminding that we have the Common Classification Framework meeting today, in 
about an hour, at #openstack-meeting.

It will be a short update about the code and plans for the PTG.

Agenda: 
https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#Discussion_Topic_8_August_2017

Best regards,
Igor.

__
OpenStack Development Mailing 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] [docs] Updating the docs team mission statement

[Andreas Jaeger]

On 08/08/2017 03:28 AM, Thierry Carrez wrote:

Petr Kovar wrote:

Hi all,

With the core docs suite moving from openstack-manuals to individual
project repos as per
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
it's also time to update the docs team mission statement from
https://governance.openstack.org/tc/reference/projects/documentation.html.

What are everybody's thoughts on what should the new mission statement
say now that most OpenStack docs maintenance is in the hands of project
teams?

One idea is for the docs team to act as a focused group of editors and
maintain a common set of guidelines, recommended practices (style
guidelines come to mind, for instance), and requirements (such as a common
docs and publishing structure shared across projects).


I think the team needs to be more than "editors". I agree with the rest 
of the statement and the direction Thierry provides below:



I would say something like:

The docs team provides guidance, assistance, tooling, and style guides
enabling OpenStack project teams to produce consistent, accurate, and
high-quality documentation.


Note the doc team still has a few guides but I would not put emphasis on 
that, so the above is fine.


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


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

Re: [openstack-dev] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

[Jay Pipes]

On 08/08/2017 12:39 AM, Clint Byrum wrote:

Excerpts from Matt Riedemann's message of 2017-08-07 14:33:22 -0500:

There is nothing like this for Nova so I'm not sure why Nova should be
involved here. We dropped all support for extending the API via
stevedore extension loading in Pike [1]. The virt drivers don't extend
the REST API either.

[1] https://blueprints.launchpad.net/nova/+spec/api-no-more-extensions-pike



And there was much rejoicing.

If the thing you're doing doesn't fit in the mainline API, then what
you're doing is making a new API. Extensions just bypass the important
part where that API gets designed and thought through.


100 times this.

-jay

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

[Gary Kotton]

Hi,
I will do this.
Thanks
Gary

On 8/8/17, 4:47 AM, "Takashi Yamamoto"  wrote:

hi,

who is planning to make stable/pike for networking-l2gw?

__
OpenStack Development Mailing 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] [elections][Karbor] PTL candidacy for Queens

[Chen Ying]

Hi,

I would like to nominate myself to be the Karbor PTL for the Queens release
cycle.

I began to contribute to Karbor project since 2016.01 and as a core reviewer
in Newton cycle. It is my pleasure to work with the great team to make this
project better and better. We will keep moving and look forward to push Karbor
to the next level.

In Pike, we have done a lot of great works about OpenStack resources protection
in karbor: supported Network resources protection, integrated manila with share
snapshot, integrated cinder with volume snapshot, integrated trove with database
instance backup and restores. More banks: now the local file system and S3 can
be supported as banks in karbor.
Other achievements are: significantly improved docs, removed Heat dependency,
added a new operation log API, implemented OpenStack Client integration,
OperationEngine multi-node deployment and so on.

For the next cycle I'd like to focus on the tasks as follows:
 * API support the checkpoint verification
 * Support quotas
 * Support checkpoint cross AZ，region copy API
 * Cross-site backup and restore
 * Support freezer protection plugin
 * Support K8S pods protection integration
 * API support micro-version
 * Support OpenStack Ansible deployment
 * Implement policies in code

Thanks for taking the time to read through this roadmap. If you have any ideas
on these points we're always happy to discuss and correct our plans.

We're always happy to get new contributors on the project and always ready
to help people interested in Karbor development get up to speed. I'm excited
to continue contributing to Karbor.

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

[openstack-dev] [tripleo] RC schedule

[Emilien Macchi]

Greetings,

We'll push the last RC of TripleO during the week of Aug 28 - Sep 01.

https://releases.openstack.org/pike/schedule.html#p-trailing-rc

There is no date (yet) for RC1, it all depends on how CI works and how
patches can merge.

Reminder:
* we only merge bugfixes that are High or Critical.
* anything related to Upgrades can be merged.
* only blueprints with FFE can be merged (listed:
https://launchpad.net/tripleo/+milestone/pike-rc1)

If you have any doubt, please ping me on IRC / email.

Thanks,
-- 
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] [neutron][tap-as-a-service] pike branch/release

[Doug Hellmann]

Excerpts from Takashi Yamamoto's message of 2017-08-08 10:49:09 +0900:
> hi
> 
> i'll create stable/pike (and probably a release) for tap-as-a-service
> in this week.
> 

We have a bunch of tools that expect stable branches to only be created
from releases, so please do tag before branching.

Doug

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

Re: [openstack-dev] [docs] Updating the docs team mission statement

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2017-08-08 12:28:58 +0200:
> Petr Kovar wrote:
> > Hi all,
> > 
> > With the core docs suite moving from openstack-manuals to individual
> > project repos as per
> > http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
> > it's also time to update the docs team mission statement from
> > https://governance.openstack.org/tc/reference/projects/documentation.html.
> > 
> > What are everybody's thoughts on what should the new mission statement
> > say now that most OpenStack docs maintenance is in the hands of project
> > teams?
> > 
> > One idea is for the docs team to act as a focused group of editors and
> > maintain a common set of guidelines, recommended practices (style
> > guidelines come to mind, for instance), and requirements (such as a common
> > docs and publishing structure shared across projects).
> 
> I would say something like:
> 
> The docs team provides guidance, assistance, tooling, and style guides
> enabling OpenStack project teams to produce consistent, accurate, and
> high-quality documentation.
> 

Thanks for starting this thread, Petr.

To make it easier to compare, here's the current mission statement:

  Provide documentation for core OpenStack projects to promote
  OpenStack.  Develop and maintain tools and processes to ensure
  quality, accurate documentation. Treat documentation like OpenStack
  code.

Thierry's suggestion highlights some of the changes I see coming
for the docs team. I would like to hear from some of the other team
members about what they think about that.

Doug

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

Re: [openstack-dev] [tripleo][qa] Enabling elastic-recheck for tripleo job

[Paul Belanger]

On Mon, Aug 07, 2017 at 03:28:13PM -0400, Paul Belanger wrote:
> On Mon, Aug 07, 2017 at 10:34:59AM -0700, Emilien Macchi wrote:
> > On Mon, Aug 7, 2017 at 9:18 AM, Paul Belanger  wrote:
> > > I've just pushed up a change to puppet-elastic_recheck[1] to update the 
> > > jobs
> > > regex for elastic-recheck to start tracking tripleo.  What this means, is 
> > > now
> > > the elasticRecheck bot will start leaving comments on reviews once it 
> > > matches a
> > > failure in knows about.
> > 
> > Really cool, thanks.
> > Note we have an etherpad to track old queries in logstash:
> > https://etherpad.openstack.org/p/tripleo-ci-logstash-queries
> > I know it's not the best way to handle it and we should use more
> > elastic-recheck, but we can also re-use some queries if needed and
> > remove this etherpad, with this move to elastic-recheck.
> 
> Yes, once we have the current elastic-recheck bugs commenting on tripleo
> reviews, we should migrated any existing logstash queries into it.
> 
Just a heads up, this is now live. You'll start to see comments from 'Elastic
Recheck' bot on failed jobs. Please take a moment to look into the failures that
elastic-recheck is reporting, and if the failures is 'unrecognized error',
please dive a little deeper before typing 'recheck'.

The idea now is the start classifying failures, in an attempt to find patterns.
Chances are, if you are hitting an 'unrecognized error' somebody else is hitting
it too.  And what issues have been classified, we can then triage the issue and
see what is needed to fix 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

Re: [openstack-dev] [mistral][heat][tripleo][trove][murano][solum][tacker] Releasing python-mistralclient 3.1.2

[Renat Akhmerov]

On 8 Aug 2017, 17:45 +0700, Thierry Carrez , wrote:

> Renat Akhmerov wrote:
> > [...]
> > So long story short, this change will affect your project only if you
> > use “mistral action-execution-list” CLI command because now this command
> > will be returning by default only 100 entries (to return all
> > “--limit=-1” needs to be passed).
>
> A number of projects depend on python-mistralclient:
>
> openstack/python-tripleoclient [cycle-trailing]
> openstack/python-troveclient [cycle-with-intermediary]
> openstack/heat [cycle-with-milestones]
> openstack/mistral [cycle-with-milestones]
> openstack/murano [cycle-with-milestones]
> openstack/solum [cycle-with-intermediary]
> openstack/tacker [cycle-with-intermediary]
> openstack/instack-undercloud [cycle-with-intermediary]
> openstack/mistral-dashboard [None]
> openstack/openstackclient [None]
> openstack/python-openstackclient [cycle-with-intermediary]
> openstack/tripleo-common [cycle-trailing]
>
> However, I suspect none of those go through the CLI, so they likely
> won't be affected by the proposed change and could still depend on
> > =3.1.1 (therefore avoiding re-releases). Could you have a quick look at
> those and confirm that ?

Thierry, I checked quickly and didn’t find any uses of Mistral CLI in the 
mentioned repos so I think we’re safe.

Renat

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

Re: [openstack-dev] [nova] [docs] Ideal landing page

[Sean Dague]

On 08/07/2017 06:58 PM, Doug Hellmann wrote:
> Excerpts from Sean Dague's message of 2017-08-07 17:07:37 -0400:
>> The integration of all the manual docs, plus all of our native docs
>> trying to get restructured a bit, has left us with a first order mess
>> when it comes to our front page (and the Table of Contents in the
>> sidebar) - https://docs.openstack.org/nova/latest/
>>
>> I started trying to pull things out of the sidebar TOC by creating some
>> interior landing pages for Contributors and a Deep Dive Technical
>> Reference. In staring at what was left on the page for a good hour today
>> I came up with the following ideal front page outline.
>>
>> https://etherpad.openstack.org/p/ideal-nova-docs-landing-page
>>
>> This probably turns into 3 additional patches on topic:bp/doc-migration
>> * For Users
>> * For Operators
>> * Index page smooth over
>>
>> The original docs spec didn't really separate out users / operators as
>> target audiences. None of this will involve moving subpages around (so
> 
> End-user content goes in /user. Operator content goes in /admin.  See
> http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html#proposed-change
> for details.

Ok, I guess a lot of things got binned incorrectly during the
transition. I think the definition of user was less clearly understood.
But it's fine, we can collect things together in subpages however works.

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [docs] [training-guides] Team meeting reminder

[Pančur , Matjaž]

Hi all,

Just a reminder: Training guides team meeting is today (Tuesday) at 1300UTC, 
#openstack-meeting-3.

On the agenda [1] is moving from Hieroglyph for rendering slides [2].

-Matjaz

[1] https://etherpad.openstack.org/p/training-guides-meeting-agenda
[2] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120598.html


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

Re: [openstack-dev] [nova][docs] Concerns with docs migration

[Sean Dague]

On 08/07/2017 05:04 PM, Clark Boylan wrote:
> On Wed, Aug 2, 2017, at 01:44 PM, Clark Boylan wrote:
>> On Wed, Aug 2, 2017, at 11:37 AM, Sean Dague wrote:
>>> On 08/02/2017 12:28 PM, Clark Boylan wrote:
 On Wed, Aug 2, 2017, at 07:55 AM, Matt Riedemann wrote:
> Now that Stephen Finucane is back from enjoying his youth and 
> gallivanting all over Europe, and we talked about a few things in IRC 
> this morning on the docs migration for Nova, I wanted to dump my 
> concerns here for broader consumption.
>
> 1. We know we have to fix a bunch of broken links by adding in redirects 
> [1] which sdague started here [2]. However, that apparently didn't catch 
> everything, e.g. [3], so I'm concerned we're missing other broken links. 
> Is there a way to find out?

 The infra team can generate lists of 404 urls fairly easily on the docs
 server. This won't show you everything but will show you what urls
 people are finding/using that 404.
>>>
>>> If we could get a weekly report of 404 urls posted somewhere public,
>>> that would be extremely useful, because the easy ones based on git
>>> renames are done, and everything else is going to require human
>>> inspection to figure out what the right landing target is.
>>>
>>
>> I've pushed https://review.openstack.org/#/c/490175/ which will generate
>> a report each day for roughly the last day's worth of 404s. You should
>> be able to see them at https://docs.openstack.org/404s once the change
>> merges and the cron job fires.
>>
>> You can see what that will look like (from my test runs) at
>> http://paste.openstack.org/show/617322/. Note that this isn't a complete
>> file because paste.openstack.org truncated it but you'll get the full
>> data from the wbeserver once this change merges.
> 
> http://files.openstack.org/docs-404s/ is now live (note it moved to
> http://files.openstack.org/docs-404s because that is where we are
> hosting raw bits of utility info for this hosting service). The current
> content there was just generated by running the scripts manually, but it
> should update daily at 0700UTC going forward.

Awesome. Thank you Clark.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [oslo][oslo.config][ansible][tripleo][kolla][ptg] Pluggable drivers and protect plaintext secrets

[Thierry Carrez]

Emilien Macchi wrote:
> On Mon, Aug 7, 2017 at 9:15 AM, Doug Hellmann  wrote:
>> Kendall & Thierry, what do we need to do to reserve that room if we
>> can't find space in another team room?
> 
> Worst case, we can use a slot from TripleO - this topic is also
> critical to us and I think we can make our schedule to have one free
> room during the 2 and a half days that we have.
> Just let me know.

It could also be scheduled in one of the extra reservable rooms we have
on Thursday/Friday. The ethercalc for that should be up next week.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [mistral][heat][tripleo][trove][murano][solum][tacker] Releasing python-mistralclient 3.1.2

[Thierry Carrez]

Renat Akhmerov wrote:
> [...]
> So long story short, this change will affect your project only if you
> use “mistral action-execution-list” CLI command because now this command
> will be returning by default only 100 entries (to return all
> “--limit=-1” needs to be passed).

A number of projects depend on python-mistralclient:

 openstack/python-tripleoclient[cycle-trailing]
 openstack/python-troveclient  [cycle-with-intermediary]
 openstack/heat[cycle-with-milestones]
 openstack/mistral [cycle-with-milestones]
 openstack/murano  [cycle-with-milestones]
 openstack/solum   [cycle-with-intermediary]
 openstack/tacker  [cycle-with-intermediary]
 openstack/instack-undercloud  [cycle-with-intermediary]
 openstack/mistral-dashboard   [None]
 openstack/openstackclient [None]
 openstack/python-openstackclient  [cycle-with-intermediary]
 openstack/tripleo-common  [cycle-trailing]

However, I suspect none of those go through the CLI, so they likely
won't be affected by the proposed change and could still depend on
>=3.1.1 (therefore avoiding re-releases). Could you have a quick look at
those and confirm that ?

> We at Nokia need this fix released in Pike because we need to trigger
> updates of RDO packages used in our system.

Since this change affects behavior, it's better to do it before Pike
release than after Pike release as a stable point update. So if my hunch
on CLI usage above is right, then I would rather grant the library
release freeze exception now.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [docs] Updating the docs team mission statement

[Thierry Carrez]

Petr Kovar wrote:
> Hi all,
> 
> With the core docs suite moving from openstack-manuals to individual
> project repos as per
> http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html,
> it's also time to update the docs team mission statement from
> https://governance.openstack.org/tc/reference/projects/documentation.html.
> 
> What are everybody's thoughts on what should the new mission statement
> say now that most OpenStack docs maintenance is in the hands of project
> teams?
> 
> One idea is for the docs team to act as a focused group of editors and
> maintain a common set of guidelines, recommended practices (style
> guidelines come to mind, for instance), and requirements (such as a common
> docs and publishing structure shared across projects).

I would say something like:

The docs team provides guidance, assistance, tooling, and style guides
enabling OpenStack project teams to produce consistent, accurate, and
high-quality documentation.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [docs] Doc meeting Thursday

[Alexandra Settle]

Hi everyone,

With the upcoming PTG and all of the big changes with the migration, I will be 
hosting the docs meeting as normally scheduled in #openstack-meeting on 
Thursday, 10th of August at 16:00UTC.

I will send out the agenda closer to the day. I *strongly* urge all to attend. 
I know it’s not the best time in the world, but we’re closing in on the first 
release for the doc team with the new release format.

The meeting chair will be me – although I’ll be juggling my regular conflict at 
the same time! Hope you can all make it :)

Thanks,

Alex

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

[openstack-dev] 503 Errors for PUT and POST calls....

[Shyam Prasad N]

Hi,

In my openstack swift cluster, I'm seeing a lot of 503 errors as a
result of tracebacks in swift logs with "No such file or directory"
exceptions...
# grep -Rnw txdaba05e70c6b4dfaa5884-0059895aca /var/log/swift/*
/var/log/swift/proxy.error:31030:Aug  7 23:31:39
BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c proxy-server: ERROR 500
Traceback (most recent call last):#012  File
"/usr/lib/python2.7/dist-packages/swift/obj/server.py", line 1032, in
__call__#012res = method(req)#012  File
"/usr/lib/python2.7/dist-packages/swift/common/utils.py", line 1412,
in _timing_stats#012resp = func(ctrl, *args, **kwargs)#012  File
"/usr/lib/python2.7/dist-packages/swift/obj/server.py", line 751, in
PUT#012writer.put(metadata)#012  File
"/usr/lib/python2.7/dist-packages/swift/obj/diskfile.py", line 2451,
in put#012super(DiskFileWriter, self)._put(metadata, True)#012
File "/usr/lib/python2.7/dist-packages/swift/obj/diskfile.py", line
1476, in _put#012self._finalize_put, metadata, target_path,
cleanup)#012  File
"/usr/lib/python2.7/dist-packages/swift/common/utils.py", line 3342,
in force_run_in_thread#012return self._run_in_eventlet_tpool(func,
*args, **kwargs)#012  File
"/usr/lib/python2.7/dist-packages/swift/common/utils.py", line 3322,
in _run_in_eventlet_tpool#012raise result#012OSError: [Errno 2] No
such file or directory#012 From Object Server re:
/v1/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1
10.3.60.8:6010/xvdb1 (txn: txdaba05e70c6b4dfaa5884-0059895aca)
(client_ip: 10.3.60.11)
/var/log/swift/proxy.error:31031:Aug  7 23:31:39
BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c proxy-server: Object
PUT returning 503 for [500, 201] (txn:
txdaba05e70c6b4dfaa5884-0059895aca) (client_ip: 10.3.60.11)
/var/log/swift/proxy.error:31032:Aug  7 23:31:39
BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c proxy-server: STDERR:
10.3.60.11 - - [08/Aug/2017 06:31:39] "PUT
/v1/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1
HTTP/1.1" 503 346 1.553481 (txn: txdaba05e70c6b4dfaa5884-0059895aca)
/var/log/swift/proxy.log:27701:Aug  7 23:31:39
BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c proxy-server:
10.3.60.11 10.3.60.11 08/Aug/2017/06/31/39 PUT
/v1/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1
HTTP/1.0 503 - - AUTH_tke6014ecd5... 16777216 118 -
txdaba05e70c6b4dfaa5884-0059895aca - 1.5526 - - 1502173898.383203983
1502173899.935844898 0
/var/log/swift/storage1.log:41634:Aug  7 23:31:39
BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c object-server:
10.3.60.8 - - [08/Aug/2017:06:31:39 +] "PUT
/xvdb1/118/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1"
500 981 "PUT 
http://10.3.60.8:8080/v1/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1;
"txdaba05e70c6b4dfaa5884-0059895aca" "proxy-server 2117" 1.0534 "-"
2127 0
/var/log/swift/storage2.log:128852:Aug  7 23:31:39
BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c container-server:
10.3.60.9 - - [08/Aug/2017:06:31:39 +] "PUT
/xvdb2/972/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1"
201 - "PUT 
http://10.3.60.8:8080/xvdb2/118/AUTH_test/8kpc/data/37363A32353A33393A63353A36633A3566CA558859.73.0.1;
"txdaba05e70c6b4dfaa5884-0059895aca" "object-server 1728" 0.0006 "-"
2099 0

I'm also seeing some errors removing tempfile errors in storage logs also...
Aug  8 02:28:15 BulkStore-c2f99bd4-75ce-11e7-b536-02e7b943c03c
object-server: Error removing tempfile:
/srv/xvdb1/node/xvdb1/tmp/tmpFouKzU: #012Traceback (most recent call
last):#012  File
"/usr/lib/python2.7/dist-packages/swift/obj/diskfile.py", line 2396,
in create#012os.unlink(tmppath)#012OSError: [Errno 2] No such file
or directory: '/srv/xvdb1/node/xvdb1/tmp/tmpFouKzU' (txn:
tx860a415e4c454baeab4fc-005989842e)

Can someone tell me what's going on?
Thanks in advance for any help you can give me here.

Regards,
Shyam

__
OpenStack Development Mailing 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][vpnaas] pike rc

[Akihiro Motoki]

I proposed a project-config patch to allow us to release neutron-vpnaas.
https://review.openstack.org/#/c/491670/
There is a missing configuration when neutron-vpnaas was pushed out
from the neutron stadium.
Once the patch is merged and -release group are setup, we can release
neutron-vpnaas by ourselves.

Akihiro

2017-08-08 10:46 GMT+09:00 Takashi Yamamoto :
> hi,
>
> can anyone with an appropriate permission create a stable/pike
> and pike rc1 for neutron-vpnaas?
>
> stable/pike
> 11.0.0.0rc1
> openstack/neutron-vpnaas
> 8278615c1f35f98447a3f9692a78ab45e90ee8c6
>
> thank you.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [mistral][heat][tripleo][trove][murano][solum][tacker] Releasing python-mistralclient 3.1.2

[Renat Akhmerov]

Hi,

We recently sent a patch [1] to release the version 3.1.2 of 
python-mistralclient out of Pike branch. It was done after the date of final 
client library releases so we’d like to discuss if we can allow such an 
exception. All the projects mentioned in the subject may be affected so please 
share if the change is acceptable for you or not. Details are below.

When using Mistral CLI in real deployments we found that some of the list 
commands may be extremely heavy (mostly memory footprint) when called w/o the 
“limit” parameter that constrains the result set by the specified value. For 
example, “mistral execution-list”, “mistral task-list” and “mistral 
action-execution-list”. We saw a number of times that machines went out of 
memory after running such a command, sometimes it was done by mistake by 
operators. So we decided to set a default value for this parameter, which is 
currently 100, to prevent from unintentional execution of such heavy commands. 
The corresponding patch [2] was sent on July 11 and was included in the release 
3.1.1. For “action-execution-list”, before this patch “limit" parameter didn’t 
exist at all so we added it too. However, the change wasn’t made properly so 
that “limit” parameter was just ignored at all times. We fixed that in [3] and 
decided to release 3.1.2.

So long story short, this change will affect your project only if you use 
“mistral action-execution-list” CLI command because now this command will be 
returning by default only 100 entries (to return all “--limit=-1” needs to be 
passed).

We at Nokia need this fix released in Pike because we need to trigger updates 
of RDO packages used in our system.


The question: can we afford to make this release now?

More details on requirements updates etc. you can see in the discussion in [1].

[1] https://review.openstack.org/#/c/491269
[2] https://review.openstack.org/#/c/476110/
[3] https://review.openstack.org/#/c/489217/

Thanks

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

Re: [openstack-dev] [all] New code contributors no longer forced to join the foundation

[ChangBo Guo]

thanks for all of the effort, great work

2017-08-08 13:30 GMT+08:00 Swapnil Kulkarni :

> On Tue, Aug 8, 2017 at 4:58 AM, Jeremy Stanley  wrote:
> > Due to improvements in the OpenStack Foundation member directory and
> > our technical election tooling, it is no longer necessary to join
> > the foundation as an individual member just to be able to submit
> > changes through Gerrit for official repositories. You do, however,
> > still eventually need to join if you want to be able to participate
> > in technical elections (as a candidate or a voter).
> >
> > The Account Setup section[1] of the Developer's Guide has been
> > updated to reflect the new simpler process, and a separate
> > (optional) Eligibility to Vote in Elections section[2] has been
> > added. This process change significantly simplifies the onboarding
> > process for new code contributors by removing a very error-prone
> > and, for many, eyebrow-raising hurdle.
> >
> > A little background: the Bylaws of the OpenStack Foundation Appendix
> > 4 Technical Committee Member Policy[3] (section 3b) limits voter
> > rolls for technical elections to Foundation Individual Members. It
> > was never strictly required by policy to join the foundation if you
> > only wanted to contribute code and had no interest in voting, which
> > is not an entirely uncommon case for new contributors. Due to
> > previous technical limitations in our systems we still forced new
> > contributors to join, because that was the easiest way at the time
> > to be relatively certain who was qualified to participate in
> > technical elections. Now that we have a mechanism for verifying
> > membership on demand when validating nominations and generating
> > voter rolls, we have made the step of joining the foundation
> > optional (though still very much recommended once you reach the
> > point as a contributor where you want to participate in community
> > governance processes).
> >
> > [1] https://docs.openstack.org/infra/manual/developers.html#
> account-setup
> > [2] https://docs.openstack.org/infra/manual/developers.html#
> eligibility-to-vote-in-elections
> > [3] https://www.openstack.org/legal/technical-committee-member-policy/
> > --
> > 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
> >
>
> Great, excellent step to reduce barrier to entry. Kudos!
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

[openstack-dev] [vitrage] stable/pike branch for vitrage

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

I’m going to create stable/pike branches for vitrage and vitrage-dashboard 
tomorrow or the day after.
If you have changes that should enter Pike, try to push them today. After that, 
we will be able to fix Pike bugs on top of stable/pike for two more weeks.
Please do not merge changes that should enter Queens until the stable/pike 
branches are created.

Thanks,
Ifat.

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

[openstack-dev] [os-upstream-institute] Meeting reminder

[Ildiko Vancsa]

Hi Training Team,

This is a friendly reminder that this week’s meeting is in one and a half hours 
at 0900 UTC on #openstack-meeting-3.

You can find the agenda here: 
https://etherpad.openstack.org/p/openstack-upstream-institute-meetings

See you on the meeting soon! :)

Thanks and Best Regards,
Ildikó



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

[openstack-dev] [ptl][election][mistral] PTL candidacy for Queens

[Renat Akhmerov]

Hi,

I’d like to continue to be the PTL of Mistral project and submitted my 
candidacy.

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

Thanks

Renat Akhmerov
@Nokia
__
OpenStack Development Mailing 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] [python-swiftclient] download multiple files at once (in-memory)

[Gerlando FALAUTO]

Hi everyone,

I'm using python-swiftclient and I'd like to be able to download several 
(small) files.
Actually I don't need/want to have those files saved to disk, I'd rather be 
able to use their contents in memory for later inline processing through a 
Jupyter notebook.
I can already download one file at a time by using swiftclient.SwiftService's 
.download() by passing options  = {"out_file": "-"},
provided my objects list only contains one file.
However, for efficiency reasons (i.e. high latency) I'd like to run several 
downloads in parallel.

I've identified the offending code block in 
https://github.com/openstack/python-swiftclient/blob/master/swiftclient/service.py:

if options['out_file'] and len(objects) > 1:
options['out_file'] = None

I believe this should be something like:
if options['out_file'] and len(objects) > 1 and options['out_file'] 
!= '-':
options['out_file'] = None

Then everything else should actually work out of the box, I assume.
Does that make any sense at all?

Thank you!
Gerlando
__
OpenStack Development Mailing 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] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

[rajeev.satyanaray...@wipro.com]

Hi MohanKumar,

Thanks for the reply.

Is the design part for the “OAM Operation Manager for SFC” done? What is the 
approach being used to monitor the SFC? If the design is already done, I would 
like to contribute in implementing it. Please provide your comments.

Thanks and Regards,
Rajeev

From: Mohan Kumar [mailto:nmohankumar1...@gmail.com]
Sent: Friday, July 28, 2017 1:32 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Rajeev Satyanarayana (MFG & Tech) 
Subject: ** Newsletter/Marketing email** Re: [openstack-dev] 
[ceilometer][networking-sfc] Meters/Statistics for Networking-SFC


** This mail has been sent from an external source. Treat hyperlinks and 
attachments in this email with caution**
Hi Rajeev,

The Chain Monitoring is the missing piece in networking-sfc . Vikram and myself 
were discussed to introduce "SFC Manager" [1] (basically OAM tool ) few cycle 
before.

It'll continuously monitor an existing SFC chain,  when any SF VM goes down or 
any packet drop. It'll trigger alert and capture corresponding logs . But we 
haven't started any implementation on this. Feel free to discuss with 
community, IMO  this feature will be great addition to networking-sfc

[1]  https://bugs.launchpad.net/networking-sfc/+bug/1513368


IRC: #networking-sfc
Weekly Meeting:  
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting

Thanks.,
Mohankumar.N







On Thu, Jul 27, 2017 at 11:30 AM, 
rajeev.satyanaray...@wipro.com 
> wrote:
Hi Igor/Cathy/Gord,

Sorry for the delay in replying.

As part of monitoring the SFC, I think maintaining the details of “Number of 
flows assigned to a given SFC”, “Number of packets/bytes dropped/hit due to the 
policies at each Service Function entry/exit points or for the entire SFC” 
would be good to start with. I feel based on some of these details, an operator 
can know how much the virtual switch is loaded and take a call on whether to 
add a new SFC, or it could even help during debugging which service function 
has exactly caused the disruption to SFC.
As a first step, I think it would be good to add meters to provide “number of 
packets/bytes hit due to policy at the ingress and egress of the entire SFC” 
and to realize that, we would need to add specific pollsters. We can use 
neutron_client API to fetch the ingress and egress port details and fetch the 
corresponding flows for those specific ports(also get flow_infos from 
flow_classifier and then use them to dump_flows matching those flow_infos) and 
fetch the no.of packets hit due to policy from them.

I have just mentioned my idea on this. Can I please know your opinion on this 
and provide your comments?

Thanks and Regards,
Rajeev.
The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com

__
OpenStack Development Mailing List (not for usage 

[openstack-dev] [Openstack][horizon][ceilometer][gnocchi]Viewing gnocchi statistics on Dashboard

[pearl.dsil...@wipro.com]

Hi all,

I would like to know if there exists support to view the statistics fetched by 
gnocchi on Horizon(dashboard). If so, please let me know how to configure it in 
Newton release.

Thanks & Regards,
Pearl Dsilva
The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev