[openstack-dev] FW: [zun] python3 devstack+functional tests

[Hongbin Lu]

Hi Zuner,

FYI. A BP was created for that: 
https://blueprints.launchpad.net/zun/+spec/support-python-35 .

Best regards,
Hongbin

-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com] 
Sent: January-08-17 2:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [all][ptls][goals] python3 devstack+functional tests

Folks,

Here's where we track the work for a little while:
https://etherpad.openstack.org/p/support-python3.5-functional-tests

There's lots of work to be done to get stuff working properly. What we have now 
is the ability to just startup a bunch of services using py35. Does not mean 
they all work.

Teams that do not have functional tests in their own projects may still be able 
to look for, find and fix bugs. Example, the heat functional tests exercises 
Nova, Oslo etc. So look for tracebacks there and get going!

This is a good chance for newbies to get involved as well. Find a traceback to 
fix, propose a fix with a python3 unit test :)

Thanks,
Dims

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

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

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

Re: [openstack-dev] [tripleo] Fwd: Do you want to ask a project-specific question on the next User Survey?

[Ligong LG1 Duan]

I would like to ask:
· Which deployment tool of OpenStack are you using, TripleO or Fuel or 
Kolla or your customized tool?

Regards,
Ligong Duan

From: arkady.kanev...@dell.com [mailto:arkady.kanev...@dell.com]
Sent: Monday, January 09, 2017 12:30 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tripleo] Fwd: Do you want to ask a 
project-specific question on the next User Survey?

Suggest we request a question on life-cycle management tools, including 
TripleO, like upgrade, patching, etc. Not just deployment.
Arkady

From: Emilien Macchi [mailto:emil...@redhat.com]
Sent: Tuesday, January 03, 2017 8:08 AM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [tripleo] Fwd: Do you want to ask a project-specific 
question on the next User Survey?

(Happy new year folks!)

Forwarding Heidi's email to TripleO folks, so anyone can contribute to it.

Feel free to propose questions on:
https://etherpad.openstack.org/p/tripleo-user-survey-2017

The question with the more voting, will be proposed to the survey.
Please take 2 min and help on $topic, it will be very helpful.

Thanks,

-- Forwarded message --
From: Heidi Joy Tretheway 
mailto:heidi...@openstack.org>>
Date: Thu, Dec 22, 2016 at 4:58 PM
Subject: Do you want to ask a project-specific question on the next User Survey?
To: Jimmy McArthur mailto:ji...@openstack.org>>, Lauren 
Sell mailto:lau...@openstack.org>>
Greetings,

I wanted to offer you the opportunity to ask a question on the upcoming User 
Survey, which launches on or before Feb. 1. Each PTL of a project with 
significant adoption can submit one question. You can decide which audience to 
serve the question to - those who are USING, TESTING, or INTERESTED in your 
project (or some combination of these).

My hope is to gather as much information as possible to help you, and send it 
all raw, without commentary, in advance of the Project Team Gathering in late 
February.

The deadline to submit is Jan. 9.

Feel free to drop me a note if I can answer any questions for you!

Best,
Heidi Joy


[Image removed by sender. photo]

Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | Skype: 
heidi.tretheway
[Image removed by sender.] [Image 
removed by sender.]   [Image removed by 
sender.] 







--
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] [docs] Stepping down from core

[Lana Brindley]

On 22/12/16 02:11, Matt Kassawara wrote:
> Howdy!
> 
> After several years of contributing to OpenStack documentation, a significant 
> change in my career path warrants resigning from my role as a core reviewer. 
> Working with the OpenStack community was a great experience and I hope it 
> continues to grow... with sufficient documentation, of course.
> 
> Cheers,
> Matt
> 

Thanks for all your dedication and hard work over many years, Matt. Without you 
(and Tom!) I would never have gotten my first docs patch in, so I owe you a lot 
:)

All the best for the next step in your big adventure.

Lana

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



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

[openstack-dev] [Ceilometer] Scale deployment

[Srikanth Vavilapalli]

Hi

Can anyone plz point me to any document that captures how Ceilometer can be 
deployed in a scaled environment?

