Re: [openstack-dev] [all][elections] Candidate proposals for TC (Technical Committee) positions are now open

[Jens Rosenboom]

2017-03-31 2:00 GMT+02:00 Kendall Nelson :
>
> Hello All!
>
> Candidate proposals for the Technical Committee positions (7 positions) are
> now open and will remain open until 2017-04-20, 23:45 UTC

The table below states a much earlier closing time.

> All candidacies must be submitted as a text file to the openstack/election
> repository as explained on the election website[1].
> Please note that the name of the file has changed this cycle to be the
> candidates IRC nic *not* full-name.
>
> Also for TC candidates election officials refer to the community member
> profiles at [2] please take this opportunity to ensure that the you profile
> contains current information.
>
> Candidates for the Technical Committee Positions: Any Foundation individual
> member can propose their candidacy for an available, directly-elected TC
> seat. (except the six (6) TC members who were elected for a one-year seat in
> October[3]).
>
> The election will be held from March 30th through to 23:45 April 20th, 2017

This also doesn't match the dates listed below, please clarify.

> UTC. The electorate are the Foundation individual members that are also
> committers for one of the official programs projects[4] over the
> Newton-Ocata timeframe (Apr 07, 2016 00:00 UTC to Feb 22, 2017 23:59 UTC),
> as well as the extra-ATCs who are acknowledged by the TC[5].
>
> Please see the website[1] for additional details about this election. Please
> find below the timeline:
>
> TC nomination starts   @ 2017-03-30, 23:59 UTC
> TC nomination ends @ 2017-04-09, 23:45 UTC
> TC elections starts@ 2017-04-13, 23:59 UTC
> TC elections ends  @ 2017-04-20, 23:45 UTC
>
> If you have any questions please be sure to either voice them on the mailing
> list or to the elections officials[6].
>
> Thank you, and we look forward to reading your candidate proposals,
>
> Kendall Nelson (diablo_rojo)
>
> [1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
> [2] http://www.openstack.org/community/members/
> [3] https://governance.openstack.org/election/results/ocata/tc.html
> [4]
> https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=jan-2017-elections
> [5] Look for the extra-atcs element in [4]
> [6] http://governance.openstack.org/election/#election-officials

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

[openstack-dev] [all] BOS Forum - User/Dev Feedback session for your project?

[Tom Fifield]

Hi all,

Forum topic submission closes in 2 days (Sunday 23:59 UTC).

One of the types of topics you could consider submitting is a user/dev 
feedback session for your project. I see Swift, Keystone and Kolla have 
already done this - thanks!


From experience running the ops meetups, the best user/dev feedback 
sessions are co-organised by a leading developer and a prominent user. 
The dev can bring burning questions that the project wants answered; the 
user is great at eliciting information from the room.


If you're interested in doing something like that in Boston,

http://forumtopics.openstack.org/

welcomes you ... for the next 68 hours.


Regards,


Tom

__
OpenStack Development Mailing 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]: floating IP not being set for L2 GRE packets

[Kevin Benton]

I would file a bug against devstack to get some feedback on the best place
to automatically load that module.

On Thu, Mar 30, 2017 at 11:47 AM, Anil Rao  wrote:

> I manually loaded the specified kernel module (nf_conntrack_proto_gre) in
> the network node and now the translation between the VM’ local IP and its
> assigned floating IP is working as expected for L2 GRE traffic.
>
>
>
> Thanks a million, Kevin. J
>
>
>
> Is there something I need to do to automate this step for DevStack
> installations?
>
>
>
> Regards,
>
> Anil
>
>
>
> *From:* Anil Rao [mailto:anil@gigamon.com]
> *Sent:* Thursday, March 30, 2017 11:36 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron]: floating IP not being set for
> L2 GRE packets
>
>
>
> This sender failed our fraud detection checks and may not
> be who they appear to be. Learn about spoofing
> 
>
> Feedback 
>
> Hi,
>
>
>
> Thanks for the reply. I checked the network node and the
> nf_conntrack_proto_gre kernel module is not loaded. Among the loaded kernel
> modules the only ones bearing the ‘nf_conntrack’ prefix are the following:
>
>
>
> -  nf_conntrack
>
> -  nf_conntrack_ipv4
>
> -  nf_conntrfack_ipv6
>
> -  nf_conntrack_netlink
>
>
>
> -Anil
>
>
>
> *From:* Kevin Benton [mailto:ke...@benton.pub ]
> *Sent:* Thursday, March 30, 2017 12:41 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron]: floating IP not being set for
> L2 GRE packets
>
>
>
> Do you have the nf_conntrack_proto_gre kernel module loaded on the network
> node?
>
>
>
> On Wed, Mar 29, 2017 at 4:37 PM, Anil Rao  wrote:
>
> Strangely enough, there is no problem when I make use of a VxLAN tunnel to
> communicate between the VM (inside the cloud) and an external machine. In
> this case, the network node is performing the correct translation between
> the VM’s local IP and the floating IP currently assigned to it.
>
> So far I have only seen this problem when using L2 GRE tunnels.
>
> Thanks,
>
> Anil
>
>
>
> *From:* Anil Rao [mailto:anil@gigamon.com]
> *Sent:* Wednesday, March 29, 2017 3:17 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [neutron]: floating IP not being set for L2
> GRE packets
>
>
>
> This sender failed our fraud detection checks and may not
> be who they appear to be. Learn about spoofing
> 
>
> Feedback 
>
> Hi,
>
> I am seeing a strange behavior when it comes to floating IPs and L2 GRE
> tunnels that I was hoping someone could shed light on.
>
> Inside a tenant (project) I have a VM that wants to communicate with a
> machine residing outside the cloud. For this purpose, a floating IP has
> been assigned to the VM’s interface.
>
> *Case 1: VM communicates with external machine using ‘ping’.*
>
> This is successful.
>
> At the network node (from where the packets leave the OpenStack cloud),
> the VM’s local IP address is replaced with its floating IP for outgoing
> packets. Similarly, for incoming packets, the floating IP is replaced with
> the VM’s local IP address.
>
> *Case 2: VM communicates with the external machine using an L2 GRE tunnel.*
>
> This is not successful.
>
> At the network node, the outgoing packets [still] have the VM’ local IP
> address. It is not surprising that no packets come back for the VM from the
> external machine.
>
> My question is:  why didn’t the network node replace the VM’s IP address
> with its floating IP for the L2 GRE case although it did this for the
> simple ping case?
>
> I see this behavior on a multi-node DevStack based on stable/ocata as well
> as a multi-node production Newton cloud.
>
> Thanks and regards,
>
> Anil
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] How to find "ovs_mechanism + vxlan tanent_type_driver + L2_pop" configure steps?

[Sam]

Hi all,

In openstack-ocata install docs, I only found "linux_bridge + vxlan +
l2pop" configure steps, Is there "ovs+vxlan+l2pop" configure steps?

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

Re: [openstack-dev] [stable][heat] Nominate huangtianhua for heat-stable-maint

[Rico Lin]

+1 for huangtianhua. She been very active for stable branch and all the
reviews and patches seems all fallowing stable branch rules.

+1 for remove Angus, and thanks very much for his hard works. Hope to have
him join in the future.

2017年3月31日 上午4:48，"Zane Bitter" 寫道：

> We are feeling the pinch on stable-branch reviewers in Heat, so now that I
> understand the process a bit better, let's try this again.
>
> I'd like to nominate Huang Tianhua to join the heat-stable-maint team.
> Tianhua is a heat-core member and one of our most prolific stable branch
> reviewers:
>
> https://review.openstack.org/#/q/reviewer:huangtianhua+-owne
> r:huangtianhua+projects:openstack/heat+branch:%22%255Estable/.*%22
>
> IMHO her track record displays an understanding of the stable branch
> policies appropriate to a stable branch core. e.g.
>
> * https://review.openstack.org/#/c/434030/
> * https://review.openstack.org/#/c/371135/
> * https://review.openstack.org/#/c/244948/
>
> Also, I suggest we take this opportunity to remove Angus Salkeld, since he
> is no longer actively working on OpenStack (http://stackalytics.com/?rele
> ase=all_id=asalkeld)
>
> thanks,
> Zane.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][elections] Candidate proposals for TC (Technical Committee) positions are now open

[Kendall Nelson]

Hello All!

Candidate proposals for the Technical Committee positions (7 positions) are
now open and will remain open until 2017-04-20, 23:45 UTC

All candidacies must be submitted as a text file to the openstack/election
repository as explained on the election website[1].
Please note that the name of the file has changed this cycle to be the
candidates IRC nic *not* full-name.

Also for TC candidates election officials refer to the community member
profiles at [2] please take this opportunity to ensure that the you profile
contains current information.

Candidates for the Technical Committee Positions: Any Foundation individual
member can propose their candidacy for an available, directly-elected TC
seat. (except the six (6) TC members who were elected for a one-year seat
in October[3]).

The election will be held from March 30th through to 23:45 April 20th, 2017
UTC. The electorate are the Foundation individual members that are also
committers for one of the official programs projects[4] over the
Newton-Ocata timeframe (Apr 07, 2016 00:00 UTC to Feb 22, 2017 23:59 UTC),
as well as the extra-ATCs who are acknowledged by the TC[5].

Please see the website[1] for additional details about this election.
Please find below the timeline:

TC nomination starts   @ 2017-03-30, 23:59 UTC
TC nomination ends @ 2017-04-09, 23:45 UTC
TC elections starts@ 2017-04-13, 23:59 UTC
TC elections ends  @ 2017-04-20, 23:45 UTC

If you have any questions please be sure to either voice them on the
mailing list or to the elections officials[6].

Thank you, and we look forward to reading your candidate proposals,

Kendall Nelson (diablo_rojo)

[1] http://governance.openstack.org/election/#how-to-submit-your-candidacy
[2] http://www.openstack.org/community/members/
[3] https://governance.openstack.org/election/results/ocata/tc.html
[4]
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=jan-2017-elections
[5] Look for the extra-atcs element in [4]
[6] http://governance.openstack.org/election/#election-officials
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][ml2] - heads up for mechanism drivers that don't use in tree DHCP agent

[Kevin Benton]

Hi,

Once [1] merges, a port will not transition to ACTIVE on a subnet with
enable_dhcp=True unless something clears the DHCP provisioning block.

If your mechanism driver uses the in-tree DHCP agent, there is nothing you
need to do. However, if you do not utilize the DHCP agent in your
deployment scenarios and you offload DHCP to something else, your mechanism
driver must now explicitly acknowledge that DHCP has been provisioned for
that port.

Acknowledging that DHCP is ready for a port is a one-line call to the
provisioning_blocks module[2]. For more information on provisioning blocks,
see [3].

1. https://review.openstack.org/452009
2. https://github.com/openstack/neutron/blob/4ed53a880714fd33280064c58e6f91
b9ecd3823e/neutron/api/rpc/handlers/dhcp_rpc.py#L292-L294
3. https://docs.openstack.org/developer/neutron/devref/
provisioning_blocks.html

Cheers,
Kevin Benton
__
OpenStack Development Mailing 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] - Adding Miguel Lavalle to neutron-drivers team

[Ihar Hrachyshka]

On Thu, Mar 30, 2017 at 2:11 PM, Kevin Benton  wrote:
> Hi,
>
> I would like to add Miguel Lavalle (mlavalle) to the Neutron drivers team
> [1].

It's not completely clear if you seek support here, but in case you do, +1.

Ihar

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

[openstack-dev] [glance] priorities for the coming week (03/31-04/06)

[Brian Rosmaita]

As discussed at today's meeting, here are the priorities for Glance this
week:

Pike-1 milestone approaching

Hemanth announced Thursday 6 April as the deadline for patches to be
merged for P-1.  That will give us roughly a week before P-1 to fix any
bugs or regressions that occur.  Please concentrate on the following items:

1. Support for partial downloads.  These are close to completion:
- https://review.openstack.org/441501
- https://review.openstack.org/434558
- https://review.openstack.org/441707

2. Replace pycrypto with cryptography.  (This is actually a small patch,
we were only using pycrypto in two utility functions.)
- https://review.openstack.org/#/c/449401/

3. Image import refactor.  I think Hemanth figured out how to get around
the config problem that was causing these to fail in the gate.  As we
discussed in today's meeting, let's focus on the essential aspects of
these patches and leave rewording of log messages and help text to
follow up patches.  (Of course, if you see a problem in the code, I
expect you to call it out.)  It would be nice to get the basic backend
into P-1.
- https://review.openstack.org/#/c/391442/
- https://review.openstack.org/#/c/391441/
- https://review.openstack.org/#/c/443636/
- https://review.openstack.org/#/c/443632/
- https://review.openstack.org/#/c/443633/


Spec Reviews

Please provide early feedback for the specs you "volunteered" to look at:
https://etherpad.openstack.org/p/glance-pike-specs-review

People who missed today's glance meeting and weren't able to volunteer,
don't let that stop you from reviewing a few of these also.

To be considered for Pike, specs must be merged by 23:59 on Friday 14
April 2017.


Wishing everyone a productive week,
brian

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

[openstack-dev] [neutron] - Adding Miguel Lavalle to neutron-drivers team

[Kevin Benton]

Hi,

I would like to add Miguel Lavalle (mlavalle) to the Neutron drivers team
[1].

Miguel has been instrumental in implemented features across Neutron and
Nova (routed networks, DNS, etc) and is now leading the L3 team. He has a
very good high level architectural view of Neutron necessary for deciding
what features are feasible for the platform.



1.
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team

Cheers,
Kevin Benton
__
OpenStack Development Mailing 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] [stable][heat] Nominate huangtianhua for heat-stable-maint

[Zane Bitter]

We are feeling the pinch on stable-branch reviewers in Heat, so now that 
I understand the process a bit better, let's try this again.


I'd like to nominate Huang Tianhua to join the heat-stable-maint team. 
Tianhua is a heat-core member and one of our most prolific stable branch 
reviewers:


https://review.openstack.org/#/q/reviewer:huangtianhua+-owner:huangtianhua+projects:openstack/heat+branch:%22%255Estable/.*%22

IMHO her track record displays an understanding of the stable branch 
policies appropriate to a stable branch core. e.g.


* https://review.openstack.org/#/c/434030/
* https://review.openstack.org/#/c/371135/
* https://review.openstack.org/#/c/244948/

Also, I suggest we take this opportunity to remove Angus Salkeld, since 
he is no longer actively working on OpenStack 
(http://stackalytics.com/?release=all_id=asalkeld)


thanks,
Zane.

__
OpenStack Development Mailing 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] rebuild_instance (nova evacuate) failed to add trunk port

