Re: [openstack-dev] [nova][qa] gate-grenade-dsvm-neutron-multinode-live-migration-nv is 100% fail since 1/21

[Ken'ichi Ohmichi]

2017-01-27 19:35 GMT-08:00 Matt Riedemann :
> On 1/27/2017 5:00 PM, Matt Riedemann wrote:
>>
>> I noticed that this job is 100% failure since 1/21:
>>
>> http://tinyurl.com/zjh5bc5
>>
>>
>> http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/logs/devstack-gate-post_test_hook.txt.gz#_2017-01-27_23_43_40_367
>>
>>
>> For whatever reason, live_migration=False in tempest.conf:
>>
>>
>> http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/logs/new/tempest_conf.txt.gz
>>
>>
>
> The only thing I can think that might be causing some mischief is the
> devstack-tools stuff that was integrated recently into the CI system, which
> messes with local.conf. But I don't know enough about how that works, so
> would need sdague to investigate.

Yeah, this misconfiguration happens only on grenade multinode jobs only.
The live_migration config is set correctly on tempest multinode jobs
like 
http://logs.openstack.org/16/411816/5/check/gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial/4a95eca/logs/tempest_conf.txt.gz
which its grenade multinode jobs fails on the same time.

Thanks

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

Re: [openstack-dev] [nova][qa] gate-grenade-dsvm-neutron-multinode-live-migration-nv is 100% fail since 1/21

[Matt Riedemann]

On 1/27/2017 5:00 PM, Matt Riedemann wrote:

I noticed that this job is 100% failure since 1/21:

http://tinyurl.com/zjh5bc5

http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/logs/devstack-gate-post_test_hook.txt.gz#_2017-01-27_23_43_40_367


For whatever reason, live_migration=False in tempest.conf:

http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/logs/new/tempest_conf.txt.gz




The only thing I can think that might be causing some mischief is the 
devstack-tools stuff that was integrated recently into the CI system, 
which messes with local.conf. But I don't know enough about how that 
works, so would need sdague to investigate.


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing 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] Latest and greatest on trying to get n-sch to require placement

[Matt Riedemann]

On 1/26/2017 8:40 AM, Matt Riedemann wrote:


And circling back on *that*, we've agreed to introduce a new service
version for the compute to indicate it's Ocata or not. Then we'll:

* check in the scheduler if the minimum compute service version is ocata,
* if minimum is ocata, then use placement, else fallback to the old
resource tracker data in the compute_nodes table - then we remove that
fallback in Pike.

We'll also have a check for the placement config during init_host on the
ocata compute such that if you are upgrading to ocata code for the
compute but don't have placement configured, it's a hard fail and the
nova-compute service is doing to die.

I'm pretty sure we've come full circle on this now.



Just an update:

The two nova changes for the filter scheduler using placement are 
passing CI testing now and are approved. They are held up from being 
merged due to the grenade change at the bottom of the series which 
installs placement before upgrading to ocata and configures nova-compute:


https://review.openstack.org/424730

We need that in as soon as possible, so Sean, if you're reading this, 
you know what to do.


--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing 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] [puppet] Nominating zhongshengping for core of the Puppet OpenStack modules

[钟生平]

Thanks everyone, it's my pleasure! I'll try to do my best.

On Fri, Jan 20, 2017 at 10:19 AM, Alex Schultz  wrote:
>> Hey Puppet Cores,
 I would like to nominate Zhong Shengping as a Core reviewer for the
>> Puppet OpenStack modules.  He is an excellent contributor to our
>> modules over the last several cycles. His stats for the last 90 days
>> can be viewed here[0].
 Please response with your +1 or any objections. If there are no
>> objections by Jan 27 I will add him to the core list.
>>>
> As there were no objections, I have added Zhong to the core list.
> Keep up the good work.
>
> Thanks,
> -Alex
>
>> Thanks,
>> -Alex
 [0] http://stackalytics.com/report/contribution/puppet%20openstack-group/90
Thanks,
Shengping__
OpenStack Development Mailing 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][Community_App_Catalog][Ec2_Api][Karbor][Magnum][OpenStack_UX][Requirements][Senlin] Last days for PTL candidate announcements

[Tristan Cacqueray]

On 01/26/2017 06:33 PM, Kendall Nelson wrote:
> Hello All!
> 
> It appears that there are several projects without PTL nominations and we
> are reaching the close of the nomination period. The period ends Jan 29,
> 2017 23:45 UTC.
> 
The current leaderless projects are:
 - Community_App_Catalog
 - Ec2_Api
 - Karbor
 - Magnum
 - OpenStack_UX
 - Requirements
 - Senlin

If you want to stand for PTL, don't delay, follow the instructions at
[0] to make sure the community knows your intentions. Make sure your
candidacy have been submitted to the openstack/election
repository and approved by election officials.

Election statistics[1]:
Nominations started   @ 2017-01-18 23:59:00 UTC
Nominations end   @ 2017-01-29 23:45:00 UTC
Nominations duration  : 10 days, 23:46:00
Nominations remaining : 1 day, 21:59:38
Nominations progress  :  82.56%
---
Projects  :61
Projects with candidates  :54 ( 88.52%)
Projects with election: 4 (  6.56%)
---
Need election : 4 (Ironic Keystone Neutron
   Quality_Assurance)
Need appointment  : 7 (Community_App_Catalog Ec2_Api Karbor
   Magnum OpenStack_UX Requirements Senlin)
===
Stats gathered@ 2017-01-28 01:45:22 UTC

This means that with approximately 2 days left more than 10% of projects
will be deemed leaderless.  In this case the TC will be bound by [2].

Thank you,
-Tristan

[0] http://governance.openstack.org/election/#how-to-submit-your-candidacy
[1] Assuming the open reviews below are validated
   https://review.openstack.org/#/q/is:open+project:openstack/election
[2]
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.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] OpenStack Developer Mailing List Digest January 21-27

[Mike Perez]

HTML version: 
https://www.openstack.org/blog/2017/01/openstack-developer-mailing-list-digest-20170127/

SuccessBot Says
===
* dims [1] : Nova now has a python35 based CI job in check queue running
  Tempest tests (everything running on py35)
* markvoelker [2]: Newly published Foundation annual report starts off with
  interoperability right in the chairman's note [3]
*  Tell us yours via OpenStack IRC channels with message “#success ”
* All: [4]

Get Active in Upstream Training
===
* There is a continuous effort in helping newcomers join our community by
  organizing upstream contribution trainings [5][6] before every summit.
  - 1.5 - 2 days of hands-on steps of becoming an active OpenStack contributor.
* Like everything else, this is a community effort.
  - In preparation for the Boston summit and the upcoming PTG in Atlanta, we
are looking for coaches and mentors to help us make the training better.
  - If you’re interested in helping contact:
-- Ildiko Vancsa IRC freenode at ildikov or email [7]
-- Kendall Nelson IRC freenode at diablo_rojo or email [8]
* Full thread: [9]

Project Team Gathering Coordination Tool

* No central scheduling, beyond assigned rooms to teams and days.
  - Each team arranges their time in their room.
  - List of etherpads [10]
* We still need centralized communication beyond each room:
  - An event IRC channel: ##openstack-ptg on free node IRC
-- Do public service announcements
-- Pings from room to room.
  - An EtherCalc spreadsheet powered dynamic schedule with extra rooms
available:
-- One fishbowl
-- A few dark rooms with projectors and screens (not all will have a/v
equipment due to budget).
-- Infra is working on setting up EtherCalc
* Full thread: [11]

POST /api-wg/news
=
* API Guidelines proposed for freeze:
  - Add guidelines on usage of state vs. status [12]
  - Clarify the status values in versions [13]
  - Add guideline for invalid query parameters [14]
* Guidelines currently under review:
  - Add guidelines for boolean names [15]
  - Define pagination guidelines [16]
  - Add API capabilities discovery guideline [17]
* Full thread: [18]

Lots of Teams Without PTL Candidates

* We are reaching close to the end of the PTL nominations (Jan 29, 2017 23:45
  UTC), but have projects that are leaderless:
* Community App Catalog
* Ec2 API
* Fuel
* Karbor
* Magnum
* Monasca
* OpenStackClient
* OpenStackUX
* Packaging Prm
* Rally
* RefStack
* Requirements
* Senlin
* Stable Branch Maintenance
* Vitrage
* Zun
* Full thread [19]


[1] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-python3/%23openstack-python3.2017-01-23.log.html
[2] - 
http://eavesdrop.openstack.org/irclogs/%23openstack-interop/%23openstack-interop.2017-01-24.log.html
[3] - 
https://www.openstack.org/assets/reports/OpenStack-2016-Annual-Report-final-draft.pdf
[4] - 
https://www.openstack.org/assets/reports/OpenStack-2016-Annual-Report-final-draft.pdf
[5] - http://docs.openstack.org/upstream-training/
[6] - 
http://superuser.openstack.org/articles/openstack-upstream-training-revamp/
[7] - mailto:ild...@openstack.org
[8] - mailto:knel...@openstack.org
[9] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110788.html
[10] - https://wiki.openstack.org/wiki/PTG/Pike/Etherpads
[11] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110909.html
[12] - https://review.openstack.org/#/c/411528/
[13] - https://review.openstack.org/#/c/411849/
[14] - https://review.openstack.org/417441
[15] - https://review.openstack.org/#/c/411529/
[16] - https://review.openstack.org/#/c/386555/
[17] - https://review.openstack.org/#/c/386555/
[18] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/111058.html
[19] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/111071.html


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] [Zun] PTL candidacy