I found in different documentation that Ceilometer can be configured for scaled 
environment (as below), but could not find a unified document that covers all 
the details together for ceilometer deployment in a scaled environment:

-  More than one rabbitmq servers is deployed for faster data collection

-  More than one Notification agents can be deployed with 
"workload_partitioning" enabled for faster data fetching from rabbitmq

-  Enabling multiple pipeline processing queues 
"pipeline_processing_queues" for faster pipeline processing

-  Deploying database cluster on separate nodes with sharding and 
replica-sets enabled

My questions are:

1.   How to determine the number of ceilometer-agent-notification that I 
should deploy? For example I have 3 node environment to deploy ceilometer where 
a 3-node RabbitMq cluster is running. Should I deploy three 
ceilometer-agent-notification each of them pointing to 3-node rabbitmq cluster 
or can I deploy 1 or 2 notification agents that can fetch the messages from 
rabbitmq nodes? Is there any guidline for this?

2.   How do the ceilometer-agent-notification distribute the received 
messages from rabbitmq among themselves? Is it round robin among all messages 
or share the load at rabbitmq exchange levels? For example if rabbitmq cluster 
is deployed with N number of exchanges where telemetry data is sent equally 
among all these exchanges, can I partition the rabbitmq exchanges such that 
each notification agents process a subset of exchanges?

3.   Do I need to deploy "ceilometer-collector" daemon also in multiples in 
order to handle the load coming from ceilometer-agent-notifications and to 
write to database replicas?

Appreciate your inputs...

Thanks
Srikanth
__
OpenStack Development Mailing 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-dynamic-routing] tempest api test of neutron-dynamic-routing does not work

[fumihiko kakuma]

Hi team,

Currently the tempest api test of neutron-dynamic-routing does not work
due to my changes [1]. I apologize about it.
I pushed patch Iefc1a812680f48eb7eafc7d957b3a913a8c6d78a to fix this.
Please review it.

[1] Ieb710181c1e496742e1e019a6238e5e0bd922971
 I9923775806b095455ed3723e71410287bdf6cb1e


Thanks,
kakuma

-- 
fumihiko kakuma 


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

[openstack-dev] [nova] Reflecting on progress made by the live migration subteam

[Matt Riedemann]

I just watched this video of a summit session from Vancouver (Liberty 
summit):


https://www.youtube.com/watch?v=Vy8rS_5vea4

And had to leave a comment in there reflecting on the many improvements 
made by the live migration subteam in Nova in the Mitaka and Newton 
releases. Watching the video you can see several things pointed out as 
limitations or manual monitoring steps or workarounds at that time which 
are now features built into Nova since then, which is awesome to see.


When we're so heads down on getting the current release out it's hard to 
reflect sometimes on how far things have come in less than two years, 
and appreciate how a small dedicated group of people can make major 
improvements in OpenStack.


So I'm tipping my hat to the whole live migration subteam here on a job 
well done and thank you for the hard work you've put in.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [infra][diskimage-builder] containers, Containers, CONTAINERS!

[Gregory Haynes]

On Fri, Jan 6, 2017, at 09:57 AM, Paul Belanger wrote:
> On Fri, Jan 06, 2017 at 09:48:31AM +0100, Andre Florath wrote:
> > Hello Paul,
> > 
> > thank you very much for your contribution - it is very appreciated.
> > 

Seconded - I'm very excited for some effort to be put in to improving
the use case of making containers with DIB. Thanks :).

> > You addressed a topic with your patch set that was IMHO not in a wide
> > focus: generating images for containers.  The ideas in the patches are
> > good and should be implemented.
> > 
> > Nevertheless I'm missing the concept behind your patches. What I saw
> > are a couple of (independent?) patches - and it looks that there is
> > one 'big goal' - but I did not really get it.  My proposal is (as it
> > is done for other bigger changes or introducing new concepts) that
> > you write a spec for this first [1].  That would help other people
> > (see e.g. Matthew) to use the same blueprint also for other
> > distributions.

