Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Tony Breeds]

Hi All,
In an effort to qualify which projects are likley to be affected if
when we open the requirements repo I generated a list of all repos that:

1. Subscribe to requirements management
2. Do not already have a stable/pike branch
3. Do not follow the cycle-with-milestones, cycle-trailing or
   independent release models
4. Are not a 'branchless' project (tempest or tempest-plugin)

These repos I believe *should* have a stable/pike branch or will see
problems when we open openstack/requirements.  Those issues were
described in [1]

It turns out close to 1/3rd of projects that subscribe to requirements
management are not ready for us to re-open for master.  So we need you
help to get that number down to a much more acceptable number.

The good news is it's pretty easy to fix this with the cool tools and
workflow in the releases repo[2].  I suspect that the 'service' will
take care of themselves, and the horizon-plugins are waiting to horizon
to cut RC1.

Repos with type: horizon-plugin
ironic-ui  ironic  
manila-ui  manila  
monasca-ui monasca 
neutron-fwaas-dashboardneutron 
solum-dashboardsolum   
tacker-horizon tacker  
watcher-dashboard  watcher 
zun-ui zun 

Repos with type: other
python-openstackclient OpenStackClient 
patroleQuality Assurance   
heat-agentsheat
ironic-inspector   ironic  
ironic-python-agentironic  
kuryr-kubernetes   kuryr   
monasca-common monasca 
monasca-notification   monasca 
monasca-persister  monasca 
monasca-transform  monasca 

Repos with type: service
ironic ironic  
monasca-apimonasca 
monasca-log-apimonasca 
swift  swift   
tricircle  tricircle   
vitragevitrage 
watcherwatcher 
zunzun

Those are the easy items.

The following repos don't seem to use the openstack/releases repo so I
have less information there.

i18n   I18n
almanach   
blazar 
blazar-nova
compute-hyperv 
ekko   
gce-api
glare  
ironic-staging-drivers 
kosmos 
masakari   
masakari-monitors  
mixmatch   
mogan  
nemesis
networking-dpm 
networking-fujitsu 
networking-generic-switch  
networking-l2gw
networking-powervm 
neutron-vpnaas 
neutron-vpnaas-dashboard   
nova-dpm   
nova-lxd   
nova-powervm   
os-xenapi  
python-blazarclient

[openstack-dev] [mistral][core] Proposing Andras Kovi to the Mistral core team

[Renat Akhmerov]

Hi,

I’d like to propose Andras Kovi to the Mistral core team.

The current statistics of Andras can be seen at [1].
Andras has been contributing for about 1.5 years and in Pike he increased his 
activity significantly, primarily reviewing. His reviews are always thorough 
and insightful. He cares about code quality. He knows both OpenStack ecosystem 
and Mistral architecture and codebase well. Adding Andras to the core team 
would be also very useful for us because he is a very active user of Mistral, 
he implemented or participated in implementation of lots of Nokia CBAM use 
cases based on Mistral.
Andras also gave an excellent presentation about Mistral performance in Boston, 
[2]. I’d really recommend to watch it if you work with Mistral as a contributor 
or as a user.
Speaking less formally, Andras is a very good guy, deep thinker with a great 
experience in software programming. Every time I have a chance to meet him 
personally it’s a lot of fun to talk to him and learn from him.

So I’m asking you to support me in this promotion. I really believe that Andras 
will be an invaluable addition to our team.

[1] http://stackalytics.com/?module=mistral-group_id=akovi
[2] https://www.openstack.org/videos/boston-2017/mistral-performance-in-numbers

Thanks

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

Re: [openstack-dev] [requirements][OpenStackAnsible][kolla][tripleo] Upcoming requirements thaw.

[Tony Breeds]

Hello!
The requirements team is expecting the re-open the master branch
shortly after we create a stable/pike branch.  This means that
cycle-training projects may (will?) start seeing bot generated
requirements syncs intended for queens.  I tried to come up with an
automated way to block this and failed.  This measn it's going to fall
on your teams to block all requirements updates you branch your repo's for pike.

If you think a change is destined for pike feel free to reach out for
clarification.

Alos if you can think of a better way to handle this in 6 months we're
all ears :)

For the sake of completeness here's a list of repos[1] I expect you'll need
to keep an eye on.

openstack-ansible  OpenStackAnsible
openstack-ansible-apt_package_pinning  OpenStackAnsible
openstack-ansible-ceph_client  OpenStackAnsible
openstack-ansible-galera_clientOpenStackAnsible
openstack-ansible-galera_serverOpenStackAnsible
openstack-ansible-haproxy_server   OpenStackAnsible
openstack-ansible-lxc_container_create OpenStackAnsible
openstack-ansible-lxc_hostsOpenStackAnsible
openstack-ansible-memcached_server OpenStackAnsible
openstack-ansible-openstack_hosts  OpenStackAnsible
openstack-ansible-openstack_openrc OpenStackAnsible
openstack-ansible-ops  OpenStackAnsible
openstack-ansible-os_almanach  OpenStackAnsible
openstack-ansible-os_aodh  OpenStackAnsible
openstack-ansible-os_barbican  OpenStackAnsible
openstack-ansible-os_ceilometerOpenStackAnsible
openstack-ansible-os_cinderOpenStackAnsible
openstack-ansible-os_cloudkittyOpenStackAnsible
openstack-ansible-os_designate OpenStackAnsible
openstack-ansible-os_freezer   OpenStackAnsible
openstack-ansible-os_glanceOpenStackAnsible
openstack-ansible-os_gnocchi   OpenStackAnsible
openstack-ansible-os_heat  OpenStackAnsible
openstack-ansible-os_horizon   OpenStackAnsible
openstack-ansible-os_ironicOpenStackAnsible
openstack-ansible-os_keystone  OpenStackAnsible
openstack-ansible-os_magnumOpenStackAnsible
openstack-ansible-os_moltenironOpenStackAnsible
openstack-ansible-os_monasca   OpenStackAnsible
openstack-ansible-os_monasca-agent OpenStackAnsible
openstack-ansible-os_monasca-uiOpenStackAnsible
openstack-ansible-os_neutron   OpenStackAnsible
openstack-ansible-os_nova  OpenStackAnsible
openstack-ansible-os_octavia   OpenStackAnsible
openstack-ansible-os_rally OpenStackAnsible
openstack-ansible-os_saharaOpenStackAnsible
openstack-ansible-os_searchlight   OpenStackAnsible
openstack-ansible-os_swift OpenStackAnsible
openstack-ansible-os_tempest   OpenStackAnsible
openstack-ansible-os_trove OpenStackAnsible
openstack-ansible-os_watcher   OpenStackAnsible
openstack-ansible-os_zaqar OpenStackAnsible
openstack-ansible-pip_install  OpenStackAnsible
openstack-ansible-plugins  OpenStackAnsible
openstack-ansible-rabbitmq_server  OpenStackAnsible
openstack-ansible-repo_build   OpenStackAnsible
openstack-ansible-repo_server  OpenStackAnsible
openstack-ansible-rsyslog_client   OpenStackAnsible
openstack-ansible-rsyslog_server   OpenStackAnsible
openstack-ansible-specsOpenStackAnsible
openstack-ansible-testsOpenStackAnsible
kolla  kolla   
kolla-ansible  kolla   
kolla-kubernetes   kolla   
diskimage-builder  tripleo 
instack-undercloud tripleo 
os-apply-configtripleo 
os-collect-config  tripleo 
os-refresh-config  tripleo 
tripleo-common tripleo

Re: [openstack-dev] [all][infra]Plan to support Python 3.6 ?

[Clint Byrum]

Ubuntu will ship Python 3.6 in the next LTS, Ubuntu 18.04 next April.

AFAICT CentOS 7 still doesn't ship Python 3 in mainline. EPEL has 3.4
still.

Excerpts from Doug Hellmann's message of 2017-08-09 09:31:37 -0400:
> Excerpts from ChangBo Guo's message of 2017-08-09 21:25:07 +0800:
> > We received Python 3.6 related Bug recently [1][2]. That let me think
> > what's the plan to support Python 3.6 for OpenStack in the future.   Python
> > 3.6 was released on December 23, 2016, has some different behaviors from
> > Python 3.5[3]. talked with cdent in the IRC, would like to discuss this
> > through mailing list , and suggest a discussion at the PTG[3]
> 
> One of the reasons we were able to move ahead with 3.5 was that it would
> be available on the platforms for which we test deployments, as defined
> in the CTI [5]. Are Ubuntu LTS and CentOS shipping Python 3.6?
> 
> [5] 
> https://governance.openstack.org/tc/reference/project-testing-interface.html
> 
> > 
> > 1. what's the time to support Python 3.6 ?
> > 
> > 2. what 's the  plan or process ?
> >  Maybe we can do that we support python 3
> >  1) setup python 3.6 non-voting CI jobs
> >  2) Fix related issues about Python 3.6
> >  3) enable pyhton 3.6 jobs voting
> > 
> > [1] https://bugs.launchpad.net/oslo.rootwrap/+bug/1709505
> > [2]https://bugs.launchpad.net/pbr/+bug/1690103
> > [3]https://docs.python.org/3/whatsnew/3.6.html
> > [4] https://etherpad.openstack.org/p/infra-ptg-queens
> 

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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Morgan Fainberg]

On Aug 9, 2017 16:48, "Kendall Nelson"  wrote:

Hello Everyone!

The PTL Nomination period is now over. The official candidate list is
available on the election website[0].

There are 2 projects without candidates, so according to this
resolution[1], the TC will have to appoint a new PTL for Storlets, and
Packaging-Deb.

There are 2 projects that will have elections: Ironic and Documentation. The
details for those will be posted shortly after we setup the CIVS system.

Thank you,

-Kendall Nelson (diablo_rojo)

[0]: http://governance.openstack.org/election/#
queens

-ptl-candidates

[1]: http://governance.openstack.org/resolutions/20141128-electio
ns-process-for-leaderless-programs.html



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


I believe packaging deb is being retired[0].

[0] http://lists.openstack.org/pipermail/openstack-dev/
2017-August/120581.html

--Morgan
__
OpenStack Development Mailing 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][infra] Functional job failure rate at 100%

[Kevin Benton]

This is just the code simulating the conntrack entries that would be
created by real traffic in a production system, right?

On Wed, Aug 9, 2017 at 11:46 AM, Jakub Libosvar  wrote:

> On 09/08/2017 18:23, Jeremy Stanley wrote:
> > On 2017-08-09 15:29:04 +0200 (+0200), Jakub Libosvar wrote:
> > [...]
> >> Is it possible to switch used image for jenkins machines to use
> >> back the older version? Any other ideas how to deal with the
> >> kernel bug?
> >
> > Making our images use non-current kernel packages isn't trivial, but
> > as Thierry points out in his reply this is not just a problem for
> > our CI system. Basically Ubuntu has broken OpenStack (and probably a
> > variety of other uses of conntrack) for a lot of people following
> > kernel updates in 16.04 LTS so the fix needs to happen there
> > regardless. Right now, basically, Ubuntu Xenial is not a good
> > platform to be running OpenStack on until they get the kernel
> > regression addressed.
>
> True. Fortunately, the impact is not that catastrophic for Neutron as it
> might seem on the first look. Not sure about the other projects, though.
> Neutron doesn't create conntrack entries in production code - only in
> testing. That said, agents should work just fine even with the kernel bug.
>
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing 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] [all][elections] PTL Voting is now open