[KHAN, RAO ADNAN]

In Juno, there is an issue with instance rebuild (nova evacuate) when trunk 
port is associated with that instance. On the target, it is not provisioning 
tbr (bridge) and hence 'ovs-vsctl' command failed when adding trunk port.

To me this seems a design gap; but I couldn't pin point it. Can someone point 
me to the right direction?

Thanks much,

Rao Adnan Khan
AT Integrated Cloud (AIC) Development | SE
Software Development & Engineering (SD)
Emai: rk2...@att.com
Cell phone: 972-342-5638

RESTRICTED - PROPRIETARY INFORMATION
This email is the property of AT and intended solely for the use of the 
addressee. If you have reason to believe you have received this in error, 
please delete this immediately; any other use, retention, dissemination, 
copying or printing of this email is strictly prohibited.


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

Re: [openstack-dev] [TripleO] spec-lite process for tripleo

[Ben Nemec]

On 03/28/2017 11:09 AM, Emilien Macchi wrote:

Bringing an old topic on the table.

We might have noticed:

1. Some tripleo-specs take huge amount of time before getting merged
(or even reviewed). We have been asking folks to review them every
week but unfortunately they don't get much attraction (# of core
reviewers versus # of folks actually reviewing specs).


To me, this is an indication that cores are overloaded already (or 
apathetic about software design, but I'm going to be optimistic here). 
Adding more features for them to review isn't going to help that. :-/



2. Some folks spend a lot of time writing TripleO specs and wait for
feedback before starting some implementation (like proof of concept).

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

1. If you have an idea, don't feel obliged to write a specs. Create a
blueprint on launchpad, announce it on the ML and start writing code
(can be real implementation or just a simple PoC). Feedback will be
given in the classic code review.


I hate that we've come to this (and yes, hate is a strong word.  That's 
not an accident).  For minor features that only require a single or 
couple of patches, sure.  But one of the advantages of specs is that 
they provide an explicit list of things that the submitter needs to 
think about (user interaction, documentation, testing, security, etc.). 
This is all stuff that needs to be considered whether we use full specs 
or not, unless the feature is so small that none of them apply, which is 
a good indication that a spec is not required anyway.


That said, I do recognize the problems we've had with specs.  I wonder 
if, regardless of whether we do a spec-lite thing, we need to revisit 
https://specs.openstack.org/openstack/tripleo-specs/specs/policy/spec-review.html 
and streamline it a lot.  Stronger emphasis on not nit-picking spelling 
and grammar, maybe better guidelines about the expected level of detail 
of a spec and how deeply (or not) they should be reviewed.


Also worth noting is that a few of us have been contacted privately 
asking for tips on writing specs.  It might be worth writing something 
up from the other side to help committers write good, reviewable specs. 
It wouldn't have to be elaborate, but some guidelines might make 
everyone's lives easier.



2. If you still want to write a spec, please make it readable and
communicate about it. If your spec is 900 lines long and not announced
anywhere, there is an high change that it will never been reviewed.


+1.  It seems like a lot of the problems with specs stem from the fact 
that they get too deep into the implementation details and it just takes 
too long to review.  Also, as Steve mentioned, it's hard to know all the 
implementation details up front.  The spec should just be setting the 
direction and allowing people to raise concerns with same.



3. If you still want to write a spec, please don't stop your work
after the specs. Please engage some PoC and prototypes to get feedback
directly on the implementation.


Having a PoC to look at while reviewing a spec can be super helpful.  I 
would caution about getting too invested in a specific direction in case 
the review feedback requires major changes, but I'm +1 overall on this.




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

Thanks,

On Fri, Jan 29, 2016 at 3:26 AM, Dougal Matthews  wrote:



On 27 January 2016 at 16:21, Derek Higgins  wrote:


Hi All,

We briefly discussed feature tracking in this weeks tripleo meeting. I
would like to provide a way for downstream consumers (and ourselves) to
track new features as they get implemented. The main things that came out of
the discussion is that people liked the spec-lite process that the glance
team are using.

I'm proposing we would start to use the same process, essentially small
features that don't warrant a blueprint would instead have a wishlist bug
opened against them and get marked with the spec-lite tag. This bug could
then be referenced in the commit messages. For larger features blueprints
can still be used. I think the process documented by glance[1] is a good
model to follow so go read that and see what you think

The general feeling at the meeting was +1 to doing this[2] so I hope we
can soon start enforcing it, assuming people are still happy to proceed?



+1 sounds good.




thanks,
Derek.

[1]
http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite
[2]
http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01-26-14.02.log.html

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

Re: [openstack-dev] [ironic] Translations removal

[Doug Hellmann]

Excerpts from Jim Rollenhagen's message of 2017-03-30 15:08:13 -0400:
> On Thu, Mar 30, 2017 at 2:36 PM, Doug Hellmann 
> wrote:
> 
> > Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:
> > > On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
> > > > On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:
> > > > > However, pep8 does not accept passing variable to translation
> > > > > functions,  so this results in ‘H701 Empty localization string’
> > error.
> > > > >
> > > > > Possible options to handle that:
> > > > >
> > > > > 1)  Duplicate messages:
> > > > >
> > > > > LOG.error(“”, {: })
> > > > >
> > > > > raise Exception(_(“”) % {: })
> > > > >
> > > > > 2)  Ignore this error
> > > > >
> > > > > 3)  Talk to hacking people about possible upgrade of this check
> > > > >
> > > > > 4)  Pass translated text to LOG in such cases
> > > > >
> > > > >
> > > > >
> > > > > I’d personally vote for 2. What are your thoughts?
> > > >
> > > > When the translators go to translate, they generally only get to see
> > > > what's inside _(), so #2 is a no-go for translations, and #3 also is a
> > > > no-go.
> > > > --
> > >
> > > I think the appropriate thing here is to do something like:
> > >
> > > msg = _('') % {: }
> > > LOG.error(msg)
> > > raise Exception(msg)
> > >
> > > This results in a translated string going to the log, but I think that's
> > > OK.
> > >
> >
> > Why is the error being logged and then thrown? If it's a true exception,
> > won't the outer-most part of the application loop log the error? And if
> > it's something that the application is catching and handling, that makes
> > it seem like it's not an operator-facing error.
> >
> 
> That's a good point. Without looking for examples, I suspect there's a few
> reasons here:
> 
> 1) in ironic, the operator and API user are often the same person
> 2) ironic deals with hardware. Often, errors that are returned to the user
> are
>something only the operator can fix.
> 3) Nova is a heavy user of the ironic API - errors returned to nova may not
> be
>seen by the user, but the operator needs to see it somewhere (though it
>is easy to argue those shouldn't be translated).
> 
> // jim

I guess my point was that unhandled exceptions should all be handled
by the Ironic API service code before the response is delivered,
rather than having them handled in the code that is throwing the
exception. If the exception is handled, that makes the message a warning
or info log message, not an error, under our guidelines [1].

[1] 
http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html

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

Re: [openstack-dev] [ironic] Translations removal

[Jim Rollenhagen]

On Thu, Mar 30, 2017 at 2:36 PM, Doug Hellmann 
wrote:

> Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:
> > On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
> > > On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:
> > > > However, pep8 does not accept passing variable to translation
> > > > functions,  so this results in ‘H701 Empty localization string’
> error.
> > > >
> > > > Possible options to handle that:
> > > >
> > > > 1)  Duplicate messages:
> > > >
> > > > LOG.error(“”, {: })
> > > >
> > > > raise Exception(_(“”) % {: })
> > > >
> > > > 2)  Ignore this error
> > > >
> > > > 3)  Talk to hacking people about possible upgrade of this check
> > > >
> > > > 4)  Pass translated text to LOG in such cases
> > > >
> > > >
> > > >
> > > > I’d personally vote for 2. What are your thoughts?
> > >
> > > When the translators go to translate, they generally only get to see
> > > what's inside _(), so #2 is a no-go for translations, and #3 also is a
> > > no-go.
> > > --
> >
> > I think the appropriate thing here is to do something like:
> >
> > msg = _('') % {: }
> > LOG.error(msg)
> > raise Exception(msg)
> >
> > This results in a translated string going to the log, but I think that's
> > OK.
> >
>
> Why is the error being logged and then thrown? If it's a true exception,
> won't the outer-most part of the application loop log the error? And if
> it's something that the application is catching and handling, that makes
> it seem like it's not an operator-facing error.
>

That's a good point. Without looking for examples, I suspect there's a few
reasons here:

1) in ironic, the operator and API user are often the same person
2) ironic deals with hardware. Often, errors that are returned to the user
are
   something only the operator can fix.
3) Nova is a heavy user of the ironic API - errors returned to nova may not
be
   seen by the user, but the operator needs to see it somewhere (though it
   is easy to argue those shouldn't be translated).

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

[Farr, Kaitlin M.]

>    As i known, the secrets are saved in a user's domain, and other 
> project/user can not retrieve the secrets.
>    But i have a situation that many users need retrieve a same secret.
>
>    After looking into the castellan usage,  I see the method that saving the 
>credentials in configuration,
> then all operators use this pre-created user to create/retrieve secrets. 
> I want to know, is this way typical and easy-accepted? Does other projects 
>face this issue?
  

​By default, the secrets in Barbican are available at the project-level
[1]. I am not sure specifically which project or feature you are
referring to that all users need to access to one secret, but I would
suggest that editing the Barbican RBAC policy or ACL is a more elegant
solution than storing username/pw in the conf file. You can find more
details about RBAC at [2] and a sample policy.json file at [3].

Kaitlin Farr

1. https://developer.openstack.org/api-guide/key-manager/acls.html#default-acl
2. 
https://docs.openstack.org/developer/barbican/admin-guide-cloud/access_control.html
3. https://github.com/openstack/barbican/blob/master/etc/barbican/policy.json

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

Re: [openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

[Doug Hellmann]

Excerpts from Paul Belanger's message of 2017-03-22 09:58:46 -0400:
> On Tue, Mar 21, 2017 at 05:53:35PM -0600, Alex Schultz wrote:
> > On Tue, Mar 21, 2017 at 5:35 PM, John Dickinson  wrote:
> > >
> > >
> > > On 21 Mar 2017, at 15:34, Alex Schultz wrote:
> > >
> > >> On Tue, Mar 21, 2017 at 3:45 PM, John Dickinson  wrote:
> > >>> I've been following this thread, but I must admit I seem to have missed 
> > >>> something.
> > >>>
> > >>> What problem is being solved by storing per-server service 
> > >>> configuration options in an external distributed CP system that is 
> > >>> currently not possible with the existing pattern of using local text 
> > >>> files?
> > >>>
> > >>
> > >> This effort is partially to help the path to containerization where we
> > >> are delivering the service code via container but don't want to
> > >> necessarily deliver the configuration in the same fashion.  It's about
> > >> ease of configuration where moving service -> config files (on many
> > >> hosts/containers) to service -> config via etcd (single source
> > >> cluster).  It's also about an alternative to configuration management
> > >> where today we have many tools handling the files in various ways
> > >> (templates, from repo, via code providers) and trying to come to a
> > >> more unified way of representing the configuration such that the end
> > >> result is the same for every deployment tool.  All tools load configs
> > >> into $place and services can be configured to talk to $place.  It
> > >> should be noted that configuration files won't go away because many of
> > >> the companion services still rely on them (rabbit/mysql/apache/etc) so
> > >> we're really talking about services that currently use oslo.
> > >
> > > Thanks for the explanation!
> > >
> > > So in the future, you expect a node in a clustered OpenStack service to 
> > > be deployed and run as a container, and then that node queries a 
> > > centralized etcd (or other) k/v store to load config options. And other 
> > > services running in the (container? cluster?) will load config from local 
> > > text files managed in some other way.
> > 
> > No the goal is in the etcd mode, that it  may not be necessary to load
> > the config files locally at all.  That being said there would still be
> > support for having some configuration from a file and optionally
> > provide a kv store as another config point.  'service --config-file
> > /etc/service/service.conf --config-etcd proto://ip:port/slug'
> > 
> Hmm, not sure I like this.  Having a service magically read from 2 different
> configuration source at run time, merge them, and reload, seems overly
> complicated. And even harder to debug.
> 
> > >
> > > No wait. It's not the *services* that will load the config from a kv 
> > > store--it's the config management system? So in the process of deploying 
> > > a new container instance of a particular service, the deployment tool 
> > > will pull the right values out of the kv system and inject those into the 
> > > container, I'm guessing as a local text file that the service loads as 
> > > normal?
> > >
> > 
> > No the thought is to have the services pull their configs from the kv
> > store via oslo.config.  The point is hopefully to not require
> > configuration files at all for containers.  The container would get
> > where to pull it's configs from (ie. http://11.1.1.1:2730/magic/ or
> > /etc/myconfigs/).  At that point it just becomes another place to load
> > configurations from via oslo.config.  Configuration management comes
> > in as a way to load the configs either as a file or into etcd.  Many
> > operators (and deployment tools) are already using some form of
> > configuration management so if we can integrate in a kv store output
> > option, adoption becomes much easier than making everyone start from
> > scratch.
> > 
> > > This means you could have some (OpenStack?) service for inventory 
> > > management (like Karbor) that is seeding the kv store, the cloud 
> > > infrastructure software itself is "cloud aware" and queries the central 
> > > distributed kv system for the correct-right-now config options, and the 
> > > cloud service itself gets all the benefits of dynamic scaling of 
> > > available hardware resources. That's pretty cool. Add hardware to the 
> > > inventory, the cloud infra itself expands to make it available. Hardware 
> > > fails, and the cloud infra resizes to adjust. Apps running on the infra 
> > > keep doing their thing consuming the resources. It's clouds all the way 
> > > down :-)
> > >
> > > Despite sounding pretty interesting, it also sounds like a lot of extra 
> > > complexity. Maybe it's worth it. I don't know.
> > >
> > 
> > Yea there's extra complexity at least in the
> > deployment/management/monitoring of the new service or maybe not.
> > Keeping configuration files synced across 1000s of nodes (or
> > containers) can be just as hard however.
> > 
> Please correct me if I am 

Re: [openstack-dev] [murano] MuranoPL types question

[Stan Lagun]

Hi Paul,

> Here both key and value appear to be a string (note, I can't confirm this
as the typeinfo function doesn't appear to be available in Instance.yaml
for some reason... perhaps I'm using it wrong)

They are not strings. Reporter converts everything that is passed to it
into string by doing unicode(obj). What you see is the Python string
representation of lists and dicts, where every unicode string is prefixed
with "u".
Typinfo function works on objects (instances of MuranoPL classes), not on
primitive types like strings, dicts and lists.

> 1) Why is the content of this 'get_attr' coming from heat being stored in
the stack outputs as a string,
it is stored exactly as it comes from Heat. In theory conversion to string
could happen on Heat side, but most likely it just the output of reporter
made it look like this