I strongly agree with the point that this is something were going to end
up repeating across many distros so we should make sure there's some
common patterns for doing so. A spec seems fine to me, but ideally the
end result involves some developer documentation. A spec is probably a
good place to get started on getting some consensus which we can turn in
to the dev docs.

> Sure, I can write a spec if needed but the TL;DR is:
> 
> Use diskimage-builder to build debootstrap --variant=minbase chroot, and
> nothing
> else. So I can then use take the generated tarball and do something else
> with
> it.
> 
> > One possibility would be to classify different element sets and define
> > the dependency between them.  E.g. to have a element class 'container'
> > which can be referenced by other classes, but is not able to reference
> > these (e.g. VM or hardware specific things).
> > 

It sounds like we need to step back a bit get a clear idea of how were
going to manage the full use case matrix of distro * (minimal / full) *
(container / vm / baremetal), which is something that would be nice to
get consensus on in a spec. This is something that keeps tripping up
both users and devs and I think adding containers to the matrix is sort
of a tipping point in terms of complexity so again, some docs after
figuring out our plan would be *awesome*.

Currently we have distro-minimal elements which are minimal
vm/baremetal, and distro elements which actually are full vm/baremetal
elements. I assume by adding an element class you mean add a set of
distro-container elements? If so, I worry that we might be falling in to
a common dib antipattern of making distro-specific elements. I have a
alternate proposal:

Lets make two elements: kernel, and minimal-userspace which,
respectively, install the kernel package and a minimal set of userspace
packages for dib to function (e.g. dependencies for dib-run-parts,
package-installs). The kernel package should be doable as basically a
package-installs and a pkg-map. The minimal-userspace element gets
tricky because it needs to install deps which are required for things
like package-installs to function (which is why the various distro
elements do this independently).  Even so, I think it would be nice to
take care of installing these from within the chroot rather than from
outside (see https://review.openstack.org/#/c/392253/ for a good reason
why). If we do this then the minimal-userspace element can have some
common logic to enter the chroot as part of root.d and then install the
needed deps.

The end result of this would be we have distro-minimal which depends on
kernel, minimal-userspace, and yum/debootstrap to build a vm/baremetal
capable image. We could also create a distro-container element which
only depends on minimal-userspace and yum/debootstrap and creates a
minimal container. The point being - the top level -container or
-minimal elements are basically convenience elements for exporting a few
vars and pulling in the proper elements at this point and the
elements/code are broken down by the functionality they provide rather
than use case.

> > There are additional two major points:
> > 
> > * IMHO you addressed only some elements that needs adaptions to be
> >   able to used in containers.  One element I stumbled over yesterday
> >   is the base element: it is always included until you explicitly
> >   exclude it.  This base element depends on a complete init-system -
> >   which is for a container unneeded overhead. [2]

I think you're on the right track with removing base - we had consensus
a while back that it should go away but we never got around to it. The
big issue is going to be preserving backwards compat or making it part
of a major version bump and not too painful to upgrade to. I think we
can have this convo on the patchset, though.

> 
> Correct, for this I simply pass the -n flag to disk-image-create. This
> removes
> the need for include the base element. If we want to make a future
> optimization
> t

[openstack-dev] [all][ptls][goals] python3 devstack+functional tests

[Davanum Srinivas]

Folks,

Here's where we track the work for a little while:
https://etherpad.openstack.org/p/support-python3.5-functional-tests

There's lots of work to be done to get stuff working properly. What we
have now is the ability to just startup a bunch of services using
py35. Does not mean they all work.

Teams that do not have functional tests in their own projects may
still be able to look for, find and fix bugs. Example, the heat
functional tests exercises Nova, Oslo etc. So look for tracebacks
there and get going!

This is a good chance for newbies to get involved as well. Find a
traceback to fix, propose a fix with a python3 unit test :)

Thanks,
Dims

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

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

Re: [openstack-dev] [tripleo] Fwd: Do you want to ask a project-specific question on the next User Survey?

[Arkady.Kanevsky]

Suggest we request a question on life-cycle management tools, including 
TripleO, like upgrade, patching, etc. Not just deployment.
Arkady