[Kendall Nelson]

Hello Again!

Elections are underway and will remain open for you to cast your vote until
Aug 16th, 2017 23:45 UTC.

We are having elections for Ironic and Documentation.

If you are a Foundation individual member and had a commit in one of the
program's projects[0] over the Ocata-Pike timeframe (September, 2016 23:59
UTC to August 3rd , 2017 23:59 UTC) then you are eligible to vote. You
should find your email with a link to the Condorcet page to cast your vote
in the inbox of your gerrit preferred email[1].

What to do if you don't see the email and have a commit in at least one of
the programs having an election:
  * check the trash or spam folders of your gerrit Preferred Email address,
in case it went into trash or spam
  * wait a bit and check again, in case your email server is a bit slow
  * find the sha of at least one commit from the program project repos[0]
and email the election officials. If we can confirm that you are entitled
to vote, we will add you to the voters list for the appropriate election.

Our democratic process is important to the health of OpenStack, please
exercise your right to vote!

Candidate statements/platforms can be found linked to Candidate names on
this page: http://governance.openstack.org/election/#pike-ptl-candidates

Happy voting,

-Kendall Nelson (diablo_rojo)

[0] The list of the program projects eligible for electoral status:
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=aug-2017-elections

[1] Sign into review.openstack.org:
Go to Settings > Contact Information.
Look at the email listed as your Preferred Email.
That is where the ballot has been sent.
__
OpenStack Development Mailing 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] PTL nomination period is now over

[Kendall Nelson]

Hello Everyone!

The PTL Nomination period is now over. The official candidate list is
available on the election website[0].

There are 2 projects without candidates, so according to this
resolution[1], the TC will have to appoint a new PTL for Storlets, and
Packaging-Deb.

There are 2 projects that will have elections: Ironic and Documentation. The
details for those will be posted shortly after we setup the CIVS system.

Thank you,

-Kendall Nelson (diablo_rojo)

[0]: http://governance.openstack.org/election/#
queens

-ptl-candidates

[1]:
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] Meeting Thursday Aug 10th at 8:00 UTC

[Ghanshyam Mann]

Hello everyone,

Please reminder that the weekly OpenStack QA team IRC meeting will be
Thursday, Aug 10th at 8:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_August_10th_2017_.280800_UTC.29

Anyone is welcome to add an item to the agenda.

-gmann

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

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

[Ken Giusti]

Thanks for kicking this off.  I've left some comments in the review.

-K

On Tue, Aug 8, 2017 at 10:07 AM, Matthieu Simonin  wrote:

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

Re: [openstack-dev] [all][infra]Plan to support Python 3.6 ?

[David Moreau Simard]

On Wed, Aug 9, 2017 at 9:31 AM, Doug Hellmann  wrote:
>
> Are Ubuntu LTS and CentOS shipping Python 3.6?
>

CentOS doesn't even carry python 3 at all right now, outside of
perhaps python 3.4 from EPEL.
Unless mistaken, RHEL 8 (and by extension CentOS 8) is bound to ship with 3.5.

We're still a bit far away from RHEL 8.

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]

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

Re: [openstack-dev] [neutron][infra] Functional job failure rate at 100%

[Jakub Libosvar]

On 09/08/2017 18:23, Jeremy Stanley wrote:
> On 2017-08-09 15:29:04 +0200 (+0200), Jakub Libosvar wrote:
> [...]
>> Is it possible to switch used image for jenkins machines to use
>> back the older version? Any other ideas how to deal with the
>> kernel bug?
> 
> Making our images use non-current kernel packages isn't trivial, but
> as Thierry points out in his reply this is not just a problem for
> our CI system. Basically Ubuntu has broken OpenStack (and probably a
> variety of other uses of conntrack) for a lot of people following
> kernel updates in 16.04 LTS so the fix needs to happen there
> regardless. Right now, basically, Ubuntu Xenial is not a good
> platform to be running OpenStack on until they get the kernel
> regression addressed.

True. Fortunately, the impact is not that catastrophic for Neutron as it
might seem on the first look. Not sure about the other projects, though.
Neutron doesn't create conntrack entries in production code - only in
testing. That said, agents should work just fine even with the kernel bug.

> 
> 
> 
> __
> OpenStack Development Mailing 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][infra]Plan to support Python 3.6 ?

[Jeremy Stanley]

On 2017-08-09 09:31:37 -0400 (-0400), Doug Hellmann wrote:
[...]
> One of the reasons we were able to move ahead with 3.5 was that it
> would be available on the platforms for which we test deployments,
> as defined in the CTI [5]. Are Ubuntu LTS and CentOS shipping
> Python 3.6?
[...]

Yes, we ran early 3.3 testing on Ubuntu 12.04 LTS with the aid of
some backported packages but this was far from ideal. Proper support
for 3.4 testing came with Ubuntu 14.04 LTS which included it
directly in the package archive, and then we switched to testing
against 3.5 when Ubuntu 16.04 became available installing it by
default. The Ubuntu python3.6 packages started appearing after 16.04
was out the door, and so looks like it will be generally available
to us once Ubuntu 18.04 LTS is released and we can start using it as
a basis for CI jobs (likely in Q2 of next year, so probably during
OpenStack's "Rocky" release cycle).
-- 
Jeremy Stanley


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

Re: [openstack-dev] [TripleO][Heat] using convergence_engine to deploy overcloud stack

[Ben Nemec]

On 08/09/2017 05:49 AM, Rabi Mishra wrote:
On Wed, Aug 9, 2017 at 1:41 PM, Smigielski, Radoslaw (Nokia - IE) 
> 
wrote:


Hi there!

I have a question about heat "convergence_engine" option, it's
present in heat config since quite a long time but still not enabled.

Well, convergence is enabled by default in heat since newton. However, 
Tripleo does not use it yet, as convergence engine memory usage is 
higher than that of legacy engine.


There has been number of optimizations in the last two cycles to improve 
that situation. However, AFAIK, when using a single node undercloud, 
memory usage would always be more with convergence.


I think there are plans for Tripleo to move to convergence in Queens as 
discussed in this ML thread.


http://lists.openstack.org/pipermail/openstack-dev/2017-June/118237.html


Yeah, my understanding is that we'll look at turning on convergence for 
the undercloud by default in Queens.  It was just getting too late in a 
cycle of full of huge architectural changes to flip the switch in Pike.


If there's no indication of trouble from the experimental job we should 
definitely turn it on ASAP once Queens opens though.




And I am wondering if anyone has tried enabled it and deploy
overcloud? I did it myself and it seems to be working.

The main reason why I am looking at this options are problems with
scaling out, adding computes, replacing failed controllers on setups
with 50+ computes and number of nested stack 1000+.


You've to probably scale out undercloud heat to get most of the benefits 
of convergence that comes with the distributed architecture.


Is there any reason what holds Heat switch to convergence architecture?


_
*Radosław Śmigielski*
Nokia CBIS R

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





--
Regards,
Rabi Misra



__
OpenStack Development Mailing 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][infra] Functional job failure rate at 100%

[Jeremy Stanley]

On 2017-08-09 15:29:04 +0200 (+0200), Jakub Libosvar wrote:
[...]
> Is it possible to switch used image for jenkins machines to use
> back the older version? Any other ideas how to deal with the
> kernel bug?

Making our images use non-current kernel packages isn't trivial, but
as Thierry points out in his reply this is not just a problem for
our CI system. Basically Ubuntu has broken OpenStack (and probably a
variety of other uses of conntrack) for a lot of people following
kernel updates in 16.04 LTS so the fix needs to happen there
regardless. Right now, basically, Ubuntu Xenial is not a good
platform to be running OpenStack on until they get the kernel
regression addressed.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [neutron][infra] Functional job failure rate at 100%

[Thierry Carrez]

Thanks for this nice detective work, Jakub and Daniel ! This disabled
test job was making me nervous wrt. Pike release.

Now I suspect that this kernel regression is affecting Ubuntu Xenial
users for previous releases of OpenStack, too, so I hope this will get
fixed in Ubuntu soon enough.

Daniel Alvarez Sanchez wrote:
> Some more info added to Jakub's excellent report :)
> 
> 
> New kernel Ubuntu-4.4.0-89.112HEADUbuntu-4.4.0-89.112master was
> tagged 9 days ago (07/31/2017) [0].
> 
> From a quick look, the only commit around this function is [1].
> 
> [0] 
> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=64de31ed97a03ec1b86fd4f76e445506dce55b02
> [1] 
> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=2ad4caea651e1cc0fc86111ece9f9d74de825b78
> 
> On Wed, Aug 9, 2017 at 3:29 PM, Jakub Libosvar  > wrote:
> 
> Daniel Alvarez and I spent some time looking at it and the culprit was
> finally found.
> 
> tl;dr
> 
> We updated a kernel on machines to one containing bug when creating
> conntrack entries which makes functional tests stuck. More info at [4].
> 
> For now, I sent a patch [5] to disable for now jobs that create
> conntrack entries manually, it needs update of commit message. Once it
> merges, we an enable back functional job to voting to avoid regressions.
> 
> Is it possible to switch used image for jenkins machines to use back the
> older version? Any other ideas how to deal with the kernel bug?
> 
> Thanks
> Jakub
> 
> [5] https://review.openstack.org/#/c/492068/1
> 
> 
> On 07/08/2017 11:52, Jakub Libosvar wrote:
> > Hi all,
> >
> > as per grafana [1] the functional job is broken. Looking at
> logstash [2]
> > it started happening consistently since 2017-08-03 16:27. I didn't
> find
> > any particular patch in Neutron that could cause it.
> >
> > The culprit is that ovsdb starts misbehaving [3] and then we retry
> calls
> > indefinitely. We still use 2.5.2 openvswitch as we had before. I
> opened
> > a bug [4] and started investigation, I'll update my findings there.
> >
> > I think at this point there is no reason to run "recheck" on your
> patches.
> >
> > Thanks,
> > Jakub
> >
> > [1]
> >
> 
> http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=7
> 
> 
> > [2] http://bit.ly/2vdKMwy
> > [3]
> >
> 
> http://logs.openstack.org/14/488914/8/check/gate-neutron-dsvm-functional-ubuntu-xenial/75d7482/logs/openvswitch/ovsdb-server.txt.gz
> 
> 
> > [4] https://bugs.launchpad.net/neutron/+bug/1709032
> 
> >
> 
> 
> __
> OpenStack Development Mailing 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
> 


-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type VIFHostDevice

[Mooney, Sean K]