> 2) Is there a way I can cast this to a list of dicts or similar structure
so it can be iterated as expected?
It's hard to answer without seeing your code and how you got the results
that you provided.

>  when I access this from a sample app, I end up with a list of strings,
shown by $reporter as: ...

Curly braces in the output indicate that this is not a list of strings but
rather the single dict converted to a string by reporter. So what you see
is the value of that 'vol-7c8ee61f-a444-46a1-ad70-fc6fce6a7b56-attachments'
output, which sounds like what you're wanted it to be. In MuranoPL you can
have very detailed contracts: not just [] (any list) but something like
Contract:
  - key1: string().notNull()
key2: int().notNull()

which is a list of dicts with contract on each dict entry. If you don't get
contract violation exception, you can be sure that the list contains list
of dicts with appropriate keys/values rather than list of strings or
anything else


Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis



On Thu, Mar 30, 2017 at 10:17 AM, Paul Bourke 
wrote:

> Hi Stan,
>
> I had a quick(hopefully) question about MuranoPL that I hope you might be
> able to help with, Felipe had mentioned you are very knowledgeable in this
> area. If you don't have time please disregard!
>
> I'm working on a patch for the Murano core library to make volume
> attachment info available, which is available at
> https://review.openstack.org/451909. It's mostly working, but I'm having
> some issues getting the types correct in MuranoPL to make this info
> consumable by end users.
>
> The attachment info from a sample run in the stack $outputs looks like
> this (taken from the dashboard using $reporter)
>
> u'vol-7c8ee61f-a444-46a1-ad70-fc6fce6a7b56-attachments':
> u"[{u'server_id': u'2891067b-e7bb-4ab9-a759-9e81096c0682',
> u'attachment_id': u'7456a4b0-3abd-48a0-a0cb-f3fa0f2706bb',
> u'attached_at': u'2017-03-30T16:51:57.00', u'host_name': None,
> u'volume_id': u'373e4a5a-46b6-4091-82d6-b3dba62d552b', u'device':
> u'/dev/vda', u'id': u'373e4a5a-46b6-4091-82d6-b3dba62d552b'}]"
>
> Here both key and value appear to be a string (note, I can't confirm this
> as the typeinfo function doesn't appear to be available in Instance.yaml
> for some reason... perhaps I'm using it wrong)
>
> My goal is to then set this into a property of CinderVolume.yaml, with a
> Contract of '[]'. However, when I access this from a sample app, I end up
> with a list of strings, shown by $reporter as:
>
> (u"[{u'server_id': u'2891067b-e7bb-4ab9-a759-9e81096c0682',
> u'attachment_id': u'f5bd50ab-4040-4e2b-8b50-790781d9bc37',
> u'attached_at': u'2017-03-30T16:51:59.00', u'host_name': None,
> u'volume_id': u'ed7eb535-9e81-4c97-b063-86936d4ee306', u'device':
> u'/dev/vdb', u'id': u'ed7eb535-9e81-4c97-b063-86936d4ee306'}]",)
>
> So my question is:
>
> 1) Why is the content of this 'get_attr' coming from heat being stored in
> the stack outputs as a string, and
>
> 2) Is there a way I can cast this to a list of dicts or similar structure
> so it can be iterated as expected?
>
> Any tips much appreciated.
>
> Thanks,
> -Paul
>
__
OpenStack Development Mailing 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]: floating IP not being set for L2 GRE packets

[Anil Rao]

I manually loaded the specified kernel module (nf_conntrack_proto_gre) in the 
network node and now the translation between the VM’ local IP and its assigned 
floating IP is working as expected for L2 GRE traffic.

Thanks a million, Kevin. ☺

Is there something I need to do to automate this step for DevStack 
installations?

Regards,
Anil

From: Anil Rao [mailto:anil@gigamon.com]
Sent: Thursday, March 30, 2017 11:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE 
packets


This sender failed our fraud detection checks and may not be who they appear to 
be. Learn about spoofing

Feedback

Hi,

Thanks for the reply. I checked the network node and the nf_conntrack_proto_gre 
kernel module is not loaded. Among the loaded kernel modules the only ones 
bearing the ‘nf_conntrack’ prefix are the following:


-  nf_conntrack

-  nf_conntrack_ipv4

-  nf_conntrfack_ipv6

-  nf_conntrack_netlink

-Anil

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Thursday, March 30, 2017 12:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE 
packets

Do you have the nf_conntrack_proto_gre kernel module loaded on the network node?

On Wed, Mar 29, 2017 at 4:37 PM, Anil Rao 
> wrote:
Strangely enough, there is no problem when I make use of a VxLAN tunnel to 
communicate between the VM (inside the cloud) and an external machine. In this 
case, the network node is performing the correct translation between the VM’s 
local IP and the floating IP currently assigned to it.
So far I have only seen this problem when using L2 GRE tunnels.
Thanks,
Anil

From: Anil Rao [mailto:anil@gigamon.com]
Sent: Wednesday, March 29, 2017 3:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets


This sender failed our fraud detection checks and may not be who they appear to 
be. Learn about spoofing

Feedback

Hi,
I am seeing a strange behavior when it comes to floating IPs and L2 GRE tunnels 
that I was hoping someone could shed light on.
Inside a tenant (project) I have a VM that wants to communicate with a machine 
residing outside the cloud. For this purpose, a floating IP has been assigned 
to the VM’s interface.
Case 1: VM communicates with external machine using ‘ping’.
This is successful.
At the network node (from where the packets leave the OpenStack cloud), the 
VM’s local IP address is replaced with its floating IP for outgoing packets. 
Similarly, for incoming packets, the floating IP is replaced with the VM’s 
local IP address.
Case 2: VM communicates with the external machine using an L2 GRE tunnel.
This is not successful.
At the network node, the outgoing packets [still] have the VM’ local IP 
address. It is not surprising that no packets come back for the VM from the 
external machine.
My question is:  why didn’t the network node replace the VM’s IP address with 
its floating IP for the L2 GRE case although it did this for the simple ping 
case?
I see this behavior on a multi-node DevStack based on stable/ocata as well as a 
multi-node production Newton cloud.
Thanks and regards,
Anil


__
OpenStack Development Mailing 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]: floating IP not being set for L2 GRE packets

[Anil Rao]

Hi,

Thanks for the reply. I checked the network node and the nf_conntrack_proto_gre 
kernel module is not loaded. Among the loaded kernel modules the only ones 
bearing the ‘nf_conntrack’ prefix are the following:


-  nf_conntrack

-  nf_conntrack_ipv4

-  nf_conntrfack_ipv6

-  nf_conntrack_netlink

-Anil

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Thursday, March 30, 2017 12:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron]: floating IP not being set for L2 GRE 
packets

Do you have the nf_conntrack_proto_gre kernel module loaded on the network node?

On Wed, Mar 29, 2017 at 4:37 PM, Anil Rao 
> wrote:
Strangely enough, there is no problem when I make use of a VxLAN tunnel to 
communicate between the VM (inside the cloud) and an external machine. In this 
case, the network node is performing the correct translation between the VM’s 
local IP and the floating IP currently assigned to it.
So far I have only seen this problem when using L2 GRE tunnels.
Thanks,
Anil

From: Anil Rao [mailto:anil@gigamon.com]
Sent: Wednesday, March 29, 2017 3:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron]: floating IP not being set for L2 GRE packets


This sender failed our fraud detection checks and may not be who they appear to 
be. Learn about spoofing

Feedback

Hi,
I am seeing a strange behavior when it comes to floating IPs and L2 GRE tunnels 
that I was hoping someone could shed light on.
Inside a tenant (project) I have a VM that wants to communicate with a machine 
residing outside the cloud. For this purpose, a floating IP has been assigned 
to the VM’s interface.
Case 1: VM communicates with external machine using ‘ping’.
This is successful.
At the network node (from where the packets leave the OpenStack cloud), the 
VM’s local IP address is replaced with its floating IP for outgoing packets. 
Similarly, for incoming packets, the floating IP is replaced with the VM’s 
local IP address.
Case 2: VM communicates with the external machine using an L2 GRE tunnel.
This is not successful.
At the network node, the outgoing packets [still] have the VM’ local IP 
address. It is not surprising that no packets come back for the VM from the 
external machine.
My question is:  why didn’t the network node replace the VM’s IP address with 
its floating IP for the L2 GRE case although it did this for the simple ping 
case?
I see this behavior on a multi-node DevStack based on stable/ocata as well as a 
multi-node production Newton cloud.
Thanks and regards,
Anil


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

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

Re: [openstack-dev] [ironic] Translations removal

[Doug Hellmann]

Excerpts from Sean McGinnis's message of 2017-03-22 10:44:05 -0500:
> On Wed, Mar 22, 2017 at 08:42:42AM -0500, Kevin L. Mitchell wrote:
> > On Tue, 2017-03-21 at 22:10 +, Taryma, Joanna wrote:
> > > However, pep8 does not accept passing variable to translation
> > > functions,  so this results in ‘H701 Empty localization string’ error.
> > > 
> > > Possible options to handle that:
> > > 
> > > 1)  Duplicate messages:
> > > 
> > > LOG.error(“”, {: })
> > > 
> > > raise Exception(_(“”) % {: })
> > > 
> > > 2)  Ignore this error
> > > 
> > > 3)  Talk to hacking people about possible upgrade of this check
> > > 
> > > 4)  Pass translated text to LOG in such cases
> > > 
> > >  
> > > 
> > > I’d personally vote for 2. What are your thoughts?
> > 
> > When the translators go to translate, they generally only get to see
> > what's inside _(), so #2 is a no-go for translations, and #3 also is a
> > no-go.
> > -- 
> 
> I think the appropriate thing here is to do something like:
> 
> msg = _('') % {: }
> LOG.error(msg)
> raise Exception(msg)
> 
> This results in a translated string going to the log, but I think that's
> OK.
> 

Why is the error being logged and then thrown? If it's a true exception,
won't the outer-most part of the application loop log the error? And if
it's something that the application is catching and handling, that makes
it seem like it's not an operator-facing error.

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

[Jim Rollenhagen]

On Thu, Mar 30, 2017 at 12:04 PM, Jimmy McArthur 
wrote:

> This (http://paste.openstack.org/show/604775/) is absolutely perfect. I
> feel like the format could work for microversions as well. Anyone from
> Neutron or another microversion project that could weigh in?
>

This mostly seems fine to me, a couple problems I see:

* so far projects using microversions haven't been deprecating
microversions (though I'm working on making that a thing), so I see this
bloating quickly. Ironic has over 30 supported versions as of Ocata, Nova
has even more, etc.
* I'm not sure that the governance repo is the right place for this, though
I don't have a better suggestion.
* if we do put it here, we should do it per deliverable, as some projects
may have more than one deliverable with an API (e.g. when nova spins
placement out to its own repo).

Thanks for proposing this, Brian! :)

// jim
__
OpenStack Development Mailing 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] [quotas] Unified Limits Conceptual Spec RFC

[Sean Dague]

The near final draft of the unified limits spec is up now -
https://review.openstack.org/#/c/440815/

If you have not yet wandered in, now is the time, we're going to make
the final go / no go the end of this week.

-Sean

