Re: [openstack-dev] [heat] glance v2 support?

[Flavio Percoco]

On 10/01/17 12:35 +0530, Rabi Mishra wrote:

On Mon, Jan 9, 2017 at 4:45 PM, Flavio Percoco  wrote:


On 06/01/17 09:34 +0530, Rabi Mishra wrote:


On Fri, Jan 6, 2017 at 4:38 AM, Emilien Macchi 
wrote:

Greetings Heat folks!


My question is simple:
When do you plan to support Glance v2?
https://review.openstack.org/#/c/240450/

The spec looks staled while Glance v1 was deprecated in Newton (and v2
was started in Kilo!).


Hi Emilien,


I think we've not been able to move to v2 due to v1/v2 incompatibility[1]
with respect to the location[2] property. Moving to v2 would break all
existing templates using that property.

I've seen several discussions around that without any conclusion.  I think
we can support a separate v2 image resource and deprecate the current one,
unless there is a better path available.



Hi Rabi,

Could you elaborate on why Heat depends on the location attribute? I'm not
familiar with Heat and knowing this might help me to propose something (or
at
least understand the difficulties).

I don't think putting this on hold will be of any help. V1 ain't coming
back and
the improvements for v2 are still under heavy coding. I'd probably
recommend
moving to v2 with a proper deprecation path rather than sticking to v1.



Hi Flavio,

As much as we would like to move to v2, I think we still don't have a
acceptable solution for the question below. There is an earlier ML
thread[1], where it was discussed in detail.

- What's the migration path for images created with v1 that use the
location attribute pointing to an external location?


Moving to Glance v2 shouldn't break this. As in, Glance will still be able to
pull the images from external locations.

Also, to be precise more precise, you actually *can* use locations in V2.
Glance's node needs to have 2 settings enabled. The first is
`show_multple_locations` and the second one is a policy config[0]. It's however
not recommended to expose that to end users but that's why it was shielded
behind policies.

I'd recommend Heat to not use locations as that will require deployers to either
enable them for everyone or have a dedicate glance-api node for Heat.

All that being said, switching to v2 won't prevent Glance from reading images
from external locations if the image records exist already.

[0] https://github.com/openstack/glance/blob/master/etc/policy.json#L16-L18


While answering the above we've to keep in mind the following constraint.

- Any change in the image id(new image) would potentially result in nova
servers using them in the template being rebuilt/replaced, and we would
like to avoid it.

There was a suggestion to allow the 'copy-from'  with v2, which would
possibly make it easier for us. Is that still an option?


May be, in the long future. The improvements for v2 are still under heavy
development.


I assume we can probably use glance upload api to upload the image
data(after getting it from the external location) for an existing image?
Last time i tried to do it, it seems to be not allowed for an 'active'
image. It's  possible I'm missing something here.  We don't have a way at
present,  for a user to upload an image to heat engine( not sure if we
would like do to it either) or heat engine downloading the image from an
'external location' and then uploading it to glance while creating/updating
an image resource.


Downloading the image locally and uploading it is a workaround, yes. Not ideal
but it's simple. However, you won't need it for the migration to v2, I believe,
since you can re-use existing images. Heat won't be able to create new images
and have them point to external locations, though, unless the settings I
mentioned above have been enabled.


Also, glance location api could probably have been useful here. However, we
were advised in the earlier thread not to use it, as exposing the location
to the end user is perceived as a security risk.


++

Flavio



[1]  http://lists.openstack.org/pipermail/openstack-dev/2016-May/094598.html


Cheers,

Flavio



[1] https://wiki.openstack.org/wiki/Glance-v2-v1-client-compatability
[2] https://github.com/openstack/heat/blob/master/heat/engine/
resources/openstack/glance/image.py#L107-L112


As an user, I need Glance v2 support so I can remove Glance Registry

from my deployment. and run pure v2 everywhere in my cloud.

Thanks for your help,
--
Emilien Macchi


__
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





--
Regards,
Rabi Misra



__

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

[openstack-dev] [tc][all] Feedback from driver maintainers about future of driver projects

[Steve Martinelli]

In preparation for the next TC meeting, a survey was sent out to driver
maintainers, here is a summary of the feedback that was gathered.

Major observations

==

* Are drivers an important part of OpenStack? YES!

* Discoverability of drivers needs to be fixed immediately.

* It is important to have visibility in a central place of the status of
each driver.

* Perspective of a driver developer and a high level person at the company
should feel like they're part of something.

* OpenStack should stop treating drivers like second-class citizens. They
want access to the same resources (publish on docs.o.org, config guides,
etc).

* The initial wording about what constitutes a project was never intended
for drivers. Drivers are a part of the project. Driver developers
contribute to OpenStack by creating drivers.

Discoverability

===

* Consensus: It is currently all over the place. A common mechanism to view
all supported drivers is needed.

* Cinder list: http://docs.openstack.org/developer/cinder/drivers.html

* Nova list: http://docs.openstack.org/developer/nova/support-matrix.html

* Stackalytics list: http://stackalytics.openstack.org/report/driverlog

* Opinion: If we intend to use the marketplace (or anywhere on openstack.org)
to list in-tree and out-of-tree drivers, they should have CI results
available as a requirement. A driver that fails CI is not just a vendor
problem, it’s an OpenStack problem, it reflects poorly on OpenStack and the
project.

* Opinion: What constitutes a supported driver, why not list all drivers?

* Opinion: Fixing discoverability can be done independently of governance
changes. We have the option of tabling the governance discussion until we
get the discoverability properly fixed, and see then if we still need to do
anything more.

* Opinion: Between giving full access to vertical resources to driver
teams, and making the marketplace *the* place for learning about OpenStack
drivers, we would have solved at least the biggest portion of the problem
we're facing.

Driver projects - official or not?

==

* Fact: There is desire from some out-of-tree vendors to become ‘official’
OpenStack projects, and gain the benefits of that (access to horizontal
teams).

* Opinion: Let drivers projects become official, there should be no 3rd
party CI requirement, that can be a tag.

* Opinion: Do not allow drivers projects to become official, that doesn’t
mean they shouldn’t easily be discoverable.

* Opinion: We don't need to open the flood gates of allowing vendors to be
teams in the OpenStack governance to make the vendors developers happy.

* Fact: This implies being placed under the TC oversight. It is a
significant move that could have unintended side-effects, it is hard to
reverse (kicking out teams we accepted is worse than not including them in
the first place), and our community is divided on the way forward. So we
need to give that question our full attention and not rush the answer.

* Opinion: Consider https://github.com/openstack/driverlog an official
OpenStack project to be listed under governance with a PTL, weekly
meetings, and all that it required to allow the team to be effective in
their mission of keeping the marketplace a trustworthy resource for
learning about OpenStack driver ecosystem.

Driver developers

=

* Opinion: A driver developer that ONLY contributes to vendor specific
driver code should not have the same influence as other OpenStack
developers, voting for PTL, TC, and ATC status.

* Opinion: PTLs should leverage the extra-atcs option in the governance repo

In-tree vs Out-of-tree

==

* Cinder has in-tree drivers, but also has out-of-tree drivers when their
CI is not maintained or when minimum feature requirements are not met. They
are marked as ‘not supported’ and have a single release to get things
working before being moved out-of-tree.

* Ironic has a single out-of-tree repo:
https://github.com/openstack/ironic-staging-drivers -- But also in-tree
https://github.com/openstack/ironic/tree/master/ironic/drivers

* Neutron has all drivers out-of-tree, with project names like:
‘networking-cisco’.

* Many opinions on the “stick-based” approach the cinder team took.

* Opinion: The in-tree vs out-of-tree argument is developer focused.
Out-of-tree drivers have obvious benefits (develop quickly, maintain their
own team, no need for a core to review the patch). But a vendor that is
looking to make sure a driver is supported will not be searching git repos
(goes back to discoverability).

* Opinion: May be worth handling the projects that keep supported drivers
in-tree differently that we handle projects that have everything
out-of-tree.

thanks for reading! stevemar
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [neutron] PTL nominations deadline and non-candidacy

[Andreas Scheuring]

I'm sad to see you stepping down. Thanks a lot Armando for your amazing
service as PTL! 


-- 
-
Andreas 
IRC: andreas_s



On Mo, 2017-01-09 at 15:11 +0100, Armando M. wrote:
> Hi neutrinos,
> 
> 
> The PTL nomination week is fast approaching [0], and as you might have
> guessed by the subject of this email, I am not planning to run for
> Pike. If I look back at [1], I would like to think that I was able to
> exercise the influence on the goals I set out with my first
> self-nomination [2].
> 
> 
> That said, when it comes to a dynamic project like neutron one can't
> never claim to be *done done* and for this reason, I will continue to
> be part of the neutron core team, and help the future PTL drive the
> next stage of the project's journey.
> 
> 
> I must admit, I don't write this email lightly, however I feel that it
> is now the right moment for me to step down, and give someone else the
> opportunity to grow in the amazing role of neutron PTL! I have
> certainly loved every minute of it!
> 
> 
> Cheers,
> Armando
> 
> 
> [0] https://releases.openstack.org/ocata/schedule.html
> [1] https://review.openstack.org/#/q/project:openstack/election
> +owner:armando-migliaccio
> [2] https://review.openstack.org/#/c/223764/
> 
> __
> OpenStack Development Mailing 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] [heat] glance v2 support?

[Rabi Mishra]

On Mon, Jan 9, 2017 at 4:45 PM, Flavio Percoco  wrote:

> On 06/01/17 09:34 +0530, Rabi Mishra wrote:
>
>> On Fri, Jan 6, 2017 at 4:38 AM, Emilien Macchi 
>> wrote:
>>
>> Greetings Heat folks!
>>>
>>> My question is simple:
>>> When do you plan to support Glance v2?
>>> https://review.openstack.org/#/c/240450/
>>>
>>> The spec looks staled while Glance v1 was deprecated in Newton (and v2
>>> was started in Kilo!).
>>>
>>>
>>> Hi Emilien,
>>
>> I think we've not been able to move to v2 due to v1/v2 incompatibility[1]
>> with respect to the location[2] property. Moving to v2 would break all
>> existing templates using that property.
>>
>> I've seen several discussions around that without any conclusion.  I think
>> we can support a separate v2 image resource and deprecate the current one,
>> unless there is a better path available.
>>
>
> Hi Rabi,
>
> Could you elaborate on why Heat depends on the location attribute? I'm not
> familiar with Heat and knowing this might help me to propose something (or
> at
> least understand the difficulties).
>
> I don't think putting this on hold will be of any help. V1 ain't coming
> back and
> the improvements for v2 are still under heavy coding. I'd probably
> recommend
> moving to v2 with a proper deprecation path rather than sticking to v1.
>
>
Hi Flavio,

As much as we would like to move to v2, I think we still don't have a
acceptable solution for the question below. There is an earlier ML
thread[1], where it was discussed in detail.

- What's the migration path for images created with v1 that use the
location attribute pointing to an external location?

While answering the above we've to keep in mind the following constraint.

- Any change in the image id(new image) would potentially result in nova
servers using them in the template being rebuilt/replaced, and we would
like to avoid it.

There was a suggestion to allow the 'copy-from'  with v2, which would
possibly make it easier for us. Is that still an option?

I assume we can probably use glance upload api to upload the image
data(after getting it from the external location) for an existing image?
Last time i tried to do it, it seems to be not allowed for an 'active'
image. It's  possible I'm missing something here.  We don't have a way at
present,  for a user to upload an image to heat engine( not sure if we
would like do to it either) or heat engine downloading the image from an
'external location' and then uploading it to glance while creating/updating
an image resource.

Also, glance location api could probably have been useful here. However, we
were advised in the earlier thread not to use it, as exposing the location
to the end user is perceived as a security risk.


[1]  http://lists.openstack.org/pipermail/openstack-dev/2016-May/094598.html


Cheers,
> Flavio
>
>
>> [1] https://wiki.openstack.org/wiki/Glance-v2-v1-client-compatability
>> [2] https://github.com/openstack/heat/blob/master/heat/engine/
>> resources/openstack/glance/image.py#L107-L112
>>
>>
>> As an user, I need Glance v2 support so I can remove Glance Registry
>>> from my deployment. and run pure v2 everywhere in my cloud.
>>>
>>> Thanks for your help,
>>> --
>>> Emilien Macchi
>>>
>>> 
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> Regards,
>> Rabi Misra
>>
>
> __
>> 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
>>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing 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] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] Re: [ALU] Re: [ALU]Re: [ALU]Re: [ALU][vitrage]how touseplaceholder vertex

[Weyl, Alexey (Nokia - IL)]

I see, you want 2 edges between PC_a and PC_b.

In order to model such a use case you need to use the action 
update_relationship in the processor.

You can it in the following way:
   1. in the transformer create PC_a -> PC_b in the regular way, by using the 
action create_entity or update_entity.
   2. when a new relationship arrives, that should arrive with a new label you 
can model the transformer to return an action update_relationship and thus a 
new edge will be added between those entities.