> -Original Message-
> From: Moshe Levi [mailto:mosh...@mellanox.com]
> Sent: Wednesday, August 9, 2017 4:47 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on
> VIF_Type VIFHostDevice
> 
> 
> 
> -Original Message-
> From: Mooney, Sean K [mailto:sean.k.moo...@intel.com]
> Sent: Wednesday, August 9, 2017 6:36 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on
> VIF_Type VIFHostDevice
> 
> 
> 
> > -Original Message-
> > From: Moshe Levi [mailto:mosh...@mellanox.com]
> > Sent: Wednesday, August 9, 2017 3:25 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on
> > VIF_Type VIFHostDevice
> >
> > Hi,
> >
> > 1) you should use neutron port with vnic_type direct
> > 2) yes,  just use neutron port with vnic_type  direct and confighure
> > the nova compute with pci passthogth whitelist
> > 3) you can configure firewall_driver = openvswitch to work with
> > Conntrack.
> >
> > So in your case if have SR-IOV nic which doesn't support  hardware
> > offload (but has VF representors port)  you will just fallback to the
> > ovs kernel datapath.
> 
> [Mooney, Sean K] that is not what will happen with intel nics and I
> would be doubtful Based on the code I have seen in nova and neutron
> that a fallback will happen with mellanox.
> If the neutron port has vnic_type direct it will Always result in a
> sriov vf being allocated for that port.
> There is no check in nova to ensure ovs support vf configuration and
> there is no check in neutron ml2 driver Either. This is why I wanted
> the feature based scheduling to prevent this from happening as that
> would prevent Nova from allocating the vf which would cause scheduling
> to fail.
> 
> [Moshe Levi] This is not what I meant. I was talking on the
> implementation of the ovs 2.8.0 hardware offload.
> I was referring  for NIC with SR-IOV that support representor ports
> switchdev mode (maybe I miss understood the question).  If it just SR-
> IOV NIC then you are correct.
[Mooney, Sean K] ah yes if the nic and ovs both support representor ports
And tc flower then yes the datapath will auto negociate what can be offloaded
Vs what has to take the exception path via the kernel dataplane. 
> 
> 
> When nova generates the Libvirt xml for that interface it will
> configure that port to use sriov direct pass-through.
> If ovs does not support managing that nic via the representor netdev or
> the nic does not support the tc flower protocol then the port add will
> not fail as we are just adding the representor netdev as a normal port
> But it will not be able to preform any control plane actions on it.
> there is no way for a Libvirt hostdevice to gracefully fall back to the
> kernel dataplane without modifying Xml. After all we are not even
> adding the vf to ovs we are adding a representor port to ovs so the
> dataplane is entirely bypassing ovs for unsupported nics.
> 
> 
> As long as you have the host has vf available and the ovs ml2 driver is
> listed before the sriov nic Agent ml2 driver you will get into this
> broken state.
> 
> > The ovs 2.8.0 code try to offload each datapath rule to NIC hardware
> > if it failed it fails back to the ovs kernel datapath.
> > So if have NIC that can offload classification  on vlan  and action
> > output. Only datapath flows that constructed for this classification
> > and action  will be offload to hardware.
> >
> > -Original Meyssage-
> > From: pranab boruah [mailto:pranabjyotibor...@gmail.com]
> > Sent: Wednesday, August 9, 2017 4:36 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type
> > VIFHostDevice
> >
> > Hi,
> > I am experimenting with the os-vif library and stumbled upon this new
> > VIF type called VIFHostDevice. I have few general queries. TIA.
> >
> > 1. How do I create ports with VIF_type as VIFHostDevice? Looking for
> > the CLI command options.
> >
> >
> > 2. Say, I have OVS running completely on x86 host(no datapath or flow
> > offload to
> >  NIC) as the networking mechanism and a SRIOV capable NIC(for
> > existence of VF representors that will be added to the OVS bridge).
> > Can I still launch instances with VIF_type as VIFHostDevice?
> >
> >
> > 3. I want to use Security Groups using OVS+Conntrack as the
> mechanism.
> > Can I apply SG rules on the ports of type VIFHostDevice using the
> > above mechanism?
> >
> > PS: I am still trying to understand this. Hence, I might get my
> > premises wrong in the above questions. Will appreciate a detailed
> > explanation.
> >
> > Regards,
> > Pranab
> >
> 

Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type VIFHostDevice

[Moshe Levi]

-Original Message-
From: Mooney, Sean K [mailto:sean.k.moo...@intel.com] 
Sent: Wednesday, August 9, 2017 6:36 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type 
VIFHostDevice



> -Original Message-
> From: Moshe Levi [mailto:mosh...@mellanox.com]
> Sent: Wednesday, August 9, 2017 3:25 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on 
> VIF_Type VIFHostDevice
> 
> Hi,
> 
> 1) you should use neutron port with vnic_type direct
> 2) yes,  just use neutron port with vnic_type  direct and confighure 
> the nova compute with pci passthogth whitelist
> 3) you can configure firewall_driver = openvswitch to work with 
> Conntrack.
> 
> So in your case if have SR-IOV nic which doesn't support  hardware 
> offload (but has VF representors port)  you will just fallback to the 
> ovs kernel datapath.

[Mooney, Sean K] that is not what will happen with intel nics and I would be 
doubtful Based on the code I have seen in nova and neutron that a fallback will 
happen with mellanox.
If the neutron port has vnic_type direct it will Always result in a sriov vf 
being allocated for that port. 
There is no check in nova to ensure ovs support vf configuration and there is 
no check in neutron ml2 driver Either. This is why I wanted the feature based 
scheduling to prevent this from happening as that would prevent Nova from 
allocating the vf which would cause scheduling to fail.

[Moshe Levi] This is not what I meant. I was talking on the implementation of 
the ovs 2.8.0 hardware offload. 
I was referring  for NIC with SR-IOV that support representor ports switchdev 
mode (maybe I miss understood the question).  If it just SR-IOV NIC then you 
are correct.  
 

When nova generates the Libvirt xml for that interface it will configure that 
port to use sriov direct pass-through.
If ovs does not support managing that nic via the representor netdev or the nic 
does not support the tc flower protocol then the port add will not fail as we 
are just adding the representor netdev as a normal port But it will not be able 
to preform any control plane actions on it. there is no way for a Libvirt 
hostdevice to gracefully fall back to the kernel dataplane without modifying 
Xml. After all we are not even adding the vf to ovs we are adding a representor 
port to ovs so the dataplane is entirely bypassing ovs for unsupported nics.


As long as you have the host has vf available and the ovs ml2 driver is listed 
before the sriov nic Agent ml2 driver you will get into this broken state.

> The ovs 2.8.0 code try to offload each datapath rule to NIC hardware 
> if it failed it fails back to the ovs kernel datapath.
> So if have NIC that can offload classification  on vlan  and action 
> output. Only datapath flows that constructed for this classification 
> and action  will be offload to hardware.
> 
> -Original Meyssage-
> From: pranab boruah [mailto:pranabjyotibor...@gmail.com]
> Sent: Wednesday, August 9, 2017 4:36 PM
> To: OpenStack Development Mailing List (not for usage questions) 
> 
> Subject: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type 
> VIFHostDevice
> 
> Hi,
> I am experimenting with the os-vif library and stumbled upon this new 
> VIF type called VIFHostDevice. I have few general queries. TIA.
> 
> 1. How do I create ports with VIF_type as VIFHostDevice? Looking for 
> the CLI command options.
> 
> 
> 2. Say, I have OVS running completely on x86 host(no datapath or flow 
> offload to
>  NIC) as the networking mechanism and a SRIOV capable NIC(for 
> existence of VF representors that will be added to the OVS bridge). 
> Can I still launch instances with VIF_type as VIFHostDevice?
> 
> 
> 3. I want to use Security Groups using OVS+Conntrack as the mechanism.
> Can I apply SG rules on the ports of type VIFHostDevice using the 
> above mechanism?
> 
> PS: I am still trying to understand this. Hence, I might get my 
> premises wrong in the above questions. Will appreciate a detailed 
> explanation.
> 
> Regards,
> Pranab
> 
> __
> _
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> s
> .openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C0af8192c256c42f1252308d4df
> 2 
> b96b4%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636378825693889082&
> s
> data=iNi%2FLHV5LkTKs8sSpS4BgHU6lwaoywo6O%2BNcF3hqtms%3D=0
> __
> _
> ___
> OpenStack Development Mailing List (not 

Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type VIFHostDevice

[Mooney, Sean K]

> -Original Message-
> From: Moshe Levi [mailto:mosh...@mellanox.com]
> Sent: Wednesday, August 9, 2017 3:25 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on
> VIF_Type VIFHostDevice
> 
> Hi,
> 
> 1) you should use neutron port with vnic_type direct
> 2) yes,  just use neutron port with vnic_type  direct and confighure
> the nova compute with pci passthogth whitelist
> 3) you can configure firewall_driver = openvswitch to work with
> Conntrack.
> 
> So in your case if have SR-IOV nic which doesn't support  hardware
> offload (but has VF representors port)  you will just fallback to the
> ovs kernel datapath.

[Mooney, Sean K] that is not what will happen with intel nics and I would be 
doubtful
Based on the code I have seen in nova and neutron that a fallback will happen 
with mellanox.
If the neutron port has vnic_type direct it will Always result in a sriov vf 
being allocated for that port. 
There is no check in nova to ensure ovs support vf configuration and there is 
no check in neutron ml2 driver
Either. This is why I wanted the feature based scheduling to prevent this from 
happening as that would prevent
Nova from allocating the vf which would cause scheduling to fail. 

When nova generates the Libvirt xml for that interface it will configure that 
port to use sriov direct pass-through.
If ovs does not support managing that nic via the representor netdev or the nic 
does not support the
tc flower protocol then the port add will not fail as we are just adding the 
representor netdev as a normal port
But it will not be able to preform any control plane actions on it. there is no 
way for a Libvirt hostdevice
to gracefully fall back to the kernel dataplane without modifying Xml. After 
all we are not even adding the vf
to ovs we are adding a representor port to ovs so the dataplane is entirely 
bypassing ovs for unsupported nics.

As long as you have the host has vf available and the ovs ml2 driver is listed 
before the sriov nic
Agent ml2 driver you will get into this broken state.

> The ovs 2.8.0 code try to offload each datapath rule to NIC hardware if
> it failed it fails back to the ovs kernel datapath.
> So if have NIC that can offload classification  on vlan  and action
> output. Only datapath flows that constructed for this classification
> and action  will be offload to hardware.
> 
> -Original Meyssage-
> From: pranab boruah [mailto:pranabjyotibor...@gmail.com]
> Sent: Wednesday, August 9, 2017 4:36 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type
> VIFHostDevice
> 
> Hi,
> I am experimenting with the os-vif library and stumbled upon this new
> VIF type called VIFHostDevice. I have few general queries. TIA.
> 
> 1. How do I create ports with VIF_type as VIFHostDevice? Looking for
> the CLI command options.
> 
> 
> 2. Say, I have OVS running completely on x86 host(no datapath or flow
> offload to
>  NIC) as the networking mechanism and a SRIOV capable NIC(for existence
> of VF representors that will be added to the OVS bridge). Can I still
> launch instances with VIF_type as VIFHostDevice?
> 
> 
> 3. I want to use Security Groups using OVS+Conntrack as the mechanism.
> Can I apply SG rules on the ports of type VIFHostDevice using the above
> mechanism?
> 
> PS: I am still trying to understand this. Hence, I might get my
> premises wrong in the above questions. Will appreciate a detailed
> explanation.
> 
> Regards,
> Pranab
> 
> ___
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> .openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev=02%7C01%7Cmoshele%40mellanox.com%7C0af8192c256c42f1252308d4df2
> b96b4%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636378825693889082
> data=iNi%2FLHV5LkTKs8sSpS4BgHU6lwaoywo6O%2BNcF3hqtms%3D=0
> ___
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type VIFHostDevice