From: Emilien Macchi [mailto:emil...@redhat.com]
Sent: Tuesday, January 03, 2017 8:08 AM
To: OpenStack Development Mailing List 
Subject: [openstack-dev] [tripleo] Fwd: Do you want to ask a project-specific 
question on the next User Survey?

(Happy new year folks!)

Forwarding Heidi's email to TripleO folks, so anyone can contribute to it.

Feel free to propose questions on:
https://etherpad.openstack.org/p/tripleo-user-survey-2017

The question with the more voting, will be proposed to the survey.
Please take 2 min and help on $topic, it will be very helpful.

Thanks,

-- Forwarded message --
From: Heidi Joy Tretheway 
mailto:heidi...@openstack.org>>
Date: Thu, Dec 22, 2016 at 4:58 PM
Subject: Do you want to ask a project-specific question on the next User Survey?
To: Jimmy McArthur mailto:ji...@openstack.org>>, Lauren 
Sell mailto:lau...@openstack.org>>

Greetings,

I wanted to offer you the opportunity to ask a question on the upcoming User 
Survey, which launches on or before Feb. 1. Each PTL of a project with 
significant adoption can submit one question. You can decide which audience to 
serve the question to - those who are USING, TESTING, or INTERESTED in your 
project (or some combination of these).

My hope is to gather as much information as possible to help you, and send it 
all raw, without commentary, in advance of the Project Team Gathering in late 
February.

The deadline to submit is Jan. 9.

Feel free to drop me a note if I can answer any questions for you!

Best,
Heidi Joy


[Image removed by sender. photo]

Heidi Joy Tretheway
Senior Marketing Manager, OpenStack Foundation
503 816 9769 | Skype: 
heidi.tretheway
[Image removed by sender.] [Image 
removed by sender.]   [Image removed by 
sender.] 







--
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] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] [vitrage] how touseplaceholder vertex

[Yujun Zhang]

Hi, Alexey

On Sun, Jan 8, 2017 at 2:50 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Hi Yujun,
>
> A relationship is defined by the following trio: source id, target id and
> a label on the edge.
> In the processor, I add only edges that doesn't exists.
>

Currently the vertex is mapping to entity, and the edge is mapping to
relationship.

So do you mean that we should update the label if the relationship between
two entities changes? e.g. we change the link between two PC's from cable
to Wi-Fi.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the alarms generated by vitrage evaluator

[Yujun Zhang]

Maybe I have missed something in the scenario template, but it seems you
have understood my idea quite correctly :-)

See further explanation inline

On Sun, Jan 8, 2017 at 3:06 PM Afek, Ifat (Nokia - IL) 
wrote:

> Hi Yujun,
>
>
>
> Thanks for the explanation, but I still don’t fully understand.
>
>
>
> Let me start with the current state:
>
> 1.   introduce a flexible `metadata` dict in to ALARM entity
>
> [Ifat] Already exists. An alarm is represented as a vertex in the entity
> graph, with a dictionary of properties.
>

 [yujunz] Can the alarm vertex be updated by scenario action? e.g. raise an
alarm and set the property `suspect` to true.

2.   Allow generating update event[1] on metadata change
>
> 3.   Allow using ALARM metadata in scenario condition
>
> [Ifat] Already exists. You can define properties in the ‘entities’ section
> in Vitrage templates
>

[yujunz] How do I specify the condition if one specified alarm is
'suspicious', e.g. condition: host_alarm.suspect ?

4.   Allow setting ALARM metadata in scenario action
>
>
>
> If I understand correctly, you are suggesting that one scenario will add
> metadata to an existing alarm, which will trigger an event, and as a result
> another scenario might be executed?
>

[yujunz] Exactly

Can you describe a use case where this behavior will help calculating the
> root cause?
>

[yujunz] Here's the simplified case derived from YinLiYin's example.
Suppose we add a causal relationship from `host_alarm` to `instance_alarm`,
i.e. host alarm will cause instance alarm. If an instance alarm is detected
(but no host alarm). It is "suspicious" that it may be caused by host
alarm. The reason could be event delay or lost. Instead of waiting for
snapshot service to update the host status, we want to run a diagnostic
action to check it initiatively.