Hope it helps,
Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Tuesday, January 10, 2017 7:31 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] Re: 
[ALU]Re: [ALU]Re: [ALU][vitrage]how touseplaceholder vertex

Great! So let's come back to my original question on redundant link.

Before: PC_a is connected to PC_b with Cable
After: PC_a is connected to PC_b with Cable AND Wi-Fi

How to we model this? 
1. Create a new edge labeled "Cable and Wi-Fi" ? 
2. Assign a structured label like ["Cable", "Wi-Fi"] to the edge?
3. Create two edges, one labeled "Cable", the other labeled "Wi-Fi"?
--
Yujun

On Mon, Jan 9, 2017 at 6:44 PM Weyl, Alexey (Nokia - IL) 
 wrote:
Hi Yujun,

After some more checks, I found out the current code will handle your case as 
well, because it will go into the 2.c.1.

Alexey

> -Original Message-
> From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com]
> Sent: Monday, January 09, 2017 10:54 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> Re: [ALU]Re: [ALU][vitrage]how touseplaceholder vertex
>
> What will happen is the following:
> We have a connection between PC_a and PC_b with label Cable.
> Now a new event arrives and the transformer builds the following trio:
> (Vertex_A, Neighbors((Vertex_B, Edge), UPDATE) This transformed data
> arrives to the processor that goes to the UPDATE action:
> 1. Updates the Vertex_A (PC_a) properties in the graph.
> 2. Calls the _update_neighbors method:
>    a. finds all the valid_edges and the obsolete_edges
>    b. deletes all the obsolete edges from the graph
>    c. connects the valid edges to the graph:
>       iterates over all the neighbors, and for each neighbor checks:
>       1. if the neighbor_vertex doesn't exist yet or if the is_deleted
> property of the neighbor_vertex is false then:
>          a. Update this vertex in the graph.
>          b. check if the edge doesn't exist yet and if so then add the
> edge.
>
> In your case the edge the edge 'Cable' will be deleted from the graph
> because it is obsolete, but from what I see at the moment and can be
> seen in the code, it won't enter the to the 2.c.1 because the neighbor
> vertex already exists and the neighbor vertex isn't defined as
> is_delete=false.
>
> That is a problem, and I have a solution for the problem, which I need
> to make sure that it ruin anything else because everything goes through
> the processor.
>
> Alexey
>
> From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> Sent: Monday, January 09, 2017 10:26 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> Re: [ALU][vitrage]how touseplaceholder vertex
>
> Thanks Alexey. Could you explain a bit more detail based on the example
> in comments below?
>
> On Mon, Jan 9, 2017 at 4:08 PM Weyl, Alexey (Nokia - IL)
>  wrote:
> That’s not what I mean.
>
> When some data is changed in a some vertices, their event is pushed to
> the event queue, and thus the correct transformer is called.
> We update the data of the current vertex, and for each neighbor that we
> created in the transformer, we check the following:
> if the neighbor vertex doesn't exist yet or if the id_deleted property
> of the neighbor vertex is false, then update the vertex in the graph.
> Then it checks if the edge is not in the graph yet, then it adds it.
>
> Before: PC_a is linked to PC_b with Cable
> After: PC_a is linked to PC_b with Wi-Fi
>
> So this will results in a removal of original edge (labeled Cable) and
> adding of new edge (labeled Wi-Fi) . Is that correct?
>
> Alexey
>
> From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> Sent: Sunday, January 08, 2017 5:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> [vitrage]how touseplaceholder vertex
>
> Hi, Alexey
> On Sun, Jan 8, 2017 at 2:50 PM Weyl, Alexey (Nokia - IL)
>  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.
>

[openstack-dev] [nova] Inconsistency of parameter type in Nova API Reference

[Takashi Natsume]

Hi Nova developers.

In Nova API Reference(*1),
the following parameters' values are 'null' in HTTP request body samples.
And their parameter types are defined as 'string'.

* 'confirmResize' parameter in "Confirm Resized Server (confirmResize  
Action)"

* 'lock' parameter in "Lock Server (lock Action)"
* 'pause' parameter in "Pause Server (pause Action)"
* 'resume' parameter in "Resume Suspended Server (resume Action)"
* 'revertResize' parameter in "Revert Resized Server (revertResize Action)"
* 'os-start' parameter in "Start Server (os-start Action)"
* 'os-stop' parameter in "Stop Server (os-stop Action)"
* 'suspend' parameter in "Suspend Server (suspend Action)"

On the other hand,
the following parameter's value is 'null' in the HTTP request body sample.
But the parameter type is defined as 'none'.

* 'trigger_crash_dump' in "Trigger Crash Dump In Server"

IMO, there is inconsistency of parameter types.
Should they be unified as 'none'?

*1: Compute API Reference
http://developer.openstack.org/api-ref/compute/

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp



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

I prefer 2.b from instinct.

Not sure it could be linked to the vitrage_id[1] evolution. If an uuid is
created for the alarm, the implementation could be quite straightforward.

[1]: https://blueprints.launchpad.net/vitrage/+spec/standard-vitrage-id

On Tue, Jan 10, 2017 at 1:55 AM Afek, Ifat (Nokia - IL) 
wrote:

> Hi Yujun,
>
>
>
> I understand the use case now, thanks for the detailed explanation.
>
>
>
> Supporting this use case will require some development in Vitrage. Let me
> try to list down the requirements and options that we have.
>
>
>
> 1.   Requirement: Raise ‘suspect’ deduced alarms in Vitrage.
>
> Implementation: Quite straight forward. There is no way to set ‘suspect’
> property in Vitrage right now, but it should be easy to add this option.
>
>
>
> 2.   Requirement: Change a ‘suspect’ alarm of type ‘vitrage’ to a
> ‘real’ alarm of type ‘nagios’.
>
> Implementation: There are a few alternatives how to achieve this goal
>
>
>
> a.   Delete the ‘suspect’ alarm and create the ‘real’ alarm. This
> will require supporting ‘not’ condition in the templates. An example
> scenario:
>
> condition: vm_alarm and not nagios_alarm:
>
>(action: create vitrage alarm)
>
> condition: nagios_alarm and vitrage_alarm:
>
>(action: delete vitrage_alarm)
>
>
>
> b.   Have both ‘suspect’ alarm and ‘real’ alarm, and create a
> ‘equivalent’ relationship between them. Configuring the template should be
> easy, however it won’t look nice in the UI. In past discussions we
> mentioned an option to group some vertices together in the UI. If we have
> this option, we might want to group these two alarms together.
>
>
>
> c.   Merge the two alarms. This solution seems the most reasonable
> one at first, but it is not trivial. For example: suppose one alarm is
> defined as ‘critical’ and was raised at 10:01, and the other alarm was
> defined as ‘warning’ and was raised at 10:02. How will you combine the two?
> And what if the ‘critical’ alarm then goes down, will you know how to
> change the severity back to ‘warning’? in case of vitrage vs. nagios we
> would like to prefer nagios; but let’s think of the more general case of
> two different monitors.
>
>
>
> 3.   In one of your emails you mentioned an option of having two
> ‘suspects’. Suppose vm_alarm is raised, will you raise two suspect vitrage
> alarms, e.g. host_alarm and switch_alarm? And if you then receive
> host_alarm from nagios, would you like to delete the suspect switch_alarm,
> or keep it? If you would like to delete it, it will require supporting
> ‘not’ in the template condition.
>
>
>
> Personally I would go for option 2b, but I will be happy to hear your
> thoughts about it.
>
>
>
> Hope I helped, but I suspect I just made things more complicated ;-)
>
> Ifat.
>
>
>
>
>
> *From: *Yujun Zhang 
>
>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
>
> *Date: *Sunday, 8 January 2017 at 17:38
>
>
> *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
>
> 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) <
> ifat.a...@nokia.com> 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?
>
>
>
> 

Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] Re: [ALU] Re: [ALU]Re: [ALU][vitrage]how touseplaceholder vertex

[Yujun Zhang]

Great! So let's come back to my original question on redundant link.

Before: PC_a is connected to PC_b with Cable
After: PC_a is connected to PC_b with Cable *AND* Wi-Fi

How to we model this?

   1. Create a new edge labeled "Cable and Wi-Fi" ?
   2. Assign a structured label like ["Cable", "Wi-Fi"] to the edge?
   3. Create two edges, one labeled "Cable", the other labeled "Wi-Fi"?

--
Yujun

On Mon, Jan 9, 2017 at 6:44 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

Hi Yujun,

After some more checks, I found out the current code will handle your case
as well, because it will go into the 2.c.1.

Alexey

> -Original Message-
> From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com]
> Sent: Monday, January 09, 2017 10:54 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> Re: [ALU]Re: [ALU][vitrage]how touseplaceholder vertex
>
> What will happen is the following:
> We have a connection between PC_a and PC_b with label Cable.
> Now a new event arrives and the transformer builds the following trio:
> (Vertex_A, Neighbors((Vertex_B, Edge), UPDATE) This transformed data
> arrives to the processor that goes to the UPDATE action:
> 1. Updates the Vertex_A (PC_a) properties in the graph.
> 2. Calls the _update_neighbors method:
>a. finds all the valid_edges and the obsolete_edges
>b. deletes all the obsolete edges from the graph
>c. connects the valid edges to the graph:
>   iterates over all the neighbors, and for each neighbor checks:
>   1. if the neighbor_vertex doesn't exist yet or if the is_deleted
> property of the neighbor_vertex is false then:
>  a. Update this vertex in the graph.
>  b. check if the edge doesn't exist yet and if so then add the
> edge.
>
> In your case the edge the edge 'Cable' will be deleted from the graph
> because it is obsolete, but from what I see at the moment and can be
> seen in the code, it won't enter the to the 2.c.1 because the neighbor
> vertex already exists and the neighbor vertex isn't defined as
> is_delete=false.
>
> That is a problem, and I have a solution for the problem, which I need
> to make sure that it ruin anything else because everything goes through
> the processor.
>
> Alexey
>
> From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> Sent: Monday, January 09, 2017 10:26 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> Re: [ALU][vitrage]how touseplaceholder vertex
>
> Thanks Alexey. Could you explain a bit more detail based on the example
> in comments below?
>
> On Mon, Jan 9, 2017 at 4:08 PM Weyl, Alexey (Nokia - IL)
>  wrote:
> That’s not what I mean.
>
> When some data is changed in a some vertices, their event is pushed to
> the event queue, and thus the correct transformer is called.
> We update the data of the current vertex, and for each neighbor that we
> created in the transformer, we check the following:
> if the neighbor vertex doesn't exist yet or if the id_deleted property
> of the neighbor vertex is false, then update the vertex in the graph.
> Then it checks if the edge is not in the graph yet, then it adds it.
>
> Before: PC_a is linked to PC_b with Cable
> After: PC_a is linked to PC_b with Wi-Fi
>
> So this will results in a removal of original edge (labeled Cable) and
> adding of new edge (labeled Wi-Fi) . Is that correct?
>
> Alexey
>
> From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> Sent: Sunday, January 08, 2017 5:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> [vitrage]how touseplaceholder vertex
>
> Hi, Alexey
> On Sun, Jan 8, 2017 at 2:50 PM Weyl, Alexey (Nokia - IL)
>  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
> ___
> ___
> OpenStack Development Mailing 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] Meeting at 20:00UTC this Wednesday, 11th January

[Richard Jones]

Hi folks,

The Horizon team will be having our next meeting at 20:00 UTC this
Wednesday, 11th January in #openstack-meeting-3

Meeting agenda is here: https://wiki.openstack.org/wiki/Meetings/Horizon

If we have spare time this meeting I think we should look into getting some
patches reviewed together.

Anyone is welcome to to add agenda items and everyone interested in
Horizon is encouraged to attend.


Cheers,

Richard

__
OpenStack Development Mailing 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] nova-api-metadata managing firewall

[Sam Morrison]

Hi nova-devs,

I raised a bug about nova-api-metadata messing with iptables on a host 

https://bugs.launchpad.net/nova/+bug/1648643 


It got closed as won’t fix but I think it could do with a little more 
discussion.

Currently nova-api-metadata will create an iptable rule and also delete other 
rules on the host. This was needed for back in the nova-network days as there 
was some trickery going on there.
Now with neutron and neutron-metadata-proxy nova-api-metadata is little more 
that a web server much like nova-api.

I may be missing some use case but I don’t think nova-api-metadata needs to 
care about firewall rules (much like nova-api doesn’t care about firewall rules)

Thanks,
Sam

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

Re: [openstack-dev] [Ceilometer] Scale deployment

[gordon chung]

On 09/01/17 07:21 PM, Srikanth Vavilapalli wrote:
> Thanks Gordon for your inputs, Quick follow-up question: I see few new 
> alternatives existing in place of ceilometer mongo storage: Gnocchi and 
> Panko. Are these recommended data storage options from now on for Ceilometer? 
> Also, I suppose Gnocchi and Panko needs to be deployed on a separate node in 
> a cluster mode to support scale and performance. Plz let me know if otherwise.

Gnocchi is the solution for storing time-series measurement data 
(replacement for metering api). Panko is just a fork of existing event 
api in Ceilometer. in theory you can run Panko the same as you've always 
been doing. Gnocchi is a bit different and details can be found in 
docs[1]. the Ceph backend for Gnocchi is probably the most mature of 
existing storage drivers.

that said, Ceilometer is pluggable so you can just push data to your own 
datasources if you are more familiar with other stuff.

[1] http://gnocchi.xyz

cheers,

-- 
gord

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

Re: [openstack-dev] [Ceilometer] Scale deployment

[Srikanth Vavilapalli]

Thanks Gordon for your inputs, Quick follow-up question: I see few new 
alternatives existing in place of ceilometer mongo storage: Gnocchi and Panko. 
Are these recommended data storage options from now on for Ceilometer? Also, I 
suppose Gnocchi and Panko needs to be deployed on a separate node in a cluster 
mode to support scale and performance. Plz let me know if otherwise.

Thanks
Srikanth


-Original Message-
From: gordon chung [mailto:g...@live.ca] 
Sent: Monday, January 09, 2017 6:58 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Ceilometer] Scale deployment



On 08/01/17 07:28 PM, Srikanth Vavilapalli wrote:
>
> -  Deploying database cluster on separate nodes with sharding
> and replica-sets enabled
>

we don't recommend you use ceilometer storage since it's deprecated and hasn't 
been worked on for over a year.

>
>
> 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?

i don't think there is a guide line. a single agent for 3 nodes is suffice. i 
would probably just suggest you monitor notifications.* queues and if they 
start lagging, add more notification agents as required. i believe a single 
agent can handle hundreds of notifications per second.


>
> 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?

notification agents just greedily grab from queues it's subscribed to when it 
can. it'll then requeue them (if you have multiple agents and
workload_partitioning) enabled.

>
> 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?
>

ceilometer collector is not a required service and probably just adds 
more load to your rabbitmq. you can send data directly from notification 
agent using direct:// publisher (or one of the aliases if you're master.)

only suggestion i have off top of head is to enabled batching (set 
batch_size, batch_timeout in notification agent)

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

Re: [openstack-dev] [tc][goals] Microversions in OpenStack projects

[Ed Leafe]

On Jan 9, 2017, at 3:43 PM, LAM, TIN  wrote:

> As noted in [1], "Add microversion to REST APIs" is one of the cross-project
> community goals.  Given the scope and the fact there is still discussion on
> what "microversion" means to each project and the exact technical 
> implementation, what are your thoughts on the direction the community should
> take with regards to this goal.
> 
> Aside from adopting microversions, what other consistent API behaviors should
> the community be aiming for in future release? Also, is this goal a potential
> target for the Q- or R-release.

These and similar issues are discussed regularly by the API Working Group [0], 
and the Guidelines [1] we create are meant to be a summary of Best Practices 
for all OpenStack APIs. We are always looking to expand these to cover the many 
areas that are still unaddressed, so if you’d like to add something that you 
think is important, please contribute!

[0] https://wiki.openstack.org/wiki/API_Working_Group
[1] https://specs.openstack.org/openstack/api-wg/

-- Ed Leafe






__
OpenStack Development Mailing 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][bugs] Nova Bugs Team Meeting this Tuesday Cancelled

[Augustina Ragwitz]

Due to a scheduling conflict I need to cancel the next Nova Bugs Team
Meeting. The next meeting will be Tuesday,  January 23, 2017 at 1800UTC
in #openstack-meeting-4.

I've updated the meeting agenda:
https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam


-- 
Augustina Ragwitz
Señora Software Engineer
---
Waiting for your change to get through the gate? Clean up some Nova
bugs!
http://45.55.105.55:8082/bugs-dashboard.html
---
email: aragwitz+n...@pobox.com
irc: auggy

__
OpenStack Development Mailing 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] [designate] Non Candidacy for PTL - Pike

[Hayes, Graham]

Happy new year!

As you may have guessed from the subject, I have decided that the time
has come to step aside as PTL
for the upcoming cycle. It is unfortunate, but my work has pivoted in a
different direction over the last
year (containers all the way down man - but hey, I got part of my wish
to write Golang, just not on the
project I envisaged :) ).

As a result, I have been trying to PTL out of hours for the last cycle
and a half. Unfortunatly, this has had a
bad impact on this cycle, and I don't think we should repeat the pattern.

We have done some great work over the last year or so - Worker Model,
the s/Domain/Zone work,
the new dashboard, being one of the first projects to have an external
tempest plugin and getting lost in
the west of Ireland in the aftermath of the flooding.

I can honestly say, I have enjoyed my entire time with this team, from
our first meeting in Austin, back in
the beginning of 2014, the whole way through to today. We have always
been a small team, but when I think back
to what we have produced over the last few years, I am incredibly proud.

Change is healthy, and I have been in a leadership position in Designate
longer than most, and no project should
rely on a person or persons to continue to exist.

I will stick around on IRC, and still remain a member of the core review
team, as a lot of the roadmap is still in
the heads of myself and 2 or 3 others, but my main aim will be to
document the roadmap in a single place, and not
just in thousands of etherpads.

It has been a fun journey - I have gotten to work with some great
people, see some amazing places, work on really
interesting problems and contribute to a project that was close to my heart.

This is not an easy thing to do, but I think the time is right for the
project and me to let someone else make
their stamp on the project, and bring it to the next level.

Nominations close soon [0] so please start thinking about if you would
like to run or not. If anyone has any questions
about the role, please drop me an email or ping me [1] on IRC [2]

Thank you for this opportunity to serve the community for so long, it is
not something I will forget.

- Graham

0 - https://governance.openstack.org/election/
1 - mugsie
2 - #openstack-dns


__
OpenStack Development Mailing 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] [py3][devstack] being explicit about enabling python 3 for services

[Doug Hellmann]

At the BCN summit, one of the suggestions for enabling Python 3 in
devstack was to provide an explicit whitelist of services that
should be run under Python 3. The first phase of that is in [1],
which adds both a white and black list.  The automatic detection
using the python classifiers is retained, for now, until we can
either (a) decide if we still want to drop it or (b) update any
existing test jobs to use the new whitelist feature to avoid breaking
them.

The patch in [2] is a related change to ensure that all libraries
listed in LIBS_FROM_GIT are installed under both Python 2 and Python
3 so the version being edited is tested in all cases.

Doug

[1] https://review.openstack.org/418125
[2] https://review.openstack.org/418135 

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

[openstack-dev] [tc][goals] Microversions in OpenStack projects

[LAM, TIN]

As noted in [1], "Add microversion to REST APIs" is one of the cross-project
community goals.  Given the scope and the fact there is still discussion on
what "microversion" means to each project and the exact technical 
implementation, what are your thoughts on the direction the community should
take with regards to this goal.

Aside from adopting microversions, what other consistent API behaviors should
the community be aiming for in future release? Also, is this goal a potential
target for the Q- or R-release.

[1] https://etherpad.openstack.org/p/community-goals


Tin Lam
AT Integrated Cloud Engineer



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

Re: [openstack-dev] [api-wg] restarting service-types-authority / service catalog work

[Mike Perez]

On 14:10 Jan 06, Sean Dague wrote:
> Cinder / volume - right now the devstack example of using cinder is to
> use volumev2 as the service type (volumev3 is also added), which is kind
> of ugly and not a thing that I'd like us to standardize on. How do we
> move forward here to not make volumev2 a required type?

At one point I did a patch in Cinderclient to not care about the endpoint
having volumev2 as the service type, or version in the endpoint [1], with
examples of this working [2]. This was reverted [3] due to cases where a proxy
was being used and returned internal endpoints. We could probably revisit this
now that the appropriate configuration option to get around this problem has
been around for some time [4].

[1] - https://review.openstack.org/#/c/145613/
[2] - http://paste.openstack.org/raw/155906/
[3] - https://review.openstack.org/#/c/194476/
[4] - https://review.openstack.org/#/c/159374/

-- 
Mike Perez

__
OpenStack Development Mailing 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] [telemetry] [ceilometer] [panko] ceilometer API deprecation

[William M Edmonds]

It's just come to my attention that the Newton release notes indicated
deprecation of the events support in favor of Panko [1] and that it has
already been removed in master [2]. But I don't believe there were any
deprecation warnings for this in the Newton code, which is the typical way
many folks learn about deprecations. The only deprecation warning I've
found was merged after Newton released [3]. And while the official
OpenStack deprecation policy allows you to remove things in the next
release after deprecation, it also says "Note that this delay is a required
minimum. For significant features, it is recommended that the deprecated
feature appears at least in the next two stable release branches." [4]. So
a) we should have had a deprecation warning in the code to go along with
the releasenote in Newton and b) even then we probably shouldn't be
removing the event API support until Pike.

I started the conversation on IRC [5], but wanted to send this to the
mailing list and see if others have thoughts/concerns here and figure out
what we should do about this going forward.

[1]
http://docs.openstack.org/releasenotes/ceilometer/newton.html#deprecation-notes
[2]
https://github.com/openstack/ceilometer/commit/8d23f431ab0bd638edbf2197e56bea68d7b06a21
[3]
https://github.com/openstack/ceilometer/commit/6616a714009a80c7484fa2292c2331868617cb9c
[4]
https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html
[5]
http://eavesdrop.openstack.org/irclogs/%23openstack-telemetry/%23openstack-telemetry.2017-01-09.log.html#t2017-01-09T17:24:36


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

[Major Hayden]

On 01/09/2017 11:07 AM, Ian Cordasco wrote:
>> I am new to the STIG hardening process and wanted to see if there was a
>> standard way to diff between releases (RHEL STIG 7 draft 0.2 and 0.3 for
>> example) or between RHEL 5 and 6 or something. Obviously the reason for
>> this is too quickly check / implement the diff instead of going through the
>> whole STIG again.
> Hi Joel,
> 
> I'm not sure you meant to send this to the OpenStack mailing list, but
> in case you did, I don't know of a good way of doing that. That said,
> there is at least one project that attempts to automate it for you
> (openstack-ansible-security). I've CC'd one of the cores to grab their
> attention in case they can help you.

Hello Joel,

(Thanks for making the connection, Ian!)

The openstack-ansible-security role has support for the RHEL 7 STIG (version 
0.2) and I'll be doing my best to keep that updated going forward. The repo has 
a parser in it that generates documentation metadata from the giant STIG XML 
file. That should allow us to closely track any changes coming from the STIG. 
The security role would be updated when that occurs and proper release notes 
will be provided.

Here are some helpful links:

  https://github.com/openstack/openstack-ansible-security
  http://docs.openstack.org/developer/openstack-ansible-security/

If you'd like to talk on IRC, hop into #openstack-ansible and find me (mhayden).

--
Major Hayden

__
OpenStack Development Mailing 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] [ironic] this week's priorities and subteam reports

[Loo, Ruby]

Hi,

We are jazzy to present this week's priorities and subteam report for Ironic. 
As usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. attach/detach: review code, needs done ASAP to unblock nova stuff before 
freeze: https://review.openstack.org/#/q/topic:bug/1582188+status:open
2. nova code for portgroups and attach/detach: 
https://review.openstack.org/#/c/364413/ and 
https://review.openstack.org/#/c/388756/
3. client patch for soft power/reboot: https://review.openstack.org/#/c/357627/ 
to unblock the nova patch: https://review.openstack.org/#/c/407977/
4. ironic-lib queue: 
https://review.openstack.org/#/q/status:open+project:openstack/ironic-lib
5. Continue reviewing driver composition things: 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1524745
6. boot from volume: next up: 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1559691
7. Rolling upgrades work: 
https://review.openstack.org/#/q/topic:bug/1526283+status:open
8. Work to test UEFI: https://review.openstack.org/#/c/414227/ (Ironic), 
https://review.openstack.org/#/c/414604/ (Devstack).


Bugs (dtantsur)
===
- Stats (diff between 19 Dec 2016 and 09 Jan 2017)
- Ironic: 223 bugs (+5) + 238 wishlist items (+5). 14 new (+5), 192 in progress 
(+6), 0 critical, 28 high (-1) and 26 incomplete (-2)
- Inspector: 12 bugs (+1) + 23 wishlist items (+1). 0 new, 12 in progress, 0 
critical (-1), 2 high (+1) and 5 incomplete (+1)
- Nova bugs with Ironic tag: 10. 0 new, 0 critical, 0 high

Portgroups support (sambetts, vdrok)

* trello: https://trello.com/c/KvVjeK5j/29-portgroups-support
- status as of most recent weekly meeting:
- just one patch left on the ironic side (OSC): 
https://review.openstack.org/#/q/topic:bug/1618754 merged
- Another one needed is adding mode/properties to the portgroups in client, 
will be done soon :)
- once those land, will need a client release and then nova patches
- note that the nova patch cannot land until after the attach/detach 
API nova-patch lands

Interface attach/detach API (sambetts)
==
* trello: https://trello.com/c/nryU4w58/39-interface-attach-detach-api
- status as of most recent weekly meeting:
- Spec merged and Nova BP approved
- Last Ironic patch up for review: https://review.openstack.org/#/c/404240/
- Rebasing in progress (sambetts)
- IronicClient patch - https://review.openstack.org/364420
- Nova patch needs updating based on IronicClient patch and can't merge 
until we make a client release including the above patch - 
https://review.openstack.org/364413

CI refactoring (dtantsur, lucasagomes)
==
* trello: https://trello.com/c/c96zb3dm/32-ci-refactoring
- status as of most recent weekly meeting:
- We need to move the logic of setting the default image from DevStack into 
Ironic to be able to set a UEFI compatible image, patches are: 
https://review.openstack.org/#/c/414227/ (Ironic), 
https://review.openstack.org/#/c/414604/ (Devstack)

Rolling upgrades and grenade-partial (rloo, jlvillal)
=
* trello: 
https://trello.com/c/GAlhSzLm/2-rolling-upgrades-and-grenade-with-multi-node
- status as of most recent weekly meeting:
- RFE for online-db-migration, approved: 
https://bugs.launchpad.net/ironic/+bug/1585141
- patches need reviews: https://review.openstack.org/#/q/topic:bug/1526283
- Testing work:
- Tempest "smoke" is now working for multi-tenant / multi-node
- Patch up to enable tempest "smoke" for the multi-node job
- https://review.openstack.org/417959
- Next step Grenade
- Work is ongoing for enabling Grenade with multi-tenant: 
https://review.openstack.org/389268

Generic boot-from-volume (TheJulia)
===
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- status as of most recent weekly meeting:
- API side changes for volume connector information have a procedural -2 
until we can begin making use of the data in the conductor, but should stil be 
reviewed
- https://review.openstack.org/#/c/214586/
- This change will need to be rebased on top of the storage interface 
work so we can begin working towards a single chain of revisions to build 
testing against. +1
- Boot from volume/storage interface work needs to be updated, TheJulia 
will be doing that this week
- 
https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1559691

Driver composition (dtantsur)
=
* trello: https://trello.com/c/fTya14y6/14-driver-composition
- gerrit topic: 

Re: [openstack-dev] [all][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)

[John Villalovos]

On Mon, Jan 2, 2017 at 1:06 PM, Davanum Srinivas  wrote:

> Folks,
>
> Other teams:
> Please consider adding DSVM jobs with USE_PYTHON3=True for your
> projects. This will hopefully help us get to our Pike goal for Python
> 3.x [10]
>
>
As a note the variable name for DSVM jobs has been changed to:
DEVSTACK_GATE_USE_PYTHON3=True
__
OpenStack Development Mailing 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

[Afek, Ifat (Nokia - IL)]

Hi Yujun,

I understand the use case now, thanks for the detailed explanation.

Supporting this use case will require some development in Vitrage. Let me try 
to list down the requirements and options that we have.


1.   Requirement: Raise ‘suspect’ deduced alarms in Vitrage.

Implementation: Quite straight forward. There is no way to set ‘suspect’ 
property in Vitrage right now, but it should be easy to add this option.



2.   Requirement: Change a ‘suspect’ alarm of type ‘vitrage’ to a ‘real’ 
alarm of type ‘nagios’.

Implementation: There are a few alternatives how to achieve this goal



a.   Delete the ‘suspect’ alarm and create the ‘real’ alarm. This will 
require supporting ‘not’ condition in the templates. An example scenario:

condition: vm_alarm and not nagios_alarm:

   (action: create vitrage alarm)

condition: nagios_alarm and vitrage_alarm:

   (action: delete vitrage_alarm)



b.   Have both ‘suspect’ alarm and ‘real’ alarm, and create a ‘equivalent’ 
relationship between them. Configuring the template should be easy, however it 
won’t look nice in the UI. In past discussions we mentioned an option to group 
some vertices together in the UI. If we have this option, we might want to 
group these two alarms together.



c.   Merge the two alarms. This solution seems the most reasonable one at 
first, but it is not trivial. For example: suppose one alarm is defined as 
‘critical’ and was raised at 10:01, and the other alarm was defined as 
‘warning’ and was raised at 10:02. How will you combine the two? And what if 
the ‘critical’ alarm then goes down, will you know how to change the severity 
back to ‘warning’? in case of vitrage vs. nagios we would like to prefer 
nagios; but let’s think of the more general case of two different monitors.


3.   In one of your emails you mentioned an option of having two 
‘suspects’. Suppose vm_alarm is raised, will you raise two suspect vitrage 
alarms, e.g. host_alarm and switch_alarm? And if you then receive host_alarm 
from nagios, would you like to delete the suspect switch_alarm, or keep it? If 
you would like to delete it, it will require supporting ‘not’ in the template 
condition.

Personally I would go for option 2b, but I will be happy to hear your thoughts 
about it.

Hope I helped, but I suspect I just made things more complicated ;-)
Ifat.


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

Date: Sunday, 8 January 2017 at 17:38
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: "han.jin...@zte.com.cn" , "wang.we...@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

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 

Re: [openstack-dev] [heat] glance v2 support?

[Monty Taylor]

On 01/09/2017 05:15 AM, Flavio Percoco wrote:
> On 06/01/17 09:34 +0530, Rabi Mishra wrote:
>> On Fri, Jan 6, 2017 at 4:38 AM, Emilien Macchi 
>> wrote:
>>
>>> Greetings Heat folks!
>>>
>>> My question is simple:
>>> When do you plan to support Glance v2?
>>> https://review.openstack.org/#/c/240450/
>>>
>>> The spec looks staled while Glance v1 was deprecated in Newton (and v2
>>> was started in Kilo!).
>>>
>>>
>> Hi Emilien,
>>
>> I think we've not been able to move to v2 due to v1/v2 incompatibility[1]
>> with respect to the location[2] property. Moving to v2 would break all
>> existing templates using that property.
>>
>> I've seen several discussions around that without any conclusion.  I
>> think
>> we can support a separate v2 image resource and deprecate the current
>> one,
>> unless there is a better path available.
> 
> Hi Rabi,
> 
> Could you elaborate on why Heat depends on the location attribute? I'm not
> familiar with Heat and knowing this might help me to propose something
> (or at
> least understand the difficulties).
> 
> I don't think putting this on hold will be of any help. V1 ain't coming
> back and
> the improvements for v2 are still under heavy coding. I'd probably
> recommend
> moving to v2 with a proper deprecation path rather than sticking to v1.

I'm going to agree with Flavio here. However, it's worth noting what Tim
said:


> Would this be backwards compatible (i.e. the old image resource would
> still work without taking advantage of the new functions) or would heat
> users have to change their templates?
>
> It would be good if there is a way to minimise the user impact.

Which I also agree with.

Normally I'd say that heat could be clever and code around such a thing
- but from v1 to v2 the entire concept of an external image location was
removed, so there is no possibility of compat. While I love to rant
about breaking compat ... this is, at this point, a _VERY_ old break
that happened back when people thought it was ok for us to release new
Major versions of OpenStack APIs. We no longer think that - but the
glance v2, cinder v2/3 and keystone v3 are essentially all water under
the bridge. (for the record, I believe you can find an argument between
bcwaldon and I from the folsom/grizzly time frame about the evils of
major version bumps, but I lost the argument at the time)

Honestly, I'd just add an error message if someone tries to use the
location field on a glance v2 cloud that says:

"This cloud does not support referencing external or pre-existing image
locations. Please upload the image directly to glance." - with maybe a
link to a doc page that explains how to write a template that does the
new thing.

Heat users using heat to upload images are going to have to rewrite
their templates to deal with direct upload rather than external
reference at some point. It's not going to get any easier for them the
longer we let them continue to shoot themselves in the foot by using the
location field.

Monty



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

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Andrey Kurilin]

On Mon, Jan 9, 2017 at 6:37 PM, Flavio Percoco  wrote:

> On 09/01/17 17:55 +0200, Andrey Kurilin wrote:
>
>> Hi, Flavio!
>>
>> Does it possible to create badges per project release?
>>
>
> mmh, it's currently not possible.
>
> Could you elaborate on why you need a specific tag per release? IS it to
> tag the
> releases that were done after the inclusion in the big tent?
>
>
OpenStack has a bunch of different tags. "the inclusion in the big tent" is
one of tags that should not match to all project releases once project did
it.
Another one is a "single-vendor" and so on. I think most of tags should be
applied per project release.

One more "feature request": creation of custom badges(I'm interested in
"tested on %(operation_system)s".


> Flavio
>
>
> On Mon, Jan 9, 2017 at 3:23 PM, Flavio Percoco  wrote:
>>
>> Just a heads up!
>>>
>>> There are still unmerged patches on this effort. If you have a couple of
>>> spare
>>> brain cycles, it'd be awesome to get the patches relative to the projects
>>> you've
>>> +2 votes on in.
>>>
>>> I'll proceed to abandon remaining patches in 2 weeks from now assuming
>>> that
>>> projects are not interested in having them. As I mentioned in previous
>>> emails,
>>> you're free to update the patches to match your project needs.
>>>
>>> Here's the link to see the remaining patches:
>>> https://review.openstack.org/#/q/status:open+topic:project-badges
>>>
>>> Thanks a lot,
>>> Flavio
>>>
>>>
>>> On 12/10/16 14:50 +0200, Flavio Percoco wrote:
>>>
>>> Greetings,

 One of the common complains about the existing project organization in
 the big
 tent is that it's difficult to wrap our heads around the many projects
 there
 are, their current state (in/out the big tent), their tags, etc.

 This information is available on the governance website[0]. Each
 official
 project team has a page there containing the information related to the
 deliverables managed by that team. Unfortunately, I don't think this
 page
 is
 checked often enough and I believe it's not known by everyone.

 In the hope that we can make this information clearer to people browsing
 the
 many repos (most likely on github), I'd like to propose that we include
 the
 information of each deliverable in the readme file. This information
 would be
 rendered along with the rest of the readme (at least on Github, which
 might not
 be our main repo but it's the place most humans go to to check our
 projects).

 Rather than duplicating this information, I'd like to find a way to just
 "include it" in the Readme file. As far as showing the "official" badge
 goes, I
 believe it'd be quite simple. We can do it the same way CI tags are
 exposed when
 using travis (just include an image). As for the rest of the tags, it
 might
 require some extra hacking.

 So, before I start digging more into this, I wanted to get other
 opinions/ideas
 on this topic and how we can make this information more evident to the
 rest of
 the community (and people not as familiar with our processes as some of
 us are).

 Thanks in advance,
 Flavio

 [0] http://governance.openstack.org/reference/projects/index.html

 --
 @flaper87
 Flavio Percoco


>>>
>>>
>>> --
>>> @flaper87
>>> Flavio Percoco
>>>
>>> 
>>> __
>>> 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
>>>
>>>
>>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>>
>
> __
>> 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
>>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing 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] STIG Tools

[Ian Cordasco]

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

Date: January 9, 2017 at 10:25:36
To: openstack-dev@lists.openstack.org 
Subject:  [openstack-dev] STIG Tools

> I am new to the STIG hardening process and wanted to see if there was a
> standard way to diff between releases (RHEL STIG 7 draft 0.2 and 0.3 for
> example) or between RHEL 5 and 6 or something. Obviously the reason for
> this is too quickly check / implement the diff instead of going through the
> whole STIG again.

Hi Joel,

I'm not sure you meant to send this to the OpenStack mailing list, but
in case you did, I don't know of a good way of doing that. That said,
there is at least one project that attempts to automate it for you
(openstack-ansible-security). I've CC'd one of the cores to grab their
attention in case they can help you.

Cheers,
--
Ian Cordasco

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

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Flavio Percoco]

On 09/01/17 17:55 +0200, Andrey Kurilin wrote:

Hi, Flavio!

Does it possible to create badges per project release?


mmh, it's currently not possible.

Could you elaborate on why you need a specific tag per release? IS it to tag the
releases that were done after the inclusion in the big tent?

Flavio


On Mon, Jan 9, 2017 at 3:23 PM, Flavio Percoco  wrote:


Just a heads up!

There are still unmerged patches on this effort. If you have a couple of
spare
brain cycles, it'd be awesome to get the patches relative to the projects
you've
+2 votes on in.

I'll proceed to abandon remaining patches in 2 weeks from now assuming that
projects are not interested in having them. As I mentioned in previous
emails,
you're free to update the patches to match your project needs.

Here's the link to see the remaining patches:
https://review.openstack.org/#/q/status:open+topic:project-badges

Thanks a lot,
Flavio


On 12/10/16 14:50 +0200, Flavio Percoco wrote:


Greetings,

One of the common complains about the existing project organization in
the big
tent is that it's difficult to wrap our heads around the many projects
there
are, their current state (in/out the big tent), their tags, etc.

This information is available on the governance website[0]. Each official
project team has a page there containing the information related to the
deliverables managed by that team. Unfortunately, I don't think this page
is
checked often enough and I believe it's not known by everyone.

In the hope that we can make this information clearer to people browsing
the
many repos (most likely on github), I'd like to propose that we include
the
information of each deliverable in the readme file. This information
would be
rendered along with the rest of the readme (at least on Github, which
might not
be our main repo but it's the place most humans go to to check our
projects).

Rather than duplicating this information, I'd like to find a way to just
"include it" in the Readme file. As far as showing the "official" badge
goes, I
believe it'd be quite simple. We can do it the same way CI tags are
exposed when
using travis (just include an image). As for the rest of the tags, it
might
require some extra hacking.

So, before I start digging more into this, I wanted to get other
opinions/ideas
on this topic and how we can make this information more evident to the
rest of
the community (and people not as familiar with our processes as some of
us are).

Thanks in advance,
Flavio

[0] http://governance.openstack.org/reference/projects/index.html

--
@flaper87
Flavio Percoco





--
@flaper87
Flavio Percoco

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





--
Best regards,
Andrey Kurilin.



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



--
@flaper87
Flavio Percoco


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] [docs][badges][all] Docs gate broken for projects that include README.rst in docs

[Flavio Percoco]

On 09/01/17 15:02 +0100, Andreas Jaeger wrote:

On 2016-12-12 09:22, Flavio Percoco wrote:

On 11/12/16 13:32 +0100, Flavio Percoco wrote:

On 09/12/16 17:20 +0100, Flavio Percoco wrote:

Greetings,

Some docs jobs seem to be broken by the latest (or not?) docutils
release. The
breakage seems to be related to the latest addition of the bages
patch. The docs
generation doesn't like to have remote images. It used to be a
warning but it
seems to have turned into an error now. While this is reported and fixed
upstream, we can workaround the issue by tagging the image as remote.

An example of this fix can be found here:
https://review.openstack.org/#/q/topic:readme-badge-fix

Note that this is mostly relevant for projects that include the
readme files in
their documentation. If your project doesn't do it, you can ignore
this email.
That said, I'd recommend all projects to do it.



Apparently this "fix" doesn't render the image, which is far from the
ideal
solution. Hang on while we find a better fix.


Ok, here's the actual "fix" for this issue. We're now skipping version
0.13.1 of
docutils as that's breaking several docs dates. if your project is using
the
requirements constraints, you should not be hitting this issue. However,
if your
project isn't using the upper constraints, then you may want to do
something
similar to this[0][1].

This issue has been reported upstream [2]

[0] https://review.openstack.org/#/c/409630/
[1] https://review.openstack.org/#/c/409529/
[2] https://sourceforge.net/p/docutils/bugs/301/


I see that upstream has closed the issues with "Fixed in Sphinx 1.5.1".

Should we update Sphinx to 1.5.1? Anybody wants to go for it? Right now,
the global requirements file has:

global-requirements.txt:sphinx>=1.2.1,!=1.3b1,<1.4  # BSD



Happy to help here,
Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] STIG Tools

[Joel Parker]

I am new to the STIG hardening process and wanted to see if there was a
standard way to diff between releases (RHEL STIG 7 draft 0.2 and 0.3 for
example) or between RHEL 5 and 6 or something. Obviously the reason for
this is too quickly check / implement the diff instead of going through the
whole STIG again.
__
OpenStack Development Mailing 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] PTL nominations deadline and non-candidacy

[Nate Johnston]

Thank you Armando for your leadership in transforming the Stadium, for always
being being helpful and patient shepherding a gaggle of small projects.  You
set an example for how to deal with difficult Layer 8 and Layer 9 issues[1].
Thank you for your leadership and your service.  

--N.

[1] https://en.wikipedia.org/wiki/Layer_8 if you've hever heard the term before

On Mon, Jan 09, 2017 at 03:11:01PM +0100, Armando M. wrote:
> Hi neutrinos,
> 
> The PTL nomination week is fast approaching [0], and as you might have
> guessed by the subject of this email, I am not planning to run for Pike. If
> I look back at [1], I would like to think that I was able to exercise the
> influence on the goals I set out with my first self-nomination [2].
> 
> That said, when it comes to a dynamic project like neutron one can't never
> claim to be *done done* and for this reason, I will continue to be part of
> the neutron core team, and help the future PTL drive the next stage of the
> project's journey.
> 
> I must admit, I don't write this email lightly, however I feel that it is
> now the right moment for me to step down, and give someone else the
> opportunity to grow in the amazing role of neutron PTL! I have certainly
> loved every minute of it!
> 
> Cheers,
> Armando
> 
> [0] https://releases.openstack.org/ocata/schedule.html
> [1] https://review.openstack.org/#/q/project:openstack/elect
> ion+owner:armando-migliaccio
> [2] https://review.openstack.org/#/c/223764/

> __
> OpenStack Development Mailing 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][tc] Exposing project team's metadata in README files

[Andrey Kurilin]

Hi, Flavio!

Does it possible to create badges per project release?

On Mon, Jan 9, 2017 at 3:23 PM, Flavio Percoco  wrote:

> Just a heads up!
>
> There are still unmerged patches on this effort. If you have a couple of
> spare
> brain cycles, it'd be awesome to get the patches relative to the projects
> you've
> +2 votes on in.
>
> I'll proceed to abandon remaining patches in 2 weeks from now assuming that
> projects are not interested in having them. As I mentioned in previous
> emails,
> you're free to update the patches to match your project needs.
>
> Here's the link to see the remaining patches:
> https://review.openstack.org/#/q/status:open+topic:project-badges
>
> Thanks a lot,
> Flavio
>
>
> On 12/10/16 14:50 +0200, Flavio Percoco wrote:
>
>> Greetings,
>>
>> One of the common complains about the existing project organization in
>> the big
>> tent is that it's difficult to wrap our heads around the many projects
>> there
>> are, their current state (in/out the big tent), their tags, etc.
>>
>> This information is available on the governance website[0]. Each official
>> project team has a page there containing the information related to the
>> deliverables managed by that team. Unfortunately, I don't think this page
>> is
>> checked often enough and I believe it's not known by everyone.
>>
>> In the hope that we can make this information clearer to people browsing
>> the
>> many repos (most likely on github), I'd like to propose that we include
>> the
>> information of each deliverable in the readme file. This information
>> would be
>> rendered along with the rest of the readme (at least on Github, which
>> might not
>> be our main repo but it's the place most humans go to to check our
>> projects).
>>
>> Rather than duplicating this information, I'd like to find a way to just
>> "include it" in the Readme file. As far as showing the "official" badge
>> goes, I
>> believe it'd be quite simple. We can do it the same way CI tags are
>> exposed when
>> using travis (just include an image). As for the rest of the tags, it
>> might
>> require some extra hacking.
>>
>> So, before I start digging more into this, I wanted to get other
>> opinions/ideas
>> on this topic and how we can make this information more evident to the
>> rest of
>> the community (and people not as familiar with our processes as some of
>> us are).
>>
>> Thanks in advance,
>> Flavio
>>
>> [0] http://governance.openstack.org/reference/projects/index.html
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing 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] [Performance] PTG?

[Andrey Kurilin]

Here[*] you can find an etherpad of Performance team. I think Rally team
will re-use it.

[*] - https://etherpad.openstack.org/p/ptg-performance-team

On Sat, Jan 7, 2017 at 9:35 PM, Joe Talerico  wrote:

> Hey Andrey - Is there a shared etherpad for the Rally/Performance days?
>
> Thanks,
> Joe
>
> On Wed, Jan 4, 2017 at 11:01 AM, Andrey Kurilin 
> wrote:
> > Hi, Joe!
> >
> > It is not a mistake. After a talk with Dina B., we decided to extend
> Rally
> > session for the wider
> > audience and I requested "Rally & Performance team" session.
> >
> > On Wed, Jan 4, 2017 at 5:29 PM, Joe Talerico 
> wrote:
> >>
> >> When I signed up to attend the PTG, Performance was not listed as a
> >> option, however on the website it clearly shows Performance is
> >> Monday-Tuesday.
> >>
> >> Is this just a mistake in the event website?
> >>
> >> Joe
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Best regards,
> > Andrey Kurilin.
> >
> > 
> __
> > OpenStack Development Mailing 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
>



-- 
Best regards,
Andrey Kurilin.
__
OpenStack Development Mailing 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]

+1

From: Ligong LG1 Duan [mailto:duan...@lenovo.com]
Sent: Sunday, January 08, 2017 7:41 PM
To: OpenStack Development Mailing List (not for usage questions) 

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

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 
>
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 
>
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 >, Lauren 
Sell >
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] [Ceilometer] Scale deployment

[gordon chung]

On 08/01/17 07:28 PM, Srikanth Vavilapalli wrote:
>
> -  Deploying database cluster on separate nodes with sharding
> and replica-sets enabled
>

we don't recommend you use ceilometer storage since it's deprecated and 
hasn't been worked on for over a year.

>
>
> 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?

i don't think there is a guide line. a single agent for 3 nodes is 
suffice. i would probably just suggest you monitor notifications.* 
queues and if they start lagging, add more notification agents as 
required. i believe a single agent can handle hundreds of notifications 
per second.


>
> 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?

notification agents just greedily grab from queues it's subscribed to 
when it can. it'll then requeue them (if you have multiple agents and 
workload_partitioning) enabled.

>
> 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?
>

ceilometer collector is not a required service and probably just adds 
more load to your rabbitmq. you can send data directly from notification 
agent using direct:// publisher (or one of the aliases if you're master.)

only suggestion i have off top of head is to enabled batching (set 
batch_size, batch_timeout in notification agent)

cheers,

-- 
gord

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

Re: [openstack-dev] [neutron] PTL nominations deadline and non-candidacy

[John Davidge]

On 1/9/17, 2:11 PM, "Armando M."  wrote:

>Hi neutrinos,
>
>The PTL nomination week is fast approaching [0], and as you might have
>guessed by the subject of this email, I am not planning to run for Pike.
>If I look back at [1], I would like to think that I was able to exercise
>the influence on the goals I set out
> with my first self-nomination [2].
>
>That said, when it comes to a dynamic project like neutron one can't
>never claim to be *done done* and for this reason, I will continue to be
>part of the neutron core team, and help the future PTL drive the next
>stage of the project's journey.
>
>I must admit, I don't write this email lightly, however I feel that it is
>now the right moment for me to step down, and give someone else the
>opportunity to grow in the amazing role of neutron PTL! I have certainly
>loved every minute of it!
>
>Cheers,
>Armando
>
>[0] https://releases.openstack.org/ocata/schedule.html
>[1]
>https://review.openstack.org/#/q/project:openstack/election+owner:armando-
>migliaccio
>[2] https://review.openstack.org/#/c/223764/
>

We’re all doomed! DOOMED!

But seriously, thank you for all of the work you’ve put into leading
neutron for as long as you have. Your decisiveness on various issues has
allowed development to continue at pace rather than always getting bogged
down in never ending debates.

This blow is softened only by the knowledge that there are some excellent
potential candidates who are ready (and willing?) to step into the role.

Thank you, and I’m looking forward to your continued contributions.

John



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing 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?

[Emilien Macchi]

On Tue, Jan 3, 2017 at 9:08 AM, Emilien Macchi  wrote:

> (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.
>

We've picked up this question:
"As a user/operator, do you value having a common interface for deployment
tooling and the deployed cloud (e.g common APIs and CLI tools)?"

With multiple answers:
Yes definitely
Yes, but not required
No opinion
No, it's a bad idea.

Thanks for the folks involved in this survey!


> Thanks,
>
> -- Forwarded message --
> From: Heidi Joy Tretheway 
> 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 , Lauren Sell <
> 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: photo]
> *Heidi Joy Tretheway*
> Senior Marketing Manager, OpenStack Foundation
> 503 816 9769 | Skype: heidi.tretheway
> 
> 
>   
>
>
>
>
>
>
> --
> Emilien Macchi
>



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

Re: [openstack-dev] [neutron] PTL nominations deadline and non-candidacy

[Kevin Benton]



Thank you for being PTL for as long as you did. If it weren't for your
effort with the vendor and advanced services decomposition, Neutron would
have died under review load. I hope this means we'll be seeing more code
from you! :)

On Mon, Jan 9, 2017 at 6:11 AM, Armando M.  wrote:

> Hi neutrinos,
>
> The PTL nomination week is fast approaching [0], and as you might have
> guessed by the subject of this email, I am not planning to run for Pike. If
> I look back at [1], I would like to think that I was able to exercise the
> influence on the goals I set out with my first self-nomination [2].
>
> That said, when it comes to a dynamic project like neutron one can't never
> claim to be *done done* and for this reason, I will continue to be part of
> the neutron core team, and help the future PTL drive the next stage of the
> project's journey.
>
> I must admit, I don't write this email lightly, however I feel that it is
> now the right moment for me to step down, and give someone else the
> opportunity to grow in the amazing role of neutron PTL! I have certainly
> loved every minute of it!
>
> Cheers,
> Armando
>
> [0] https://releases.openstack.org/ocata/schedule.html
> [1] https://review.openstack.org/#/q/project:openstack/elect
> ion+owner:armando-migliaccio
> [2] https://review.openstack.org/#/c/223764/
>
> __
> OpenStack Development Mailing 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] PTL nominations deadline and non-candidacy

[Dariusz Śmigiel]

2017-01-09 8:11 GMT-06:00 Armando M. :
> Hi neutrinos,
>
> The PTL nomination week is fast approaching [0], and as you might have
> guessed by the subject of this email, I am not planning to run for Pike. If
> I look back at [1], I would like to think that I was able to exercise the
> influence on the goals I set out with my first self-nomination [2].
>
> That said, when it comes to a dynamic project like neutron one can't never
> claim to be *done done* and for this reason, I will continue to be part of
> the neutron core team, and help the future PTL drive the next stage of the
> project's journey.
>
> I must admit, I don't write this email lightly, however I feel that it is
> now the right moment for me to step down, and give someone else the
> opportunity to grow in the amazing role of neutron PTL! I have certainly
> loved every minute of it!
>
> Cheers,
> Armando
>
> [0] https://releases.openstack.org/ocata/schedule.html
> [1]
> https://review.openstack.org/#/q/project:openstack/election+owner:armando-migliaccio
> [2] https://review.openstack.org/#/c/223764/
>

Armando,
Sad to see you're stepping down. Thanks for your time and guidance as
neutron PTL.

Dariusz

__
OpenStack Development Mailing 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] PTL nominations deadline and non-candidacy

[Armando M.]

Hi neutrinos,

The PTL nomination week is fast approaching [0], and as you might have
guessed by the subject of this email, I am not planning to run for Pike. If
I look back at [1], I would like to think that I was able to exercise the
influence on the goals I set out with my first self-nomination [2].

That said, when it comes to a dynamic project like neutron one can't never
claim to be *done done* and for this reason, I will continue to be part of
the neutron core team, and help the future PTL drive the next stage of the
project's journey.

I must admit, I don't write this email lightly, however I feel that it is
now the right moment for me to step down, and give someone else the
opportunity to grow in the amazing role of neutron PTL! I have certainly
loved every minute of it!

Cheers,
Armando

[0] https://releases.openstack.org/ocata/schedule.html
[1] https://review.openstack.org/#/q/project:openstack/elect
ion+owner:armando-migliaccio
[2] https://review.openstack.org/#/c/223764/
__
OpenStack Development Mailing 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][badges][all] Docs gate broken for projects that include README.rst in docs

[Andreas Jaeger]

On 2016-12-12 09:22, Flavio Percoco wrote:
> On 11/12/16 13:32 +0100, Flavio Percoco wrote:
>> On 09/12/16 17:20 +0100, Flavio Percoco wrote:
>>> Greetings,
>>>
>>> Some docs jobs seem to be broken by the latest (or not?) docutils
>>> release. The
>>> breakage seems to be related to the latest addition of the bages
>>> patch. The docs
>>> generation doesn't like to have remote images. It used to be a
>>> warning but it
>>> seems to have turned into an error now. While this is reported and fixed
>>> upstream, we can workaround the issue by tagging the image as remote.
>>>
>>> An example of this fix can be found here:
>>> https://review.openstack.org/#/q/topic:readme-badge-fix
>>>
>>> Note that this is mostly relevant for projects that include the
>>> readme files in
>>> their documentation. If your project doesn't do it, you can ignore
>>> this email.
>>> That said, I'd recommend all projects to do it.
>>
>>
>> Apparently this "fix" doesn't render the image, which is far from the
>> ideal
>> solution. Hang on while we find a better fix.
> 
> Ok, here's the actual "fix" for this issue. We're now skipping version
> 0.13.1 of
> docutils as that's breaking several docs dates. if your project is using
> the
> requirements constraints, you should not be hitting this issue. However,
> if your
> project isn't using the upper constraints, then you may want to do
> something
> similar to this[0][1].
> 
> This issue has been reported upstream [2]
> 
> [0] https://review.openstack.org/#/c/409630/
> [1] https://review.openstack.org/#/c/409529/
> [2] https://sourceforge.net/p/docutils/bugs/301/

I see that upstream has closed the issues with "Fixed in Sphinx 1.5.1".

Should we update Sphinx to 1.5.1? Anybody wants to go for it? Right now,
the global requirements file has:

global-requirements.txt:sphinx>=1.2.1,!=1.3b1,<1.4  # BSD

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


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

Re: [openstack-dev] [glance][tempest][api] community images, tempest tests, and API stability

[Brian Rosmaita]

On 1/5/17 10:19 AM, Brian Rosmaita wrote:
> To anyone interested in this discussion: I put it on the agenda for
> today's API-WG meeting (16:00 UTC):
> 
> https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda

As you probably noticed in the API-WG newsletter [A], this issue was
discussed at last week's API-WG meeting.  The complete discussion is in
the meeting log [B], but the tldr; is that the proposed change is
acceptable.  I'll address specific points inline for those who are
interested, but the key request from the Glance team right now is that
the QA team approve this patch:

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


[A]
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109698.html
[B]
http://eavesdrop.openstack.org/meetings/api_wg/2017/api_wg.2017-01-05-16.00.log.html

> On 12/25/16 12:04 PM, GHANSHYAM MANN wrote:
>> Thanks Brian for bringing this up, same we been discussing last week on QA
>> channel and this patch[1] but I completely agree with Matthew opinion here.
>> There is no doubt that this change(4-valued) are much better and clear than
>> old one. This makes much defined and clear way of defining the image
>> visibility by/for operator/user.

Yes, we think that the change clarifies the visibility semantics of
images and, in particular, fixes the problem of there being "private"
images that aren't actually private.

The current situation is easily misunderstood by end users, as evidenced
by bugs that have been filed, for example,
https://bugs.launchpad.net/glance/+bug/1394299
https://bugs.launchpad.net/glance/+bug/1452443

>> Upgrade procedure defined in all referenced ML/spec looks fine for
>> redefining the visibility for images with or without members to
>> shared/private. Operator feedback/acceptance for this change makes it
>> acceptable.

Thanks, we discussed this thoroughly and solicited operator feedback.

>> But operator/users creating images with visibility as "private"
>> *explicitly*, this changes is going to break them:
>>
>> - Images with member already added in that would not works
>> as Tempest tests does [2].
>>
>> - They cannot add member as they used to do that.

Yes, we recognize that this change will introduce an incompatibility in
the workflow for users who are setting visibility explicitly to
'private' upon image creation.  The positive side to this change,
however, is that when a user requests a private image, that's what
they'll get.  It's important to note that the default visibility value
will allow the current create-and-immediately-share workflow to continue
exactly as it does now.

One way to see how small this change is in context is to look at how it
will appear in release notes:

https://etherpad.openstack.org/p/glance-ocata-sharing-release-note-draft

The incompatibility you're worried about is explained at line 8.

>> First one is being something tested by Tempest and which is valid tests as
>> per current behaviour of API
>>
>> There might be lot of operators will be doing the same and going to be
>> broken after this. We really need to think about this change as API
>> backward incompatible pov where upgrade Cloud with new visibility
>> definition is all ok but it break the way of usage(Image of Private
>> visibility explicitly with added members).

It's possible that some scripts will break, but it's important to note
that the default visibility upon image creation will allow the current
workflow to succeed.  While that's small consolation to those whose
scripts may break, the plus side is that image visibility changes will
now occur in a uniform way for all visibility values with no "magic"
changes occurring as a side effect of a different API call.

>> After looking into glance API versioning mechanism, it seems /v2 points to
>> latest version irrespective of version includes backward compatible or
>> incompatible changes. I mean users cannot lock API on old version (say they
>> want only v2.2). How glance introduced backward incompatible changes?
>>
>> I am not sure why it is not done like api-wg suggested microversion way
>> (like nova). I know glance API versioning is much older but when there are
>> some better improvement coming like this community image change, I feel it
>> should be done with backward compatible way in microversion.

Not everyone in the Glance community is on board with the microversion
movement.  But also, I'm not convinced that microversions would be an
acceptable solution to this situation.  From Ocata on, we want 'private'
to mean "private"; users have to take an extra step to update the
visibility to 'shared' before an image will accept members.  I don't
think a user who expects that behavior will appreciate a pre-Ocata
client that can bypass this safety mechanism and simply add members to
private images.

>> Tempest testing the old behaviour is something very valid here and we
>> should not change that to introduced backward incompatible changes which
>> going to break 

Re: [openstack-dev] [nova] placement/resource providers update 7

[Chris Dent]

On Fri, 6 Jan 2017, Chris Dent wrote:


* CORS support in placement API:
 https://review.openstack.org/#/c/392891/


This is one we should probably get in in Ocata because it enables
the sole piece of configurability that is present in the WSGI
middleware stack used for the placement API. Unlike nova-api, no
paste.ini file is used. In order to add CORS to the placement API,
this change is required. It will check for cors config in the
*.conf file, and if present, include the middleware.

One can image some rather nice javascript-driver single page
applications (or otherwise) that read the placement API to provide
overviews of resource data. Such things are made a lot easier by
having CORS in the picture.

--
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] [all][tc] Exposing project team's metadata in README files

[Flavio Percoco]

Just a heads up!

There are still unmerged patches on this effort. If you have a couple of spare
brain cycles, it'd be awesome to get the patches relative to the projects you've
+2 votes on in.

I'll proceed to abandon remaining patches in 2 weeks from now assuming that
projects are not interested in having them. As I mentioned in previous emails,
you're free to update the patches to match your project needs.

Here's the link to see the remaining patches:
https://review.openstack.org/#/q/status:open+topic:project-badges

Thanks a lot,
Flavio


On 12/10/16 14:50 +0200, Flavio Percoco wrote:

Greetings,

One of the common complains about the existing project organization in the big
tent is that it's difficult to wrap our heads around the many projects there
are, their current state (in/out the big tent), their tags, etc.

This information is available on the governance website[0]. Each official
project team has a page there containing the information related to the
deliverables managed by that team. Unfortunately, I don't think this page is
checked often enough and I believe it's not known by everyone.

In the hope that we can make this information clearer to people browsing the
many repos (most likely on github), I'd like to propose that we include the
information of each deliverable in the readme file. This information would be
rendered along with the rest of the readme (at least on Github, which might not
be our main repo but it's the place most humans go to to check our projects).

Rather than duplicating this information, I'd like to find a way to just
"include it" in the Readme file. As far as showing the "official" badge goes, I
believe it'd be quite simple. We can do it the same way CI tags are exposed when
using travis (just include an image). As for the rest of the tags, it might
require some extra hacking.

So, before I start digging more into this, I wanted to get other opinions/ideas
on this topic and how we can make this information more evident to the rest of
the community (and people not as familiar with our processes as some of us are).

Thanks in advance,
Flavio

[0] http://governance.openstack.org/reference/projects/index.html

--
@flaper87
Flavio Percoco




--
@flaper87
Flavio Percoco


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] Fixing Swift rings when upscaling/replacing nodes in TripleO deployments

[Arkady.Kanevsky]

Thanks

-Original Message-
From: Christian Schwede [mailto:cschw...@redhat.com] 
Sent: Thursday, January 05, 2017 1:29 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] Fixing Swift rings when 
upscaling/replacing nodes in TripleO deployments

On 05.01.2017 17:03, Steven Hardy wrote:
> On Thu, Jan 05, 2017 at 02:56:15PM +, arkady.kanev...@dell.com wrote:
>> I have concern to rely on undercloud for overcloud swift.
>> Undercloud is not HA (yet) so it may not be operational when disk failed or 
>> swift overcloud node is added/deleted.
> 
> I think the proposal is only for a deploy-time dependency, after the 
> overcloud is deployed there should be no dependency on the undercloud 
> swift, because the ring data will have been copied to all the nodes.

Yes, exactly - there is no runtime dependency. The overcloud will continue to 
work even if the undercloud is gone.

If you "loose" the undercloud (or more precisely, the overcloud rings that are 
stored on the undercloud Swift) you can copy them from any overcloud node and 
run an update.

Even if one deletes the rings from the undercloud, the deployment will continue 
to work after an update - puppet-swift will simply continue to use the already 
existing .builder files on the nodes.

Only if one deletes the rings on the undercloud and runs an update with 
new/replaced nodes it will fail - the swift-recon check will raise an error in 
step 5 because rings are inconsistent on the new/replaced nodes. But the 
inconsistency is already the case today (in fact it's the same way as it works 
today), except that there is no check and no warning to the operator.

-- Christian

> During create/update operations you need the undercloud operational by 
> definition, so I think this is probably OK?
> 
> Steve
>>
>> -Original Message-
>> From: Christian Schwede [mailto:cschw...@redhat.com]
>> Sent: Thursday, January 05, 2017 6:14 AM
>> To: OpenStack Development Mailing List 
>> 
>> Subject: [openstack-dev] [TripleO] Fixing Swift rings when 
>> upscaling/replacing nodes in TripleO deployments
>>
>> Hello everyone,
>>
>> there was an earlier discussion on $subject last year [1] regarding a bug 
>> when upscaling or replacing nodes in TripleO [2].
>>
>> Shortly summarized: Swift rings are built on each node separately, and if 
>> adding or replacing nodes (or disks) this will break the rings because they 
>> are no longer consistent across the nodes. What's needed are the previous 
>> ring builder files on each node before changing the rings.
>>
>> My former idea in [1] was to build the rings in advance on the undercloud, 
>> and also using introspection data to gather a set of disks on each node for 
>> the rings.
>>
>> However, this changes the current way of deploying significantly, and also 
>> requires more work in TripleO and Mistral (for example to trigger a ring 
>> build on the undercloud after the nodes have been started, but before the 
>> deployment triggers the Puppet run).
>>
>> I prefer smaller steps to keep everything stable for now, and therefore I 
>> changed my patches quite a bit. This is my updated proposal:
>>
>> 1. Two temporary undercloud Swift URLs (one PUT, one GET) will be computed 
>> before Mistral starts the deployments. A new Mistral action to create such 
>> URLs is required for this [3].
>> 2. Each overcloud node will try to fetch rings from the undercloud Swift 
>> deployment before updating it's set of rings locally using the temporary GET 
>> url. This guarantees that each node uses the same source set of builder 
>> files. This happens in step 2. [4] 3. puppet-swift runs like today, updating 
>> the rings if required.
>> 4. Finally, at the end of the deployment (in step 5) the nodes will upload 
>> their modified rings to the undercloud using the temporary PUT urls. 
>> swift-recon will run before this, ensuring that all rings across all nodes 
>> are consistent.
>>
>> The two required patches [3][4] are not overly complex IMO, but they solve 
>> the problem of adding or replacing nodes without changing the current 
>> workflow significantly. It should be even easy to backport them if needed.
>>
>> I'll continue working on an improved way of deploying Swift rings (using 
>> introspection data), but using this approach it could be even done using 
>> todays workflow, feeding data into puppet-swift (probably with some updates 
>> to puppet-swift/tripleo-heat-templates to allow support for regions, zones, 
>> different disk layouts and the like). However, all of this could be built on 
>> top of these two patches.
>>
>> I'm curious about your thoughts and welcome any feedback or reviews!
>>
>> Thanks,
>>
>> -- Christian
>>
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2016-August/100720
>> .html [2] https://bugs.launchpad.net/tripleo/+bug/1609421
>> [3] https://review.openstack.org/#/c/413229/
>> [4] 

Re: [openstack-dev] [heat] project specific question for the next user survey

[Rico Lin]

Dear team

Thanks for joining the vote.
Base on the polling result, we decide to go with the question that:

*What's the expected load on your Heat deployment?*

   -
*Few small stacks (<100 resources each) *
   -
*Lots of small stacks (<100 resources each) *
   -
*Few big stacks (>100 resources each) *
   - *Lots of big stacks (>100 resources each)*


Also here are other opinions we collected:

   - I'm not convinced that any of these will give us hard data that would
   be useful. e.g. "What is the total number of (non-deleted) stacks and
   resources defined in Heat right now?" would be hard data; "Is your
   deployment really big? [No/Yes/Heck Yes]", not so much. Unfortunately, I
   don't think we have any easy ways of collecting the former that don't
   involve database spelunking. If we really care about this data then we
   should probably consider adding admin APIs to collect it and report it in
   the form that we want it (e.g. we could report max & median resource
   counts, instead of just mean).


2017-01-06 14:24 GMT+08:00 Rico Lin :

> Dear Team
> Base on suggestions
> We open a simple doodle to collect opinions.
> http://doodle.com/poll/fns89s3ee4za3saw
> Please help to pick the better question in your mind.
> Let's voting till the end of this Friday (for everyone!)
>
> 2017-01-05 1:06 GMT+08:00 Rico Lin :
>
>> Dear Team
>> Let's put some thoughts here[1] in next 24h.
>> Any idea/suggestion to this heat adoption question are welcome.
>> It will be great if we can get some really useful information from users
>> by given the right question.
>>
>> [1] https://etherpad.openstack.org/p/ocata-heat-user-survey
>>
>>
>> 2017-01-02 12:18 GMT+08:00 Rabi Mishra :
>>
>>> Hi All,
>>>
>>> We have an opportunity to submit a heat adoption related question (for
>>> those who are USING, TESTING, or INTERESTED in heat) to be included in the
>>> User Survey.
>>>
>>> Please provide your suggestions/questions.*The deadline for this is 9th
>>> Jan.*
>>>
>>> --
>>> Regards,
>>> Rabi Misra
>>>
>>>
>>> 
>>> __
>>> 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
>>>
>>>
>>
>>
>> --
>> May The Force of OpenStack Be With You,
>>
>>
>>
>> *Rico LinChief OpenStack Technologist, inwinSTACK*irc: ricolin
>>
>>
>
>
> --
> May The Force of OpenStack Be With You,
>
>
>
> *Rico LinChief OpenStack Technologist, inwinSTACK*irc: ricolin
>
>
__
OpenStack Development Mailing 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][ui] FYI, the tripleo-ui package is currently broken

[Julie Pichon]

On 6 January 2017 at 14:52, Julie Pichon  wrote:
> Hi folks,
>
> Just a heads-up that the DLRN "current"/dev package for the Tripleo UI
> is broken in Ocata and will cause the UI to only show a blank page,
> until we resolve some dependencies issues within the -deps package.
>
> If I understand correctly, we ended up with an incomplete package
> because we were silently ignoring errors during builds [1] - many
> thanks to Honza for the debugging work, and the patch!!

The good news: the 'stop on error' patch merged, meaning we will catch
such errors early in the future, and won't be able to merge patches
until the dependencies are properly sorted out. A backport was also
proposed at [1].

The bad news: because currently we're already in a "missing
dependencies" state due to patches that merged with silent errors and
the older -deps package, no patch can merge on tripleo-ui until the
-deps package gets updated. I'm not sure about the ETA for the new
-deps package but the good folks on #rdo are looking into it (see
also [2]).

Thanks,

Julie

[1] https://review.openstack.org/#/c/417866/
[2] https://review.rdoproject.org/r/#/c/4215/

> In the meantime, if you want to work with the UI package you should
> get a version built before December 19th, e.g. [2], or you're probably
> better off using the UI from source for the time being [3].
>
> I'll update this thread when this is resolved.
>
> Thanks,
>
> Julie
>
> [1] https://bugs.launchpad.net/tripleo/+bug/1654051
> [2] 
> https://trunk.rdoproject.org/centos7-master/04/15/0415ee80b5c8354124290ac933a34823f2567800_c211fbe8/openstack-tripleo-ui-2.0.0-0.20161212153814.2dfbb0b.el7.centos.noarch.rpm
> [3] 
> https://github.com/openstack/tripleo-ui/blob/master/README.md#install-tripleo-ui

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

Re: [openstack-dev] [oslo] Not running for Oslo PTL for Pike

[Davanum Srinivas]

Piling on the +1's :) Thanks for your work/guidance/leadership.

-- Dims

On Mon, Jan 9, 2017 at 6:27 AM, Flavio Percoco  wrote:
> On 03/01/17 12:03 -0800, Joshua Harlow wrote:
>>
>> Hi Oslo folks (and others),
>>
>> Happy new year!
>>
>> After serving for about a year I think it's a good opportunity for myself
>> to let another qualified individual run for Oslo PTL (seems common to only
>> go for two terms and hand-off to another).
>>
>> So I just wanted to let folks know that I will be doing this, so that we
>> can grow others in the community that wish to try out being a PTL.
>>
>> I don't plan on leaving the Oslo community btw, just want to make sure we
>> spread the knowledge (and the fun!) of being a PTL.
>>
>> Hopefully I've been a decent PTL (with  room to improve) during this
>> time :-)
>
>
> Just wanted to second what other folks have said in this thread. You've done
> an
> amazing work over the past year. Thanks for the time spent as PTL.
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing 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

[openstack-dev] [mistral] Team meeting - 01/09/2017

[Renat Akhmerov]

Hi,

We’ll have a team meeting today at 16.00 UTC at #openstack-mistral IRC channel.

Agenda:
Review action items
General syncup after the holidays
Current status (progress, issues, roadblocks, further plans)
Open discussion

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] [oslo] Not running for Oslo PTL for Pike

[Flavio Percoco]

On 03/01/17 12:03 -0800, Joshua Harlow wrote:

Hi Oslo folks (and others),

Happy new year!

After serving for about a year I think it's a good opportunity for 
myself to let another qualified individual run for Oslo PTL (seems 
common to only go for two terms and hand-off to another).


So I just wanted to let folks know that I will be doing this, so that 
we can grow others in the community that wish to try out being a PTL.


I don't plan on leaving the Oslo community btw, just want to make sure 
we spread the knowledge (and the fun!) of being a PTL.


Hopefully I've been a decent PTL (with  room to improve) during 
this time :-)


Just wanted to second what other folks have said in this thread. You've done an
amazing work over the past year. Thanks for the time spent as PTL.

Flavio

--
@flaper87
Flavio Percoco


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] [heat] glance v2 support?

[Flavio Percoco]

On 06/01/17 09:34 +0530, Rabi Mishra wrote:

On Fri, Jan 6, 2017 at 4:38 AM, Emilien Macchi  wrote:


Greetings Heat folks!

My question is simple:
When do you plan to support Glance v2?
https://review.openstack.org/#/c/240450/

The spec looks staled while Glance v1 was deprecated in Newton (and v2
was started in Kilo!).



Hi Emilien,

I think we've not been able to move to v2 due to v1/v2 incompatibility[1]
with respect to the location[2] property. Moving to v2 would break all
existing templates using that property.

I've seen several discussions around that without any conclusion.  I think
we can support a separate v2 image resource and deprecate the current one,
unless there is a better path available.


Hi Rabi,

Could you elaborate on why Heat depends on the location attribute? I'm not
familiar with Heat and knowing this might help me to propose something (or at
least understand the difficulties).

I don't think putting this on hold will be of any help. V1 ain't coming back and
the improvements for v2 are still under heavy coding. I'd probably recommend
moving to v2 with a proper deprecation path rather than sticking to v1.

Cheers,
Flavio



[1] https://wiki.openstack.org/wiki/Glance-v2-v1-client-compatability
[2] https://github.com/openstack/heat/blob/master/heat/engine/
resources/openstack/glance/image.py#L107-L112



As an user, I need Glance v2 support so I can remove Glance Registry
from my deployment. and run pure v2 everywhere in my cloud.

Thanks for your help,
--
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





--
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



--
@flaper87
Flavio Percoco


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] removing glance-registry & api v1

[Flavio Percoco]

On 05/01/17 19:21 -0500, Emilien Macchi wrote:

Just some heads-up for those who were interested by removing Glance
Registry from TripleO (yes Flavio, I'm looking at you !).

Because TripleO relies on Heat for the pingtest (validation that
OpenStack cloud is up and running) and because Heat doesn't support
Glance v2 API [1], we strongly rely on Glance v1 API and therefore
Glance Registry service now.
I've started a thread [2] to ask Heat folks when they plan to support
Glance v2 API.

The pingtest is a heat template used to manage the images, volumes and
servers. Because our scenarios are testing boot from volume, creating
from an image, Glance API is used.
A (dirty) workaround would be to stop testing boot from volume and
manage the glance image creating by just using osc in tripleo-ci
scripts, and find a way to give the image ID to the heat template. I
personally don't like it as I consider it as a test regression and I'm
not sure we want that at this point.


As much as I would like to get rid of it I think it's best for us to keep it
around a bit longer. However, I do think we should have a way to disable it, at
least for the overcloud or other cases where the registry is not really needed.


Here's the work done to remove Glance Registry in both Puppet & TripleO CI:
https://review.openstack.org/#/q/topic:g-registry/removal

Any feedback or suggestion is welcome. On my side, I won't work on the
workaround as I don't like the idea, and I'll just wait for Heat to
support Glance v2 API.


I'll follow-up with the heat team and see what's missing and how we can move
forward. I'd rather have this fixed than the workaround you proposed.

Flavio


[1] https://review.openstack.org/#/c/240450/
[2] http://lists.openstack.org/pipermail/openstack-dev/2017-January/109722.html
--
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


--
@flaper87
Flavio Percoco


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

[Weyl, Alexey (Nokia - IL)]

Hi Yujun,

After some more checks, I found out the current code will handle your case as 
well, because it will go into the 2.c.1.

Alexey

> -Original Message-
> From: Weyl, Alexey (Nokia - IL) [mailto:alexey.w...@nokia.com]
> Sent: Monday, January 09, 2017 10:54 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> Re: [ALU]Re: [ALU][vitrage]how touseplaceholder vertex
> 
> What will happen is the following:
> We have a connection between PC_a and PC_b with label Cable.
> Now a new event arrives and the transformer builds the following trio:
> (Vertex_A, Neighbors((Vertex_B, Edge), UPDATE) This transformed data
> arrives to the processor that goes to the UPDATE action:
> 1. Updates the Vertex_A (PC_a) properties in the graph.
> 2. Calls the _update_neighbors method:
>a. finds all the valid_edges and the obsolete_edges
>b. deletes all the obsolete edges from the graph
>c. connects the valid edges to the graph:
>   iterates over all the neighbors, and for each neighbor checks:
>   1. if the neighbor_vertex doesn't exist yet or if the is_deleted
> property of the neighbor_vertex is false then:
>  a. Update this vertex in the graph.
>  b. check if the edge doesn't exist yet and if so then add the
> edge.
> 
> In your case the edge the edge 'Cable' will be deleted from the graph
> because it is obsolete, but from what I see at the moment and can be
> seen in the code, it won't enter the to the 2.c.1 because the neighbor
> vertex already exists and the neighbor vertex isn't defined as
> is_delete=false.
> 
> That is a problem, and I have a solution for the problem, which I need
> to make sure that it ruin anything else because everything goes through
> the processor.
> 
> Alexey
> 
> From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> Sent: Monday, January 09, 2017 10:26 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> Re: [ALU][vitrage]how touseplaceholder vertex
> 
> Thanks Alexey. Could you explain a bit more detail based on the example
> in comments below?
> 
> On Mon, Jan 9, 2017 at 4:08 PM Weyl, Alexey (Nokia - IL)
>  wrote:
> That’s not what I mean.
> 
> When some data is changed in a some vertices, their event is pushed to
> the event queue, and thus the correct transformer is called.
> We update the data of the current vertex, and for each neighbor that we
> created in the transformer, we check the following:
> if the neighbor vertex doesn't exist yet or if the id_deleted property
> of the neighbor vertex is false, then update the vertex in the graph.
> Then it checks if the edge is not in the graph yet, then it adds it.
> 
> Before: PC_a is linked to PC_b with Cable
> After: PC_a is linked to PC_b with Wi-Fi
> 
> So this will results in a removal of original edge (labeled Cable) and
> adding of new edge (labeled Wi-Fi) . Is that correct?
> 
> Alexey
> 
> From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> Sent: Sunday, January 08, 2017 5:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
> [vitrage]how touseplaceholder vertex
> 
> Hi, Alexey
> On Sun, Jan 8, 2017 at 2:50 PM Weyl, Alexey (Nokia - IL)
>  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
> ___
> ___
> OpenStack Development Mailing 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] [nova] Next notification meeting

[Balazs Gibizer]

Hi,

The next notification subteam meeting will be held on 2017.01.10 17:00 
UTC [1] on #openstack-meeting-4.


Cheers,
gibi

[1] 
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170110T17





__
OpenStack Development Mailing 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-operators] [nova] Automatically disabling compute service on RBD EMFILE failures

[Daniel P. Berrange]

On Sat, Jan 07, 2017 at 12:04:25PM -0600, Matt Riedemann wrote:
> A few weeks ago someone in the operators channel was talking about issues
> with ceph-backed nova-compute and OSErrors for too many open files causing
> issues.
> 
> We have a bug reported that's very similar sounding:
> 
> https://bugs.launchpad.net/nova/+bug/1651526
> 
> During the periodic update_available_resource audit, the call to RBD to get
> disk usage fails with the EMFILE OSError. Since this is in a periodic it
> doesn't cause any direct operations to fail, but it will cause issues with
> scheduling as that host is really down, however, nothing sets the service to
> down (disabled).
> 
> I had proposed a solution in the bug report that we could automatically
> disable the service for that host when this happens, and then automatically
> enable the service again if/when the next periodic task run is successful.
> Disabling the service would take that host out of contention for scheduling
> and may also trigger an alarm for the operator to investigate the failure
> (although if there are EMFILE errors from the ceph cluster I'm guessing
> alarms should already be going off).
> 
> Anyway, I wanted to see how hacky of an idea this is. We already
> automatically enable/disable the service from the libvirt driver when the
> connection to libvirt itself drops via an event callback. This would be
> similar albeit less sophisticated as it's not using an event listening
> mechanism, we'd have to maintain some local state in memory to know if we
> need to enable/disable the service again. And it seems pretty
> hacky/one-offish to handle this just for the RBD failure, but maybe we just
> generically handle it for any EMFILE error when collecting disk usage in the
> resource audit?

Presumably this deployment was using the default Linux file limits
which are at a ridiculously low value of 1024. Ceph with 900 OSDs
will potentially need 900 files, not really leaving any slack for
Nova todo other work. I'd be willing to bet there are other scenarios
in which Nova would hit the 1024 FD limit under high usage, not merely
Ceph. So perhaps regardless of whether Ceph is used, we should just
recommend that you always run Nova with 4096 fds, and check that in
initialize() on startup and log a warning if the num files is lower
than this.

With pretty much all distros using systemd, it would be nice if Nova
shipped a standard systemd unit file, which could then also contain
the recommended higher FD limit so people get sane limits out of the
box.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

__
OpenStack Development Mailing 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] Team and drivers meetings

[Armando M.]

Hi neutrinos,

A reminder that from this week on it is business as usual. Therefore the
calendar for team and drivers meetings is back up and running.

Cheers,
Armando
__
OpenStack Development Mailing 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] Re: [ALU] Re: [ALU][vitrage]how touseplaceholder vertex

[Weyl, Alexey (Nokia - IL)]

What will happen is the following:
We have a connection between PC_a and PC_b with label Cable.
Now a new event arrives and the transformer builds the following trio:
(Vertex_A, Neighbors((Vertex_B, Edge), UPDATE)
This transformed data arrives to the processor that goes to the UPDATE action:
1. Updates the Vertex_A (PC_a) properties in the graph.
2. Calls the _update_neighbors method: 
   a. finds all the valid_edges and the obsolete_edges
   b. deletes all the obsolete edges from the graph
   c. connects the valid edges to the graph:
  iterates over all the neighbors, and for each neighbor checks:
  1. if the neighbor_vertex doesn't exist yet or if the is_deleted property 
of the neighbor_vertex is false then:
 a. Update this vertex in the graph.
 b. check if the edge doesn't exist yet and if so then add the edge.

In your case the edge the edge 'Cable' will be deleted from the graph because 
it is obsolete, but from what I see at the moment and can be seen in the code, 
it won't enter the to the 2.c.1 because the neighbor vertex already exists and 
the neighbor vertex isn't defined as is_delete=false.

That is a problem, and I have a solution for the problem, which I need to make 
sure that it ruin anything else because everything goes through the processor.

Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Monday, January 09, 2017 10:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] Re: 
[ALU][vitrage]how touseplaceholder vertex

Thanks Alexey. Could you explain a bit more detail based on the example in 
comments below?

On Mon, Jan 9, 2017 at 4:08 PM Weyl, Alexey (Nokia - IL) 
 wrote:
That’s not what I mean.

When some data is changed in a some vertices, their event is pushed to the 
event queue, and thus the correct transformer is called.
We update the data of the current vertex, and for each neighbor that we created 
in the transformer, we check the following:
if the neighbor vertex doesn't exist yet or if the id_deleted property of the 
neighbor vertex is false, then update the vertex in the graph. Then it checks 
if the edge is not in the graph yet, then it adds it.

Before: PC_a is linked to PC_b with Cable
After: PC_a is linked to PC_b with Wi-Fi

So this will results in a removal of original edge (labeled Cable) and adding 
of new edge (labeled Wi-Fi) . Is that correct?

Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Sunday, January 08, 2017 5:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] 
[vitrage]how touseplaceholder vertex

Hi, Alexey
On Sun, Jan 8, 2017 at 2:50 PM Weyl, Alexey (Nokia - IL) 
 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
__
OpenStack Development Mailing 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

[yinliyin]

Hi Ifat, 

 I think there is a situation that all the alarms are reported by the 
monitored system. We use vitrage to:

1.  Found the relationships of the alarms, and find the root cause.

2.  Deduce the alarm before it really occured. This comprise two 
aspects:

 1) A cause B:  When A occured,  we deduce that B would occur

 2) B is caused by A:  When B occured, we deduce that A must 
occured

In "2",   we do expect vitrage to raise the alarm before the alarm 
is reported because the alarm would be lost or be delayed for some reason.  So 
we would write "raise alarm" actions in the scenarios of the template.  I think 
that the alarm is reported or is deduced should be a state property of the 
alarm. The vertex reported and the vertex deduced of the same alarm should be 
merged to one vertex. 





 Best Regards,

 Yinliyin.















  

   



















殷力殷 YinLiYin






项目经理   Project Manager
虚拟化上海五部/无线研究院/无线产品经营部 NIV Shanghai Dept. V/Wireless Product R＆D 
Institute/Wireless Product Operation









上海市浦东新区碧波路889号中兴研发大楼D502 
D502, ZTE Corporation R Center, 889# Bibo Road, 
Zhangjiang Hi-tech Park, Shanghai, P.R.China, 201203 
T: +86 21 68896229
M: +86 13641895907 
E: yinli...@zte.com.cn
www.zte.com.cn










原始邮件



发件人： ＜ifat.a...@nokia.com＞
收件人： ＜openstack-dev@lists.openstack.org＞
抄送人：韩静6838王维雅00042110章宇军10200531贾培源10101785龚亚辉6092001895
日 期 ：2017年01月07日 02:18
主 题 ：Re: [openstack-dev] [Vitrage] About alarms reported by datasource and the 
alarms generated by vitrage evaluator







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" ＜yinli...@zte.com.cn＞
 Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
＜openstack-dev@lists.openstack.org＞
 Date: Friday, 6 January 2017 at 03:27
 To: "openstack-dev@lists.openstack.org" ＜openstack-dev@lists.openstack.org＞
 Cc: "gong.yah...@zte.com.cn" ＜gong.yah...@zte.com.cn＞, "han.jin...@zte.com.cn" 
＜han.jin...@zte.com.cn＞, "wang.we...@zte.com.cn" ＜wang.we...@zte.com.cn＞, 
"jia.peiy...@zte.com.cn" ＜jia.peiy...@zte.com.cn＞, "zhang.yuj...@zte.com.cn" 
＜zhang.yuj...@zte.com.cn＞
 Subject: [openstack-dev] [Vitrage] About alarms reported by datasource and the 
alarms generated by vitrage evaluator



 



Hi all, 


   Vitrage generate alarms acording to the templates. All the alarms raised by 
vitrage has the type "vitrage". Suppose Nagios has an alarm A. Alarm A is 
raised by vitrage evaluator according to the action part of a scenario, type  
of alarm A is "vitrage". If Nagios reported alarm A latter, a new alarm A with 
type "Nagios" would be generator in the entity graph. There would be two 
vertices for the same alarm in the graph. And we have to define two alarm 
entities, two relationships,  two scenarios in the template file to make the 
alarm propagation procedure work.


   It is inconvenient to describe fault model of system with lot of alarms. How 
to solve this problem?


 


殷力殷 YinLiYin


 


 






 上海市浦东新区碧波路889号中兴研发大楼D502 
 D502, ZTE Corporation R Center, 889# Bibo Road, 
 Zhangjiang Hi-tech Park, Shanghai, P.R.China, 201203 
 T: +86 21 68896229
 M: +86 13641895907 
 E: yinli...@zte.com.cn
 www.zte.com.cn__
OpenStack Development Mailing 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] Re: [ALU] [vitrage]how touseplaceholder vertex

[Yujun Zhang]

Thanks Alexey. Could you explain a bit more detail based on the example in
comments below?

On Mon, Jan 9, 2017 at 4:08 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

That’s not what I mean.

When some data is changed in a some vertices, their event is pushed to the
event queue, and thus the correct transformer is called.
We update the data of the current vertex, and for each neighbor that we
created in the transformer, we check the following:
if the neighbor vertex doesn't exist yet or if the id_deleted property of
the neighbor vertex is false, then update the vertex in the graph. Then it
checks if the edge is not in the graph yet, then it adds it.


Before: PC_a is linked to PC_b with Cable
After: PC_a is linked to PC_b with Wi-Fi

So this will results in a removal of original edge (labeled Cable) and
adding of new edge (labeled Wi-Fi) . Is that correct?

Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Sunday, January 08, 2017 5:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU]
[vitrage]how touseplaceholder vertex

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

[Weyl, Alexey (Nokia - IL)]

That’s not what I mean.

When some data is changed in a some vertices, their event is pushed to the 
event queue, and thus the correct transformer is called.
We update the data of the current vertex, and for each neighbor that we created 
in the transformer, we check the following:
if the neighbor vertex doesn't exist yet or if the id_deleted property of the 
neighbor vertex is false, then update the vertex in the graph. Then it checks 
if the edge is not in the graph yet, then it adds it.

Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com] 
Sent: Sunday, January 08, 2017 5:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] Re: [ALU] 
[vitrage]how touseplaceholder vertex

Hi, Alexey
On Sun, Jan 8, 2017 at 2:50 PM Weyl, Alexey (Nokia - IL) 
 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