[Hongbin Lu]

Hi all,

This is the first time Zun participants on official PTL election, which is
exciting. I nominated myself to be a candidate of Zun PTL. As the founder of
this project, it is my honor to work with all of you to build an innovative
container service for OpenStack.

Since April 2016, in which the project was founded, the Zun team were making
an impressive progress during these 8 months. With the hard work of the whole
team, we delivered most of the fundamental capabilities. The completed
essential features includes:
* A full-featured container API.
* Two drivers that serve as reference implementations.
* Neutron integration in one of the drivers.
* Two image drivers: Docker Registry (i.e. Docker Hub) and Glance.
* Multi-tenancy: Containers are isolated by OpenStack projects.
* HA deployment: Support multiple compute hosts.
* Horizon integration.
* OpenStack Client integration.

Zun is an important project for OpenStack because it enables unique use cases
that requires container to be an OpenStack-managed resource (i.e. orchstrating
containerized and virtualized resources). Furthermore, it allows users to use
one platform, that is OpenStack, to manage containers, VMs, and baremetal.
To achieve the goal, there are a lot of exicting tasks to do.

For Pike, I would suggest the Zun team to focus on the followings:
* Container network: Integrate with Kuryr-libnetwork for providing networking
  for Docker containers.
* Container storage: Leverage Cinder for providing container data volume.
* Nova integration: Enhance the existing Nova driver.
* Resource management: Enhance the management of compute host resources, and
  introduce different placement policy (i.e. pin container to dedicated
  CPU cores).

Beyond Pike, I would suggest to target for the following use cases:
* Strong isolation between neighboring containers. This could be solved by
  introducing Hypervisor-based container runtime.
* Containerize stateful application (i.e. DBMS).
* NFV/HPC workload.

Also, I would like to highlight that nova-docker is going to retire, and
the users who were using nova-docker might want to find a replacement.
If they are willing to migrate from nova-docker to Zun, I would encourage the
Zun team to help out.

Best regards,
Hongbin
__
OpenStack Development Mailing 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][qa] gate-grenade-dsvm-neutron-multinode-live-migration-nv is 100% fail since 1/21

[Matt Riedemann]

I noticed that this job is 100% failure since 1/21:

http://tinyurl.com/zjh5bc5

http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/logs/devstack-gate-post_test_hook.txt.gz#_2017-01-27_23_43_40_367

For whatever reason, live_migration=False in tempest.conf:

http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/logs/new/tempest_conf.txt.gz

--

Thanks,

Matt Riedemann

__
OpenStack Development Mailing 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-ansible] Proposing Amy Marrich for core

[Jimmy McCrory]

+1

Amy's been giving helpful reviews for a long time.

On Fri, Jan 27, 2017 at 7:54 AM, Ian Cordasco 
wrote:

> -Original Message-
> From: Major Hayden 
> Reply: OpenStack Development Mailing List (not for usage questions)
> 
> Date: January 27, 2017 at 08:52:58
> To: openstack-dev@lists.openstack.org 
> Subject:  Re: [openstack-dev] [openstack-ansible] Proposing Amy Marrich
> for core
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > On 01/27/2017 08:29 AM, Alexandra Settle wrote:
> > > I would like to propose Amy Marrich for the core team for
> OpenStack-Ansible.
> >
> > +3.14
>
> +2.718
>
> --
> Ian Cordasco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [release] libraries that still need stable/ocata branches

[Doug Hellmann]

We are now past the library release freeze, and all libraries should
have their final release and be ready for a stable/ocata branch.

The following libraries have not yet branched:

$ list-deliverables --no-stable-branch -v --model cycle-with-intermediary 
--type library
ceilometermiddleware   Telemetry1.0.0
cliff  OpenStackClient  2.4.0
django_openstack_auth  horizon  3.1.0
os-brick   cinder   1.11.0
os-client-config   OpenStackClient  1.26.0
os-vif nova 1.4.0
os-win winstackers  1.4.0
osc-libOpenStackClient  1.3.0
python-aodhclient  Telemetry0.8.0
python-brick-cinderclient-ext  cinder   0.3.0
python-cinderclientcinder   1.11.0
python-designateclient designate2.5.0
python-heatclient  heat 1.8.0
python-mistralclient   mistral  3.0.0
python-novaclient  nova 7.1.0
python-saharaclientsahara   1.1.0
python-searchlightclient   searchlight  1.1.0
python-swiftclient swift3.3.0
python-troveclient trove2.8.0
python-vitrageclient   vitrage  1.1.0
python-zaqarclient zaqar1.3.0

If you anticipate a bug fix release before the RC1 deadline of 2 Feb,
then it's safe to wait to branch until you get to that point, to avoid
having to backport the fix immediately. If not, please update the
deliverable data file in openstack/releases with the branch information
to create a stable/ocata branch.

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] [networking-sfc]

[Sridhar Ramaswamy]

Networking-sfc features are available to orchestrate using a TOSCA
template through Tacker. The feature is called VNF Forwarding Graph
(VNFFG) and it is available both through tacker cli and horizon
screens.

See tacker docs here for more details,

http://docs.openstack.org/developer/tacker/devref/vnffg_usage_guide.html
http://docs.openstack.org/developer/tacker/devref/vnffgd_template_description.html

On a different note, the last I tried, I also used that setting to get
sfc working on Ubuntu 16.04 devstack,

# Enable networking-sfc
SFC_UPDATE_OVS=False
enable_plugin networking-sfc https://git.openstack.org/openstack/networking-sfc



On Tue, Jan 24, 2017 at 5:30 AM, Bernard Cafarelli  wrote:
> On 20 January 2017 at 00:06, Michael Gale  wrote:
>> Hello,
>>
>> Are there updated install docs for sfc? The only install steps for a
>> testbed I can find are here and they seem outdated:
>> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
> There is also a SFC chapter in the networking guide:
> http://docs.openstack.org/newton/networking-guide/config-sfc.html
>
> Which parts do you find outdated? Some references to Ubuntu/OVS
> versions may need a cleanup, but the design and API parts should still
> be OK
> (OSC client, SFC graph API, symmetric ports and other goodies are
> still under review and not yed merged)
>
>> Also from the conference videos there seems to be some Horizon menu /
>> screens that are available?
> Not for networking-sfc directly, but there is a SFC tab in the tacker
> horizon plugin (or will be, someone from the tacker team can confirm
> that)
>
>
> --
> Bernard Cafarelli
>
> __
> OpenStack Development Mailing 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-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Andrey Grebennikov]

Ah, I see the point... So basically it is just updating one of the values
of the cert object in Barbican.
In this case yes, fully agree it should be marked as a bug and fixed asap.

Sorry for misunderstanding!

On Fri, Jan 27, 2017 at 1:44 PM, Jiahao Liang (Frankie) <
gzliangjia...@gmail.com> wrote:

> Hi German,
>
> Once again, we are not talking about a real delete of a cert in whatever
> cert storage.
>
> The problem we are trying to resolve is, even the lbaas is deleted, users
> still see the lbaas is using the cert in Barbican.
> We didn't call the deregister logic during lbaas deletion.
>
> Best,
>
> On Fri, Jan 27, 2017 at 11:37 AM, Jiahao Liang (Frankie) <
> gzliangjia...@gmail.com> wrote:
>
>> Hi Andrey,
>>
>> The reason Barbican cert container has a property called consumer. The
>> definition is as following:
>>
>>> What is a Consumer?
>>>
>>>
 A consumer is a way to register as an interested party for a container.
 All of the registered consumers can be viewed by performing a GET on the
 {container_ref}/consumers. The idea being that before a container is
 deleted all consumers should be notified of the delete.
>>>
>>>
>> When we create a Terminated_HTTPS listener in lbaas, we register the
>> lbaas as one of the consumers of corresponding cert container.
>>
>> But when we delete the listener/lb, we didn't deregister/revert the
>> consumer registration.
>> This deregister/revert is actually what delete_cert() do for Barbican
>> cert_manager in neutron_lbaas, NOT a real delete.
>>
>> My suggestion was we need to add this deregister/revert procedure.
>>
>> Hope this helps.
>>
>> Best,
>>
>> On Fri, Jan 27, 2017 at 9:07 AM, Andrey Grebennikov <
>> agrebenni...@mirantis.com> wrote:
>>
>>> Frankie,
>>>
>>> What is the reason why the cert has to be deleted on the balancer
>>> deletion?
>>> The entire workflow, if I'm not mistaken, is to first work with Barbican
>>> API in order to create the cert bundle. And technically it is not yet
>>> connected to anything else.
>>> After that you create the balancer, specifying the link to where the
>>> cert bundle is.
>>> From this perspective, why one should expect the cert bundle to be
>>> deleted?
>>>
>>> For me personally it is the same as deletion of the image automatically
>>> once the instance got deleted :/
>>>
>>> Sorry if I'm missing the context.
>>>
>>> On Fri, Jan 27, 2017 at 2:19 AM, Adam Harwell 
>>> wrote:
>>>
 Yeah, I believe it was because we intended to leave it up to the
 specific certificate manager to determine what needs to be done -- we are
 treating it as a delete, and if the cert manager wants to do a true delete,
 they can. I'll agree the verb is not perfectly clear, but the driver author
 should make sure the correct action is taken regardless of the function
 name.

 It's possible we should just rename the function to something like
 "unget_cert", which sounds a bit nonsensical but is possibly still clearer.
 I remember at the time I wrote this being frustrated with trying to name
 the function and wanting to just move on. T_T