On 03/17/2017 06:36 AM, Sean Dague wrote:
> Background:
> 
> At the Atlanta PTG there was yet another attempt to get hierarchical
> quotas more generally addressed in OpenStack. A proposal was put forward
> that considered storing the limit information in Keystone
> (https://review.openstack.org/#/c/363765/). While there were some
> concerns on details that emerged out of that spec, the concept of the
> move to Keystone was actually really well received in that room by a
> wide range of parties, and it seemed to solve some interesting questions
> around project hierarchy validation. We were perilously close to having
> a path forward for a community request that's had a hard time making
> progress over the last couple of years.
> 
> Let's keep that flame alive!
> 
> 
> Here is the proposal for the Unified Limits in Keystone approach -
> https://review.openstack.org/#/c/440815/. It is intentionally a high
> level spec that largely lays out where the conceptual levels of control
> will be. It intentionally does not talk about specific quota models
> (there is a follow on that is doing some of that, under the assumption
> that the exact model(s) supported will take a while, and that the
> keystone interfaces are probably not going to substantially change based
> on model).
> 
> We're shooting for a 2 week comment cycle here to then decide if we can
> merge and move forward during this cycle or not. So please
> comment/question now (either in the spec or here on the mailing list).
> 
> It is especially important that we get feedback from teams that have
> limits implementations internally, as well as any that have started on
> hierarchical limits/quotas (which I believe Cinder is the only one).
> 
> Thanks for your time, and look forward to seeing comments on this.
> 
>   -Sean
> 


-- 
Sean Dague
http://dague.net

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

[openstack-dev] [all][api] POST /api-wg/news

[Ed Leafe]

Greetings OpenStack community,

Well, today's meeting was very brief. For the longest time, edleafe had the 
room to himself, and breezed through the prepared topics, until stevelle showed 
up. We had a good discussion about the stability guidelines and some of the 
issues in resolving the two different viewpoints. What came out of our 
discussion was the realization that these viewpoints weren't simply a matter of 
degree of strictness, but rather two different things: APIs that are stable to 
"robust" clients, and APIs that support cloud interoperability. So maybe the 
reason we have been having a hard time reaching agreement or compromise is that 
the two concepts are not congruent. edleafe agreed to try to write a blog post 
about this, so check out his blog [4] in the next day or so in case he actually 
does what he says he'll do.

# Newly Published Guidelines

Nothing new this week.

# API Guidelines Proposed for Freeze

Guidelines that are ready for wider review by the whole community.

None this week, although the pagination guideline below is close.

# Guidelines Currently Under Review [3]

* Define pagination guidelines
  https://review.openstack.org/#/c/446716/

* Create a new set of api stability guidelines
  https://review.openstack.org/#/c/421846/

* Microversions: add next_min_version field in version body
  https://review.openstack.org/#/c/446138/

* Mention max length limit information for tags
  https://review.openstack.org/#/c/447344/

* Add API capabilities discovery guideline
  https://review.openstack.org/#/c/386555/

* Recommend the correct HTTP method for tags
  https://review.openstack.org/451536

* Clarify the meaning of BODY (trivial fix)
  https://review.openstack.org/451568

* WIP: microversion architecture archival doc (very early; not yet ready for 
review)
  https://review.openstack.org/444892

# Highlighting your API impacting issues

If you seek further review and insight from the API WG, please address your 
concerns in an email to the OpenStack developer mailing list[1] with the tag 
"[api]" in the subject. In your email, you should include any relevant reviews, 
links, and comments to help guide the discussion of the specific challenge you 
are facing.

To learn more about the API WG mission and the work we do, see OpenStack API 
Working Group [2].

Thanks for reading and see you next week!

# References

[1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[2] http://specs.openstack.org/openstack/api-wg/
[3] https://review.openstack.org/#/q/status:open+project:openstack/api-wg,n,z
[4] https://blog.leafe.com

Meeting Agenda
https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
Past Meeting Records
http://eavesdrop.openstack.org/meetings/api_wg/
Open Bugs
https://bugs.launchpad.net/openstack-api-wg


-- Ed Leafe







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

Re: [openstack-dev] [nova][api] GET or HEAD for checking trait existence

[Ken'ichi Ohmichi]

Hi Jay,

Thanks for your reply.

2017-03-29 12:26 GMT-07:00 Jay Pipes :
> On 03/29/2017 02:04 PM, Ken'ichi Ohmichi wrote:
>>
>> Hi
>>
>> I have some questions about plancement API design from
>> https://review.openstack.org/#/c/376200
>> Current implementation of the above patch (PS26) adds GET method for
>> checking trait existence, and tags.rst of api-wg guideline[1] requires
>> GET for checking trait existence.
>> On the other hand, http.rst of api-wg guideline[2] requires HEAD instead.
>>
>> So there are two questions.
>> 1. Why the part of tags.rst is different from http.rst?
>> I checked the review history of
>> https://review.openstack.org/#/c/155620/ which have added the part,
>> but I could not find the reason.
>> 2. trait should follow tags.rst? or http.rst?
>
>
> This is from the http.rst guideline in the API-WG:
>
> "TODO: HEAD is weird in a bunch of our wsgi frameworks and you don't have
> access to it. Figure out if there is anything useful there."
>
> and frankly, I tend to agree with the above statement. I'd say use GET for
> exists checking.

Ed submitted a LP about this as
https://bugs.launchpad.net/openstack-api-wg/+bug/1677360
On the LP, Chris did put a nice comment like:

  "HEAD is a shortcut to use when you don't want to pay the price of GET"

We can use HEAD without receiving a response body to check a resource
existence if the response body could be huge on GET.
In this case, IIUC trait API doesn't return a response body when
getting the detail of resource, that would be the same as a resource
existence check.
Both GET and HEAD could be acceptable in this case.
I was confused when seeing the conflict between tags.rst and http.rst,
I will try it clear later on api-wg guideline.

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] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

[Davanum Srinivas]

Julien,

Right. the idea is to expand where we use etcd in openstack for other
things as well. example the os-lively effort from Jay, another one is
the oslo.config calling etcd3 fetch config entries.

Thanks,
Dims

On Thu, Mar 30, 2017 at 1:10 PM, Julien Danjou  wrote:
> On Thu, Mar 30 2017, Davanum Srinivas wrote:
>
>> Julien,
>>
>> Yes, Jay is adding this driver for "etcd3://" using the
>> https://pypi.python.org/pypi/etcd3 library
>> https://review.openstack.org/#/c/447223/
>>
>> and i'll followup with a "etcd3+http://; driver using the
>> https://pypi.python.org/pypi/etcd3gw library
>
> Ah ok, works for me. I'm not sure I see the value of using etc3gw which
> is IIUC just a wrapper around requests. For the etcd:// driver in tooz
> we just went ahead and used requests directly, so I imagine that's what
> I'd do for etcd3+http:// :-)
>
> --
> Julien Danjou
> -- Free Software hacker
> -- https://julien.danjou.info



-- 
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] [murano] MuranoPL types question

[Paul Bourke]

Hi Stan,

I had a quick(hopefully) question about MuranoPL that I hope you might 
be able to help with, Felipe had mentioned you are very knowledgeable in 
this area. If you don't have time please disregard!


I'm working on a patch for the Murano core library to make volume 
attachment info available, which is available at 
https://review.openstack.org/451909. It's mostly working, but I'm having 
some issues getting the types correct in MuranoPL to make this info 
consumable by end users.


The attachment info from a sample run in the stack $outputs looks like 
this (taken from the dashboard using $reporter)


u'vol-7c8ee61f-a444-46a1-ad70-fc6fce6a7b56-attachments': 
u"[{u'server_id': u'2891067b-e7bb-4ab9-a759-9e81096c0682', 
u'attachment_id': u'7456a4b0-3abd-48a0-a0cb-f3fa0f2706bb', 
u'attached_at': u'2017-03-30T16:51:57.00', u'host_name': None, 
u'volume_id': u'373e4a5a-46b6-4091-82d6-b3dba62d552b', u'device': 
u'/dev/vda', u'id': u'373e4a5a-46b6-4091-82d6-b3dba62d552b'}]"


Here both key and value appear to be a string (note, I can't confirm 
this as the typeinfo function doesn't appear to be available in 
Instance.yaml for some reason... perhaps I'm using it wrong)


My goal is to then set this into a property of CinderVolume.yaml, with a 
Contract of '[]'. However, when I access this from a sample app, I end 
up with a list of strings, shown by $reporter as:


(u"[{u'server_id': u'2891067b-e7bb-4ab9-a759-9e81096c0682', 
u'attachment_id': u'f5bd50ab-4040-4e2b-8b50-790781d9bc37', 
u'attached_at': u'2017-03-30T16:51:59.00', u'host_name': None, 
u'volume_id': u'ed7eb535-9e81-4c97-b063-86936d4ee306', u'device': 
u'/dev/vdb', u'id': u'ed7eb535-9e81-4c97-b063-86936d4ee306'}]",)


So my question is:

1) Why is the content of this 'get_attr' coming from heat being stored 
in the stack outputs as a string, and


2) Is there a way I can cast this to a list of dicts or similar 
structure so it can be iterated as expected?


Any tips much appreciated.

Thanks,
-Paul

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

Re: [openstack-dev] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

[Julien Danjou]

On Thu, Mar 30 2017, Davanum Srinivas wrote:

> Julien,
>
> Yes, Jay is adding this driver for "etcd3://" using the
> https://pypi.python.org/pypi/etcd3 library
> https://review.openstack.org/#/c/447223/
>
> and i'll followup with a "etcd3+http://; driver using the
> https://pypi.python.org/pypi/etcd3gw library

Ah ok, works for me. I'm not sure I see the value of using etc3gw which
is IIUC just a wrapper around requests. For the etcd:// driver in tooz
we just went ahead and used requests directly, so I imagine that's what
I'd do for etcd3+http:// :-)

-- 
Julien Danjou
-- Free Software hacker
-- https://julien.danjou.info


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

Re: [openstack-dev] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

[Davanum Srinivas]

Julien,

Yes, Jay is adding this driver for "etcd3://" using the
https://pypi.python.org/pypi/etcd3 library
https://review.openstack.org/#/c/447223/

and i'll followup with a "etcd3+http://; driver using the
https://pypi.python.org/pypi/etcd3gw library

Thanks,
Dims

On Thu, Mar 30, 2017 at 12:51 PM, Julien Danjou  wrote:
> On Thu, Mar 30 2017, Davanum Srinivas wrote:
>
>> Update.. So i just proposed a new library built off the [3] gist to be
>> added to g-r and u-c.
>>
>> https://review.openstack.org/#/c/450967/
>>
>> The alternative was to add support for custom backends in etcd3
>> library itself with grpc and v3alpha HTTP API as implementations.
>> Since tooz is already an abstraction and the work non-trivial we can
>> start this way. If etcd3 ends up with supporting both, then we can
>> just eliminate this library at that time.
>
> Is it simpler than just writing two tooz drivers, e.g. etcd3 and
> etcd3+http for example?
>
> --
> Julien Danjou
> /* Free Software hacker
>https://julien.danjou.info */



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

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

Re: [openstack-dev] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

[Julien Danjou]

On Thu, Mar 30 2017, Davanum Srinivas wrote:

> Update.. So i just proposed a new library built off the [3] gist to be
> added to g-r and u-c.
>
> https://review.openstack.org/#/c/450967/
>
> The alternative was to add support for custom backends in etcd3
> library itself with grpc and v3alpha HTTP API as implementations.
> Since tooz is already an abstraction and the work non-trivial we can
> start this way. If etcd3 ends up with supporting both, then we can
> just eliminate this library at that time.

Is it simpler than just writing two tooz drivers, e.g. etcd3 and
etcd3+http for example?

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


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

Re: [openstack-dev] Forum Details Summary- Hacking & Onboarding Rooms, Session Proposals & More!

[Kendall Nelson]

One more thing!

We have created an *#openstack-forum* irc channel for any questions you may
have! One disclaimer is that logging hasn't been set up yet, but it should
be in the next day or two.

*Days Till Boston: 39 Days*

-Kendall Nelson (diablo_rojo)

On Wed, Mar 29, 2017 at 8:22 AM Kendall Nelson 
wrote:

> Hello All!
>
> I know you have been getting bombarded with information about the upcoming
> Summit & Forum so I just wanted to take a moment to summarize everything
> into one place.
>
> Hacking Rooms: There are no specific plans for these rooms. They will be
> filled with roundtables for ad-hoc discussions that projects want to have.
> Here is the ethercalc signup for some of the available times for the
> hacking rooms[1]. The cells marked with ‘Unscheduled Drop In Time’ we are
> keeping open as a place for impromptu discussions.
>
> Onboarding Rooms: These two rooms will be set up classroom style,
> dedicated to the projects that have signed up to teach new contributors
> about the project, code, and give them an opportunity to meet established
> community members. The idea is that new contributors will come here to get
> started in the project after they have gone to OpenStack Upstream Institute
> and know the basics of contribution [2]. The schedule for these 90 min
> slots will be released soon.
>
> Forum Session Proposals: There is still time to submit topics to be
> discussed with all of our community at the Forum! [3] [4] You have until 
> Sunday
> April 2nd to submit them here [5].
>
> Community Contributor Awards: Another chance to give people the
> recognition they deserve that they aren’t getting. Please nominate those
> Stackers you depend on, look up to, or just deserve an extra pat on the
> back! [6] Submissions being accepted until Sunday April 23rd. These
> awards will be presented during the dual Forum Feedback/ Community
> Contributor Awards Session on Thursday during lunch at the Sheraton on the
> 2nd Floor in the Constitution Ballroom.
>
> As always, you can check the Boston website FAQ [7] for other information.
>
> Days till Boston: 40 Days
>
> All the Best,
>
> Kendall Nelson (diablo_rojo)
>
> [1] https://ethercalc.openstack.org/Boston_Forum_Hacking_Rooms
>
> [2] https://docs.openstack.org/upstream-training/
>
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2017-March/113115.html
>
> [4]
> http://lists.openstack.org/pipermail/openstack-dev/2017-March/114352.html
>
> [5] http://forumtopics.openstack.org/
>
> [6] https://openstackfoundation.formstack.com/forms/cca_nominations_boston
>
> [7] https://www.openstack.org/summit/boston-2017/faq/
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-l2gw] openstack vtep setup missing docs

[Armando M.]

On 30 March 2017 at 08:47, Saverio Proto  wrote:

> Hello,
>
> I am trying to use the neutron l2gw plugin, but I am not using a bare
> metal switch to bridge.
>
> I am using a server with Openvswitch.
>

I am not aware of any effort to implement L2GW purely in software, in fact
this was one key missing pieces that prevented the project to have CI
solely dealt with the upstream infra resources. Perhaps OVN may come to the
rescue here, I recall at some point the team was looking at the L2GW API.

Thanks,
Armando


>
> Following this documentation:
>
> http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/
>
> At one point there is this command:
>
> sudo vtep-bootstrap L5 10.0.0.5 192.168.91.21 --no_encryption
>
> This vtep-bootstrap is specific for Cumulux Linux
>
> Anybody has documentation with normal vtep-ctl commands ?
>
> So far on the Ubuntu server I did the following:
>
> apt-get install openvswitch-vtep
> ovsdb-tool create /etc/openvswitch/vtep.db
> /usr/share/openvswitch/vtep.ovsschema
>
> Anyone has more complete documentation ?
>
> I did not understand if the vtep-openvswitch controlled by the l2gw
> plugin will make vxlan tunnels to all the compute nodes, to bridge the
> tenant network with a physical l2 network ? Or all this traffic has to
> pass to the network node also because the vtep openvswitch is not able
> to talk to the compute nodes ?
>
> thank you
>
> Saverio
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
> __
> OpenStack Development Mailing 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][networking-l2gw] database tables for neutron l2gw plugin

[Armando M.]

On 30 March 2017 at 08:08, Saverio Proto  wrote:

> Hello,
>
> I am testing the neutron l2gw in our staging env.
>
> Because I cant redeploy everything, to retry the installation of the
> l2gw, to clean the database I drop the following tables from the neutron
> database:
>
> drop table physical_ports;
> drop table physical_locators;
> drop table physical_switches;
> drop table logical_switches;
> drop table ucast_macs_remotes;
> drop table ucast_macs_locals;
> drop table vlan_bindings;
> drop table pending_ucast_macs_remotes;
> drop table l2gatewayinterfaces;
> drop table l2gatewaydevices;
> drop table l2gatewayconnections;
> drop table l2gateways;
> drop table l2gw_alembic_version;
>
> I would strongly suggest to have a common prefix like l2gw_ for all the
> tables that belong to the same neutron plugin.
>
> How can I figure out if I missed a table without reading all the code ?
>

There's no written rule to prefix tables with formal labels. IMO it would
largely fail as a rule in practice even if we wrote one down. Have you
considered taking a backup of your DB prior to the migration so that you
can restore from it?

Thanks,
Armando


> Thank you
>
> Saverio
>
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] os-cloud-config retirement

[Jiří Stránský]

On 30.3.2017 18:02, Bogdan Dobrelya wrote:

On 30.03.2017 15:40, Jiří Stránský wrote:


What might be interesting is solving the keystone init within containers
along with our container entrypoint situation. We've talked earlier that
we may have to build our custom entrypoints into the images as we
sometimes need to do things that the current entrypoints don't seem fit
for, or don't give us enough control over what happens. This single
optimized python script for endpoint config you mentioned could be one
of such in-image entrypoint scripts. We could build multiple different


I'm concerned of having entry points in-image. Could it be mounted as a
hostpath instead, then executed? Custom entry-points could replace
existing ones this way. This would allow keep kolla or other images
clean from side changes.


That was actually my initial thought as well, but it means more 
entanglement between the containers and the bare-metal hosts, and 
creates some new issues.


E.g. it makes container image versioning harder. We'd need to implement 
additional logic to make sure we use the correct entrypoint version for 
a particular container image version (think rolling back to an older 
image but still using the newest entrypoint, perhaps those two not being 
fully compatible, and having the container crash because of this). This 
alone is quite disadvantageous IMO.


Jirka




scripts like this into a single image and select the right one when
starting the container (defaulting to a script that handles the usual


We could use a clean container and mount in that we need. Those entry
points looks similar to heat agent hooks, right? I think they should be
packaged as a separate artifacts.


"worker" case, in this case Keystone API).

This gets somewhat similar to the os-cloud-config usecase, but even if
we wanted a separate repo, or even a RPM for these, i suppose it would
be cleaner to just start from scratch rather than repurpose
os-cloud-config.

Jirka






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

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

[Jimmy McArthur]

Afek, Ifat (Nokia - IL/Kfar Sava) 
March 30, 2017 at 11:01 AM


·Under “API Versions” there should also be Newton

This is something we are currently attempting to sort out. Projects 
don't have a consistent method for listing the APIs. See previous thread.


·Why aren’t the adoption and maturity specified?

In order for us to get more info about your project, we need to have the 
proper tags. Compare 
http://git.openstack.org/cgit/openstack/releases/plain/deliverables/ocata/neutron.yaml 
vs 
http://git.openstack.org/cgit/openstack/releases/plain/deliverables/ocata/vitrage.yaml   
As well as here: 
https://github.com/openstack/ops-tags-team/tree/master/ocata


Thanks,
Jimmy


Thanks,

Ifat.

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

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


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

Hi everyone,

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


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

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


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


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


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

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


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


Thanks for your feedback and help.

Best,
Lauren

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

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

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


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

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

[Jimmy McArthur]

This (http://paste.openstack.org/show/604775/) is absolutely perfect. I 
feel like the format could work for microversions as well. Anyone from 
Neutron or another microversion project that could weigh in?


Another great thing about this, is we can use this API version history 
to determine project age, which again is a manual thing we're doing 
right now.


Thanks!! Would love to hear others opinions on this?

Brian Rosmaita 
March 29, 2017 at 9:23 PM
On 3/29/17 12:55 AM, Jimmy McArthur wrote:
[snip]

See what you think of these. They add an "apis" section to the glance
section of projects.yaml in the governance repo.

http://paste.openstack.org/show/604775/ has a complete history, where
for each release, the complete set of versions of the API that are
available in that release (and their statuses) are listed.

http://paste.openstack.org/show/604776/ has an abbreviated history,
where only the changes in available APIs are listed from version to
version, and if there's no change, the release isn't listed at all.

I don't know if this format would work for microversions, though. (And
I don't know if it's a good idea in the first place.)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur 
March 28, 2017 at 11:55 PM

Brian,

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

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

What we really need is the following:

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

thanks,
brian

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

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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Brian Rosmaita 
March 28, 2017 at 10:25 PM
On 3/27/17 5:01 PM, Lauren Sell wrote:

Hi Matt,

Thanks for the feedback.


On Mar 24, 2017, at 3:50 PM, Matt Riedemann  wrote:

[snip]

2. The "API Version History" section in the bottom right says:

"Version v2.1 (Ocata) - LATEST RELEASE"

And links to https://releases.openstack.org/. 
The latest compute microversion in Ocata was actually 2.42:

https://docs.openstack.org/developer/nova/api_microversion_history.html

I'm wondering how we can better sort that out. I guess "API Version History" in 
the navigator is meant more for major versions and wasn't intended to handle 
microversions? That seems like something that should be dealt with at some point as more 
and more projects are moving to using micro versions.

Agreed, we could use some guidance here. From what we can tell, each team logs 
these a little bit differently, so there's no easy way for us to pull them. 
Could we output the correct link as a tag for each project, or does anyone have 
a recommendation?


I don't have a helpful recommendation here, but the version history for
Glance is incorrect as well.  We maintain a version history in the
glance api-ref [0], but that's probably not much help (and, as you point
out, is idiosyncratic to Glance anyway).  At this point, 

Re: [openstack-dev] [tripleo] os-cloud-config retirement

[Bogdan Dobrelya]

On 30.03.2017 15:40, Jiří Stránský wrote:
> 
> What might be interesting is solving the keystone init within containers
> along with our container entrypoint situation. We've talked earlier that
> we may have to build our custom entrypoints into the images as we
> sometimes need to do things that the current entrypoints don't seem fit
> for, or don't give us enough control over what happens. This single
> optimized python script for endpoint config you mentioned could be one
> of such in-image entrypoint scripts. We could build multiple different

I'm concerned of having entry points in-image. Could it be mounted as a
hostpath instead, then executed? Custom entry-points could replace
existing ones this way. This would allow keep kolla or other images
clean from side changes.

> scripts like this into a single image and select the right one when
> starting the container (defaulting to a script that handles the usual

We could use a clean container and mount in that we need. Those entry
points looks similar to heat agent hooks, right? I think they should be
packaged as a separate artifacts.

> "worker" case, in this case Keystone API).
> 
> This gets somewhat similar to the os-cloud-config usecase, but even if
> we wanted a separate repo, or even a RPM for these, i suppose it would
> be cleaner to just start from scratch rather than repurpose
> os-cloud-config.
> 
> Jirka


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

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

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

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

Thanks Lauren,

A few issues regarding the Vitrage page:


· Vitrage is currently listed under “Management Tools” category. As a 
Root Cause Analysis service, it doesn’t manage anything, just provides insights 
to the user (or to other projects). Can you please move it under ‘Data and 
Analytics’ category?

· Please write that Vitrage is a “Root Cause Analysis Service” without 
“RCA” and parenthesis (which are misplaced at the moment).

· Under “API Versions” there should also be Newton

· Why aren’t the adoption and maturity specified?

Thanks,
Ifat.


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

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

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

Hi everyone,

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

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

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

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

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

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

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

Thanks for your feedback and help.

Best,
Lauren

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

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

Re: [openstack-dev] [tripleo] os-cloud-config retirement

[Alex Schultz]

On Thu, Mar 30, 2017 at 6:58 AM, Dan Prince  wrote:
> There is one case that I was thinking about reusing this piece of code
> within a container to help initialize keystone endpoints. It would
> require some changes and updates (to match how puppet-* configures
> endpoints).
>
> For TripleO containers we use various puppet modules (along with hiera)
> to drive the creation of endpoints. This functionally works fine, but
> is quite slow to execute (puppet is slow here) and takes several
> minutes to complete. I'm wondering if a single optimized python script
> might serve us better here. It could be driven via YAML (perhaps
> similar to our Hiera), idempotent, and likely much faster than having
> the code driven by puppet. This doesn't have to live in os-cloud-
> config, but initially I thought that might be a reasonable place for
> it. It is worth pointing out that this would be something that would
> need to be driven by our t-h-t workflow and not a post-installation
> task. So perhaps that makes it not a good fit for os-cloud-config. But
> it is similar to the keystone initialization already there so I thought
> I'd mention it.
>

Do we know why puppet is slow here? Since puppet is just executing the
openstack client, that usually is the culprit on these things.  While
it might be faster to write a python script to handle this, the
question becomes should we be using a different thing to accomplish
the same task as we're doing elsewhere?

Thanks,
-Alex

> Dan
>
> On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote:
>> Hi,
>>
>> os-cloud-config was deprecated in the Ocata release and is going to
>> be
>> removed in Pike.
>>
>> TripleO project doesn't need it anymore and after some investigation
>> in codesearch.openstack.org, nobody is using it in OpenStack.
>> I'm working on the removal this cycle, please let us know any
>> concern.
>>
>> 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

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

[openstack-dev] [neutron][networking-l2gw] openstack vtep setup missing docs

[Saverio Proto]

Hello,

I am trying to use the neutron l2gw plugin, but I am not using a bare
metal switch to bridge.

I am using a server with Openvswitch.

Following this documentation:

http://networkop.co.uk/blog/2016/05/21/neutron-l2gw/

At one point there is this command:

sudo vtep-bootstrap L5 10.0.0.5 192.168.91.21 --no_encryption

This vtep-bootstrap is specific for Cumulux Linux

Anybody has documentation with normal vtep-ctl commands ?

So far on the Ubuntu server I did the following:

apt-get install openvswitch-vtep
ovsdb-tool create /etc/openvswitch/vtep.db
/usr/share/openvswitch/vtep.ovsschema

Anyone has more complete documentation ?

I did not understand if the vtep-openvswitch controlled by the l2gw
plugin will make vxlan tunnels to all the compute nodes, to bridge the
tenant network with a physical l2 network ? Or all this traffic has to
pass to the network node also because the vtep openvswitch is not able
to talk to the compute nodes ?

thank you

Saverio


-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
OpenStack Development Mailing 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] os-cloud-config retirement

[Juan Antonio Osorio]

Why not drive the post-config with something like shade over ansible?
Similar to what the kolla-ansible community is doing.

On 30 Mar 2017 16:42, "Jiří Stránský"  wrote:

> On 30.3.2017 14:58, Dan Prince wrote:
>
>> There is one case that I was thinking about reusing this piece of code
>> within a container to help initialize keystone endpoints. It would
>> require some changes and updates (to match how puppet-* configures
>> endpoints).
>>
>> For TripleO containers we use various puppet modules (along with hiera)
>> to drive the creation of endpoints. This functionally works fine, but
>> is quite slow to execute (puppet is slow here) and takes several
>> minutes to complete. I'm wondering if a single optimized python script
>> might serve us better here. It could be driven via YAML (perhaps
>> similar to our Hiera), idempotent, and likely much faster than having
>> the code driven by puppet. This doesn't have to live in os-cloud-
>> config, but initially I thought that might be a reasonable place for
>> it. It is worth pointing out that this would be something that would
>> need to be driven by our t-h-t workflow and not a post-installation
>> task. So perhaps that makes it not a good fit for os-cloud-config. But
>> it is similar to the keystone initialization already there so I thought
>> I'd mention it.
>>
>
> I agree we could have an optimized python script instead of puppet to do
> the init. However, os-cloud-config also doesn't strike me as the ideal
> place.
>
> What might be interesting is solving the keystone init within containers
> along with our container entrypoint situation. We've talked earlier that we
> may have to build our custom entrypoints into the images as we sometimes
> need to do things that the current entrypoints don't seem fit for, or don't
> give us enough control over what happens. This single optimized python
> script for endpoint config you mentioned could be one of such in-image
> entrypoint scripts. We could build multiple different scripts like this
> into a single image and select the right one when starting the container
> (defaulting to a script that handles the usual "worker" case, in this case
> Keystone API).
>
> This gets somewhat similar to the os-cloud-config usecase, but even if we
> wanted a separate repo, or even a RPM for these, i suppose it would be
> cleaner to just start from scratch rather than repurpose os-cloud-config.
>
> Jirka
>
>
>> Dan
>>
>> On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote:
>>
>>> Hi,
>>>
>>> os-cloud-config was deprecated in the Ocata release and is going to
>>> be
>>> removed in Pike.
>>>
>>> TripleO project doesn't need it anymore and after some investigation
>>> in codesearch.openstack.org, nobody is using it in OpenStack.
>>> I'm working on the removal this cycle, please let us know any
>>> concern.
>>>
>>> Thanks,
>>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

[Davanum Srinivas]

Update.. So i just proposed a new library built off the [3] gist to be
added to g-r and u-c.

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

The alternative was to add support for custom backends in etcd3
library itself with grpc and v3alpha HTTP API as implementations.
Since tooz is already an abstraction and the work non-trivial we can
start this way. If etcd3 ends up with supporting both, then we can
just eliminate this library at that time.

Thanks,
Dims


On Sun, Mar 19, 2017 at 4:34 PM, Davanum Srinivas  wrote:
> Quick update: We have 3 options to talk to etcd:
>
> 1) existing V2 HTTP API - still not deprecated in etcd 3.1.x, so
> existing code in tooz still works.
> 2) grpc based V3 API - We can use the etcd3 package, discussion in
> review[1], problem is that this will not work currently with eventlet
> based services
> 3) v3alpha HTTP API - See details in [2], quick prototype requests
> based code [3]
>
> Thanks,
> Dims
>
> [1] https://review.openstack.org/#/c/446983/
> [2] 
> https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md
> [3] https://gist.github.com/dims/19ceaf9472ef54aa3011d7a11e809371
>
> On Sun, Mar 19, 2017 at 9:32 AM, Jay Pipes  wrote:
>> On 03/18/2017 07:48 PM, Mike Perez wrote:
>>>
>>> On 12:35 Mar 14, Jay Pipes wrote:

 On 03/14/2017 08:57 AM, Julien Danjou wrote:
>
> On Tue, Mar 14 2017, Davanum Srinivas wrote:
>
>> Let's do it!! (etcd v2-v3 in tooz)
>
>
> Hehe. I'll move that higher in my priority list, I swear. But anyone is
> free to beat me to it in the meantime. ;)


 A weekend experiment:

 https://github.com/jaypipes/os-lively

 Not tooz, because I'm not interested in a DLM nor leader election library
 (that's what the underlying etcd3 cluster handles for me), only a fast
 service liveness/healthcheck system, but it shows usage of etcd3 and
 Google
 Protocol Buffers implementing a simple API for liveness checking and host
 maintenance reporting.

 My plan is to push some proof-of-concept patches that replace Nova's
 servicegroup API with os-lively and eliminate Nova's use of an RDBMS for
 service liveness checking, which should dramatically reduce the amount of
 both DB traffic as well as conductor/MQ service update traffic.
>>>
>>>
>>> As Monty has mentioned, I'd love for us to decide on one thing. As being
>>> a moderator of that discussion I was trying not to be one-sided.
>>>
>>> Whether or not a decision was made 1.5 years ago, the community that was
>>> present at that time of the decision at the summit decided on an
>>> abstraction
>>> layer to have options. Forcing an option on the community without
>>> gathering
>>> feedback of what the community currently looks like is not a good idea.
>>>
>>> I'd recommend if you want to make this base service, start the discussions
>>> in
>>> somewhere other than the dev list, like the Forum.
>>
>>
>> Mike, it was an experiment :)
>>
>> But, yes, happy to participate in a discussion at the forum.
>>
>>
>> Best,
>> -jay
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> 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

Re: [openstack-dev] [requirements] pycrypto is dead, long live pycryptodome... or cryptography...

[Sean McGinnis]