In this case, we want to set the upstream (host) of a confirmed alarm
(instance) to "suspect" and trigger an diagnostic action on this change.

Hope that I have made the use case clear.

Thanks,
>
> Ifat.
>
>
>
>
>
> *From: *Yujun Zhang 
>
>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
>
> *Date: *Saturday, 7 January 2017 at 09:27
>
>
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
>
> *Cc: *"han.jin...@zte.com.cn" , "
> wang.we...@zte.com.cn" , "gong.yah...@zte.com.cn" <
> gong.yah...@zte.com.cn>, "jia.peiy...@zte.com.cn" ,
> "zhang.yuj...@zte.com.cn" 
> *Subject: *Re: [openstack-dev] [Vitrage] About alarms reported by
> datasource and the alarms generated by vitrage evaluator
>
>
>
> The two questions raised by YinLiYin is actually one, i.e. *how to enrich
> the alarm properties *that can be used as an condition in root cause
> deducing.
>
>
>
> Both 'suspect' or 'datasource' are additional information that may be
> referred as a condition in general fault model, a.k.a. scenario in vitrage.
>
>
>
> It seems it could be done by
>
>1. introduce a flexible `metadata` dict in to ALARM entity
>
> 2.  Allow generating update event[1] on metadata change
>
> 3.  Allow using ALARM metadata in scenario condition
>
> 4.  Allow setting ALARM metadata in scenario action
>
> This will leave the flexibility to continuous development by defining a
> complex scenario template and keep the vitrage evaluator simple and generic.
>
>
>
> My two cents.
>
>
>
> [1]:
> http://docs.openstack.org/developer/vitrage/scenario-evaluator.html#concepts-and-guidelines
>
>
>
>
> On Sat, Jan 7, 2017 at 2:23 AM Afek, Ifat (Nokia - IL) <
> ifat.a...@nokia.com> wrote:
>
> Hi YinLiYin,
>
>
>
> This is an interesting question. Let me divide my answer to two parts.
>
>
>
> First, the case that you described with Nagios and Vitrage. This problem
> depends on the specific Nagios tests that you configure in your system, as
> well as on the Vitrage templates that you use. For example, you can use
> Nagios/Zabbix to monitor the physical layer, and Vitrage to raise deduced
> alarms on the virtual and application layers. This way you will never have
> duplicated alarms. If you want to use Nagios to monitor the other layers as
> well, you can simply modify Vitrage templates so they don’t raise the
> deduced alarms that Nagios may generate, and use the templates to show RCA
> between different Nagios alarms.
>
>
>
> Now let’s talk about the more general case. Vitrage can receive alarms
> from different monitors, including Nagios, Zabbix, collectd and Aodh. If
> you are using more than one monitor, it is possible that the same alarm
> (maybe with a different name) will be raised twice. We need to create a
> mechanism to identify such cases and create a single alarm with the
> properties of both monitors. This has not been designed in details yet, so
> if you have any suggestion we will be happy to hear them.
>
>
>
> Best Regards,
>
> Ifat.
>
>
>
>
>
> *From: *"yinli...@zte.com.cn" 
> *Reply-To: *"OpenStack Development Mailing List (not for us

Re: [openstack-dev] [Octavia] - LBaaS and IPv6

[Gary Kotton]

Hi,
If the load balancer supports IPv6 then this should be supported.
Thanks
Gary

From: Alex Stafeyev 
Reply-To: OpenStack List 
Date: Sunday, January 8, 2017 at 2:07 PM
To: OpenStack List 
Subject: [openstack-dev] [Octavia] - LBaaS and IPv6

Hi,
Does lbaas support LB in ipv6 network?

tnx

--
Alexander Stafeyev
QE Engineer, Neutron, Openstack
Red Hat


__
OpenStack Development Mailing 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] [Octavia] - LBaaS and IPv6

[Alex Stafeyev]

Hi,
Does lbaas support LB in ipv6 network?

tnx

-- 
Alexander Stafeyev
QE Engineer, Neutron, Openstack
Red Hat
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev