Re: [openstack-dev] [release][ptl][all] self-service branch management

[Ian Cordasco]

 

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

Date: December 14, 2016 at 08:30:22
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [release][ptl][all] self-service branch management

> On 2016-12-14 08:51:29 -0500 (-0500), Ian Cordasco wrote:
> [...]
> > I do have one question, will creating the branch's end-of-life
> > eventually work the same way? For example, Glance's projects were
> > missed in the recent liberty end of life work. Could we submit a
> > review to do that work so Josh & Tony don't have to or is that
> > something that isn't planned to work through openstack/releases?
>  
> The EOL process is still a little different because it relies on
> branch deletion, which is not an explicit permission we can delegate
> in the version of Gerrit we're running today. There's some
> indication that it will be possible in Gerrit 2.14 (not yet
> released) and we might even be able to backport that feature to 2.13
> (the version to which we're currently working on upgrading). So yes,
> there is an expectation we will safely automate EOL'ing but we don't
> have an exact timeline for it yet.

Awesome! Thank you so much for that answer. =D

--  
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] [ALU] [vitrage] how to use placeholder vertex

[Yujun Zhang]

Hi, Alexey,

Thanks for the detail example. It explains the existing mechanism of vertex
creation well.

So it looks like each resource type will have a primary datasource, e.g.
nova.host for nova.host, nova.intance for nova.instance, that holds full
details. Is that correct?

Not sure that you remember the long discussion in static driver review[1]
or not. At last, we agreed on a unified entity definition for both
`nova.host` and `switch`, no extra key to indicate it is "external" (should
create a placeholder).

If I understand it correctly, no placeholder will be created in this case.
Because we can not distinguish them from the static configuration. And the
properties of `nova.host` resource shall to be merged from `static` and
nova.host` datasources. Is that so?

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

On Wed, Dec 14, 2016 at 5:40 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Hi Yujun,
>
>
>
> This is a good question, and let me explain for you how it works.
>
> Lets say we are supposed to get 2 entities from nova, nova.host called
> host1 and nova.instance called vm1 and vm1 is supposed to be connected to
> host1.
>
> The nova.host driver and nova.instance driver are working simultaneously
> and thus we don’t know the order in which those events will arrive.
>
> We have 2 use cases:
>
> 1.   Host1 event arrives before vm1.
>
> In this case the processor will call the transformer of nova.host and will
> create a vertex for host1 in the graph with the full details of host1.
>
> Then, vm1 event will arrive, the processor will create the vm1 vertex in
> the graph, it will update the host1 properties in the graph (because the
> host1 details that are created in nova.instance are only its basic details
> such as: category, type, id, is_deleted, is_placeholder they host1
> properties won’t be changed in the graph because those details are basic
> and can’t be changed), and then it will create an edge between vm1 and
> host1 (only the nova.instance knows to which nova.host it is connected and
> not vice versa).
>
> 2.   Vm1 event arrives before host1.
>
> In this case the processor will add vm1 to the graph, then it will add the
> host1 placeholder to the graph (so we will know to which host vm1 is
> connected) and then add the edge between them.
>
> Then when the processor will handle with the host1 event, it will just add
> some properties of the host1 vertex, and of course will change the
> is_placeholder property of host1 to false.
>
> We also has the consistency service that runs every 10 minutes (its
> configurable with the snapshot_interval) and checks if there are vertices
> that are is_placeholder=True and are in the graph more then
> 2*snapshot_interval time then it means that such a vertex of host1 for
> example doesn’t really exists and it deletes it from the graph).
>
> In addition, when we understand that we need to delete some entity from
> the graph, upon delete notification for example, then we don’t delete it
> right away, we change the is_deleted property of that entity to True, and
> we will delete it on the next run of the consistency service. The reason we
> do that, is because we need it for the evaluator, because it runs a
> subgraph matching algorithm on the graph, and if the entity that is
> supposed to be there doesn’t appear then it won’t work correctly.
>
>
>
> The best way to create a placeholder is to call the placeholder method of
> the correct transformer using the transformers array that each transformer
> class has.
>
>
>
> I hope this helps.
>
>
>
> Alexey
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Wednesday, December 14, 2016 10:55 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [ALU] [openstack-dev] [vitrage] how to use placeholder vertex
>
>
>
> Hi, root causers (assuming this nickname has been agreed)
>
>
>
> It seems the placeholder is created for every neighbor of an entity[1].
> I'm not sure what will happen if the neighbor entity has been created
> before.
>
>
>
> Will the graph utility handle it? Or we need to check the existence in
> transformer and deal with it?
>
>
>
> Similar question for how to create a vertex when there is already a
> placeholder with same ID
>
>
>
> [1]:
> https://github.com/openstack/vitrage/blob/master/vitrage/datasources/static_physical/transformer.py#L114
>
>
> --
>
> Yujun
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

[Ian Cordasco]

 

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

Date: December 14, 2016 at 08:08:33
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  Re: [openstack-dev] [kolla][tc] Video Meetings - input requested

> On Dec 14, 2016, at 7:45 AM, Ian Cordasco wrote:
> >
> > Taking you to the extreme of your statement, it seems there are several of 
> > these "ad hoc"  
> meetings a week (by inc0's admission). The video meetings seem to replace the 
> time that  
> sub-team is missing in the weekly IRC meeting, which Jeffrey has a plan to 
> solve for.
> >
> > Also, based on inc0's email, it seems that these meetings consistently are 
> > made up primarily  
> (if not singularly) of "cores". So they seem to be violating the open's in 
> that they're  
> effectively (even if not intentionally) creating a place where only 
> sub-groups of people  
> working on kolla (k8s) can collaborate.
> >
> > Further, the kolla team seems to think that code submissions sent after a 
> > meeting are  
> sufficient artifacts from the meeting, which there seems to be a majority who 
> feel otherwise.  
> Based on Jeffrey's descriptions, inc0's emails, and the rest of this thread, 
> it seems  
> quite clear that kolla isn't obeying one of the 4 opens.
>  
> Sorry, the conversation seems to have forked. The original issue was Kolla’s 
> practices,  
> which then forked into a more general discussion. I was responding to the 
> general side  
> of things: you can’t say that hangouts or hallway conversations are never 
> good things.  
> But when they are misused, as is described in the Kolla case, then yes, that 
> should not  
> be allowed to continue.

No worries. I was trying to bring us back to the Kolla case. If we want to 
discuss more general guidelines around this stuff, I'd rather not hijack this 
thread because it highlights serious problems in how Kolla is operating that a 
member of its team has brought up. I don't want us to side-track that 
conversation too severely. :)

--  
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] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Vladyslav Drok]

On Wed, Dec 14, 2016 at 3:48 PM, Ian Cordasco 
wrote:

> -Original Message-
> From: Joshua Hesketh 
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: December 14, 2016 at 06:56:22
> To: OpenStack Development Mailing List ,
> openstack-infra 
> Subject:  Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls]
> Tagging liberty as EOL
>
> > The repos listed[0] have had stable/liberty branch removed and replaced
> > with a liberty-eol tag. Any open reviews have been abandoned.
> >
> > Please let me know if there are any mistakes or latecomers to the list.
> >
> > Cheers,
> > Josh
> >
> > [0]
> > https://gist.githubusercontent.com/tbreeds/
> 93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>
> Glance was late to the party, but it should have had its liberty branches
> EOL'd as well.
>
> --
> Ian Cordasco
>

Also, after liberty was EOL'd and stable/liberty branches were removed,
liberty release note pages need to be updated to reference liberty-eol tag
instead of origin/stable/liberty, like done here
https://review.openstack.org/410798 as a temporary solution, until this is
fixed on the reno side (https://review.openstack.org/410792), if I get the
situation correctly.

-Vlad


>
>
> __
> OpenStack Development Mailing 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] Proposing Abhishek Raut as neutronclient core

[Gary Kotton]

+1

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

Date: Wednesday, December 14, 2016 at 4:56 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient 
core

+1

On Dec 13, 2016 17:27, "Armando M." 
> wrote:
Hi folks,

Abhishek Raut's recent involvement in OSC and python-neutronclient has helped 
moving a few efforts along in the right direction. I would like to suggest we 
double down on core firepower for the neutronclient repo alongside Akihiro [1].

This not only will help speed up our transition to OSC CLI, but also improve 
the number of folks who can effectively liasion with the OSC team, and look 
after the needs of neutron's client repo.

Many thanks,
Armando

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

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