On Wed, Mar 29, 2017 at 10:56:41AM -0400, Brian Rosmaita wrote:
> On 3/8/17 2:03 PM, Matthew Thode wrote:
> > So, pycrypto upstream is dead and has been for a while, we should look
> > at moving off of it for both bugfix and security reasons.
> > 
> > Currently it's used by the following.
> > 
> > barbican, cinder, trove, glance, heat, keystoneauth, keystonemiddleware,
> > kolla, openstack-ansible, and a couple of other smaller places.
> 

The current thought is to go with the crytography package for Cinder. No
patch is up yet, but this was discussed a bit yesterday.

Given the challenges with pycrypto and pycryptodome coexisting, the
general thought at this time is that even though transitioning to
cryptography will be a little more work, it will be the easier path
forward.

Sean

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

[openstack-dev] [neutron][networking-l2gw] database tables for neutron l2gw plugin

[Saverio Proto]

Hello,

I am testing the neutron l2gw in our staging env.

Because I cant redeploy everything, to retry the installation of the
l2gw, to clean the database I drop the following tables from the neutron
database:

drop table physical_ports;
drop table physical_locators;
drop table physical_switches;
drop table logical_switches;
drop table ucast_macs_remotes;
drop table ucast_macs_locals;
drop table vlan_bindings;
drop table pending_ucast_macs_remotes;
drop table l2gatewayinterfaces;
drop table l2gatewaydevices;
drop table l2gatewayconnections;
drop table l2gateways;
drop table l2gw_alembic_version;

I would strongly suggest to have a common prefix like l2gw_ for all the
tables that belong to the same neutron plugin.

How can I figure out if I missed a table without reading all the code ?

Thank you

Saverio



-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
OpenStack Development Mailing 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] container jobs are unstable

[Paul Belanger]

On Thu, Mar 30, 2017 at 03:08:57PM +0100, Steven Hardy wrote:
> On Wed, Mar 29, 2017 at 10:07:24PM -0400, Paul Belanger wrote:
> > On Thu, Mar 30, 2017 at 09:56:59AM +1300, Steve Baker wrote:
> > > On Thu, Mar 30, 2017 at 9:39 AM, Emilien Macchi  
> > > wrote:
> > > 
> > > > On Mon, Mar 27, 2017 at 8:00 AM, Flavio Percoco  
> > > > wrote:
> > > > > On 23/03/17 16:24 +0100, Martin André wrote:
> > > > >>
> > > > >> On Wed, Mar 22, 2017 at 2:20 PM, Dan Prince  
> > > > >> wrote:
> > > > >>>
> > > > >>> On Wed, 2017-03-22 at 13:35 +0100, Flavio Percoco wrote:
> > > > 
> > > >  On 22/03/17 13:32 +0100, Flavio Percoco wrote:
> > > >  > On 21/03/17 23:15 -0400, Emilien Macchi wrote:
> > > >  > > Hey,
> > > >  > >
> > > >  > > I've noticed that container jobs look pretty unstable lately; 
> > > >  > > to
> > > >  > > me,
> > > >  > > it sounds like a timeout:
> > > >  > > http://logs.openstack.org/19/447319/2/check-tripleo/gate-tripleo-
> > > >  > > ci-centos-7-ovb-containers-oooq-nv/bca496a/console.html#_2017-03-
> > > >  > > 22_00_08_55_358973
> > > >  >
> > > >  > There are different hypothesis on what is going on here. Some
> > > >  > patches have
> > > >  > landed to improve the write performance on containers by using
> > > >  > hostpath mounts
> > > >  > but we think the real slowness is coming from the images 
> > > >  > download.
> > > >  >
> > > >  > This said, this is still under investigation and the containers
> > > >  > squad will
> > > >  > report back as soon as there are new findings.
> > > > 
> > > >  Also, to be more precise, Martin André is looking into this. He 
> > > >  also
> > > >  fixed the
> > > >  gate in the last 2 weeks.
> > > > >>>
> > > > >>>
> > > > >>> I spoke w/ Martin on IRC. He seems to think this is the cause of 
> > > > >>> some
> > > > >>> of the failures:
> > > > >>>
> > > > >>> http://logs.openstack.org/32/446432/1/check-tripleo/gate-
> > > > tripleo-ci-cen
> > > > >>> tos-7-ovb-containers-oooq-nv/543bc80/logs/oooq/overcloud-controller-
> > > > >>> 0/var/log/extra/docker/containers/heat_engine/log/heat/heat-
> > > > >>> engine.log.txt.gz#_2017-03-21_20_26_29_697
> > > > >>>
> > > > >>>
> > > > >>> Looks like Heat isn't able to create Nova instances in the overcloud
> > > > >>> due to "Host 'overcloud-novacompute-0' is not mapped to any cell'. 
> > > > >>> This
> > > > >>> means our cells initialization code for containers may not be quite
> > > > >>> right... or there is a race somewhere.
> > > > >>
> > > > >>
> > > > >> Here are some findings. I've looked at time measures from CI for
> > > > >> https://review.openstack.org/#/c/448533/ which provided the most
> > > > >> recent results:
> > > > >>
> > > > >> * gate-tripleo-ci-centos-7-ovb-ha [1]
> > > > >>undercloud install: 23
> > > > >>overcloud deploy: 72
> > > > >>total time: 125
> > > > >> * gate-tripleo-ci-centos-7-ovb-nonha [2]
> > > > >>undercloud install: 25
> > > > >>overcloud deploy: 48
> > > > >>total time: 122
> > > > >> * gate-tripleo-ci-centos-7-ovb-updates [3]
> > > > >>undercloud install: 24
> > > > >>overcloud deploy: 57
> > > > >>total time: 152
> > > > >> * gate-tripleo-ci-centos-7-ovb-containers-oooq-nv [4]
> > > > >>undercloud install: 28
> > > > >>overcloud deploy: 48
> > > > >>total time: 165 (timeout)
> > > > >>
> > > > >> Looking at the undercloud & overcloud install times, the most task
> > > > >> consuming tasks, the containers job isn't doing that bad compared to
> > > > >> other OVB jobs. But looking closer I could see that:
> > > > >> - the containers job pulls docker images from dockerhub, this process
> > > > >> takes roughly 18 min.
> > > > >
> > > > >
> > > > > I think we can optimize this a bit by having the script that populates
> > > > the
> > > > > local
> > > > > registry in the overcloud job to run in parallel. The docker daemon 
> > > > > can
> > > > do
> > > > > multiple pulls w/o problems.
> > > > >
> > > > >> - the overcloud validate task takes 10 min more than it should 
> > > > >> because
> > > > >> of the bug Dan mentioned (a fix is in the queue at
> > > > >> https://review.openstack.org/#/c/448575/)
> > > > >
> > > > >
> > > > > +A
> > > > >
> > > > >> - the postci takes a long time with quickstart, 13 min (4 min alone
> > > > >> spent on docker log collection) whereas it takes only 3 min when 
> > > > >> using
> > > > >> tripleo.sh
> > > > >
> > > > >
> > > > > mmh, does this have anything to do with ansible being in between? Or 
> > > > > is
> > > > that
> > > > > time specifically for the part that gets the logs?
> > > > >
> > > > >>
> > > > >> Adding all these numbers, we're at about 40 min of additional time 
> > > > >> for
> > > > >> oooq containers job which is enough to cross the CI job limit.
> > > > >>
> > > > >> There is certainly a lot of room for 

Re: [openstack-dev] [ironic] New contributor

[Jay Faulkner]

Welcome to the project! We do have a large number of new / junior contributors, 
so simple bugs don’t stay outstanding very long. You can search ironic and 
ironic-python-agent in launchpad for bugs tagged “low-hanging-fruit”. If that 
comes up short, or you want to do something more advanced, I suggest reviewing 
the weekly ironic review priorities on our whiteboard at 
http://bit.ly/ironic-whiteboard. Additionally, I suggest you join 
#openstack-ironic on free node and say hello. 

Welcome and good luck,
Jay Faulkner
OSIC

> On Mar 29, 2017, at 8:13 PM, Julian Edwards  wrote:
> 
> Hi all
> 
> I'm looking to start contributing to Ironic, and in fact I did a
> couple of small patches already which are still waiting to be
> landed/reviewed. [1]
> 
> I'm finding it a little hard to find some more reasonable bugs to get
> started with fixing, so if any of you guys can point me at a few I
> would appreciate it, or indeed if someone is willing to do more
> involved mentoring.  (I am in the +10 time zone so this may be
> awkward, sadly)
> 
> Cheers
> J
> 
> PS  Some of you may remember me as the original Ubuntu MAAS lead, so I
> am pretty familiar with bare metal stuff generally.
> 
> [1] https://review.openstack.org/#/c/449454/ and
> https://review.openstack.org/#/c/450492/
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] All patches failing CI for validations stable/ocata branch - help needed

[Florian Fuchs]

On Wed, Mar 29, 2017 at 11:46 PM, Jeremy Stanley  wrote:
> On 2017-03-29 18:32:09 +0200 (+0200), Florian Fuchs wrote:
> [...]
>> The error in the logs however is always the same [2] and appears
>> to be related to an issue with setuptools 34[3], which apparently
>> hit other openstack projects as well. I tried to create a patch
>> with a fix (excluding setuptools 34),
>
> The way we "fixed" this for other projects was to update
> requirements caps and/or constraints entries for all of setuptools'
> direct and transitive install_requires (there are only three, if
> memory serves) on stable branches. This is usually not the sort of
> thing we'd want to have happening in stable branches, but keeping
> them installable with latest setuptools releases is important. Also
> pinning setuptools can be hard depending on the situation, since
> you're often using setuptools in the process of trying to control
> your version of setuptools... bit of a catch-22.

Thanks for your reply.

FYI: To solve this, I proposed a backport for a requirements patch
that already addresses the problem:
https://review.openstack.org/#/c/451815/

>> but couldn't test it because gerrit set the target patch to master
>> instead of stable/ocata (I guess it only allows me to propose
>> backport patches to stable branches, not creating a patch for a
>> stable branch only).
> [...]
>
> If the .gitreview file in your stable/ocata branch doesn't have
> defaultbranch=stable/ocata, then you have to pass the branch name as
> a parameter when invoking git review, i.e. `git review stable/ocata`
> (or just fix the .gitreview file so you don't have to think about
> it). See https://docs.openstack.org/infra/git-review/usage.html for
> details.

We have separate a patch adding the default branch to .gitignore, but,
obviously, it fails due to the problem above...
But thanks for the hint! I wasn't aware the target could be set as a
git review param as well.

Florian


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

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

Re: [openstack-dev] [tripleo] container jobs are unstable

[Dan Prince]