[Mooney, Sean K]

> -Original Message-
> From: pranab boruah [mailto:pranabjyotibor...@gmail.com]
> Sent: Wednesday, August 9, 2017 2:36 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type
> VIFHostDevice
> 
> Hi,
> I am experimenting with the os-vif library and stumbled upon this new
> VIF type called VIFHostDevice. I have few general queries. TIA.
> 
> 1. How do I create ports with VIF_type as VIFHostDevice? Looking for
> the CLI command options.
[Mooney, Sean K] hi os-vif vif objects such as VIFHostDevice have no direct 
correlation
With the neutron port binding extention vif_type or vnic_type. That is to say 
you
Cannot direcly request VIFHostDevice via the cli by seting a vif_type or 
vnic_type.
The vif object in os vif are datastuctures that encapluate the common datamodel 
that
Descibse a specific network interface type. In the case of VIFHostDevice this 
corresponds
To a sriov VF. This is then paird with a os-vif plugin which encapsulates the 
port binding logic
For plugging these abstract vif into that specific network backend. This is 
combined with an
Os vif port profile object which transports any backend specific info that 
cannot be generically included
Int the os vif vif object. For example vf representor netdev address or a 
vSwitches bridge name. 

> 
> 
> 2. Say, I have OVS running completely on x86 host(no datapath or flow
> offload to
>  NIC) as the networking mechanism and a SRIOV capable NIC(for existence
> of VF representors that will be added to the OVS bridge). Can I still
> launch instances with VIF_type as VIFHostDevice?
[Mooney, Sean K] you can launch an instance with that configuration yes however
You will not have any way to manage that vf via ovs. Libvirt would still
Connect the dataplane to the vm via standard host passthrouhg/sriov howver
Applying action to the representor port attached to the ovs bridge such as
Tagging the interface with a vlan or installing openflow rules to fileter the 
traffic
With the ovs conntrack security group driver would have no effect on dataplane.

> 
> 
> 3. I want to use Security Groups using OVS+Conntrack as the mechanism.
> Can I apply SG rules on the ports of type VIFHostDevice using the above
> mechanism?

[Mooney, Sean K] that should work with a melonox or netroneome smart nic with
A ovs that support the tc flower offload if they have implemented conntrack 
support
But it would not work with a generic nic. That is something that in the future 
we do intend
To support but at present it requires nic support to enable with conntrack. It 
may be possible
To use the learn action openflow security group driver if your nic does not 
support conntrack
For stateless firewalling which is still better then what you have today with 
sriov but the
Bottome line is you need nic support in hardware/firmware and ovs support for 
that nic offload to make this work.

> 
> PS: I am still trying to understand this. Hence, I might get my
> premises wrong in the above questions. Will appreciate a detailed
> explanation.
> 
> Regards,
> Pranab
> 
> ___
> ___
> OpenStack Development Mailing 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] [ara] Best practices on what to return from REST API ?

[David Moreau Simard]

On Wed, Aug 9, 2017 at 10:02 AM, Chris Dent  wrote:
>
> If people remember to actually read this and respond, you'll likely get
> as many different responses to this as there are options.
>

I expected as much but I very much appreciate your reply regardless!
\o/

>
> From there rather than /{collection} for list and
> /{collection}?id={id} for single entity I'd do:
>
> /{collection} # list
> /{collection}?filter=to_smaller_list # e.g. playbook_id
> /{collection}/id  # single entity
>

That makes sense.

>
> In the collection response only include the bare minimum of data, in
> the single entity include:
>
> - whatever is thought of the entity
> - anything that you think of as a child, represent as links
>   elsewhere
> - it is makes sense to have /{collection}/id/{child} and {child} is
>   actually some other /{collection}/id, consider making the child
>   URI a redirect (that is /{collection/id/{child} redirects to
>   /{childtype}/{child id}
> - if a child is actually children then you'll want to adjust the
>   grammar somewhat: /{collection}/id/{child collection}/id
>

I've read about HATEOAS [1] and it's something I will likely implement.
So, if I'm understanding correctly, you would perhaps only include
references to the childs but not their actual data ?

With the concept of HATEOAS, it would go something like:
# Example task
{
"id": 8,
"links": [
{
"href": "/api/v1/tasks/8",
"rel": "self"
}
],
"name": "Ansible >=2.2: include_role tasks",
"playbook_id": 5,
"results": [
{
"href": "/api/v1/results/1", # or /api/v1/tasks/8/results/1
"rel": "1"
},
{
"href": "/api/v1/results/2",
"rel": "2"
},
# ...
]
}

I think that would be manageable and it wasn't something I had considered.

> This provides you with good urls for things, straightforward ways of
> getting at data, and the capacity to spawn off concurrent requests
> in response to an initial query.
>
> This is essentially the same as your option 2, but with more
> structure to the URLs.

Thanks for the input !

[1]: https://spring.io/understanding/HATEOAS

David Moreau Simard
Senior Software Engineer | OpenStack RDO

dmsimard = [irc, github, twitter]

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

Re: [openstack-dev] [docs] importing openstack-manuals questions, looking for strategies

[Sean Dague]

On 08/09/2017 09:53 AM, Doug Hellmann wrote:

> 
> The option discovery stuff in oslo.config works using entry point
> plugins. oslo.vmware doesn't defined any plugins for the oslo.config.opts
> namespace.
> 
> Doug

Some more interacting debugging with Doug, and this is what I discovered.

* oslo.vmware wasn't actually what I wanted, it was nova.conf.vmware
* in order for nova.conf.vmware to be a valid reference it needs an
entry point in setup.cfg -
https://github.com/openstack/nova/blob/338ae5ef97ab7dac0831fe4e641be0d2a838b61c/setup.cfg#L30
* for that entry point to work, nova.conf.vmware needs a list_opts
function. Which we have, but it does not provide the expected format for
the importer

The net of it is that we can't use this method without changes in the
nova tree that are probably not worth it during the freeze period
(especially as a lot of this imported documentation is going to need
some heavy pruning / editing next cycle to get into shape).

For now it's just a copy and paste of the old opts.

-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] [acceleration]Cyborg Team Weekly Meeting 2017.08.09

[Zhipeng Huang]

Hi Team,

As usual we will have our team weekly meeting today at #openstack-cyborg
starting UTC 1500, agenda could be found here :

https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda_for_next_meeting

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

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

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

[Zhipeng Huang]

Hi Harm,

Thanks for your kind words :) Will try to do my best

On Wed, Aug 9, 2017 at 1:02 AM, Harm Sluiman  wrote:

> Howard, I guess you will need some +1 votes and I certainly support you
> based on our joint early work on these projects.
> I regret not having time to participate actively this year. However your
> contribution has been great for the project and the OpenStack community
>
> On Thu, Aug 3, 2017 at 3:55 AM, Zhipeng Huang 
> wrote:
>
>> Yes tony I was intended to refer to the official procedure for the
>> self-nomination period, which would be 5 buiz days.
>>
>> Thx for the offer to help with the civs poll :)
>>
>> On Thu, Aug 3, 2017 at 3:11 PM, Tony Breeds 
>> wrote:
>>
>>> On Thu, Aug 03, 2017 at 11:59:55AM +0800, Zhipeng Huang wrote:
>>> > Hi Team,
>>> >
>>> > Even though Cyborg is not an official project yet, however with an
>>> ultimate
>>> > goal of becoming one it is necessary to conduct our project governance
>>> with
>>> > compliance of OpenStack community general requirements/culture.
>>>
>>> You didn't specify how long the self-nomination period is.  I assume
>>> you're going for 5 business days?
>>>
>>> So any self nominations need to be in within a week from now
>>>
>>> Yours Tony.
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Zhipeng (Howard) Huang
>>
>> Standard Engineer
>> IT Standard & Patent/IT Product Line
>> Huawei Technologies Co,. Ltd
>> Email: huangzhip...@huawei.com
>> Office: Huawei Industrial Base, Longgang, Shenzhen
>>
>> (Previous)
>> Research Assistant
>> Mobile Ad-Hoc Network Lab, Calit2
>> University of California, Irvine
>> Email: zhipe...@uci.edu
>> Office: Calit2 Building Room 2402
>>
>> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> 宋慢
> Harm Sluiman
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

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

Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type VIFHostDevice

[Moshe Levi]

Hi, 

1) you should use neutron port with vnic_type direct
2) yes,  just use neutron port with vnic_type  direct and confighure the nova 
compute with pci passthogth whitelist 
3) you can configure firewall_driver = openvswitch to work with Conntrack.

So in your case if have SR-IOV nic which doesn't support  hardware offload (but 
has VF representors port)  you will just fallback to the ovs kernel datapath.  
The ovs 2.8.0 code try to offload each datapath rule to NIC hardware if it 
failed it fails back to the ovs kernel datapath.
So if have NIC that can offload classification  on vlan  and action output. 
Only datapath flows that constructed for this classification and action  will 
be offload to hardware.

-Original Meyssage-
From: pranab boruah [mailto:pranabjyotibor...@gmail.com] 
Sent: Wednesday, August 9, 2017 4:36 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type 
VIFHostDevice

Hi,
I am experimenting with the os-vif library and stumbled upon this new VIF type 
called VIFHostDevice. I have few general queries. TIA.

1. How do I create ports with VIF_type as VIFHostDevice? Looking for the CLI 
command options.


2. Say, I have OVS running completely on x86 host(no datapath or flow offload to
 NIC) as the networking mechanism and a SRIOV capable NIC(for existence of VF 
representors that will be added to the OVS bridge). Can I still launch 
instances with VIF_type as VIFHostDevice?


3. I want to use Security Groups using OVS+Conntrack as the mechanism.
Can I apply SG rules on the ports of type VIFHostDevice using the above 
mechanism?

PS: I am still trying to understand this. Hence, I might get my premises wrong 
in the above questions. Will appreciate a detailed explanation.

Regards,
Pranab

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-dev=02%7C01%7Cmoshele%40mellanox.com%7C0af8192c256c42f1252308d4df2b96b4%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636378825693889082=iNi%2FLHV5LkTKs8sSpS4BgHU6lwaoywo6O%2BNcF3hqtms%3D=0
__
OpenStack Development Mailing 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][infra] Functional job failure rate at 100%

[Daniel Alvarez Sanchez]

Some more info added to Jakub's excellent report :)


New kernel Ubuntu-4.4.0-89.112HEADUbuntu-4.4.0-89.112master was
tagged 9 days ago (07/31/2017) [0].

>From a quick look, the only commit around this function is [1].

[0]
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=64de31ed97a03ec1b86fd4f76e445506dce55b02
[1]
http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=2ad4caea651e1cc0fc86111ece9f9d74de825b78

On Wed, Aug 9, 2017 at 3:29 PM, Jakub Libosvar  wrote:

> Daniel Alvarez and I spent some time looking at it and the culprit was
> finally found.
>
> tl;dr
>
> We updated a kernel on machines to one containing bug when creating
> conntrack entries which makes functional tests stuck. More info at [4].
>
> For now, I sent a patch [5] to disable for now jobs that create
> conntrack entries manually, it needs update of commit message. Once it
> merges, we an enable back functional job to voting to avoid regressions.
>
> Is it possible to switch used image for jenkins machines to use back the
> older version? Any other ideas how to deal with the kernel bug?
>
> Thanks
> Jakub
>
> [5] https://review.openstack.org/#/c/492068/1
>
> On 07/08/2017 11:52, Jakub Libosvar wrote:
> > Hi all,
> >
> > as per grafana [1] the functional job is broken. Looking at logstash [2]
> > it started happening consistently since 2017-08-03 16:27. I didn't find
> > any particular patch in Neutron that could cause it.
> >
> > The culprit is that ovsdb starts misbehaving [3] and then we retry calls
> > indefinitely. We still use 2.5.2 openvswitch as we had before. I opened
> > a bug [4] and started investigation, I'll update my findings there.
> >
> > I think at this point there is no reason to run "recheck" on your
> patches.
> >
> > Thanks,
> > Jakub
> >
> > [1]
> > http://grafana.openstack.org/dashboard/db/neutron-failure-
> rate?panelId=7
> > [2] http://bit.ly/2vdKMwy
> > [3]
> > http://logs.openstack.org/14/488914/8/check/gate-neutron-
> dsvm-functional-ubuntu-xenial/75d7482/logs/openvswitch/ovsdb-server.txt.gz
> > [4] https://bugs.launchpad.net/neutron/+bug/1709032
> >
>
>
> __
> OpenStack Development Mailing 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] [congress] congress-dashboard 1.0.0.0rc1 (pike)

[no-reply]

Hello everyone,

A new release candidate for congress-dashboard for the end of the Pike
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/congress-dashboard/

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

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


http://git.openstack.org/cgit/openstack/congress-dashboard/log/?h=stable/pike

Release notes for congress-dashboard can be found at:

http://docs.openstack.org/releasenotes/congress-dashboard/

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

https://bugs.launchpad.net/congress

and tag it *pike-rc-potential* to bring it to the congress-dashboard
release crew's attention.


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

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

[Chris Dent]

On Wed, 9 Aug 2017, David Moreau Simard wrote:


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


If people remember to actually read this and respond, you'll likely get
as many different responses to this as there are options.

Alot of it is preference, but you've mentioned that you are trying
to optimize for scale and concurrency so I think there are some things
you can do to maintain a reasonable grammar, hew to standards (both
real and the dreaded "best practice"), keep things simple, and be
fast (in aggregate). You've overcome the most important hurdle
already by enumerating your resources (as nouns):


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



From there rather than /{collection} for list and

/{collection}?id={id} for single entity I'd do:

/{collection} # list
/{collection}?filter=to_smaller_list # e.g. playbook_id
/{collection}/id  # single entity

In the collection response only include the bare minimum of data, in
the single entity include:

- whatever is thought of the entity
- anything that you think of as a child, represent as links
  elsewhere
- it is makes sense to have /{collection}/id/{child} and {child} is
  actually some other /{collection}/id, consider making the child
  URI a redirect (that is /{collection/id/{child} redirects to
  /{childtype}/{child id}
- if a child is actually children then you'll want to adjust the
  grammar somewhat: /{collection}/id/{child collection}/id

This provides you with good urls for things, straightforward ways of
getting at data, and the capacity to spawn off concurrent requests
in response to an initial query.

This is essentially the same as your option 2, but with more
structure to the URLs.


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

Re: [openstack-dev] [docs] importing openstack-manuals questions, looking for strategies

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-08-09 09:39:55 -0400:
> On 08/09/2017 09:24 AM, Sean Dague wrote:
> > On 08/09/2017 09:19 AM, Doug Hellmann wrote:
> >> Excerpts from Sean Dague's message of 2017-08-08 17:01:29 -0400:
> >>> When trying to import
> >>> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/compute/hypervisor-vmware.rst#L2
> >>> into the Nova admin config reference
> >>> (https://review.openstack.org/#/c/491853), a couple of interesting
> >>> challenges popped up. These pop up in a couple of other places, but this
> >>> one file nicely contains both of them.
> >>>
> >>> The first is the common autogenerated files (like
> >>> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/tables/nova-vmware.rst#L11).
> >>> To the best of my knowledge we don't have that autogeneration tooling in
> >>> the projects. Should we just be copy/pasting this content in? Is there
> >>> another better strategy there?
> >>
> >> oslo.config does have an extension for generating a table-format
> >> list of all of the configuration options, and the idea is to replace
> >> those included tables with the 'show-options' directive. It uses
> >> the same inputs as the sample file generator. See
> >> https://docs.openstack.org/oslo.config/latest/reference/sphinxext.html for
> >> details
> > 
> > So in this case we could:
> > 
> > .. show-options::
> > 
> >oslo.vmware
> > 
> > 
> > And that would have the same impact?
> 
> I'm attempting to do this, and just getting:
> 
> Warning, treated as error:
> Could not load oslo.vmware
> 
> 
> .tox/docs/bin/pip freeze
> 
> shows that oslo.vmware is installed the tox env. Any ideas what I'm
> doing incorrectly?
> 
> -Sean
> 

The option discovery stuff in oslo.config works using entry point
plugins. oslo.vmware doesn't defined any plugins for the oslo.config.opts
namespace.

Doug

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

Re: [openstack-dev] [docs] importing openstack-manuals questions, looking for strategies

[Sean Dague]

On 08/09/2017 09:24 AM, Sean Dague wrote:
> On 08/09/2017 09:19 AM, Doug Hellmann wrote:
>> Excerpts from Sean Dague's message of 2017-08-08 17:01:29 -0400:
>>> When trying to import
>>> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/compute/hypervisor-vmware.rst#L2
>>> into the Nova admin config reference
>>> (https://review.openstack.org/#/c/491853), a couple of interesting
>>> challenges popped up. These pop up in a couple of other places, but this
>>> one file nicely contains both of them.
>>>
>>> The first is the common autogenerated files (like
>>> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/tables/nova-vmware.rst#L11).
>>> To the best of my knowledge we don't have that autogeneration tooling in
>>> the projects. Should we just be copy/pasting this content in? Is there
>>> another better strategy there?
>>
>> oslo.config does have an extension for generating a table-format
>> list of all of the configuration options, and the idea is to replace
>> those included tables with the 'show-options' directive. It uses
>> the same inputs as the sample file generator. See
>> https://docs.openstack.org/oslo.config/latest/reference/sphinxext.html for
>> details
> 
> So in this case we could:
> 
> .. show-options::
> 
>oslo.vmware
> 
> 
> And that would have the same impact?

I'm attempting to do this, and just getting:

Warning, treated as error:
Could not load oslo.vmware


.tox/docs/bin/pip freeze

shows that oslo.vmware is installed the tox env. Any ideas what I'm
doing incorrectly?

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [docs] importing openstack-manuals questions, looking for strategies

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-08-09 09:24:07 -0400:
> On 08/09/2017 09:19 AM, Doug Hellmann wrote:
> > Excerpts from Sean Dague's message of 2017-08-08 17:01:29 -0400:
> >> When trying to import
> >> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/compute/hypervisor-vmware.rst#L2
> >> into the Nova admin config reference
> >> (https://review.openstack.org/#/c/491853), a couple of interesting
> >> challenges popped up. These pop up in a couple of other places, but this
> >> one file nicely contains both of them.
> >>
> >> The first is the common autogenerated files (like
> >> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/tables/nova-vmware.rst#L11).
> >> To the best of my knowledge we don't have that autogeneration tooling in
> >> the projects. Should we just be copy/pasting this content in? Is there
> >> another better strategy there?
> > 
> > oslo.config does have an extension for generating a table-format
> > list of all of the configuration options, and the idea is to replace
> > those included tables with the 'show-options' directive. It uses
> > the same inputs as the sample file generator. See
> > https://docs.openstack.org/oslo.config/latest/reference/sphinxext.html for
> > details
> 
> So in this case we could:
> 
> .. show-options::
> 
>oslo.vmware
> 
> 
> And that would have the same impact?
> 
> -Sean

The option namespaces are based on plugins, not python packages.
We do often name them the same for easy reference, but some packages
use multiple plugins tied to different list_opts functions. I'm not
sure where those options are defined.

The oslo.vmware library doesn't seem to export any plugins for the
config generator, probably because it doesn't use oslo.config at
all.

I see some configuration options defined in the os-win library, but
I don't know if those match the table you're referring to. That
library does not export an entry point for discovering the options,
so unfortunately it won't work with the config generator or sphinx
extension. If the options you're looking for are in that library, for
Pike you'll need to import the static table.

Doug

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

[openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type VIFHostDevice

[pranab boruah]

Hi,
I am experimenting with the os-vif library and stumbled upon this new
VIF type called VIFHostDevice. I have few general queries. TIA.

1. How do I create ports with VIF_type as VIFHostDevice? Looking for
the CLI command options.


2. Say, I have OVS running completely on x86 host(no datapath or flow offload to
 NIC) as the networking mechanism and a SRIOV capable NIC(for existence of
VF representors that will be added to the OVS bridge). Can I still
launch instances with VIF_type as VIFHostDevice?


3. I want to use Security Groups using OVS+Conntrack as the mechanism.
Can I apply SG rules on the ports of type VIFHostDevice using the
above mechanism?

PS: I am still trying to understand this. Hence, I might get my
premises wrong in the above questions. Will appreciate a detailed
explanation.

Regards,
Pranab

__
OpenStack Development Mailing 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][infra]Plan to support Python 3.6 ?

[Doug Hellmann]

Excerpts from ChangBo Guo's message of 2017-08-09 21:25:07 +0800:
> We received Python 3.6 related Bug recently [1][2]. That let me think
> what's the plan to support Python 3.6 for OpenStack in the future.   Python
> 3.6 was released on December 23, 2016, has some different behaviors from
> Python 3.5[3]. talked with cdent in the IRC, would like to discuss this
> through mailing list , and suggest a discussion at the PTG[3]

One of the reasons we were able to move ahead with 3.5 was that it would
be available on the platforms for which we test deployments, as defined
in the CTI [5]. Are Ubuntu LTS and CentOS shipping Python 3.6?

[5] https://governance.openstack.org/tc/reference/project-testing-interface.html

> 
> 1. what's the time to support Python 3.6 ?
> 
> 2. what 's the  plan or process ?
>  Maybe we can do that we support python 3
>  1) setup python 3.6 non-voting CI jobs
>  2) Fix related issues about Python 3.6
>  3) enable pyhton 3.6 jobs voting
> 
> [1] https://bugs.launchpad.net/oslo.rootwrap/+bug/1709505
> [2]https://bugs.launchpad.net/pbr/+bug/1690103
> [3]https://docs.python.org/3/whatsnew/3.6.html
> [4] https://etherpad.openstack.org/p/infra-ptg-queens

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

Re: [openstack-dev] [neutron][infra] Functional job failure rate at 100%

[Jakub Libosvar]

Daniel Alvarez and I spent some time looking at it and the culprit was
finally found.

tl;dr

We updated a kernel on machines to one containing bug when creating
conntrack entries which makes functional tests stuck. More info at [4].

For now, I sent a patch [5] to disable for now jobs that create
conntrack entries manually, it needs update of commit message. Once it
merges, we an enable back functional job to voting to avoid regressions.

Is it possible to switch used image for jenkins machines to use back the
older version? Any other ideas how to deal with the kernel bug?

Thanks
Jakub

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

On 07/08/2017 11:52, Jakub Libosvar wrote:
> Hi all,
> 
> as per grafana [1] the functional job is broken. Looking at logstash [2]
> it started happening consistently since 2017-08-03 16:27. I didn't find
> any particular patch in Neutron that could cause it.
> 
> The culprit is that ovsdb starts misbehaving [3] and then we retry calls
> indefinitely. We still use 2.5.2 openvswitch as we had before. I opened
> a bug [4] and started investigation, I'll update my findings there.
> 
> I think at this point there is no reason to run "recheck" on your patches.
> 
> Thanks,
> Jakub
> 
> [1]
> http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=7
> [2] http://bit.ly/2vdKMwy
> [3]
> http://logs.openstack.org/14/488914/8/check/gate-neutron-dsvm-functional-ubuntu-xenial/75d7482/logs/openvswitch/ovsdb-server.txt.gz
> [4] https://bugs.launchpad.net/neutron/+bug/1709032
> 


__
OpenStack Development Mailing 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][infra]Plan to support Python 3.6 ?

[ChangBo Guo]

We received Python 3.6 related Bug recently [1][2]. That let me think
what's the plan to support Python 3.6 for OpenStack in the future.   Python
3.6 was released on December 23, 2016, has some different behaviors from
Python 3.5[3]. talked with cdent in the IRC, would like to discuss this
through mailing list , and suggest a discussion at the PTG[3]

1. what's the time to support Python 3.6 ?

2. what 's the  plan or process ?
 Maybe we can do that we support python 3
 1) setup python 3.6 non-voting CI jobs
 2) Fix related issues about Python 3.6
 3) enable pyhton 3.6 jobs voting

[1] https://bugs.launchpad.net/oslo.rootwrap/+bug/1709505
[2]https://bugs.launchpad.net/pbr/+bug/1690103
[3]https://docs.python.org/3/whatsnew/3.6.html
[4] https://etherpad.openstack.org/p/infra-ptg-queens
-- 
ChangBo Guo(gcb)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] importing openstack-manuals questions, looking for strategies

[Sean Dague]

On 08/09/2017 09:19 AM, Doug Hellmann wrote:
> Excerpts from Sean Dague's message of 2017-08-08 17:01:29 -0400:
>> When trying to import
>> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/compute/hypervisor-vmware.rst#L2
>> into the Nova admin config reference
>> (https://review.openstack.org/#/c/491853), a couple of interesting
>> challenges popped up. These pop up in a couple of other places, but this
>> one file nicely contains both of them.
>>
>> The first is the common autogenerated files (like
>> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/tables/nova-vmware.rst#L11).
>> To the best of my knowledge we don't have that autogeneration tooling in
>> the projects. Should we just be copy/pasting this content in? Is there
>> another better strategy there?
> 
> oslo.config does have an extension for generating a table-format
> list of all of the configuration options, and the idea is to replace
> those included tables with the 'show-options' directive. It uses
> the same inputs as the sample file generator. See
> https://docs.openstack.org/oslo.config/latest/reference/sphinxext.html for
> details

So in this case we could:

.. show-options::

   oslo.vmware


And that would have the same impact?

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [docs] importing openstack-manuals questions, looking for strategies

[Doug Hellmann]

Excerpts from Sean Dague's message of 2017-08-08 17:01:29 -0400:
> When trying to import
> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/compute/hypervisor-vmware.rst#L2
> into the Nova admin config reference
> (https://review.openstack.org/#/c/491853), a couple of interesting
> challenges popped up. These pop up in a couple of other places, but this
> one file nicely contains both of them.
> 
> The first is the common autogenerated files (like
> https://github.com/openstack/openstack-manuals/blob/6f9fc171800e8a435011f38cd4558e900884ce86/doc/config-reference/source/tables/nova-vmware.rst#L11).
> To the best of my knowledge we don't have that autogeneration tooling in
> the projects. Should we just be copy/pasting this content in? Is there
> another better strategy there?

oslo.config does have an extension for generating a table-format
list of all of the configuration options, and the idea is to replace
those included tables with the 'show-options' directive. It uses
the same inputs as the sample file generator. See
https://docs.openstack.org/oslo.config/latest/reference/sphinxext.html for
details

The "filtering" ability is limited right now to namespaces. You may not
be able to reproduce exactly the tables that were used in earlier
releases. We've asked for feedback about other capabilities that teams
want for building tables containing subsets of the input options, and if
we find contributors to build those features we can add them for Queens.

In the mean time, if the output doesn't meet your needs, you can
copy in the tables from the old guide. They aren't up to date, so
you may want to look at the tool for generating the tables in the
openstack-doc-tools repo.

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

jungleboyj is working on the cinder docs, so he may have some idea of
when those are expected to land. In the mean time, a TODO with a link to
some page in the cinder docs seems like a good temporary measure.

> 
> If anyone has thoughts on the best resolutions here, that would be great.
> 
> -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

Re: [openstack-dev] [neutron] possible race condition with nova instance and neutron ports

[Sławomir Kapłoński]

With such settings nova is not waiting for info from neutron and that is why 
Your instances starting without network ready.
If You will change this timeout to some value higher than 0 then instance will 
be paused and nova will wait for info from neutron that port is active (You 
should also check credentials config in neutron server)
If You will set also vif_plugging_is_fatal=True then nova will put instance in 
ERROR state if port will not be active after timeout time.

-- 
Slawek

> Wiadomość napisana przez Saverio Proto  w dniu 
> 09.08.2017, o godz. 14:24:
> 
> Hello,
> 
> thanks for the tip.
> I checked on a compute node, in the nova.conf file I have the following:
> 
> vif_plugging_is_fatal=False
> vif_plugging_timeout=0
> 
> both options are in the [DEFAULT] section.
> I guess these settings were never changed since we were running Icehouse.
> 
> Should I change to the Ocata default values ? (True and 300)
> 
> I will try that today.
> Thank you
> 
> Saverio
> 
> 
> On 09/08/17 09:23, Sławomir Kapłoński wrote:
>> Hello,
>> 
>> Do You have configured in nova-compute: vif_plugging_timeout and 
>> vif_plugging_is_fatal options?
>> With those options nova should pause VM until port will be set to ACTIVE in 
>> Neutron.
>> 
> 
> 
> -- 
> 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] possible race condition with nova instance and neutron ports

[Saverio Proto]

Hello,

thanks for the tip.
I checked on a compute node, in the nova.conf file I have the following:

vif_plugging_is_fatal=False
vif_plugging_timeout=0

both options are in the [DEFAULT] section.
I guess these settings were never changed since we were running Icehouse.

Should I change to the Ocata default values ? (True and 300)

I will try that today.
Thank you

Saverio


On 09/08/17 09:23, Sławomir Kapłoński wrote:
> Hello,
> 
> Do You have configured in nova-compute: vif_plugging_timeout and 
> vif_plugging_is_fatal options?
> With those options nova should pause VM until port will be set to ACTIVE in 
> Neutron.
> 


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

[Emilien Macchi]

On Tue, Aug 8, 2017 at 1:13 PM, Chris Dent  wrote:
[...]

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

I think retrospectives are always useful and we (too) rarely do that
in OpenStack, it would be a great exercise.
If that's something we want to do, I'm happy to pair with someone to
lead a 45min retro maybe.

[...]

Thanks for the report, as usual,
-- 
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] [requirements][masakari] FFE for adding python-masakariclient in global-requirements

[Tony Breeds]

On Wed, Aug 09, 2017 at 06:39:52AM +, Bhor, Dinesh wrote:
> Hello everyone,
> 
> I would like to ask for the FFE for adding "python-masakariclient" in 
> global-requirements.
> 
> Earlier, we were not having "check-requirements" job for masakari-* projects. 
> At that time, we use to manually add "python-masakariclient" as a requirement 
> in masakari-monitors project [1].
> Now we have added "check-requirements" job for masakari-* projects, but we 
> missed to add "python-masakariclient" in global-requirements and now the 
> bigger issue is it is not possible
> to manually update the "python-masakariclient" requirement in 
> masakari-monitors project as the "gate-masakari-monitors-requirements" 
> requirements job keeps failing on the patch [1].
> To resolve this problem permanently, we need to add "python-masakariclient" 
> library requirement in global-requirements.
> I have submitted a patch [2] for adding the python-masakariclient in 
> global-requirements.
> 
> Please consider my request and grant FFE to solve this problem.
> 
> [1] https://review.openstack.org/#/c/457491/
> [2] https://review.openstack.org/#/c/491692/

Are you intending to create a stable/pike branch and perform releases
from it?  Looking at masakari-monitors the whole history can be seen on
one page so it's clearly very new.

Yours Tony.


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

Re: [openstack-dev] [TripleO][Heat] using convergence_engine to deploy overcloud stack

[Sagi Shnaidman]

Hi there

On Wed, Aug 9, 2017 at 1:49 PM, Rabi Mishra  wrote:

> On Wed, Aug 9, 2017 at 1:41 PM, Smigielski, Radoslaw (Nokia - IE) <
> radoslaw.smigiel...@nokia.com> wrote:
>
>> Hi there!
>>
>>I have a question about heat "convergence_engine" option, it's
>> present in heat config since quite a long time but still not enabled.
>>
> Well, convergence is enabled by default in heat since newton. However,
> Tripleo does not use it yet, as convergence engine memory usage is higher
> than that of legacy engine.
>
>
TripleO CI has heat-convergence job running on heat patches in experimental
pipeline [1] It runs there during last year at least.
No any high memory usage was detected in last few months when I watched it.

[1]
https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L10407

Thanks

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

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

[Jason E. Rist]

On 08/09/2017 04:42 AM, Numan Siddique wrote:
> On Wed, Aug 9, 2017 at 8:41 AM, Emilien Macchi  wrote:
>
> > On Tue, Aug 8, 2017 at 7:05 AM, Numan Siddique 
> > wrote:
> >> I would like to request FFE exception for OVN containerized support. OVN
> > is
> >> an optional feature and should be a low risk.
> >>
> >> The patches can be found here -
> >> https://review.openstack.org/#/q/topic:bug/1699085
> >
> > I checked all the patches and indeed they aren't intrusive enough to
> > break anything. I think this is fine.
> > Give us a bonus and bring-up scenario007 working on containers (
> > https://review.openstack.org/#/c/490622 ) - it would be *awesome* :-)
> >
> >
> Thank you Emilien, that's the goal :)
>
>
>
> > Anyway, +1 on my side for this code to land in Pike. Any feedback from
> > the team is welcome though.
> > --
> > Emilien Macchi
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
+1 this would be nice to have.

__
OpenStack Development Mailing 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][Heat] using convergence_engine to deploy overcloud stack

[Rabi Mishra]

On Wed, Aug 9, 2017 at 1:41 PM, Smigielski, Radoslaw (Nokia - IE) <
radoslaw.smigiel...@nokia.com> wrote:

> Hi there!
>
>I have a question about heat "convergence_engine" option, it's present
> in heat config since quite a long time but still not enabled.
>
Well, convergence is enabled by default in heat since newton. However,
Tripleo does not use it yet, as convergence engine memory usage is higher
than that of legacy engine.

There has been number of optimizations in the last two cycles to improve
that situation. However, AFAIK, when using a single node undercloud, memory
usage would always be more with convergence.

I think there are plans for Tripleo to move to convergence in Queens as
discussed in this ML thread.

http://lists.openstack.org/pipermail/openstack-dev/2017-June/118237.html

And I am wondering if anyone has tried enabled it and deploy overcloud? I
> did it myself and it seems to be working.
>
> The main reason why I am looking at this options are problems with scaling
> out, adding computes, replacing failed controllers on setups with 50+
> computes and number of nested stack 1000+.
>

You've to probably scale out undercloud heat to get most of the benefits of
convergence that comes with the distributed architecture.

> Is there any reason what holds Heat switch to convergence architecture?
>
>
> _
> *Radosław Śmigielski*
> Nokia CBIS R
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Rabi Misra
__
OpenStack Development Mailing 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] [tacker] Self-nomination for PTL in Queens

[Eduardo Gonzalez]

Hi Yong,

Kolla already deploy tacker since ocata :)

Regards

On Wed, Aug 9, 2017, 7:30 AM gongys2017  wrote:

> Hi everyone,
>
> This is my self-nomination to continue running as Takcer PTL for the
> Queens cycle.
>
> In Pike cycle, tacker team is focusing on stablebility and scaling. We have
> introtroduced Barbican to keep VIM credentials and Mistral to do VIM
> monitoring and policies. These are great steps to let Tacker to be stable
> and scalable. In addition, the team has been active in promoting tacker.
> We have joined OPNFV meeting, OpenStack days China and OpenStack
> design summit in Boston.  There are some topic sessions which are
> proposed to Syndey Summit by team.
>
> In Queen cycle, I plan to
>
> - Continue to stablize tacker and make it of production quality.
> - Complete tacker document.
> - Provide kolla way to install tacker. I think tacker will be installed in
> kolla which put
>   tacker in containers. The container way will make tacker easier to use,
>   help many guys to use tacker in short way, compared to devstack
> installation.
> - introduce more kinds of VIMs
> - Promote tacker into other community.
>
> Lets make tacker roll together.
>
> Thanks for your consideration.
>
> --
>
> Thanks,
>
> yong sheng gong
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Numan Siddique]

On Wed, Aug 9, 2017 at 8:41 AM, Emilien Macchi  wrote:

> On Tue, Aug 8, 2017 at 7:05 AM, Numan Siddique 
> wrote:
> > I would like to request FFE exception for OVN containerized support. OVN
> is
> > an optional feature and should be a low risk.
> >
> > The patches can be found here -
> > https://review.openstack.org/#/q/topic:bug/1699085
>
> I checked all the patches and indeed they aren't intrusive enough to
> break anything. I think this is fine.
> Give us a bonus and bring-up scenario007 working on containers (
> https://review.openstack.org/#/c/490622 ) - it would be *awesome* :-)
>
>
Thank you Emilien, that's the goal :)



> Anyway, +1 on my side for this code to land in Pike. Any feedback from
> the team is welcome though.
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Davanum Srinivas]

Morgan,

Awesome! when there's some momentum, we can move it to a public repo

-- Dims

On Wed, Aug 9, 2017 at 12:26 AM, Morgan Fainberg
 wrote:
> I shall take a look at the webhooks and see if I can help on this front.
>
> --Morgan
>
> On Tue, Aug 8, 2017 at 6:34 PM, joehuang  wrote:
>> Dims,
>>
>> Integration of keystone and kubernetes is very cool and in high demand. 
>> Thank you very much.
>>
>> Best Regards
>> Chaoyi Huang (joehuang)
>>
>> 
>> From: Davanum Srinivas [dava...@gmail.com]
>> Sent: 01 August 2017 18:03
>> To: kubernetes-sig-openst...@googlegroups.com; OpenStack Development Mailing 
>> List (not for usage questions)
>> Subject: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone 
>> based Authentication and Authorization for Kubernetes
>>
>> Team,
>>
>> Having waded through the last 4 attempts as seen in kubernetes PR(s)
>> and Issues and talked to a few people on SIG-OpenStack slack channel,
>> the consensus was that we should use the Webhook mechanism to
>> integrate Keystone and Kubernetes.
>>
>> Here's the experiment : https://github.com/dims/k8s-keystone-auth
>>
>> Anyone interested in working on / helping with this? Do we want to
>> create a repo somewhere official?
>>
>> Thanks,
>> Dims
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> You received this message because you are subscribed to the Google Groups 
> "kubernetes-sig-openstack" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to kubernetes-sig-openstack+unsubscr...@googlegroups.com.
> To post to this group, send email to 
> kubernetes-sig-openst...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/kubernetes-sig-openstack/CAGnj6au7sxEssRVEf8d6Ha8ZKHk5sD5-Xayn%2BoV%2B5%3DcuHW4sDQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
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] [keystone][kubernetes] Webhook PoC for Keystone based Authentication and Authorization for Kubernetes

[Davanum Srinivas]

Joe,

If you see the code in the git repo, you will see that we do use
"Authorizer interface", so it is possible use the same code as a
custom module. Guess you are thinking about a downstream kubernetes
distro.

Thanks,
Dims

On Wed, Aug 9, 2017 at 1:21 AM, joehuang  wrote:
> Except webhook, how about custom module(call keystone API directly from 
> custom module) for authorization? ( 
> https://kubernetes.io/docs/admin/authorization/#custom-modules )
>
> Webhook:
> Pros.: http calling, loose coupling, more flexible configuration.
> Cons.: Degraded performance, one more hop
> custom module:
> Pros.: direct function call, better performance, less process to 
> maintain.
> Cons.: coupling, built-in module.
>
> Best Regards
> Chaoyi Huang (joehuang)
>
> 
> From: Morgan Fainberg [morgan.fainb...@gmail.com]
> Sent: 09 August 2017 12:26
> To: OpenStack Development Mailing List (not for usage questions)
> Cc: kubernetes-sig-openst...@googlegroups.com
> Subject: Re: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone 
> based Authentication and Authorization for Kubernetes
>
> I shall take a look at the webhooks and see if I can help on this front.
>
> --Morgan
>
> On Tue, Aug 8, 2017 at 6:34 PM, joehuang  wrote:
>> Dims,
>>
>> Integration of keystone and kubernetes is very cool and in high demand. 
>> Thank you very much.
>>
>> Best Regards
>> Chaoyi Huang (joehuang)
>>
>> 
>> From: Davanum Srinivas [dava...@gmail.com]
>> Sent: 01 August 2017 18:03
>> To: kubernetes-sig-openst...@googlegroups.com; OpenStack Development Mailing 
>> List (not for usage questions)
>> Subject: [openstack-dev] [keystone][kubernetes] Webhook PoC for Keystone 
>> based Authentication and Authorization for Kubernetes
>>
>> Team,
>>
>> Having waded through the last 4 attempts as seen in kubernetes PR(s)
>> and Issues and talked to a few people on SIG-OpenStack slack channel,
>> the consensus was that we should use the Webhook mechanism to
>> integrate Keystone and Kubernetes.
>>
>> Here's the experiment : https://github.com/dims/k8s-keystone-auth
>>
>> Anyone interested in working on / helping with this? Do we want to
>> create a repo somewhere official?
>>
>> Thanks,
>> Dims
>>
>> --
>> Davanum Srinivas :: https://twitter.com/dims
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
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] [Openstack][horizon][ceilometer][gnocchi]Viewing gnocchi statistics on Dashboard

[Rob Cresswell (rcresswe)]

We removed the old Ceilometer content in Horizon a while ago; since then, 
nobody has worked on a new plugin to my knowledge.

Rob

> On 8 Aug 2017, at 15:15, gordon chung  wrote:
> 
> 
> 
> On 08/08/17 02:17 AM, pearl.dsil...@wipro.com wrote:
>> I would like to know if there exists support to view the statistics
>> fetched by gnocchi on Horizon(dashboard). If so, please let me know how
>> to configure it in Newton release.
> 
> i don't know if there's plans for this in Horizon. this definitely does 
> not exist in Newton.
> 
> Gnocchi does have visualisation functionality provided by Grafana:
> http://gnocchi.xyz/grafana.html
> 
> cheers,
> -- 
> gord
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[witold.be...@est.fujitsu.com]

Hello everyone,

I would like to propose my candidacy for the role of Monasca PTL for Queens
release.

I would like to thank Roland, who has been the PTL for several releases now and
has always pushed the project forward. Your working quota seems to be unlimited,
I reckon you work at sleep as well :) I'm sure that anyone who wants to lead
Monasca will need your support and expertise. Thanks for your commitment.

To my person, I have worked for the project as core member for two years now and
acted as Release Management Liason in Ocata and Pike cycles. I have participated
in my first OpenStack Summit in Tokyo where I forgot the password to the demo
machine during the presentation. Then followed Austin, Barcelona and Boston with
presentations, design sessions, workshops and mid-cycle meetings. During this
time I have met tremendous people, learnt a great deal about Monasca and
OpenStack and had many sleepless nights :)

As PTL, in the next release I would like to focus on following topics:

* easy deployment of Monasca using Docker and Kubernetes
* improve documentation
* search for new scalable time-series database
* strengthen the community and improve active participation and contribution
* metrics aggregation
* alarms correlation
* events processing

I hope to get the support of the entire team and good cooperation in Queens
cycle.


Best greetings

Witek

__
OpenStack Development Mailing 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] 答复: [Mogan] Queens PTL candidacy

[Tao Li]

+1 ,  Zhenguo is a good PTL and will lead mogan to go to  moon.

 

发件人: openstack-dev-boun...@lists.openstack.org 
[mailto:openstack-dev-boun...@lists.openstack.org] 代表 Zhenguo Niu
发送时间: 2017年8月3日 20:17
收件人: OpenStack Development Mailing List 
主题: [openstack-dev] [Mogan] Queens PTL candidacy

 

Hi all,

 

I would like to announce my candidacy for the Mogan PTL for the Queens cycle. 
Although Mogan is not an official project yet, we seek to complete the PTL 
election with everyone’s consensus like others.

 

I have been the elected PTL since Mogan was an idea. I think that Mogan serves 
an important role in current OpenStack ecosystem and solve problems that many 
users are facing. Mogan is relatively new project but I am proud to say that we 
already have a diverse community and feel that we operate openly and advancing 
in the right direction.

 

If I’m getting an opportunity to continue serving the team for the Queens 
cycle, I’d strive to work with the team on the following items:

 

- Support RAID at deploy time

- Boot from volume and Migrate/Resize support for such diskless servers

- Change to use nested resources model for bare metals in placement to track 
NICs and DISKs as well.

- Improve bare metal node aggregates support by leveraging Placement service

- Add more policies for bare metal server groups

- Valence integration to support composing hardware

 

We will follow the official procedure. Any self nominations need be in within a 
week from now. If there are more than one candidate we will create a poll on  
 http://civs.cs.cornell.edu/ .



-- 

Best Regards,

Zhenguo Niu

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

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

[hao wang]

+1, very happy to work together with Zhenguo, I'm sure he will be a
great PTL in Mogan.

2017-08-09 16:33 GMT+08:00 Sheng Liu :
> +1,
>
> Zhenguo has done great work for Mogan in the past year, and he is already
> running as a competent PTL!
>
> 2017-08-03 20:17 GMT+08:00 Zhenguo Niu :
>>
>> Hi all,
>>
>> I would like to announce my candidacy for the Mogan PTL for the Queens
>> cycle. Although Mogan is not an official project yet, we seek to complete
>> the PTL election with everyone’s consensus like others.
>>
>>
>>
>> I have been the elected PTL since Mogan was an idea. I think that Mogan
>> serves an important role in current OpenStack ecosystem and solve problems
>> that many users are facing. Mogan is relatively new project but I am proud
>> to say that we already have a diverse community and feel that we operate
>> openly and advancing in the right direction.
>>
>>
>>
>> If I’m getting an opportunity to continue serving the team for the Queens
>> cycle, I’d strive to work with the team on the following items:
>>
>>
>>
>> - Support RAID at deploy time
>>
>> - Boot from volume and Migrate/Resize support for such diskless servers
>>
>> - Change to use nested resources model for bare metals in placement to
>> track NICs and DISKs as well.
>>
>> - Improve bare metal node aggregates support by leveraging Placement
>> service
>>
>> - Add more policies for bare metal server groups
>>
>> - Valence integration to support composing hardware
>>
>>
>>
>> We will follow the official procedure. Any self nominations need be in
>> within a week from now. If there are more than one candidate we will create
>> a poll on http://civs.cs.cornell.edu/ .
>>
>>
>>
>> --
>> Best Regards,
>> Zhenguo Niu
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing 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] [charms][ptg] PTG planning pad

[James Page]

Hi All

I've started a planning etherpad for the PTG next month; feel free to add
topics you want to discuss/sprint on during the week.

  https://etherpad.openstack.org/p/ptg-queens-charms

Cheers

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

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

[Sheng Liu]

+1,

Zhenguo has done great work for Mogan in the past year, and he is already
running as a competent PTL!

2017-08-03 20:17 GMT+08:00 Zhenguo Niu :

> Hi all,
>
> I would like to announce my candidacy for the Mogan PTL for the Queens
> cycle. Although Mogan is not an official project yet, we seek to complete
> the PTL election with everyone’s consensus like others.
>
>
>
> I have been the elected PTL since Mogan was an idea. I think that Mogan
> serves an important role in current OpenStack ecosystem and solve problems
> that many users are facing. Mogan is relatively new project but I am proud
> to say that we already have a diverse community and feel that we operate
> openly and advancing in the right direction.
>
>
>
> If I’m getting an opportunity to continue serving the team for the Queens
> cycle, I’d strive to work with the team on the following items:
>
>
>
> - Support RAID at deploy time
>
> - Boot from volume and Migrate/Resize support for such diskless servers
>
> - Change to use nested resources model for bare metals in placement to
> track NICs and DISKs as well.
>
> - Improve bare metal node aggregates support by leveraging Placement
> service
>
> - Add more policies for bare metal server groups
>
> - Valence integration to support composing hardware
>
>
>
> We will follow the official procedure. Any self nominations need be in
> within a week from now. If there are more than one candidate we will create
> a poll on http://civs.cs.cornell.edu/ .
>
>
> --
> Best Regards,
> Zhenguo Niu
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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][masakari] FFE for adding python-masakariclient in global-requirements

[Thierry Carrez]

Bhor, Dinesh wrote:
> I would like to ask for the FFE for adding "*python-masakariclient*" in
> global-requirements.
> 
> Earlier, we were not having "check-requirements" job for masakari-*
> projects. At that time, we use to manually add "*python-masakariclient*"
> as a requirement in *masakari-monitors* project [1].
> 
> Now we have added "*check-requirements*" job for masakari-* projects,
> but we missed to add "python-masakariclient" in global-requirements and
> now the bigger issue is it is not possible
> 
> to *manually update* the "python-masakariclient" requirement in
> masakari-monitors project as the "*gate-masakari-monitors-requirements*"
> requirements job keeps failing on the patch [1].
> 
> To resolve this problem permanently, we need to add
> "python-masakariclient" library requirement in global-requirements.
> 
> I have submitted a patch [2] for adding the python-masakariclient in
> global-requirements.
> 
> Please consider my request and grant FFE to solve this problem.
> 
> [1] https://review.openstack.org/#/c/457491/
> [2] https://review.openstack.org/#/c/491692/

It feels like this could wait until we create a stable/pike branch for
the requirements (which will happen as soon as we have RC1 for all
cycle-with-milestones projects, in theory at the end of this week, in
practice probably early next week).

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [TripleO][Heat] using convergence_engine to deploy overcloud stack

[Smigielski, Radoslaw (Nokia - IE)]

Hi there!

   I have a question about heat "convergence_engine" option, it's present in 
heat config since quite a long time but still not enabled. And I am wondering 
if anyone has tried enabled it and deploy overcloud? I did it myself and it 
seems to be working.

The main reason why I am looking at this options are problems with scaling out, 
adding computes, replacing failed controllers on setups with 50+ computes and 
number of nested stack 1000+.

Is there any reason what holds Heat switch to convergence architecture?


_
Radosław Śmigielski
Nokia CBIS R
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [elections] [watcher] Candidacy for Watcher OpenStack PTL (Queens)

[Alexander Chadin]

Greetings,

I am announcing my candidacy for Queens PTL role of Watcher project. If you
don't know yet, my name is Alexander Chadin, I'm alexchadin on IRC. I've been
working on Watcher project since March 2016. I served as PTL for Pike cycle
and this cycle was a difficult one. But we have implemented a lot of
blueprints and bug fixes along with general Pike goals.

I'd like to set the following goals for Queens cycle:

* Support baremetal in Watcher.

  We have requests from ZTE to add Ironic-based strategy along with
  baremetal model. It will allow Watcher to manage power of vm-free hosts in
  case of consolidation goals. To do so, we also need to implement "power on"
  and "power off" actions.

* Investigate ability to support containers.

  As you may know, almost all companies which uses VMs are trying to work with
  containers and orchestration services like Kubernates. We could add cold
  migration actions at least Docker or use OpenStack Zun to get access to
  containers backed by different container technologies.

* Bug triaging.

  The functional gate job of Watcher is pretty unstable (2-3 tests fails
  time by time) and should be fixed. Every bug fix (with submitted bug report)
  across our repos should be reviewed as soon as possible.

* Complete HA support for Watcher

  There were some patches that allows Watcher to launch services in parallel.
  All we need is to implement schedule mechanism and make sure we have
  persisted all the things which are using during optimization process.

I'd like to thank our wonderful team for Pike cycle and I hope we will make
it better! Stay tuned.

Alex

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

Re: [openstack-dev] [neutron] possible race condition with nova instance and neutron ports

[Sławomir Kapłoński]

Hello,

Do You have configured in nova-compute: vif_plugging_timeout and 
vif_plugging_is_fatal options?
With those options nova should pause VM until port will be set to ACTIVE in 
Neutron.

-- 
Slawek

> Wiadomość napisana przez Saverio Proto  w dniu 
> 09.08.2017, o godz. 09:06:
> 
> Hello,
> 
> I see this in Openstack Newton
> 
> I start 200 instances with a oneliner.
> 
> openstack server create \
> --image "Ubuntu Xenial 16.04 (SWITCHengines)" \
> --flavor c1.small \
> --network demonetwork \
> --user-data cloud-init.txt \
> --key-name macsp \
> --min 200 \
> --max 200 test
> 
> When I do this I see a problem where all the instances boot and are in
> Running state, before all neutron ports are ACTIVE.
> 
> I see with `openstack port list` neutron ports still in BUILD state. It
> takes a longer time to make them all ACTIVE, the instances that use
> those ports boot up much faster.
> 
> In rabbitmq queues I see growing the dhcp_agent. queues.
> 
> At the very end all neutron ports will be ACTIVE and rabbitmq queues
> back to normal. But many VMs failed getting an address via DHCP because
> at the time they were trying the dnsmasq process did not have a
> corresponding entry for the instance in the `host` file. Unfortunately
> the instance gives up trying obtaining an address via DHCP after 5 minutes.
> 
> When I start 200 instances I always end up with 15 to 30 instances
> without IP address. I check carefully using cloud-init: I make them
> phone-home to check if they are alive.
> 
> Should I open a bug for this ?? It looks like a race condition where
> nova boots the instance before the neutron port is really ready.
> 
> thank you for your feedback.
> 
> 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

[openstack-dev] [neutron] possible race condition with nova instance and neutron ports

[Saverio Proto]

Hello,

I see this in Openstack Newton

I start 200 instances with a oneliner.

openstack server create \
--image "Ubuntu Xenial 16.04 (SWITCHengines)" \
--flavor c1.small \
--network demonetwork \
--user-data cloud-init.txt \
--key-name macsp \
--min 200 \
--max 200 test

When I do this I see a problem where all the instances boot and are in
Running state, before all neutron ports are ACTIVE.

I see with `openstack port list` neutron ports still in BUILD state. It
takes a longer time to make them all ACTIVE, the instances that use
those ports boot up much faster.

In rabbitmq queues I see growing the dhcp_agent. queues.

At the very end all neutron ports will be ACTIVE and rabbitmq queues
back to normal. But many VMs failed getting an address via DHCP because
at the time they were trying the dnsmasq process did not have a
corresponding entry for the instance in the `host` file. Unfortunately
the instance gives up trying obtaining an address via DHCP after 5 minutes.

When I start 200 instances I always end up with 15 to 30 instances
without IP address. I check carefully using cloud-init: I make them
phone-home to check if they are alive.

Should I open a bug for this ?? It looks like a race condition where
nova boots the instance before the neutron port is really ready.

thank you for your feedback.

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-dev] [requirements][masakari] FFE for adding python-masakariclient in global-requirements

[Bhor, Dinesh]

Hello everyone,

I would like to ask for the FFE for adding "python-masakariclient" in 
global-requirements.

Earlier, we were not having "check-requirements" job for masakari-* projects. 
At that time, we use to manually add "python-masakariclient" as a requirement 
in masakari-monitors project [1].
Now we have added "check-requirements" job for masakari-* projects, but we 
missed to add "python-masakariclient" in global-requirements and now the bigger 
issue is it is not possible
to manually update the "python-masakariclient" requirement in masakari-monitors 
project as the "gate-masakari-monitors-requirements" requirements job keeps 
failing on the patch [1].
To resolve this problem permanently, we need to add "python-masakariclient" 
library requirement in global-requirements.
I have submitted a patch [2] for adding the python-masakariclient in 
global-requirements.

Please consider my request and grant FFE to solve this problem.

[1] https://review.openstack.org/#/c/457491/
[2] https://review.openstack.org/#/c/491692/


Thank you,
Dinesh Bhor | App. Software Dev. Cnslt.
dinesh.b...@nttdata.com | nttdata.com/americas

__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Renat Akhmerov]

Thanks!


Renat Akhmerov
@Nokia

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