--Adam (rm_work)

 PS: Did we remove the local cert manager yet? Now I need to check... I
 hope so, because it's not actually usable, nor can it be without API
 modifications (which we discussed but never actually implemented or even
 fully agreed on).

 On Wed, Jan 25, 2017, 17:50 Jiahao Liang (Frankie) <
 gzliangjia...@gmail.com> wrote:

> Thanks rm_work.
>
> I also notice something need to be handled properly.
>
> For barbican, the delete_cert() only deregisters the cert without
> actually delete it. That's safe for us to call during
> delete_listener()/delete_loadbalancer().
>
> But if the user uses other cert_manager by any chance, say the
> local_cert_manager, the same delete_cert() method will do a real delete of
> the cert.
>
> Probably we need to implement register_consumer()/remove_consumer()
> method for cert_manager and call them in neutron_lbaas as well.
>
>
> On Wed, Jan 25, 2017 at 10:48 Adam Harwell 
> wrote:
>
> I've got this on my list of things to look at -- I don't know if it
> was you I was talking with on IRC the other day about this issue, but I'm
> definitely aware of it. As soon as we are past the Ocata feature freeze
> crunch, I'll take a closer look.
>
> My gut says that we should be calling the delete (which is not a real
> delete) when the LB is deleted, and not doing so is a bug, but I'll need 
> to
> double check the logic as it has been a while since I touched this.
>
> --Adam (rm_work)
>
> On Mon, Jan 23, 2017, 18:38 Jiahao Liang (Frankie) <
> gzliangjia...@gmail.com> wrote:
>
> Hi community,
>
> I created a loadbalancer with a listener with protocol as
> "TERMINATED_HTTPS" and specify --default-tls-container-ref with a r

Re: [openstack-dev] [OpenStack][Dev] Changes coming to Product WG & Enterprise WG

[Doug Hellmann]

Excerpts from Barrett, Carol L's message of 2017-01-27 15:56:21 +:
> After 35+ yrs in the Technology Industry, I have decided it's time for a 
> change. I will be retiring from Intel on February 2nd.
> 
> OpenStack has been a highlight of my career and I owe much of that to you 
> all. It's been a pleasure knowing and working with you.
> 
> Yih Leong Sun (aka Leong) will be taking on the Leadership role for the 
> Enterprise WG and the co-leadership role of the Product Work Group, along 
> with Shamail Tahir. You will see other folks taking on additional roles as 
> part of my overall transition plan. I know you will help them in their new 
> roles.
> 
> Best wishes for your continued success - I'll be cheering for OpenStack from 
> the bleachers!
> 
> Carol Barrett

Congratulations, Carol!

It has been great to work with you over the past few years. We will
miss your guidance and even keeled approach in organizing the working
groups.

Good luck,
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] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Jiahao Liang (Frankie)]

Hi German,

Once again, we are not talking about a real delete of a cert in whatever
cert storage.

The problem we are trying to resolve is, even the lbaas is deleted, users
still see the lbaas is using the cert in Barbican.
We didn't call the deregister logic during lbaas deletion.

Best,

On Fri, Jan 27, 2017 at 11:37 AM, Jiahao Liang (Frankie) <
gzliangjia...@gmail.com> wrote:

> Hi Andrey,
>
> The reason Barbican cert container has a property called consumer. The
> definition is as following:
>
>> What is a Consumer?
>>
>>
>>> A consumer is a way to register as an interested party for a container.
>>> All of the registered consumers can be viewed by performing a GET on the
>>> {container_ref}/consumers. The idea being that before a container is
>>> deleted all consumers should be notified of the delete.
>>
>>
> When we create a Terminated_HTTPS listener in lbaas, we register the lbaas
> as one of the consumers of corresponding cert container.
>
> But when we delete the listener/lb, we didn't deregister/revert the
> consumer registration.
> This deregister/revert is actually what delete_cert() do for Barbican
> cert_manager in neutron_lbaas, NOT a real delete.
>
> My suggestion was we need to add this deregister/revert procedure.
>
> Hope this helps.
>
> Best,
>
> On Fri, Jan 27, 2017 at 9:07 AM, Andrey Grebennikov <
> agrebenni...@mirantis.com> wrote:
>
>> Frankie,
>>
>> What is the reason why the cert has to be deleted on the balancer
>> deletion?
>> The entire workflow, if I'm not mistaken, is to first work with Barbican
>> API in order to create the cert bundle. And technically it is not yet
>> connected to anything else.
>> After that you create the balancer, specifying the link to where the cert
>> bundle is.
>> From this perspective, why one should expect the cert bundle to be
>> deleted?
>>
>> For me personally it is the same as deletion of the image automatically
>> once the instance got deleted :/
>>
>> Sorry if I'm missing the context.
>>
>> On Fri, Jan 27, 2017 at 2:19 AM, Adam Harwell 
>> wrote:
>>
>>> Yeah, I believe it was because we intended to leave it up to the
>>> specific certificate manager to determine what needs to be done -- we are
>>> treating it as a delete, and if the cert manager wants to do a true delete,
>>> they can. I'll agree the verb is not perfectly clear, but the driver author
>>> should make sure the correct action is taken regardless of the function
>>> name.
>>>
>>> It's possible we should just rename the function to something like
>>> "unget_cert", which sounds a bit nonsensical but is possibly still clearer.
>>> I remember at the time I wrote this being frustrated with trying to name
>>> the function and wanting to just move on. T_T
>>>
>>>--Adam (rm_work)
>>>
>>> PS: Did we remove the local cert manager yet? Now I need to check... I
>>> hope so, because it's not actually usable, nor can it be without API
>>> modifications (which we discussed but never actually implemented or even
>>> fully agreed on).
>>>
>>> On Wed, Jan 25, 2017, 17:50 Jiahao Liang (Frankie) <
>>> gzliangjia...@gmail.com> wrote:
>>>
 Thanks rm_work.

 I also notice something need to be handled properly.

 For barbican, the delete_cert() only deregisters the cert without
 actually delete it. That's safe for us to call during
 delete_listener()/delete_loadbalancer().

 But if the user uses other cert_manager by any chance, say the
 local_cert_manager, the same delete_cert() method will do a real delete of
 the cert.

 Probably we need to implement register_consumer()/remove_consumer()
 method for cert_manager and call them in neutron_lbaas as well.


 On Wed, Jan 25, 2017 at 10:48 Adam Harwell  wrote:

 I've got this on my list of things to look at -- I don't know if it was
 you I was talking with on IRC the other day about this issue, but I'm
 definitely aware of it. As soon as we are past the Ocata feature freeze
 crunch, I'll take a closer look.

 My gut says that we should be calling the delete (which is not a real
 delete) when the LB is deleted, and not doing so is a bug, but I'll need to
 double check the logic as it has been a while since I touched this.

 --Adam (rm_work)

 On Mon, Jan 23, 2017, 18:38 Jiahao Liang (Frankie) <
 gzliangjia...@gmail.com> wrote:

 Hi community,

 I created a loadbalancer with a listener with protocol as
 "TERMINATED_HTTPS" and specify --default-tls-container-ref with a ref of
 secret container from Barbican.
 However, after I deleted the listener, the lbaas wasn't removed from
 barbican container consumer list.

 $openstack secret container get http://192.168.20.24:9311/v1/c
 ontainers/453e8905-d42b-43bd-9947-50e3acf499f4
 ++--
 ---+
 | Field  | Value

Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Jiahao Liang (Frankie)]

Hi Andrey,

The reason Barbican cert container has a property called consumer. The
definition is as following:

> What is a Consumer?
>
>
>> A consumer is a way to register as an interested party for a container.
>> All of the registered consumers can be viewed by performing a GET on the
>> {container_ref}/consumers. The idea being that before a container is
>> deleted all consumers should be notified of the delete.
>
>
When we create a Terminated_HTTPS listener in lbaas, we register the lbaas
as one of the consumers of corresponding cert container.

But when we delete the listener/lb, we didn't deregister/revert the
consumer registration.
This deregister/revert is actually what delete_cert() do for Barbican
cert_manager in neutron_lbaas, NOT a real delete.

My suggestion was we need to add this deregister/revert procedure.

Hope this helps.

Best,

On Fri, Jan 27, 2017 at 9:07 AM, Andrey Grebennikov <
agrebenni...@mirantis.com> wrote:

> Frankie,
>
> What is the reason why the cert has to be deleted on the balancer deletion?
> The entire workflow, if I'm not mistaken, is to first work with Barbican
> API in order to create the cert bundle. And technically it is not yet
> connected to anything else.
> After that you create the balancer, specifying the link to where the cert
> bundle is.
> From this perspective, why one should expect the cert bundle to be deleted?
>
> For me personally it is the same as deletion of the image automatically
> once the instance got deleted :/
>
> Sorry if I'm missing the context.
>
> On Fri, Jan 27, 2017 at 2:19 AM, Adam Harwell  wrote:
>
>> Yeah, I believe it was because we intended to leave it up to the specific
>> certificate manager to determine what needs to be done -- we are treating
>> it as a delete, and if the cert manager wants to do a true delete, they
>> can. I'll agree the verb is not perfectly clear, but the driver author
>> should make sure the correct action is taken regardless of the function
>> name.
>>
>> It's possible we should just rename the function to something like
>> "unget_cert", which sounds a bit nonsensical but is possibly still clearer.
>> I remember at the time I wrote this being frustrated with trying to name
>> the function and wanting to just move on. T_T
>>
>>--Adam (rm_work)
>>
>> PS: Did we remove the local cert manager yet? Now I need to check... I
>> hope so, because it's not actually usable, nor can it be without API
>> modifications (which we discussed but never actually implemented or even
>> fully agreed on).
>>
>> On Wed, Jan 25, 2017, 17:50 Jiahao Liang (Frankie) <
>> gzliangjia...@gmail.com> wrote:
>>
>>> Thanks rm_work.
>>>
>>> I also notice something need to be handled properly.
>>>
>>> For barbican, the delete_cert() only deregisters the cert without
>>> actually delete it. That's safe for us to call during
>>> delete_listener()/delete_loadbalancer().
>>>
>>> But if the user uses other cert_manager by any chance, say the
>>> local_cert_manager, the same delete_cert() method will do a real delete of
>>> the cert.
>>>
>>> Probably we need to implement register_consumer()/remove_consumer()
>>> method for cert_manager and call them in neutron_lbaas as well.
>>>
>>>
>>> On Wed, Jan 25, 2017 at 10:48 Adam Harwell  wrote:
>>>
>>> I've got this on my list of things to look at -- I don't know if it was
>>> you I was talking with on IRC the other day about this issue, but I'm
>>> definitely aware of it. As soon as we are past the Ocata feature freeze
>>> crunch, I'll take a closer look.
>>>
>>> My gut says that we should be calling the delete (which is not a real
>>> delete) when the LB is deleted, and not doing so is a bug, but I'll need to
>>> double check the logic as it has been a while since I touched this.
>>>
>>> --Adam (rm_work)
>>>
>>> On Mon, Jan 23, 2017, 18:38 Jiahao Liang (Frankie) <
>>> gzliangjia...@gmail.com> wrote:
>>>
>>> Hi community,
>>>
>>> I created a loadbalancer with a listener with protocol as
>>> "TERMINATED_HTTPS" and specify --default-tls-container-ref with a ref of
>>> secret container from Barbican.
>>> However, after I deleted the listener, the lbaas wasn't removed from
>>> barbican container consumer list.
>>>
>>> $openstack secret container get http://192.168.20.24:9311/v1/c
>>> ontainers/453e8905-d42b-43bd-9947-50e3acf499f4
>>> ++--
>>> ---+
>>> | Field  | Value
>>>   |
>>> ++--
>>> ---+
>>> | Container href | http://192.168.20.24:9311/v1/c
>>> ontainers/453e8905-d42b-43bd-9947-50e3acf499f4|
>>> | Name   | tls_container2
>>>|
>>> | Created| 2017-01-19 12:44:07+00:00
>>>   |
>>> | Status |

Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[German Eichberger]

Hi,

The idea was that we would like to let the user know in Barbican when the 
certificate is being used with LBaaS. Therefore, we added the register and 
de-register logic. I don’t know of any use case where a certificate needs to be 
deleted in Barbican when LBaaS doesn’t need it any longer.

So I agree with Andrey – it’s the same semantic as images.

German

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

Date: Friday, January 27, 2017 at 12:07 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: Subrahmanyam Ongole 
Subject: Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get 
deregistered in barbican after lbaas listener delete

Frankie,

What is the reason why the cert has to be deleted on the balancer deletion?
The entire workflow, if I'm not mistaken, is to first work with Barbican API in 
order to create the cert bundle. And technically it is not yet connected to 
anything else.
After that you create the balancer, specifying the link to where the cert 
bundle is.
From this perspective, why one should expect the cert bundle to be deleted?

For me personally it is the same as deletion of the image automatically once 
the instance got deleted :/

Sorry if I'm missing the context.

On Fri, Jan 27, 2017 at 2:19 AM, Adam Harwell 
mailto:flux.a...@gmail.com>> wrote:

Yeah, I believe it was because we intended to leave it up to the specific 
certificate manager to determine what needs to be done -- we are treating it as 
a delete, and if the cert manager wants to do a true delete, they can. I'll 
agree the verb is not perfectly clear, but the driver author should make sure 
the correct action is taken regardless of the function name.

It's possible we should just rename the function to something like 
"unget_cert", which sounds a bit nonsensical but is possibly still clearer. I 
remember at the time I wrote this being frustrated with trying to name the 
function and wanting to just move on. T_T

   --Adam (rm_work)

PS: Did we remove the local cert manager yet? Now I need to check... I hope so, 
because it's not actually usable, nor can it be without API modifications 
(which we discussed but never actually implemented or even fully agreed on).

On Wed, Jan 25, 2017, 17:50 Jiahao Liang (Frankie) 
mailto:gzliangjia...@gmail.com>> wrote:
Thanks rm_work.

I also notice something need to be handled properly.

For barbican, the delete_cert() only deregisters the cert without actually 
delete it. That's safe for us to call during 
delete_listener()/delete_loadbalancer().

But if the user uses other cert_manager by any chance, say the 
local_cert_manager, the same delete_cert() method will do a real delete of the 
cert.

Probably we need to implement register_consumer()/remove_consumer() method for 
cert_manager and call them in neutron_lbaas as well.


On Wed, Jan 25, 2017 at 10:48 Adam Harwell 
mailto:flux.a...@gmail.com>> wrote:

I've got this on my list of things to look at -- I don't know if it was you I 
was talking with on IRC the other day about this issue, but I'm definitely 
aware of it. As soon as we are past the Ocata feature freeze crunch, I'll take 
a closer look.

My gut says that we should be calling the delete (which is not a real delete) 
when the LB is deleted, and not doing so is a bug, but I'll need to double 
check the logic as it has been a while since I touched this.

--Adam (rm_work)

On Mon, Jan 23, 2017, 18:38 Jiahao Liang (Frankie) 
mailto:gzliangjia...@gmail.com>> wrote:
Hi community,

I created a loadbalancer with a listener with protocol as "TERMINATED_HTTPS" 
and specify --default-tls-container-ref with a ref of secret container from 
Barbican.
However, after I deleted the listener, the lbaas wasn't removed from barbican 
container consumer list.

$openstack secret container get 
http://192.168.20.24:9311/v1/containers/453e8905-d42b-43bd-9947-50e3acf499f4
++-+
| Field  | Value
   |
++-+
| Container href | 
http://192.168.20.24:9311/v1/containers/453e8905-d42b-43bd-9947-50e3acf499f4
|
| Name   | tls_container2   
   |
| Created| 2017-01-19 12:44:07+00:00
   |
| Status | ACTIVE   
   |
| Type   | certificate  
   |
| Certificate| 
http://192.168.20.24:9311/v1/secrets/bfc2bf01-0f23-41

[openstack-dev] [tripleo] os-collect-config 6.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for os-collect-config for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/os-collect-config/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:


http://git.openstack.org/cgit/openstack/os-collect-config/log/?h=stable/ocata

Release notes for os-collect-config can be found at:

http://docs.openstack.org/releasenotes/os-collect-config/



__
OpenStack Development Mailing 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] os-apply-config 6.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for os-apply-config for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/os-apply-config/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:

http://git.openstack.org/cgit/openstack/os-apply-config/log/?h=stable/ocata

Release notes for os-apply-config can be found at:

http://docs.openstack.org/releasenotes/os-apply-config/



__
OpenStack Development Mailing 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] os-refresh-config 6.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for os-refresh-config for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/os-refresh-config/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:


http://git.openstack.org/cgit/openstack/os-refresh-config/log/?h=stable/ocata

Release notes for os-refresh-config can be found at:

http://docs.openstack.org/releasenotes/os-refresh-config/



__
OpenStack Development Mailing 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] os-net-config 6.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for os-net-config for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/os-net-config/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:

http://git.openstack.org/cgit/openstack/os-net-config/log/?h=stable/ocata

Release notes for os-net-config can be found at:

http://docs.openstack.org/releasenotes/os-net-config/

If you find an issue that could be considered release-critical, please
file it at:

http://bugs.launchpad.net/os-net-config

and tag it *ocata-rc-potential* to bring it to the os-net-config
release crew's attention.

__
OpenStack Development Mailing 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] os-cloud-config 6.0.0.0rc1 (ocata)

[no-reply]

Hello everyone,

A new release candidate for os-cloud-config for the end of the Ocata
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/os-cloud-config/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Ocata release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/ocata release
branch at:

http://git.openstack.org/cgit/openstack/os-cloud-config/log/?h=stable/ocata

Release notes for os-cloud-config can be found at:

http://docs.openstack.org/releasenotes/os-cloud-config/



__
OpenStack Development Mailing 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] [ovo] unhashable type error

[Das, Anindita]

On 1/25/17, 1:59 PM, "Ihar Hrachyshka"  wrote:

  > Looking at the code, I don't see a clear case to even use set() type
  > there. A list would seem to work just fine. Should we try to convert
  > to using lists there?
   
I will convert it into a list and check how it works.

   > Nevertheless, we can look into extending the object base class for
   > hashing. I wonder though if it's something to tackle in Neutron scope.
   > Sounds more like an oslo.versionedobjects library feature request.

Currently, I have added the hashing in the specific object but as you mentioned 
it
should be in object base class. I will try implementing that.

As the hashing for the OVO’s is based on the primary keys
I am not sure whether we can implement this in oslo.versionedobjects library.

Thanks,
Anindita (irc: dasanind)

On Wed, Jan 25, 2017 at 11:53 AM, Das, Anindita  
wrote:
> Hi Ihar,
>
>
>
> While doing the integration for vlanallocation [1] I found that OVO
> associated with VlanAllocation throws “unhashable type” error with py35.
>
> The associated stack trace is here [2].
>
>
>
> To resolve this issue I added an equality and hash method in the
> vlanallocation OVO [3].
>
> My understanding is we will face the same problem with other OVO objects 
as
> well when we do similar operations on the object as in [1].
>
> Should we make all the OVO objects hashable or deal it case by case?
> Thoughts?
>
>
>
>
>
> [1]
> 
https://review.openstack.org/#/c/367810/28/neutron/plugins/ml2/drivers/type_vlan.py@77
>
> [2] http://paste.openstack.org/show/596281/
>
> [3]
> 
https://review.openstack.org/#/c/367810/28/neutron/objects/plugins/ml2/vlanallocation.py@38-55
>
>
>
> Thanks,
>
> Anindita (irc: dasanind)


__
OpenStack Development Mailing 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-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Andrey Grebennikov]

Frankie,

What is the reason why the cert has to be deleted on the balancer deletion?
The entire workflow, if I'm not mistaken, is to first work with Barbican
API in order to create the cert bundle. And technically it is not yet
connected to anything else.
After that you create the balancer, specifying the link to where the cert
bundle is.
>From this perspective, why one should expect the cert bundle to be deleted?

For me personally it is the same as deletion of the image automatically
once the instance got deleted :/

Sorry if I'm missing the context.

On Fri, Jan 27, 2017 at 2:19 AM, Adam Harwell  wrote:

> Yeah, I believe it was because we intended to leave it up to the specific
> certificate manager to determine what needs to be done -- we are treating
> it as a delete, and if the cert manager wants to do a true delete, they
> can. I'll agree the verb is not perfectly clear, but the driver author
> should make sure the correct action is taken regardless of the function
> name.
>
> It's possible we should just rename the function to something like
> "unget_cert", which sounds a bit nonsensical but is possibly still clearer.
> I remember at the time I wrote this being frustrated with trying to name
> the function and wanting to just move on. T_T
>
>--Adam (rm_work)
>
> PS: Did we remove the local cert manager yet? Now I need to check... I
> hope so, because it's not actually usable, nor can it be without API
> modifications (which we discussed but never actually implemented or even
> fully agreed on).
>
> On Wed, Jan 25, 2017, 17:50 Jiahao Liang (Frankie) <
> gzliangjia...@gmail.com> wrote:
>
>> Thanks rm_work.
>>
>> I also notice something need to be handled properly.
>>
>> For barbican, the delete_cert() only deregisters the cert without
>> actually delete it. That's safe for us to call during
>> delete_listener()/delete_loadbalancer().
>>
>> But if the user uses other cert_manager by any chance, say the
>> local_cert_manager, the same delete_cert() method will do a real delete of
>> the cert.
>>
>> Probably we need to implement register_consumer()/remove_consumer()
>> method for cert_manager and call them in neutron_lbaas as well.
>>
>>
>> On Wed, Jan 25, 2017 at 10:48 Adam Harwell  wrote:
>>
>> I've got this on my list of things to look at -- I don't know if it was
>> you I was talking with on IRC the other day about this issue, but I'm
>> definitely aware of it. As soon as we are past the Ocata feature freeze
>> crunch, I'll take a closer look.
>>
>> My gut says that we should be calling the delete (which is not a real
>> delete) when the LB is deleted, and not doing so is a bug, but I'll need to
>> double check the logic as it has been a while since I touched this.
>>
>> --Adam (rm_work)
>>
>> On Mon, Jan 23, 2017, 18:38 Jiahao Liang (Frankie) <
>> gzliangjia...@gmail.com> wrote:
>>
>> Hi community,
>>
>> I created a loadbalancer with a listener with protocol as
>> "TERMINATED_HTTPS" and specify --default-tls-container-ref with a ref of
>> secret container from Barbican.
>> However, after I deleted the listener, the lbaas wasn't removed from
>> barbican container consumer list.
>>
>> $openstack secret container get http://192.168.20.24:9311/v1/
>> containers/453e8905-d42b-43bd-9947-50e3acf499f4
>> ++--
>> ---+
>> | Field  | Value
>>   |
>> ++--
>> ---+
>> | Container href | http://192.168.20.24:9311/v1/
>> containers/453e8905-d42b-43bd-9947-50e3acf499f4|
>> | Name   | tls_container2
>>  |
>> | Created| 2017-01-19 12:44:07+00:00
>>   |
>> | Status | ACTIVE
>>  |
>> | Type   | certificate
>>   |
>> | Certificate| http://192.168.20.24:9311/v1/
>> secrets/bfc2bf01-0f23-4105-bf09-c75839b6b4cb   |
>> | Intermediates  | None
>>  |
>> | Private Key| http://192.168.20.24:9311/v1/
>> secrets/c85d150e-ec84-42e0-a65f-9c9ec19767e1   |
>> | PK Passphrase  | None
>>  |
>> | *Consumers  | {u'URL':
>> u'lbaas://RegionOne/loadbalancer/5e7768b9-7aa9-4146-8a71-6291353b447e',
>> u'name': u'lbaas'}*
>>
>>
>> I went through the neutron-lbaas code base. We did register consumer
>> during the creation of "TERMINATED_HTTPS" listener in [1]. But we somehow
>> doesn't deregister it during the deletion in [1]: https://github.com/
>> openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/
>> services/loadbalancer/plugin.py#L642
>> get_cert() register lbaas as a consumer for

Re: [openstack-dev] [puppet] Nominating zhongshengping for core of the Puppet OpenStack modules

[Alex Schultz]

On Fri, Jan 20, 2017 at 10:19 AM, Alex Schultz  wrote:
> Hey Puppet Cores,
>
> I would like to nominate Zhong Shengping as a Core reviewer for the
> Puppet OpenStack modules.  He is an excellent contributor to our
> modules over the last several cycles. His stats for the last 90 days
> can be viewed here[0].
>
> Please response with your +1 or any objections. If there are no
> objections by Jan 27 I will add him to the core list.
>

As there were no objections, I have added Zhong to the core list.
Keep up the good work.

Thanks,
-Alex

> Thanks,
> -Alex
>
> [0] http://stackalytics.com/report/contribution/puppet%20openstack-group/90

__
OpenStack Development Mailing 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][Dev] Changes coming to Product WG & Enterprise WG

[Thierry Carrez]

Barrett, Carol L wrote:
> After 35+ yrs in the Technology Industry, I have decided it’s time for a
> change. I will be retiring from Intel on February 2^nd .
> 
> OpenStack has been a highlight of my career and I owe much of that to
> you all. It’s been a pleasure knowing and working with you.

Thanks Carol for all your help! You were instrumental in bringing some
order into our chaos, and helping us keeping an eye on the big picture.

I wish you a lot of success in your new adventures !

-- 
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] [glance] priorities for the coming week (01/27-02/02)

[Ian Cordasco]

-Original Message-
From: Brian Rosmaita 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: January 26, 2017 at 17:03:58
To: OpenStack Development Mailing List 
Subject:  [openstack-dev] [glance] priorities for the coming week (01/27-02/02)

> First, please read the email from Ian (our release czar) about the
> feature freeze:
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/111067.html
>
> We have three priorities this week. The first is an all-hands-on-deck
> super priority, namely, reviewing (and re-reviewing, as appropriate) the
> code associated with Rolling Upgrades, which has received a FFE:
>
> - https://review.openstack.org/#/c/382958/
> - https://review.openstack.org/#/c/392993/
> - https://review.openstack.org/#/c/397409/
> - https://review.openstack.org/#/c/424774/

This last patch is described (in the commit title) as a WIP and the
author is not around (they're taking time off). Is someone else
working on it/taking it over? Does it belong in this list?

> Please start your reviews now. We don't want to be in a situation next
> week where people are rush-reviewing things.
>
> The other, secondary, not as important as the above, items are:
>
> * nominate any appropriate glanceclient bugs that didn't make it into
> this week's release by tagging them in Launchpad with
> "ocata-backport-potential". Please do this earlier rather than later,
> but do it consistently with the above.
>
> * ongoing work on the security bug - actually, this one is pretty
> important. Anyone in coresec, the only excuse for not reviewing Rolling
> Upgrades patches is if you are actively working on this bug.
>
> Have a good week, everyone!
>
> cheers,
> brian
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

--
Ian Cordasco

__
OpenStack Development Mailing 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] [glance] priorities for the coming week (01/27-02/02)

[Hemanth Makkapati]

I'm working on that patch, Ian.

-Hemanth

From: Ian Cordasco 
Sent: Friday, January 27, 2017 9:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] priorities for the coming week
(01/27-02/02)

-Original Message-
From: Brian Rosmaita 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: January 26, 2017 at 17:03:58
To: OpenStack Development Mailing List 
Subject:  [openstack-dev] [glance] priorities for the coming week (01/27-02/02)

> First, please read the email from Ian (our release czar) about the
> feature freeze:
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/111067.html
>
> We have three priorities this week. The first is an all-hands-on-deck
> super priority, namely, reviewing (and re-reviewing, as appropriate) the
> code associated with Rolling Upgrades, which has received a FFE:
>
> - https://review.openstack.org/#/c/382958/
> - https://review.openstack.org/#/c/392993/
> - https://review.openstack.org/#/c/397409/
> - https://review.openstack.org/#/c/424774/

This last patch is described (in the commit title) as a WIP and the
author is not around (they're taking time off). Is someone else
working on it/taking it over? Does it belong in this list?

> Please start your reviews now. We don't want to be in a situation next
> week where people are rush-reviewing things.
>
> The other, secondary, not as important as the above, items are:
>
> * nominate any appropriate glanceclient bugs that didn't make it into
> this week's release by tagging them in Launchpad with
> "ocata-backport-potential". Please do this earlier rather than later,
> but do it consistently with the above.
>
> * ongoing work on the security bug - actually, this one is pretty
> important. Anyone in coresec, the only excuse for not reviewing Rolling
> Upgrades patches is if you are actively working on this bug.
>
> Have a good week, everyone!
>
> cheers,
> brian
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

--
Ian Cordasco

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

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

[openstack-dev] [OpenStack][Dev] Changes coming to Product WG & Enterprise WG

[Barrett, Carol L]

After 35+ yrs in the Technology Industry, I have decided it's time for a 
change. I will be retiring from Intel on February 2nd.

OpenStack has been a highlight of my career and I owe much of that to you all. 
It's been a pleasure knowing and working with you.

Yih Leong Sun (aka Leong) will be taking on the Leadership role for the 
Enterprise WG and the co-leadership role of the Product Work Group, along with 
Shamail Tahir. You will see other folks taking on additional roles as part of 
my overall transition plan. I know you will help them in their new roles.

Best wishes for your continued success - I'll be cheering for OpenStack from 
the bleachers!

Carol Barrett


__
OpenStack Development Mailing 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-ansible] Proposing Amy Marrich for core

[Ian Cordasco]

-Original Message-
From: Major Hayden 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: January 27, 2017 at 08:52:58
To: openstack-dev@lists.openstack.org 
Subject:  Re: [openstack-dev] [openstack-ansible] Proposing Amy Marrich for core

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 01/27/2017 08:29 AM, Alexandra Settle wrote:
> > I would like to propose Amy Marrich for the core team for OpenStack-Ansible.
>
> +3.14

+2.718

--
Ian Cordasco

__
OpenStack Development Mailing 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] [requirements][stable][relmgt] PTG prep

[Thierry Carrez]

Hi!

The requirements team, the stable maintenance team and the release
management team will share a single room on the Monday and Tuesday of
the PTG. Since we don't all need 2 full days of coordination (and
several of us need to also attend some other team meeting at the same
time), I propose we split the time we have into 4 sessions:

Monday morning: Stable team session
Monday afternoon: Release management session
Tuesday morning: Requirements session
Tuesday afternoon: All together (stable/requirements/release management)

We'll use that last session for discussing common topics, but also to
cover all the stuff that we didn't have time to finish in the
team-specific sessions.

To simplify I also propose that we share the preparation etherpad:

https://etherpad.openstack.org/p/relmgt-stable-requirements-ptg-pike

Let me know if this proposed plan causes any issue.

-- 
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] [openstack-ansible] Proposing Amy Marrich for core

[Major Hayden]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/27/2017 08:29 AM, Alexandra Settle wrote:
> I would like to propose Amy Marrich for the core team for OpenStack-Ansible.

+3.14

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

iQIcBAEBCAAGBQJYi15kAAoJEHNwUeDBAR+xNkwQAI8NISykMYLjNJkwv14VOeUe
2P1OCmCFlzq5EnnLi1zkevxE8KRblh7xtwPoHYMq9+1UCW2RzqEEtW7aRLa8wjra
2qwpnfSVxSGCFxO0qjduslbD/pio/onXq8AzAVhePatXsFPHL2pKs/a5CKf9XuQR
1Y28+H7fmnXLzrIMN+WX/H88r7+qi9UqJIuqU35isVxqywE8NDh9/Xv5blKEJisu
lil9C5jVLq0Xelk8KrRPn5cBBXsdGQLcpAD/LQE9LshCPL9/+UiZdM8rPhDhCfm5
fi4lz9KtwtfAQ54rlKEwtgD91j3jXKoQGs/nsnj2KAH+oUpAzxJfKVIB73a8i8gV
mH/duVnZELlxJLVYhssWA55ZWSjvTA9plK3ylEuyJ92OCxac5raN0g4+8++6IRnd
bAey/8mHzRBCKwWZqSysLtSCl1POz96OomfIE0U04cjqRUkdJ+aOgHjKX1JRlvhi
VsGtkP7z66QZ5RlSKXIBcWouMZwqRGAFiUyILU2wEZJME06F3Dkhg10JEOYJJK9z
40MzZ4s+tOHWZrJ67617pILcrsZuBstP8jRgODrOqesMgAZsn7QpKLOrP4QUGm3e
Q3OqfvVMKsIHCGAjxNMqMVOHOvG/c+qPp6XH+cdKc0aBurFvPFD9fGL0e5Ep2W1K
H84/6oPb6iChqu0w3IZz
=rgbW
-END PGP SIGNATURE-

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

Re: [openstack-dev] [openstack-ansible] Proposing Amy Marrich for core

[Andy McCrae]

+1 from me too.
Thanks for your contributions so far Amy, glad to have you as part of the
community.

Andy
__
OpenStack Development Mailing 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] tripleo-heat-templates, vendor plugins and the new hiera hook

[Marios Andreou]

On 27/01/17 16:23, Dan Prince wrote:
> On Wed, 2017-01-25 at 14:59 +0200, Marios Andreou wrote:
>> Hi, as part of the composable upgrades workflow shaping up for Newton
>> to
>> Ocata, we need to install the new hiera hook that was first added
>> with
>> [1] and disable the old hook and data as part of the upgrade
>> initialization [2]. Most of the existing hieradata was ported to use
>> the
>> new hook in [3]. The deletion of the old hiera data is necessary for
>> the
>> Ocata upgrade, but it also means it will break any plugins still
>> using
>> the 'old' os-apply-config hiera hook.
> 
> 
> Nice catch on the old vendor hieradata. I clearly missed those

for the record... actually thanks to slagle - see discussion at
https://review.openstack.org/#/c/424715

> interfaces for the in-tree extraconfig data when doing these conversion
> (sorry about that). Would be nice to get some sort of coverage on these
> interfaces I guess.
> 
> The new hook uses Json and is much cleaner. We were accumulating a lot
> of hacks in t-h-t to work around deficiencies with the old o-a-c YAML
> element mechanism. What this means is a conversion tool is hard. Not
> impossible, but might not get 100% of the cases I think due to the
> differences in how YAML and Json can handle arrays and such with all
> the conversions going on.
> 
> Updating the rest of the in-tree interfaces (like you have done) should
> get most of it. For any out of tree extraconfig code that relies on the
> old heira element would it be reasonable to fail-fast instead? There
> isn't a great place to do this unfortunately but a couple of options:
> 
> 1) in the agent hook itself: https://review.openstack.org/#/c/426241/1
> 
> 2) in the old hiera hook: https://review.openstack.org/#/c/425955/
> 
> Option #1 handles signals more nicely but couples the old and new
> implementations a bit with the extra check. Option #2 doesn't currently
> handle signaling nicely (as shardy pointed out in the review).

fwiw #1 makes more sense to me (I didn't see that until just now, after
having reviewed #2 first thing today) just so the operator gets an early
(earlier at least) exit with some error message.

thanks

> 
> Dan
> 
>>
>> In order to be able to upgrade to Ocata any templates that define
>> hiera
>> data need to be using the new hiera hook and then the overcloud nodes
>> need to have the new hook installed (installing is done in [2] as a
>> matter of necessity, and that is what prompted this email in the
>> first
>> place). I've had a go at updating all the plugin templates that are
>> still using the old hiera data with a review at [4] which I have -1
>> for now.
>>
>> I'll try and reach out to some individuals more directly as well but
>> wanted to get the review at [4] and this email out as a first step,
>>
>> thanks, marios
>>
>> [1] https://review.openstack.org/#/c/379733/
>> [2]
>> https://review.openstack.org/#/c/424715/2/extraconfig/tasks/newton_oc
>> ata_upgrade_init_common.sh
>> [3] https://review.openstack.org/#/c/384757/
>> [4] https://review.openstack.org/#/c/425154/
>>
>> _
>> _
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
>> cribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] [openstack-ansible] Proposing Amy Marrich for core

[Truman, Travis]

+1 on spotz for core. I can always count on Amy to provide great reviews.

Travis Truman

From: Alexandra Settle mailto:a.set...@outlook.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, January 27, 2017 at 9:29 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Cc: "a...@demarco.com" 
mailto:a...@demarco.com>>, Andy McCrae 
mailto:andrew.mcc...@rackspace.co.uk>>
Subject: [openstack-dev] [openstack-ansible] Proposing Amy Marrich for core

Hi OpenStack-Ansible team,

I would like to propose Amy Marrich for the core team for OpenStack-Ansible.

Amy has been consistently in the top 10 reviewers for our team in the last 30 
[1] and 90 [2] days, respectively, this release alone.

She has been an active and diligent member of the OpenStack-Ansible team since 
the end of 2015 and has continuously provided assistance for code and 
documentation reviews.

I think she will make a great addition to the core team and will help move code 
and doc issues forward quicker.

+1 from me

Thanks,

Alex

[1] http://stackalytics.com/report/contribution/openstackansible-group/30
[2] http://stackalytics.com/report/contribution/openstackansible-group/90







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

[openstack-dev] [openstack-ansible] Proposing Amy Marrich for core

[Alexandra Settle]

Hi OpenStack-Ansible team,

I would like to propose Amy Marrich for the core team for OpenStack-Ansible.

Amy has been consistently in the top 10 reviewers for our team in the last 30 
[1] and 90 [2] days, respectively, this release alone.

She has been an active and diligent member of the OpenStack-Ansible team since 
the end of 2015 and has continuously provided assistance for code and 
documentation reviews.

I think she will make a great addition to the core team and will help move code 
and doc issues forward quicker.

+1 from me

Thanks,

Alex

[1] http://stackalytics.com/report/contribution/openstackansible-group/30
[2] http://stackalytics.com/report/contribution/openstackansible-group/90







__
OpenStack Development Mailing 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] tripleo-heat-templates, vendor plugins and the new hiera hook

[Dan Prince]

On Wed, 2017-01-25 at 14:59 +0200, Marios Andreou wrote:
> Hi, as part of the composable upgrades workflow shaping up for Newton
> to
> Ocata, we need to install the new hiera hook that was first added
> with
> [1] and disable the old hook and data as part of the upgrade
> initialization [2]. Most of the existing hieradata was ported to use
> the
> new hook in [3]. The deletion of the old hiera data is necessary for
> the
> Ocata upgrade, but it also means it will break any plugins still
> using
> the 'old' os-apply-config hiera hook.


Nice catch on the old vendor hieradata. I clearly missed those
interfaces for the in-tree extraconfig data when doing these conversion
(sorry about that). Would be nice to get some sort of coverage on these
interfaces I guess.

The new hook uses Json and is much cleaner. We were accumulating a lot
of hacks in t-h-t to work around deficiencies with the old o-a-c YAML
element mechanism. What this means is a conversion tool is hard. Not
impossible, but might not get 100% of the cases I think due to the
differences in how YAML and Json can handle arrays and such with all
the conversions going on.

Updating the rest of the in-tree interfaces (like you have done) should
get most of it. For any out of tree extraconfig code that relies on the
old heira element would it be reasonable to fail-fast instead? There
isn't a great place to do this unfortunately but a couple of options:

1) in the agent hook itself: https://review.openstack.org/#/c/426241/1

2) in the old hiera hook: https://review.openstack.org/#/c/425955/

Option #1 handles signals more nicely but couples the old and new
implementations a bit with the extra check. Option #2 doesn't currently
handle signaling nicely (as shardy pointed out in the review).

Dan

> 
> In order to be able to upgrade to Ocata any templates that define
> hiera
> data need to be using the new hiera hook and then the overcloud nodes
> need to have the new hook installed (installing is done in [2] as a
> matter of necessity, and that is what prompted this email in the
> first
> place). I've had a go at updating all the plugin templates that are
> still using the old hiera data with a review at [4] which I have -1
> for now.
> 
> I'll try and reach out to some individuals more directly as well but
> wanted to get the review at [4] and this email out as a first step,
> 
> thanks, marios
> 
> [1] https://review.openstack.org/#/c/379733/
> [2]
> https://review.openstack.org/#/c/424715/2/extraconfig/tasks/newton_oc
> ata_upgrade_init_common.sh
> [3] https://review.openstack.org/#/c/384757/
> [4] https://review.openstack.org/#/c/425154/
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron]

[Ricardo Rocha]

Hi.

Do you have a pointer to how you extended the driver to have this?

Thanks!

Ricardo

On Fri, Nov 18, 2016 at 2:02 PM, ZZelle  wrote:
> Hello,
>
> AFAIK, it's not possible.
>
> I did a similar thing by extending neutron iptables driver in order to set
> "pre-rules".
>
> Best regards,
>
>
> Cédric/ZZelle
>
> On Fri, Nov 18, 2016 at 1:58 PM, Iago Santos Pardo
>  wrote:
>>
>> Hello,
>>
>> We are using Neutron with the linuxbridge plugin and security groups
>> enabled and we have some custom rules in iptables running on the compute
>> nodes. When the agent rebuilds the firewall it changes the rules order,
>> putting the neutron chains on the top. Is there any way to preserve the
>> rules order and tell neutron to ignore our rules or stuck them on the top?
>>
>> Thank you so much.
>> __
>> OpenStack Development Mailing 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] [FFE][requirements] python-* clients from last 2 days

[Dirk Müller]

Hi Dims,

2017-01-27 13:51 GMT+01:00 Davanum Srinivas :

> I've consolidated the changes to the upper-constraints into One single review:
> https://review.openstack.org/#/c/426116/

I'm ok with it if we have release team buy in.

Greetings,
Dirk

__
OpenStack Development Mailing 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] [FFE][requirements] python-* clients from last 2 days

[Davanum Srinivas]

Dear Requirements Team,

I've consolidated the changes to the upper-constraints into One single review:
https://review.openstack.org/#/c/426116/

Thanks,
Dims

On Fri, Jan 27, 2017 at 5:58 AM, Davanum Srinivas  wrote:
> Oops hit send too soon.
>
> Technically the release deadline was till today (27th)
> https://releases.openstack.org/ocata/schedule.html
>
> If we have a release and do not have that in upper constraints and
> hence haven't tested it, bad things can happen in the field.
>
> Thanks,
> Dims
>
> On Fri, Jan 27, 2017 at 5:55 AM, Davanum Srinivas  wrote:
>> Dear requirements team,
>>
>> Can you please allow the following to merge:
>> https://review.openstack.org/#/q/owner:%22OpenStack+Proposal+Bot%22+status:open+project:openstack/requirements+branch:master+topic:new-release
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/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] [nova] placement/resource providers update 9

[Chris Dent]

There was no update last week because I was away. This week's will
be short as we're facing some challenges getting last minutes
resource provider and placement things through the gate. We'll just
do:

What Matters Most
=

There are two priorty changes in progress that we want to get dealt
with:

* resource tracker adding proper inventory for ironic
  https://review.openstack.org/#/c/404472/

  This looks pretty much ready after some cleanups from Ed overnight.

* scheduler calling the placement API
  https://review.openstack.org/#/c/417961/

  This is struggling in the gate, with issues with the grenade
  multinode job. Efforts to use the minimum service version to make
  sure we don't miscalculate when scheduling are foundering and we're
  struggling to get enough information to understand why.
  Investigations continue throughout today in #openstack-nova.


and:

Bugs


Some bugs are actively being worked on so here's a list of bugs
tagged 'placement', 'scheduler' or 'resource-tracker' ordered by
recent activity:

https://bugs.launchpad.net/nova/+bugs?field.tag=scheduler%20resource-tracker%20placement&field.tags_combinator=ANY&orderby=-date_last_updated&start=0


End
===

There will be a more complete update and catch up next week, at
which point we should have a clear picture of what bugs need to be
addressed and where longer term things stand.

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

Re: [openstack-dev] [FFE][requirements] python-* clients from last 2 days

[Davanum Srinivas]

Oops hit send too soon.

Technically the release deadline was till today (27th)
https://releases.openstack.org/ocata/schedule.html

If we have a release and do not have that in upper constraints and
hence haven't tested it, bad things can happen in the field.

Thanks,
Dims

On Fri, Jan 27, 2017 at 5:55 AM, Davanum Srinivas  wrote:
> Dear requirements team,
>
> Can you please allow the following to merge:
> https://review.openstack.org/#/q/owner:%22OpenStack+Proposal+Bot%22+status:open+project:openstack/requirements+branch:master+topic:new-release
>
> --
> Davanum Srinivas :: https://twitter.com/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] [FFE][requirements] python-* clients from last 2 days

[Davanum Srinivas]

Dear requirements team,

Can you please allow the following to merge:
https://review.openstack.org/#/q/owner:%22OpenStack+Proposal+Bot%22+status:open+project:openstack/requirements+branch:master+topic:new-release

-- 
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] [nova] The status of servers API's filters

[Alex Xu]

The patches about validation the filters and sorts for servers API are
merged [0]. But we still have something left [1].

The left is about the proposal of introducing the new rule
'os_compute_api:servers:all_tenants_visible' which is soft enforcement. The
new rule will instead of the old hard enforcement rule
"os_compute_api:servers:index:get_all_tenants".

In the discussion of nova API meeting, Join pointed out that the change
from hard enforcement to soft enforcement needs Microversion. The API used
to return 403 when user didn't have permission of all_tenants parameter.
But now the API returns 200 with the own instances when no permission of
all_tenants parameter. So the proposal should be separated to two parts:

i. rename the policy from "get_all_tenants" to the "all_tenants_visible"
ii. change the enforcement from hard to soft by Microversion.

In the old microversion, the rule keeps as hard enforcement.

So in Ocata, "get_all_tenants" will be deprecated. If the deployer have
overriden rule in the policy file, the old rule still will be enforced, and
the warning message will be emit to notice that the user needs to move
their custom rule to the new rule 'all_tenants_visiable'. And if the API
user requests with new microversion, the rule will become soft enforcement.

So if that sounds make sense, there also have another question about
whether we have enough time to merge it. I think Matt will make a call on
it.

And due to holidays in China, both I and Kevin are in vacation.  And really
really appreciate Ghanshyam take care on those patches! The spec[3] and the
patch[1] already updated by him.

AnywayHappy Chinese New Year to everyone(yea, new year again \o/).

Thanks
Alex

[0] https://review.openstack.org/408571 and https://review.openstack.
org/415142
[1] https://review.openstack.org/#/q/status:open+project:
openstack/nova+branch:master+topic:bp/add-whitelist-for-
server-list-filter-sort-parameters
[3] https://review.openstack.org/425533
__
OpenStack Development Mailing 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] [cinder][nova] Cinder-Nova API changes meeting

[Ildiko Vancsa]

Hi All,

According to the results of our Doodle poll, the new meeting day will be 
__Thursday__ starting from next week. The time slot and the meeting channel are 
supposed to remain the same, I hope the patch [1] to register the changes gets 
merged soon to make it fully official.

In this sense, the next meeting will be __ next Thursday (February 2nd), 
1700UTC on #openstack-meeting-cp__. For topics and other information see the 
etherpad [2] for this activity.

Thanks,
Ildikó

[1] https://review.openstack.org/#/c/425414/ 
 
[2] https://etherpad.openstack.org/p/cinder-nova-api-changes 
 


> On 2017. Jan 23., at 22:40, Ildiko Vancsa  wrote:
> 
> Hi All,
> 
> Unfortunately our current meeting slot (every Monday 1700UTC) is in collision 
> for several of the regular attendees.
> 
> In an attempt to find a new slot I checked the available meeting channels for 
> the same time slot over the week and we have at least on available currently 
> for each day. So for the first try let’s see whether we can find another day 
> during the week with the SAME (1700UTC) time slot that works better.
> 
> You can share your preference on this Doodle poll: 
> http://doodle.com/poll/9per237agrdy7rqz 
> 
> 
> Thanks,
> Ildikó

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

Re: [openstack-dev] [OpenStack-I18n] What's Up, Doc? Farewell edition

[Alexandra Settle]

I am sad too ☹ end of an era. 

Looking forward to what we can achieve together ☺ 

Thank you to everyone for your support ☺ 

On 1/27/17, 1:17 AM, "Lana Brindley"  wrote:

Hi everyone,

I must confess, I'm feeling a little sad. This is my very last What's Up, 
Doc. Next week, I'll be handling the Docs PTL mantle to Alexandra Settle. I've 
worked with Alex in varying capacities over many years, and I have no doubt 
that she will be a fabulous PTL. I'm really looking forward to working with 
her, and seeing what new directions she's able to take this team. I want to 
take this opportunity to thank each and every one of you for your continued 
support and encouragement over the last two years (and almost-four releases!). 
I have had an absolute ball doing this job, and it's all because of the amazing 
people I get to work with every day. Of course, I'm not going anywhere just 
yet. I will stay on as a core contributor, and continue to help out as much as 
I can.

In the meantime, we have a release to get out the door! We now only have 26 
days until Ocata is released, please keep an eye on the docs mailing list for 
updates, and consider getting your hands dirty with some Install Guide testing: 
https://wiki.openstack.org/wiki/Documentation/OcataDocTesting

== Progress towards Ocata ==

26 days to go!

Closed 211 bugs so far.

Release tasks are being tracked here: 
https://wiki.openstack.org/wiki/Documentation/OcataDeliverables
Install Guide testing is being tracked here: 
https://wiki.openstack.org/wiki/Documentation/OcataDocTesting

== The Road to PTG in Atlanta ==

Event info is available here: http://www.openstack.org/ptg 
Purchase tickets here: https://pikeptg.eventbrite.com/ 

Docs is a horizontal project, so our sessions will run across the Monday 
and Tuesday of the event. We will be combining the docs event with i18n, so 
translators and docs people will all be in the room together.

Conversation topics for Docs and i18n here: 
https://etherpad.openstack.org/p/docs-i18n-ptg-pike

Also, a quick note that the CFP and ticket sales for *Boston in May* are 
now open: https://www.openstack.org/summit/boston-2017/call-for-presentations/

== Speciality Team Reports ==

No speciality team reports this week, as we didn't have quorum for the docs 
meeting. 

== Doc team meeting ==

Our next meeting will be on Thursday 9 February at 2100 UTC in 
#openstack-meeting-alt

Meeting chair will be Alexandra Settle.

For more meeting details, including minutes and the agenda: 
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

--

Keep on doc'ing!

Lana

https://wiki.openstack.org/wiki/Documentation/WhatsUpDoc#27_January_2017

-- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com



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

[openstack-dev] [Nova] FFE Request for "restore-vm-diagnostics"

[Sergey Nikitin]

Hi, folks!

I'm asking a FFE for restore-vm-diagnostics [1]. There are 3 patches and
yesterday I had five +2 on them from Alex Xu, Stephen Finucane and John
Garbutt. Unfortunatly I lost 3 of them because of nits fixing. I mean that
patches are totally ready for merge and it would be a pity to move them
into next release.

https://review.openstack.org/#/c/394480/
https://review.openstack.org/#/c/399613/
https://review.openstack.org/#/c/355540/

[1] https://blueprints.launchpad.net/nova/+spec/restore-vm-diagnostics
__
OpenStack Development Mailing 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-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[Adam Harwell]

Yeah, I believe it was because we intended to leave it up to the specific
certificate manager to determine what needs to be done -- we are treating
it as a delete, and if the cert manager wants to do a true delete, they
can. I'll agree the verb is not perfectly clear, but the driver author
should make sure the correct action is taken regardless of the function
name.

It's possible we should just rename the function to something like
"unget_cert", which sounds a bit nonsensical but is possibly still clearer.
I remember at the time I wrote this being frustrated with trying to name
the function and wanting to just move on. T_T

   --Adam (rm_work)

PS: Did we remove the local cert manager yet? Now I need to check... I hope
so, because it's not actually usable, nor can it be without API
modifications (which we discussed but never actually implemented or even
fully agreed on).

On Wed, Jan 25, 2017, 17:50 Jiahao Liang (Frankie) 
wrote:

> Thanks rm_work.
>
> I also notice something need to be handled properly.
>
> For barbican, the delete_cert() only deregisters the cert without actually
> delete it. That's safe for us to call during
> delete_listener()/delete_loadbalancer().
>
> But if the user uses other cert_manager by any chance, say the
> local_cert_manager, the same delete_cert() method will do a real delete of
> the cert.
>
> Probably we need to implement register_consumer()/remove_consumer() method
> for cert_manager and call them in neutron_lbaas as well.
>
>
> On Wed, Jan 25, 2017 at 10:48 Adam Harwell  wrote:
>
> I've got this on my list of things to look at -- I don't know if it was
> you I was talking with on IRC the other day about this issue, but I'm
> definitely aware of it. As soon as we are past the Ocata feature freeze
> crunch, I'll take a closer look.
>
> My gut says that we should be calling the delete (which is not a real
> delete) when the LB is deleted, and not doing so is a bug, but I'll need to
> double check the logic as it has been a while since I touched this.
>
> --Adam (rm_work)
>
> On Mon, Jan 23, 2017, 18:38 Jiahao Liang (Frankie) <
> gzliangjia...@gmail.com> wrote:
>
> Hi community,
>
> I created a loadbalancer with a listener with protocol as
> "TERMINATED_HTTPS" and specify --default-tls-container-ref with a ref of
> secret container from Barbican.
> However, after I deleted the listener, the lbaas wasn't removed from
> barbican container consumer list.
>
> $openstack secret container get
> http://192.168.20.24:9311/v1/containers/453e8905-d42b-43bd-9947-50e3acf499f4
>
> ++-+
> | Field  | Value
> |
>
> ++-+
> | Container href |
> http://192.168.20.24:9311/v1/containers/453e8905-d42b-43bd-9947-50e3acf499f4
>|
> | Name   | tls_container2
>  |
> | Created| 2017-01-19 12:44:07+00:00
> |
> | Status | ACTIVE
>  |
> | Type   | certificate
> |
> | Certificate|
> http://192.168.20.24:9311/v1/secrets/bfc2bf01-0f23-4105-bf09-c75839b6b4cb
>   |
> | Intermediates  | None
>  |
> | Private Key|
> http://192.168.20.24:9311/v1/secrets/c85d150e-ec84-42e0-a65f-9c9ec19767e1
>   |
> | PK Passphrase  | None
>  |
> | *Consumers  | {u'URL':
> u'lbaas://RegionOne/loadbalancer/5e7768b9-7aa9-4146-8a71-6291353b447e',
> u'name': u'lbaas'}*
>
>
> I went through the neutron-lbaas code base. We did register consumer
> during the creation of "TERMINATED_HTTPS" listener in [1]. But we somehow
> doesn't deregister it during the deletion in [1]:
> https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/services/loadbalancer/plugin.py#L642
> get_cert() register lbaas as a consumer for barbican cert_manager.  (
> https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/common/cert_manager/barbican_cert_manager.py#L177
> )
> [2]:
> https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/services/loadbalancer/plugin.py#L805
> we probably need to call delete_cert from barbican cert_manager to remove
> the consumer. (
> https://github.com/openstack/neutron-lbaas/blob/stable/mitaka/neutron_lbaas/common/cert_manager/barbican_cert_manager.py#L187
> )
>
>
> My questions are:
> 1. is that a bug?
> 2. or is it a intentional design letting the vendor driver to handle it?
>
> It looks more like a bug to me.
>
> Any thoughts?
>
>
> Best,
> Jiahao
> --
>
> *梁嘉豪/Jiahao LIANG (Frankie) *
> Email: gzliangjia...@g

Re: [openstack-dev] [puppet] Nominating mkarpin for core for the Puppet OpenStack modules

[mkarpin]

Thank you very much for this opportunity!

I learned a lot from you and I will do my best to continue improving 
puppet modules!



On 01/26/2017 07:32 PM, Alex Schultz wrote:

On Thu, Jan 19, 2017 at 3:25 PM, Alex Schultz  wrote:

Hey Puppet Cores,

I would like to nominate Mykyta Karpin as a Core reviewer for the
Puppet OpenStack modules.  He has been providing quality patches and
reviews for some time now and I believe he would be a good addition to
the team.  His stats for the last 90 days can be viewed here[0]

Please response with your +1 or any objections. If there are no
objections by Jan 26, I will add him to the core list.


As there were no objections, I have added him to the core list. Welcome Mykyta.

Thanks,
-Alex


Thanks,
-Alex

[0] http://stackalytics.com/report/contribution/puppet%20openstack-group/90

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


--
Thanks, Nikita Karpin
MOS Puppet Devops
at Mirantis

slack: mkarpin
skype: nkarpin1
phone: + 38-066-628-02-46


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