On Wed, 2017-03-29 at 22:07 -0400, Paul Belanger wrote:
> On Thu, Mar 30, 2017 at 09:56:59AM +1300, Steve Baker wrote:
> > On Thu, Mar 30, 2017 at 9:39 AM, Emilien Macchi  > > wrote:
> > 
> > > On Mon, Mar 27, 2017 at 8:00 AM, Flavio Percoco  > > m> wrote:
> > > > On 23/03/17 16:24 +0100, Martin André wrote:
> > > > > 
> > > > > On Wed, Mar 22, 2017 at 2:20 PM, Dan Prince  > > > > om> wrote:
> > > > > > 
> > > > > > On Wed, 2017-03-22 at 13:35 +0100, Flavio Percoco wrote:
> > > > > > > 
> > > > > > > On 22/03/17 13:32 +0100, Flavio Percoco wrote:
> > > > > > > > On 21/03/17 23:15 -0400, Emilien Macchi wrote:
> > > > > > > > > Hey,
> > > > > > > > > 
> > > > > > > > > I've noticed that container jobs look pretty unstable
> > > > > > > > > lately; to
> > > > > > > > > me,
> > > > > > > > > it sounds like a timeout:
> > > > > > > > > http://logs.openstack.org/19/447319/2/check-tripleo/g
> > > > > > > > > ate-tripleo-
> > > > > > > > > ci-centos-7-ovb-containers-oooq-
> > > > > > > > > nv/bca496a/console.html#_2017-03-
> > > > > > > > > 22_00_08_55_358973
> > > > > > > > 
> > > > > > > > There are different hypothesis on what is going on
> > > > > > > > here. Some
> > > > > > > > patches have
> > > > > > > > landed to improve the write performance on containers
> > > > > > > > by using
> > > > > > > > hostpath mounts
> > > > > > > > but we think the real slowness is coming from the
> > > > > > > > images download.
> > > > > > > > 
> > > > > > > > This said, this is still under investigation and the
> > > > > > > > containers
> > > > > > > > squad will
> > > > > > > > report back as soon as there are new findings.
> > > > > > > 
> > > > > > > Also, to be more precise, Martin André is looking into
> > > > > > > this. He also
> > > > > > > fixed the
> > > > > > > gate in the last 2 weeks.
> > > > > > 
> > > > > > 
> > > > > > I spoke w/ Martin on IRC. He seems to think this is the
> > > > > > cause of some
> > > > > > of the failures:
> > > > > > 
> > > > > > http://logs.openstack.org/32/446432/1/check-tripleo/gate-
> > > 
> > > tripleo-ci-cen
> > > > > > tos-7-ovb-containers-oooq-nv/543bc80/logs/oooq/overcloud-
> > > > > > controller-
> > > > > > 0/var/log/extra/docker/containers/heat_engine/log/heat/heat
> > > > > > -
> > > > > > engine.log.txt.gz#_2017-03-21_20_26_29_697
> > > > > > 
> > > > > > 
> > > > > > Looks like Heat isn't able to create Nova instances in the
> > > > > > overcloud
> > > > > > due to "Host 'overcloud-novacompute-0' is not mapped to any
> > > > > > cell'. This
> > > > > > means our cells initialization code for containers may not
> > > > > > be quite
> > > > > > right... or there is a race somewhere.
> > > > > 
> > > > > 
> > > > > Here are some findings. I've looked at time measures from CI
> > > > > for
> > > > > https://review.openstack.org/#/c/448533/ which provided the
> > > > > most
> > > > > recent results:
> > > > > 
> > > > > * gate-tripleo-ci-centos-7-ovb-ha [1]
> > > > >    undercloud install: 23
> > > > >    overcloud deploy: 72
> > > > >    total time: 125
> > > > > * gate-tripleo-ci-centos-7-ovb-nonha [2]
> > > > >    undercloud install: 25
> > > > >    overcloud deploy: 48
> > > > >    total time: 122
> > > > > * gate-tripleo-ci-centos-7-ovb-updates [3]
> > > > >    undercloud install: 24
> > > > >    overcloud deploy: 57
> > > > >    total time: 152
> > > > > * gate-tripleo-ci-centos-7-ovb-containers-oooq-nv [4]
> > > > >    undercloud install: 28
> > > > >    overcloud deploy: 48
> > > > >    total time: 165 (timeout)
> > > > > 
> > > > > Looking at the undercloud & overcloud install times, the most
> > > > > task
> > > > > consuming tasks, the containers job isn't doing that bad
> > > > > compared to
> > > > > other OVB jobs. But looking closer I could see that:
> > > > > - the containers job pulls docker images from dockerhub, this
> > > > > process
> > > > > takes roughly 18 min.
> > > > 
> > > > 
> > > > I think we can optimize this a bit by having the script that
> > > > populates
> > > 
> > > the
> > > > local
> > > > registry in the overcloud job to run in parallel. The docker
> > > > daemon can
> > > 
> > > do
> > > > multiple pulls w/o problems.
> > > > 
> > > > > - the overcloud validate task takes 10 min more than it
> > > > > should because
> > > > > of the bug Dan mentioned (a fix is in the queue at
> > > > > https://review.openstack.org/#/c/448575/)
> > > > 
> > > > 
> > > > +A
> > > > 
> > > > > - the postci takes a long time with quickstart, 13 min (4 min
> > > > > alone
> > > > > spent on docker log collection) whereas it takes only 3 min
> > > > > when using
> > > > > tripleo.sh
> > > > 
> > > > 
> > > > mmh, does this have anything to do with ansible being in
> > > > between? Or is
> > > 
> > > that
> > > > time specifically for the part that gets the logs?
> > > > 
> > > > > 
> > > > > Adding all these numbers, we're at about 40 min of additional
> > > > > time for
> > > > > oooq containers 

Re: [openstack-dev] [tripleo] container jobs are unstable

[Steven Hardy]

On Wed, Mar 29, 2017 at 10:07:24PM -0400, Paul Belanger wrote:
> On Thu, Mar 30, 2017 at 09:56:59AM +1300, Steve Baker wrote:
> > On Thu, Mar 30, 2017 at 9:39 AM, Emilien Macchi  wrote:
> > 
> > > On Mon, Mar 27, 2017 at 8:00 AM, Flavio Percoco  wrote:
> > > > On 23/03/17 16:24 +0100, Martin André wrote:
> > > >>
> > > >> On Wed, Mar 22, 2017 at 2:20 PM, Dan Prince  wrote:
> > > >>>
> > > >>> On Wed, 2017-03-22 at 13:35 +0100, Flavio Percoco wrote:
> > > 
> > >  On 22/03/17 13:32 +0100, Flavio Percoco wrote:
> > >  > On 21/03/17 23:15 -0400, Emilien Macchi wrote:
> > >  > > Hey,
> > >  > >
> > >  > > I've noticed that container jobs look pretty unstable lately; to
> > >  > > me,
> > >  > > it sounds like a timeout:
> > >  > > http://logs.openstack.org/19/447319/2/check-tripleo/gate-tripleo-
> > >  > > ci-centos-7-ovb-containers-oooq-nv/bca496a/console.html#_2017-03-
> > >  > > 22_00_08_55_358973
> > >  >
> > >  > There are different hypothesis on what is going on here. Some
> > >  > patches have
> > >  > landed to improve the write performance on containers by using
> > >  > hostpath mounts
> > >  > but we think the real slowness is coming from the images download.
> > >  >
> > >  > This said, this is still under investigation and the containers
> > >  > squad will
> > >  > report back as soon as there are new findings.
> > > 
> > >  Also, to be more precise, Martin André is looking into this. He also
> > >  fixed the
> > >  gate in the last 2 weeks.
> > > >>>
> > > >>>
> > > >>> I spoke w/ Martin on IRC. He seems to think this is the cause of some
> > > >>> of the failures:
> > > >>>
> > > >>> http://logs.openstack.org/32/446432/1/check-tripleo/gate-
> > > tripleo-ci-cen
> > > >>> tos-7-ovb-containers-oooq-nv/543bc80/logs/oooq/overcloud-controller-
> > > >>> 0/var/log/extra/docker/containers/heat_engine/log/heat/heat-
> > > >>> engine.log.txt.gz#_2017-03-21_20_26_29_697
> > > >>>
> > > >>>
> > > >>> Looks like Heat isn't able to create Nova instances in the overcloud
> > > >>> due to "Host 'overcloud-novacompute-0' is not mapped to any cell'. 
> > > >>> This
> > > >>> means our cells initialization code for containers may not be quite
> > > >>> right... or there is a race somewhere.
> > > >>
> > > >>
> > > >> Here are some findings. I've looked at time measures from CI for
> > > >> https://review.openstack.org/#/c/448533/ which provided the most
> > > >> recent results:
> > > >>
> > > >> * gate-tripleo-ci-centos-7-ovb-ha [1]
> > > >>undercloud install: 23
> > > >>overcloud deploy: 72
> > > >>total time: 125
> > > >> * gate-tripleo-ci-centos-7-ovb-nonha [2]
> > > >>undercloud install: 25
> > > >>overcloud deploy: 48
> > > >>total time: 122
> > > >> * gate-tripleo-ci-centos-7-ovb-updates [3]
> > > >>undercloud install: 24
> > > >>overcloud deploy: 57
> > > >>total time: 152
> > > >> * gate-tripleo-ci-centos-7-ovb-containers-oooq-nv [4]
> > > >>undercloud install: 28
> > > >>overcloud deploy: 48
> > > >>total time: 165 (timeout)
> > > >>
> > > >> Looking at the undercloud & overcloud install times, the most task
> > > >> consuming tasks, the containers job isn't doing that bad compared to
> > > >> other OVB jobs. But looking closer I could see that:
> > > >> - the containers job pulls docker images from dockerhub, this process
> > > >> takes roughly 18 min.
> > > >
> > > >
> > > > I think we can optimize this a bit by having the script that populates
> > > the
> > > > local
> > > > registry in the overcloud job to run in parallel. The docker daemon can
> > > do
> > > > multiple pulls w/o problems.
> > > >
> > > >> - the overcloud validate task takes 10 min more than it should because
> > > >> of the bug Dan mentioned (a fix is in the queue at
> > > >> https://review.openstack.org/#/c/448575/)
> > > >
> > > >
> > > > +A
> > > >
> > > >> - the postci takes a long time with quickstart, 13 min (4 min alone
> > > >> spent on docker log collection) whereas it takes only 3 min when using
> > > >> tripleo.sh
> > > >
> > > >
> > > > mmh, does this have anything to do with ansible being in between? Or is
> > > that
> > > > time specifically for the part that gets the logs?
> > > >
> > > >>
> > > >> Adding all these numbers, we're at about 40 min of additional time for
> > > >> oooq containers job which is enough to cross the CI job limit.
> > > >>
> > > >> There is certainly a lot of room for optimization here and there and
> > > >> I'll explore how we can speed up the containers CI job over the next
> > > >
> > > >
> > > > Thanks a lot for the update. The time break down is fantastic,
> > > > Flavio
> > >
> > > TBH the problem is far from being solved:
> > >
> > > 1. Click on https://status-tripleoci.rhcloud.com/
> > > 2. Select gate-tripleo-ci-centos-7-ovb-containers-oooq-nv
> > >
> > > Container job has been 

Re: [openstack-dev] [tripleo] os-cloud-config retirement

[Jiří Stránský]

On 30.3.2017 14:58, Dan Prince wrote:

There is one case that I was thinking about reusing this piece of code
within a container to help initialize keystone endpoints. It would
require some changes and updates (to match how puppet-* configures
endpoints).

For TripleO containers we use various puppet modules (along with hiera)
to drive the creation of endpoints. This functionally works fine, but
is quite slow to execute (puppet is slow here) and takes several
minutes to complete. I'm wondering if a single optimized python script
might serve us better here. It could be driven via YAML (perhaps
similar to our Hiera), idempotent, and likely much faster than having
the code driven by puppet. This doesn't have to live in os-cloud-
config, but initially I thought that might be a reasonable place for
it. It is worth pointing out that this would be something that would
need to be driven by our t-h-t workflow and not a post-installation
task. So perhaps that makes it not a good fit for os-cloud-config. But
it is similar to the keystone initialization already there so I thought
I'd mention it.


I agree we could have an optimized python script instead of puppet to do 
the init. However, os-cloud-config also doesn't strike me as the ideal 
place.


What might be interesting is solving the keystone init within containers 
along with our container entrypoint situation. We've talked earlier that 
we may have to build our custom entrypoints into the images as we 
sometimes need to do things that the current entrypoints don't seem fit 
for, or don't give us enough control over what happens. This single 
optimized python script for endpoint config you mentioned could be one 
of such in-image entrypoint scripts. We could build multiple different 
scripts like this into a single image and select the right one when 
starting the container (defaulting to a script that handles the usual 
"worker" case, in this case Keystone API).


This gets somewhat similar to the os-cloud-config usecase, but even if 
we wanted a separate repo, or even a RPM for these, i suppose it would 
be cleaner to just start from scratch rather than repurpose os-cloud-config.


Jirka



Dan

On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote:

Hi,

os-cloud-config was deprecated in the Ocata release and is going to
be
removed in Pike.

TripleO project doesn't need it anymore and after some investigation
in codesearch.openstack.org, nobody is using it in OpenStack.
I'm working on the removal this cycle, please let us know any
concern.

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




__
OpenStack Development Mailing 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] [Fuel] Stepping down from core team

[Ihor Kalnytskyi]

Hey fuelers,

Having not been very active in Fuel the past year I think it's time to step 
down from the core team. If you need my review or you want to ask something, 
pls feel free to ping me in IRC.

Best,
Ihor

__
OpenStack Development Mailing 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] os-cloud-config retirement

[Dan Prince]

There is one case that I was thinking about reusing this piece of code
within a container to help initialize keystone endpoints. It would
require some changes and updates (to match how puppet-* configures
endpoints).

For TripleO containers we use various puppet modules (along with hiera)
to drive the creation of endpoints. This functionally works fine, but
is quite slow to execute (puppet is slow here) and takes several
minutes to complete. I'm wondering if a single optimized python script
might serve us better here. It could be driven via YAML (perhaps
similar to our Hiera), idempotent, and likely much faster than having
the code driven by puppet. This doesn't have to live in os-cloud-
config, but initially I thought that might be a reasonable place for
it. It is worth pointing out that this would be something that would
need to be driven by our t-h-t workflow and not a post-installation
task. So perhaps that makes it not a good fit for os-cloud-config. But
it is similar to the keystone initialization already there so I thought
I'd mention it.

Dan

On Thu, 2017-03-30 at 08:13 -0400, Emilien Macchi wrote:
> Hi,
> 
> os-cloud-config was deprecated in the Ocata release and is going to
> be
> removed in Pike.
> 
> TripleO project doesn't need it anymore and after some investigation
> in codesearch.openstack.org, nobody is using it in OpenStack.
> I'm working on the removal this cycle, please let us know any
> concern.
> 
> 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

[openstack-dev] [tripleo] os-cloud-config retirement

[Emilien Macchi]

Hi,

os-cloud-config was deprecated in the Ocata release and is going to be
removed in Pike.

TripleO project doesn't need it anymore and after some investigation
in codesearch.openstack.org, nobody is using it in OpenStack.
I'm working on the removal this cycle, please let us know any concern.

Thanks,
-- 
Emilien Macchi

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

Re: [openstack-dev] [DLRN][tripleo][kolla][puppet] trunk.rdoproject.org maintenance on Thu 30 Mar, 9:00 UTC

[Javier Pena]

> FYI, trunk.rdo maintenance will affect CI jobs tomorrow.
> 

Hi,

The maintenance has been completed, and trunk.rdoproject.org is serving 
packages as usual.

Please do not hesitate to contact us if you find any issue.

Regards,
Javier

> - Forwarded Message -
> Hi,
> 
> We need to do some maintenance patching in trunk.rdoproject.org. The expected
> downtime is 1 hour, and during the reboot you will see errors in CI jobs
> that fetch packages from it.
> 
> I will send a follow-up e-mail once the maintenance window is finished.
> 
> Regards,
> Javier
> 
> ___
> rdo-list mailing list
> rdo-l...@redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscr...@redhat.com
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [kolla] [ironic] Introducing Kayobe - Scientific OpenStack deployment using kolla

[Mark Goddard]

Hi,

Thanks for your interest! Could you provide some information on how you'd
like to get involved (operator, developer, scientist, etc.)?

We're not currently part of the OpenStack big tent and so don't yet use the
OpenStack development processes. If we see sufficient community interest in
the project we'd love to become part of the big tent.

We use Github[1] issues for bug reporting and Github pull requests for code
reviews. The documentation[2] is a good place to start and can be built
using 'tox -e docs', with HTML output generated in doc/build/html.

For communication, let's start with email or a Google hangout chat (both
via m...@stackhpc.com). I can set up an IRC channel or similar if those
methods become cumbersome.

Thanks,
Mark

[1] https://github.com/stackhpc/kayobe
[2] https://github.com/stackhpc/kayobe/tree/master/doc/source

On 30 March 2017 at 10:19, 韩晓磊  wrote:

> Hi，How to join to the project.
>
> 2017-03-30 16:46 GMT+08:00 Mark Goddard :
>
>> Hi,
>>
>> I'd like to announce Kayobe[1], a project that we at StackHPC have been
>> working on recently as we help to build out a performance prototyping
>> platform for the SKA telescope[2].
>>
>> Kayobe is an open source tool for automating deployment of Scientific
>> OpenStack onto a set of bare metal servers. Kayobe is composed of Ansible
>> playbooks, a python module, and makes heavy use of the OpenStack kolla
>> project. Kayobe aims to complement the kolla-ansible project, providing an
>> opinionated yet highly configurable OpenStack deployment and automation of
>> many operational procedures. Further information is available in the
>> project's documentation[3].
>>
>> In our recent blog post[4] we discuss some of the Zero Touch Provisioning
>> (ZTP) capabilities of the project that allowed us to quickly commission the
>> hardware for the SKA performance prototype platform. To achieve this,
>> Kayobe leverages ironic inspector's introspection rules and node discovery,
>> and Ansible's networking modules. We think these techniques may be
>> applicable to other deployment tools such as TripleO and would be
>> interested to share experiences and code with those communities.
>>
>> We'd love to hear feedback from the OpenStack community on the direction
>> this project is taking, and of course encourage interested parties to get
>> involved!
>>
>> Thanks,
>> Mark (mgoddard)
>>
>> [1] https://github.com/stackhpc/kayobe/
>> [2] https://skatelescope.org/
>> [3] https://github.com/stackhpc/kayobe/tree/master/doc
>> [4] https://www.stackhpc.com/ironic-idrac-ztp.html
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] [ironic] Introducing Kayobe - Scientific OpenStack deployment using kolla

[Paul Bourke]

Looks really cool Mark, congrats on the release!

-Paul

On 30/03/17 09:46, Mark Goddard wrote:

Hi,

I'd like to announce Kayobe[1], a project that we at StackHPC have been
working on recently as we help to build out a performance prototyping
platform for the SKA telescope[2].

Kayobe is an open source tool for automating deployment of Scientific
OpenStack onto a set of bare metal servers. Kayobe is composed of
Ansible playbooks, a python module, and makes heavy use of the OpenStack
kolla project. Kayobe aims to complement the kolla-ansible project,
providing an opinionated yet highly configurable OpenStack deployment
and automation of many operational procedures. Further information is
available in the project's documentation[3].

In our recent blog post[4] we discuss some of the Zero Touch
Provisioning (ZTP) capabilities of the project that allowed us to
quickly commission the hardware for the SKA performance prototype
platform. To achieve this, Kayobe leverages ironic inspector's
introspection rules and node discovery, and Ansible's networking
modules. We think these techniques may be applicable to other deployment
tools such as TripleO and would be interested to share experiences and
code with those communities.

We'd love to hear feedback from the OpenStack community on the direction
this project is taking, and of course encourage interested parties to
get involved!

Thanks,
Mark (mgoddard)

[1] https://github.com/stackhpc/kayobe/

[2] https://skatelescope.org/
[3] https://github.com/stackhpc/kayobe/tree/master/doc

[4] https://www.stackhpc.com/ironic-idrac-ztp.html


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



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

[openstack-dev] [kolla] [ironic] Introducing Kayobe - Scientific OpenStack deployment using kolla

[Mark Goddard]

Hi,

I'd like to announce Kayobe[1], a project that we at StackHPC have been
working on recently as we help to build out a performance prototyping
platform for the SKA telescope[2].

Kayobe is an open source tool for automating deployment of Scientific
OpenStack onto a set of bare metal servers. Kayobe is composed of Ansible
playbooks, a python module, and makes heavy use of the OpenStack kolla
project. Kayobe aims to complement the kolla-ansible project, providing an
opinionated yet highly configurable OpenStack deployment and automation of
many operational procedures. Further information is available in the
project's documentation[3].

In our recent blog post[4] we discuss some of the Zero Touch Provisioning
(ZTP) capabilities of the project that allowed us to quickly commission the
hardware for the SKA performance prototype platform. To achieve this,
Kayobe leverages ironic inspector's introspection rules and node discovery,
and Ansible's networking modules. We think these techniques may be
applicable to other deployment tools such as TripleO and would be
interested to share experiences and code with those communities.

We'd love to hear feedback from the OpenStack community on the direction
this project is taking, and of course encourage interested parties to get
involved!

Thanks,
Mark (mgoddard)

[1] https://github.com/stackhpc/kayobe/
[2] https://skatelescope.org/
[3] https://github.com/stackhpc/kayobe/tree/master/doc
[4] https://www.stackhpc.com/ironic-idrac-ztp.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] spec-lite process for tripleo

[Luke Hinds]

On Wed, Mar 29, 2017 at 10:42 PM, Steven Hardy  wrote:

> On Tue, Mar 28, 2017 at 12:09:43PM -0400, Emilien Macchi wrote:
> > Bringing an old topic on the table.
> >
> > We might have noticed:
> >
> > 1. Some tripleo-specs take huge amount of time before getting merged
> > (or even reviewed). We have been asking folks to review them every
> > week but unfortunately they don't get much attraction (# of core
> > reviewers versus # of folks actually reviewing specs).
> > 2. Some folks spend a lot of time writing TripleO specs and wait for
> > feedback before starting some implementation (like proof of concept).
> >
> > Because TripleO like innovation and also moving fast, I think it's
> > time to bring the tripleo-specs topic on the table:
> >
> > 1. If you have an idea, don't feel obliged to write a specs. Create a
> > blueprint on launchpad, announce it on the ML and start writing code
> > (can be real implementation or just a simple PoC). Feedback will be
> > given in the classic code review.
>
> +1 I for one have been burnt more than once spending significant time
> on a spec only to find our collective understanding changes after actual
> code exists.
>
> For things related to interfaces a spec can be helpful, but I think it's
> often faster to raise a blueprint with relatively few details and work on a
> prototype that clarifies the direction, particularly if such code patches
> can be generated fairly quickly.
>
> > 2. If you still want to write a spec, please make it readable and
> > communicate about it. If your spec is 900 lines long and not announced
> > anywhere, there is an high change that it will never been reviewed.
>
> I agree - I think a common mistake is to get bogged down in implementation
> detail when writing (and reviewing) a spec, so I definitely favor a
> clearly expressed summary of the problem, an overview of the proposed
> direction (including any major interface changes), and clarification of any
> user/dev visible impact.  None of this requires much focus at all on the
> details of the implementation IMO.
>
> Thanks for raising this Emilien, hopefully this will help us move a little
> faster in future!
>
> Steve


Having wrote a few specs this cycle, its good to read both your views, as I
was becoming concerned about spending a fair amount of time on answering
comments, correcting grammar nits, clarifying misunderstands etc, instead
of getting code I already had staged up for review.
__
OpenStack Development Mailing 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]: floating IP not being set for L2 GRE packets

[Kevin Benton]

Do you have the nf_conntrack_proto_gre kernel module loaded on the network
node?

On Wed, Mar 29, 2017 at 4:37 PM, Anil Rao  wrote:

> Strangely enough, there is no problem when I make use of a VxLAN tunnel to
> communicate between the VM (inside the cloud) and an external machine. In
> this case, the network node is performing the correct translation between
> the VM’s local IP and the floating IP currently assigned to it.
>
> So far I have only seen this problem when using L2 GRE tunnels.
>
> Thanks,
>
> Anil
>
>
>
> *From:* Anil Rao [mailto:anil@gigamon.com]
> *Sent:* Wednesday, March 29, 2017 3:17 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [neutron]: floating IP not being set for L2
> GRE packets
>
>
>
> This sender failed our fraud detection checks and may not
> be who they appear to be. Learn about spoofing
> 
>
> Feedback 
>
> Hi,
>
> I am seeing a strange behavior when it comes to floating IPs and L2 GRE
> tunnels that I was hoping someone could shed light on.
>
> Inside a tenant (project) I have a VM that wants to communicate with a
> machine residing outside the cloud. For this purpose, a floating IP has
> been assigned to the VM’s interface.
>
> *Case 1: VM communicates with external machine using ‘ping’.*
>
> This is successful.
>
> At the network node (from where the packets leave the OpenStack cloud),
> the VM’s local IP address is replaced with its floating IP for outgoing
> packets. Similarly, for incoming packets, the floating IP is replaced with
> the VM’s local IP address.
>
> *Case 2: VM communicates with the external machine using an L2 GRE tunnel.*
>
> This is not successful.
>
> At the network node, the outgoing packets [still] have the VM’ local IP
> address. It is not surprising that no packets come back for the VM from the
> external machine.
>
> My question is:  why didn’t the network node replace the VM’s IP address
> with its floating IP for the L2 GRE case although it did this for the
> simple ping case?
>
> I see this behavior on a multi-node DevStack based on stable/ocata as well
> as a multi-node production Newton cloud.
>
> Thanks and regards,
>
> Anil
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] broken python35 job due to webob compatibility issues

[Victor Stinner]

Adding the charset sounds like a good practice, especially in Keystone 
which is security sensitive. See this old Python vulnerability:


http://python-security.readthedocs.io/vuln/cve-2011-4940_simplehttpserver_utf-7.html

"The list_directory() function in Lib/SimpleHTTPServer.py in 
SimpleHTTPServer in Python before 2.5.6c1, 2.6.x before 2.6.7 rc2, and 
2.7.x before 2.7.2 does not place a charset parameter in the 
Content-Type HTTP header, which makes it easier for remote attackers to 
conduct cross-site scripting (XSS) attacks against Internet Explorer 7 
via UTF-7 encoding."


Maybe in 2017, browsers don't have issues with encodings anymore, right? ;-)

I don't know the WebOb module, but I'm not surprised that it doesn't 
already add charset='utf-8' *by default*.


Victor


Le 29/03/2017 à 23:54, Lance Bragstad a écrit :

The keystone gate is currently broken [0]. This seems related to a
previous change we made to be compatible with webob 1.7 [1]. Looks like
we missed a couple spots in the original patch that are failing now that
we're using a newer version of webob.

There is a solution up for review [2] that should unblock the gate.

[0] 
http://logs.openstack.org/44/443344/6/gate/gate-keystone-python35/e162b3d/testr_results.html.gz
[1] https://review.openstack.org/#/c/422234/
[2] https://review.openstack.org/#/c/451559/


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



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

Re: [openstack-dev] [nova] [neutron] What the behavior of AddFixedIp API should be?

[Alex Xu]

oops, sorry, the correct link is https://review.openstack.org/#/c/384261/,
I must remove last number accidently

2017-03-30 14:34 GMT+08:00 Kevin Benton :

> Not sure what you meant to link to, but that's not a spec. :)
>
> On Wed, Mar 29, 2017 at 11:21 PM, Alex Xu  wrote:
>
>> I just move the spec into Pike release https://review.opensta
>> ck.org/#/c/38426.
>>
>> The problem description section describes the strange API behaviour, and
>> proposal to deprecate the API since there isn't a clear use-case for this
>> API.
>>
>> 2017-03-29 8:59 GMT+08:00 Kevin Benton :
>>
>>> +1. If there is a use case missing from the neutron API that this
>>> allows, we can also expand the API to address it.
>>>
>>> On Mar 28, 2017 07:16, "Matt Riedemann"  wrote:
>>>
 On 3/27/2017 11:42 PM, Rui Chen wrote:

> Thank you Matt, the background information is important. Seems all the
> peoples don't know how the add-fixed-ip API works,
> and there is no exact use case about it. Now neutron port-update API
> also support to set multiple fixed ip for a port, and
> the fixed-ip updating will sync to nova side automatically (I had
> verified it in my latest devstack). Updating fixed-ip for
> specified port is easier to understand for me in multiple nics case
> than
> nova add-fixed-ip API.
>
> So if others known the orignal API design or had used nova add/remove
> fixed-ip API and would like to show your use cases,
> it's nice for us to understand how the API works and when we should use
> it, we can update the api-ref and add exact usage,
> avoid users' confusion about it. Feel free to reply something, thank
> you.
>
>
 If the functionality is available via Neutron APIs, we should just
 deprecate the multinic API like we did for the other network API proxies in
 microversion 2.36. This reminds me that Alex Xu had a blueprint for
 deprecating the multinic API [1] but it needs to be updated for Pike.

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

 --

 Thanks,

 Matt

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

Re: [openstack-dev] [nova] [neutron] What the behavior of AddFixedIp API should be?

[Kevin Benton]

Not sure what you meant to link to, but that's not a spec. :)

On Wed, Mar 29, 2017 at 11:21 PM, Alex Xu  wrote:

> I just move the spec into Pike release https://review.
> openstack.org/#/c/38426.
>
> The problem description section describes the strange API behaviour, and
> proposal to deprecate the API since there isn't a clear use-case for this
> API.
>
> 2017-03-29 8:59 GMT+08:00 Kevin Benton :
>
>> +1. If there is a use case missing from the neutron API that this allows,
>> we can also expand the API to address it.
>>
>> On Mar 28, 2017 07:16, "Matt Riedemann"  wrote:
>>
>>> On 3/27/2017 11:42 PM, Rui Chen wrote:
>>>
 Thank you Matt, the background information is important. Seems all the
 peoples don't know how the add-fixed-ip API works,
 and there is no exact use case about it. Now neutron port-update API
 also support to set multiple fixed ip for a port, and
 the fixed-ip updating will sync to nova side automatically (I had
 verified it in my latest devstack). Updating fixed-ip for
 specified port is easier to understand for me in multiple nics case than
 nova add-fixed-ip API.

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


>>> If the functionality is available via Neutron APIs, we should just
>>> deprecate the multinic API like we did for the other network API proxies in
>>> microversion 2.36. This reminds me that Alex Xu had a blueprint for
>>> deprecating the multinic API [1] but it needs to be updated for Pike.
>>>
>>> [1] https://review.openstack.org/#/c/384261/
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Eran Rom]

Just a quick reminder.
When: Today, Thursday March 30, @09:00 and @19:00 UTC
Where: https://zoom.us/j/7922255193

More details below.
Thanks!
Eran
Storlets PTL

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

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

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

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

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

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

Call Technicalities:
The talk will be given using Zoom video conferencing. Connecting will require
a browser plugin installation. The link to the call is:
https://zoom.us/j/7922255193

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

Re: [openstack-dev] [nova] [neutron] What the behavior of AddFixedIp API should be?

[Alex Xu]

I just move the spec into Pike release
https://review.openstack.org/#/c/38426.

The problem description section describes the strange API behaviour, and
proposal to deprecate the API since there isn't a clear use-case for this
API.

2017-03-29 8:59 GMT+08:00 Kevin Benton :

> +1. If there is a use case missing from the neutron API that this allows,
> we can also expand the API to address it.
>
> On Mar 28, 2017 07:16, "Matt Riedemann"  wrote:
>
>> On 3/27/2017 11:42 PM, Rui Chen wrote:
>>
>>> Thank you Matt, the background information is important. Seems all the
>>> peoples don't know how the add-fixed-ip API works,
>>> and there is no exact use case about it. Now neutron port-update API
>>> also support to set multiple fixed ip for a port, and
>>> the fixed-ip updating will sync to nova side automatically (I had
>>> verified it in my latest devstack). Updating fixed-ip for
>>> specified port is easier to understand for me in multiple nics case than
>>> nova add-fixed-ip API.
>>>
>>> So if others known the orignal API design or had used nova add/remove
>>> fixed-ip API and would like to show your use cases,
>>> it's nice for us to understand how the API works and when we should use
>>> it, we can update the api-ref and add exact usage,
>>> avoid users' confusion about it. Feel free to reply something, thank you.
>>>
>>>
>> If the functionality is available via Neutron APIs, we should just
>> deprecate the multinic API like we did for the other network API proxies in
>> microversion 2.36. This reminds me that Alex Xu had a blueprint for
>> deprecating the multinic API [1] but it needs to be updated for Pike.
>>
>> [1] https://review.openstack.org/#/c/384261/
>>
>> --
>>
>> Thanks,
>>
>> Matt
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev