Re: [openstack-dev] [all] Creating a new IRC meeting room ?

2016-12-04 Thread Andreas Jaeger 
On 2016-12-05 05:18, Tony Breeds wrote:
> On Sun, Dec 04, 2016 at 10:07:21PM -0500, Shamail wrote:
> 
>> Do we know how many of the project level rooms currently have bots?  I know I
>> ran into an issue that one of the bots was at its maximum (128 rooms) and,
>> therefore, I concerned about the infrastructure necessary to support too many
>> new rooms if there is a new wave of changes to add bots.
> 
> That's clearly something the infra team will need to advise on.  I wasn't 
> aware
> of a hardlimit in meetbot.  A quick grep:

Any user - including a bot - can only join up to 128 channels.

For gerritbot, Jim Blair recently used a LRU list to handle more
channels which means signing off and on from less frequrently used ones.

> balder:project-config $ grep 'name:' accessbot/channels.yaml  | wc -l
> 167

Accessbot is just permissions - this is not relevant. Meetbot is in
system-config and we're at 112 channels (see common/hiera.yaml) - so not
much more space.

> Seems to indicate we have logging on 167 channels, 5-6 have full meetbot
> acess/privs

Accessbot does not setup logging,

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] [cinder] [third-party][ci] devstack failures

2016-12-04 Thread Lenny Verkhovsky 
Hello Apoorva,
According to the log you have issue with remote git cloning,
We are facing similar issues from time to time and as a workaround started to 
use local git mirror instead of rerunning such jobs.

2016-12-05 01:19:17.356 | + functions-common:git_timed:598   :   
timeout -s SIGINT 0 git clone git://git.openstack.org/openstack/horizon.git 
/opt/stack/horizon --branch master
2016-12-05 01:19:17.358 | Cloning into '/opt/stack/horizon'...
2016-12-05 03:20:41.160 | fatal: read error: Connection reset by peer
2016-12-05 03:20:41.165 | fatal: early EOF



From: Apoorva Deshpande [mailto:apps.d...@gmail.com]
Sent: Monday, December 5, 2016 7:43 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [cinder] [third-party][ci] devstack failures

Hello,

I am encountering devstack failures on our Cinder CI [1]. Could you please help 
me debug this? Last successful devstack installation was [2].
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]

[1] http://openstack-ci.tintri.com/tintri/refs-changes-23-405223-4/
[2] http://openstack-ci.tintri.com/tintri/refs-changes-95-393395-7/

thanks,
@apoorva
__
OpenStack Development Mailing 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] [cinder] [third-party][ci] devstack failures

2016-12-04 Thread Ian Wienand 
On 12/05/2016 04:43 PM, Apoorva Deshpande wrote:
> [1] http://openstack-ci.tintri.com/tintri/refs-changes-23-405223-4/

This is failing at

 2016-12-05 01:19:17.356 | + functions-common:git_timed:598   :   
timeout -s SIGINT 0 git clone git://git.openstack.org/openstack/horizon.git 
/opt/stack/horizon --branch master
 2016-12-05 01:19:17.358 | Cloning into '/opt/stack/horizon'...
 2016-12-05 03:20:41.160 | fatal: read error: Connection reset by peer
 2016-12-05 03:20:41.165 | fatal: early EOF
 2016-12-05 03:20:41.165 | fatal: index-pack failed

> [2] http://openstack-ci.tintri.com/tintri/refs-changes-95-393395-7/

The difference to [2] seems to be we merged 399550 [3] to pass in the
--branch parameter to do the checkout all at once, rather than in a
separate step.

It doesn't seem that much different to me ... but maybe you have a
proxy involved that doesn't like this for some obscure reason?

-i

[3] https://review.openstack.org/#/c/399550/

__
OpenStack Development Mailing 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] [vitrage] datasource driverreturnsentities only?

2016-12-04 Thread Yujun Zhang 
Your answer has made everything clear, Alexey.

And I will take into consideration of the neighbor transformer in static
datasource transformer implementation.

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

> Hi,
>
>
>
> Yes, the entity_type is datasource_type, and the entity_id is the
> resources’ id which came from it’s datasource.
>
>
>
> The example is correct, and just for the clarification, the “12345678” is
> the id of that entity in the datasource.
>
>
>
> Another clarification that I want to make sure, is that the static
> datasource (and actually each datasource), retrieves the transformer of the
> neighbor from the transformers dictionary that each transformer holds, and
> using the neighbors’ transformer it creates the placeholder of the neighbor
> (this is because each transformer knows exactly how to build it’s own
> placeholder).
>
>
>
> Alexey
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Monday, December 05, 2016 2:38 AM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions)
>
> *Subject:* [ALU] Re: [openstack-dev] [ALU] Re: [ALU] [vitrage] datasource
> driverreturnsentities only?
>
>
>
> Thanks for clarification.
>
>
>
> Is `entity_type` equivalent to datasource type? And `entity_id` should be
> interpreted by the related datasource, is that right.
>
>
>
> For example, "RESOURCE:nova.host:12345678" is from `nova.host` datasource
> and `12345678` is how `nova.host` identify a resource.
>
>
>
> --
>
> Yujun
>
>
>
> On Sun, Dec 4, 2016 at 4:35 PM Weyl, Alexey (Nokia - IL) <
> alexey.w...@nokia.com> wrote:
>
> Hi Yujun,
>
>
>
> I see the confusion.
>
>
>
> The way we find the resource entity (it’s different than finding the alarm
> entity, but it’s ok because the static datasource is defining relationships
> between resource entities) is in the following way:
>
> Each entity has a vitrage_id which is defined by
> “RESOURCE:: (we are planning in the very near
> future to change the vitrage_id to be a UUID, but at the moment your change
> doesn’t need to refer to that), for example: “RESOURCE:nova.host:12345678”.
>
>
>
> So in this way all you need to know about the other entity is it’s
>  and it’s .
>
>
>
> BR,
>
> Alexey
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Thursday, December 01, 2016 4:16 PM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions)
>
> *Subject:* [ALU] Re: [openstack-dev] [ALU] [vitrage] datasource driver
> returnsentities only?
>
>
>
> Another question, how do we describe an entity from *another* datasource
> in static datasource config?
>
>
>
> In the test resources of static_physical datasource, it seems to be
> referred as following. Does it means that it will be `nova.host` to find
> the matched resource? If so, how will `nova.host` identify the resource, by
> name or by id?
>
> *relationships:*
>   - *type: *nova.host
> *name: *host-2
> *id: *2
> *relation_type: *attached
>
>
>
> On Thu, Dec 1, 2016 at 9:50 PM Weyl, Alexey (Nokia - IL) <
> alexey.w...@nokia.com> wrote:
>
> Hi Yujun,
>
>
>
> Get_all does returns a list of entities to be sent.
>
>
>
> Each event that is sent from the driver to the processor contains also all
> the details of the neighbors that it connects to.
>
> For example, the event and data that we receive from nova about an
> instance also contains the host (compute) that it sits on, and that is how
> we decide to connect it to the correct host.
>
>
>
> I think it is ok that the event of static (from driver to the processor)
> will contain for each entity it neighbors that it is supposed to be
> connected to.
>
>
>
> BR,
>
> Alexey
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Thursday, December 01, 2016 3:20 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [ALU] [openstack-dev] [vitrage] datasource driver returns
> entities only?
>
>
>
> During the implementation of static datasource driver[1], I got a question
> on the return format of `get_all` method.
>
>
>
> If I understand correctly, it should return a list of entities to be sent
> to the queue. Does it infer that the relationship should be embedded in
> entity, just like the legacy static_physical datasource?
>
>
>
> Suppose a link between two switches are created, how should we emit this
> change in `get_all` or `get_changes`?
>
>
>
> Currently I made a compromise by emitting the relationship as an update of
> the connected entity. This is not very elegant and it seems we are going
> back to the legacy static_physical datasource.
>
>
>
> [1] https://review.openstack.org/#/c/405354/
>
> --
>
> 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
>

Re: [openstack-dev] [ALU] Re: [ALU] Re: [ALU] [vitrage] datasource driverreturnsentities only?

2016-12-04 Thread Weyl, Alexey (Nokia - IL) 
Hi,

Yes, the entity_type is datasource_type, and the entity_id is the resources’ id 
which came from it’s datasource.

The example is correct, and just for the clarification, the “12345678” is the 
id of that entity in the datasource.

Another clarification that I want to make sure, is that the static datasource 
(and actually each datasource), retrieves the transformer of the neighbor from 
the transformers dictionary that each transformer holds, and using the 
neighbors’ transformer it creates the placeholder of the neighbor (this is 
because each transformer knows exactly how to build it’s own placeholder).

Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Monday, December 05, 2016 2:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] Re: [ALU] [vitrage] datasource 
driverreturnsentities only?

Thanks for clarification.

Is `entity_type` equivalent to datasource type? And `entity_id` should be 
interpreted by the related datasource, is that right.

For example, "RESOURCE:nova.host:12345678" is from `nova.host` datasource and 
`12345678` is how `nova.host` identify a resource.

--
Yujun

On Sun, Dec 4, 2016 at 4:35 PM Weyl, Alexey (Nokia - IL) 
> wrote:
Hi Yujun,

I see the confusion.

The way we find the resource entity (it’s different than finding the alarm 
entity, but it’s ok because the static datasource is defining relationships 
between resource entities) is in the following way:
Each entity has a vitrage_id which is defined by 
“RESOURCE:: (we are planning in the very near future to 
change the vitrage_id to be a UUID, but at the moment your change doesn’t need 
to refer to that), for example: “RESOURCE:nova.host:12345678”.

So in this way all you need to know about the other entity is it’s 
 and it’s .

BR,
Alexey

From: Yujun Zhang 
[mailto:zhangyujun+...@gmail.com]
Sent: Thursday, December 01, 2016 4:16 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] [vitrage] datasource driver 
returnsentities only?

Another question, how do we describe an entity from another datasource in 
static datasource config?

In the test resources of static_physical datasource, it seems to be referred as 
following. Does it means that it will be `nova.host` to find the matched 
resource? If so, how will `nova.host` identify the resource, by name or by id?

relationships:
  - type: nova.host
name: host-2
id: 2
relation_type: attached

On Thu, Dec 1, 2016 at 9:50 PM Weyl, Alexey (Nokia - IL) 
> wrote:
Hi Yujun,

Get_all does returns a list of entities to be sent.

Each event that is sent from the driver to the processor contains also all the 
details of the neighbors that it connects to.
For example, the event and data that we receive from nova about an instance 
also contains the host (compute) that it sits on, and that is how we decide to 
connect it to the correct host.

I think it is ok that the event of static (from driver to the processor) will 
contain for each entity it neighbors that it is supposed to be connected to.

BR,
Alexey

From: Yujun Zhang 
[mailto:zhangyujun+...@gmail.com]
Sent: Thursday, December 01, 2016 3:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [openstack-dev] [vitrage] datasource driver returns entities 
only?

During the implementation of static datasource driver[1], I got a question on 
the return format of `get_all` method.

If I understand correctly, it should return a list of entities to be sent to 
the queue. Does it infer that the relationship should be embedded in entity, 
just like the legacy static_physical datasource?

Suppose a link between two switches are created, how should we emit this change 
in `get_all` or `get_changes`?

Currently I made a compromise by emitting the relationship as an update of the 
connected entity. This is not very elegant and it seems we are going back to 
the legacy static_physical datasource.

[1] https://review.openstack.org/#/c/405354/
--
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

[openstack-dev] [cinder] [third-party][ci] devstack failures

2016-12-04 Thread Apoorva Deshpande 
Hello,

I am encountering devstack failures on our Cinder CI [1]. Could you please
help me debug this? Last successful devstack installation was [2].

[1] http://openstack-ci.tintri.com/tintri/refs-changes-23-405223-4/
[2] http://openstack-ci.tintri.com/tintri/refs-changes-95-393395-7/

thanks,
@apoorva
__
OpenStack Development Mailing 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] Creating a new IRC meeting room ?

2016-12-04 Thread Shamail 


> On Dec 4, 2016, at 11:18 PM, Tony Breeds  wrote:
> 
>> On Sun, Dec 04, 2016 at 10:07:21PM -0500, Shamail wrote:
>> 
>> Do we know how many of the project level rooms currently have bots?  I know I
>> ran into an issue that one of the bots was at its maximum (128 rooms) and,
>> therefore, I concerned about the infrastructure necessary to support too many
>> new rooms if there is a new wave of changes to add bots.
> 
> That's clearly something the infra team will need to advise on.  I wasn't 
> aware
> of a hardlimit in meetbot.  A quick grep:
> 
> balder:project-config $ grep 'name:' accessbot/channels.yaml  | wc -l
> 167
> 
> Seems to indicate we have logging on 167 channels, 5-6 have full meetbot
> acess/privs
Sorry, I think it's safe to ignore my message if we end up using Project rooms 
for meetings.  I looked through my change history and it was gerritbot that I 
had run into challenges with.  That is not impacted by the proposed changes to 
existing room.  If we add new rooms then OpenStack-infra might need to let us 
know whether we can deploy gerritbot to the new channels.
> 
> Yours Tony.
> __
> OpenStack Development Mailing 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] [Blazar] Blazar weekly teem meeting starts again

2016-12-04 Thread Masahito MUROI 

Hi Stackers,

I'm happy to announce it in openstack-dev ML that weekly Blazar team  
meeting is going to start again from 6th Dec.


Some of folks who are interested in resource reservation feature met  
together in Barcelona summit and agreed to re-start the project. As a  
first step for resurrecting the project, we'll start team activity from  
now on.


Following are meeting details. The meeting info[1] is now in review  
status, so if it's not merged by the time, we will use #openstack-blazar  
for the first meeting. Feel free to join it!!


Meeting days: Tuesday 9:00am UTC
Meeting channel: #openstack-meeting-alt

1. https://review.openstack.org/#/c/406667/

best regards,
Masahito



__
OpenStack Development Mailing 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] [Zun] Propose a change of Zun core membership

2016-12-04 Thread Sudipta Biswas 

+1 for both, Welcome Pradeep!


Cheers,

Sudipto


On 05/12/16 6:02 AM, Wenzhi Yu wrote:

+1, welcome Pradeep!


在 2016年12月4日，下午10:49，Qiming Teng  写道：

+1 to both.

On Wed, Nov 30, 2016 at 11:37:59PM +, Hongbin Lu wrote:

Hi Zun cores,

I am going to propose the following change of the Zun core reviewers team:
+ Pradeep Kumar Singh (pradeep-singh-u)
- Vivek Jain (vivek-jain-openstack)

Pradeep was proven to be a significant contributor to Zun. He ranked first at 
the number of commits, and his patches were non-trivial and with high quality. 
His reviews were also very helpful, and often prompted us to re-think the 
design. It would be great to have him in the core team. I would like to thank 
Vivek for his interest to join the core team when Zun was found. However, he 
became inactive in the past a few months, but he is welcomed to re-join the 
core team as long as he becomes active again.

According to the OpenStack Governance process [1], we require a minimum of 4 +1 
votes from Zun core reviewers within a 1 week voting window (consider this 
proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot get enough 
votes or there is a veto vote prior to the end of the voting window, this 
proposal is rejected.

[1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

Best regards,
Hongbin



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

Re: [openstack-dev] [all] Creating a new IRC meeting room ?

2016-12-04 Thread Tony Breeds 
On Sun, Dec 04, 2016 at 10:07:21PM -0500, Shamail wrote:

> Do we know how many of the project level rooms currently have bots?  I know I
> ran into an issue that one of the bots was at its maximum (128 rooms) and,
> therefore, I concerned about the infrastructure necessary to support too many
> new rooms if there is a new wave of changes to add bots.

That's clearly something the infra team will need to advise on.  I wasn't aware
of a hardlimit in meetbot.  A quick grep:

balder:project-config $ grep 'name:' accessbot/channels.yaml  | wc -l
167

Seems to indicate we have logging on 167 channels, 5-6 have full meetbot
acess/privs

Yours Tony.


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

Re: [openstack-dev] [oslo][monasca] Can we uncap python-kafka ?

2016-12-04 Thread Keen, Joe 


On 12/4/16, 7:36 PM, "Tony Breeds"  wrote:

>On Fri, Dec 02, 2016 at 06:18:39PM +, Keen, Joe wrote:
>> 
>> 
>> On 12/2/16, 1:29 AM, "Mehdi Abaakouk"  wrote:
>> 
>> >On Fri, Dec 02, 2016 at 03:29:59PM +1100, Tony Breeds wrote:
>> >>On Thu, Dec 01, 2016 at 04:52:52PM +, Keen, Joe wrote:
>> >>
>> >>> Unfortunately there¹s nothing wrong on the Monasca side so far as we
>> >>>know.
>> >>>  We test new versions of the kafka-python library outside of Monasca
>> >>> before we bother to try integrating a new version.  Since 1.0 the
>> >>> kafka-python library has suffered from crashes and memory leaks
>>severe
>> >>> enough that we¹ve never attempted using it in Monasca itself.  We
>> >>>reported
>> >>> the bugs we found to the kafka-python project but they were closed
>>once
>> >>> they released a new version.
>> >>
>> >>So Opening bugs isn't working.  What about writing code?
>> >
>> >The bug https://github.com/dpkp/kafka-python/issues/55
>> >
>> >Reopening it would be the right solution here.
>> >
>> >I can't reproduce the segfault neither and I agree with dpkp, that
>>looks
>> >like a
>> >ujson issue.
>> 
>> 
>> The bug I had was: https://github.com/dpkp/kafka-python/issues/551
>> 
>> In the case of that bug ujson was not an issue.  The behaviour remained
>> even using the standard json library.  The primary issue I found with it
>> was a memory leak over successive runs of the test script.  Eventually
>>the
>> leak became so bad that the OOM killer killed the process which caused
>>the
>> segfault I was seeing.  The last version I tested was 1.2.1 and it still
>> leaked badly.  I¹ll need to let the benchmark script run for a while and
>> make sure it¹s not still leaking.
>
>So you write that on Friday so you shoudl know by now if it's leaking
>care to
>give us an update?

I wasn’t able to set a test up on Friday and with all the other work I
have for the next few days I doubt I’ll be able to get to it much before
Wednesday.

>
>> >And my bench seems to confirm the perf issue have been solved:
>> >(but not in the pointed version...)
>> >
>> >$ pifpaf run kafka python kafka_test.py
>> >kafka-python version: 0.9.5
>> >...
>> >fetch size 179200 -> 45681.8728864 messages per second
>> >fetch size 204800 -> 47724.3810674 messages per second
>> >fetch size 230400 -> 47209.9841092 messages per second
>> >fetch size 256000 -> 48340.7719787 messages per second
>> >fetch size 281600 -> 49192.9896743 messages per second
>> >fetch size 307200 -> 50915.3291133 messages per second
>> >
>> >$ pifpaf run kafka python kafka_test.py
>> >kafka-python version: 1.0.2
>> >
>> >fetch size 179200 -> 8546.77931323 messages per second
>> >fetch size 204800 -> 9213.30958314 messages per second
>> >fetch size 230400 -> 10316.668006 messages per second
>> >fetch size 256000 -> 11476.2285269 messages per second
>> >fetch size 281600 -> 12353.7254386 messages per second
>> >fetch size 307200 -> 13131.2367288 messages per second
>> >
>> >(1.1.1 and 1.2.5 have also the same issue)
>> >
>> >$ pifpaf run kafka python kafka_test.py
>> >kafka-python version: 1.3.1
>> >fetch size 179200 -> 44636.9371873 messages per second
>> >fetch size 204800 -> 44324.7085365 messages per second
>> >fetch size 230400 -> 45235.8283208 messages per second
>> >fetch size 256000 -> 45793.1044121 messages per second
>> >fetch size 281600 -> 44648.6357019 messages per second
>> >fetch size 307200 -> 44877.8445987 messages per second
>> >fetch size 332800 -> 47166.9176281 messages per second
>> >fetch size 358400 -> 47391.0057622 messages per second
>> >
>> >Looks like it works well now :)
>> 
>> It¹s good that the performance problem has been fixed.  The remaining
>> issues on the Monasca side are verifying that the batch send method we
>> were using in 0.9.5 still works with the new async behaviour, seeing if
>> our consumer auto balance still functions or converting to use the Kafka
>> internal auto balance in Kafka 0.10, and finding a way to do efficient
>> synchronous writes with the new async methods.
>
>Can you +1 https://review.openstack.org/404878 to make it clear we can
>proceed
>down this path.

I don’t know, yet, that we can.  Unless we can find an answer to the
questions I had above I’m not sure that this new library will be
performant and durable enough for the use cases Monasca has.  I’m fairly
confident that we can make it work but the performance issues with
previous versions prevented us from even trying to integrate so it will
take us some time.  If you need an answer more quickly than a week or so,
and if anyone in the community is willing, I can walk them through the
testing I’d expect to happen to validate the new library.

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

Re: [openstack-dev] [all] Creating a new IRC meeting room ?

2016-12-04 Thread Shamail 


> On Dec 4, 2016, at 9:47 PM, Tony Breeds  wrote:
> 
>> On Fri, Dec 02, 2016 at 11:35:05AM +0100, Thierry Carrez wrote:
>> Hi everyone,
>> 
>> There has been a bit of tension lately around creating IRC meetings.
>> I've been busy[1] cleaning up unused slots and defragmenting biweekly
>> ones to open up possibilities, but truth is, even with those changes
>> approved, there will still be a number of time slots that are full:
>> 
>> Tuesday 14utc -- only biweekly available
>> Tuesday 16utc -- full
>> Wednesday 15utc -- only biweekly available
>> Wednesday 16utc -- full
>> Thursday 14utc -- only biweekly available
>> Thursday 17utc -- only biweekly available
>> 
>> [1] https://review.openstack.org/#/q/topic:dec2016-cleanup
>> 
>> Historically, we maintained a limited number of meeting rooms in order
>> to encourage teams to spread around and limit conflicts. This worked for
>> a time, but those days I feel like team members don't have that much
>> flexibility in picking a time that works for everyone. If the miracle
>> slot that works for everyone is not available on the calendar, they tend
>> to move the meeting elsewhere (private IRC channel, Slack, Hangouts)
>> rather than change time to use a less-busy slot.
>> 
>> So I'm now wondering how much that artificial scarcity policy is hurting
>> us more than it helps us. I'm still convinced it's very valuable to have
>> a number of "meetings rooms" that you can lurk in and be available for
>> pings, without having to join hundreds of channels where meetings might
>> happen. But I'm not sure anymore that maintaining an artificial scarcity
>> is helpful in limiting conflicts, and I can definitely see that it
>> pushes some meetings away from the meeting channels, defeating their
>> main purpose.
>> 
>> TL;DR:
> 
> Shouldn't this have been the headline ;P
> 
>> - is it time for us to add #openstack-meeting-5 ?
> 
> 13:38  info #openstack-meeting-5
> 13:38 -ChanServ(ChanServ@services.)- Information on #openstack-meeting-5:
> 13:38 -ChanServ(ChanServ@services.)- Founder: Magni, openstackinfra
> 13:38 -ChanServ(ChanServ@services.)- Successor  : freenode-staff
> 13:38 -ChanServ(ChanServ@services.)- Registered : Nov 27 20:02:51 2015 (1y 1w 
> 1d ago)
> 13:38 -ChanServ(ChanServ@services.)- Mode lock  : +ntc-slk
> 13:38 -ChanServ(ChanServ@services.)- Flags  : GUARD
> 13:38 -ChanServ(ChanServ@services.)- *** End of Info ***
> 
> So if we're going to go down that path it's just a matter of the appropriate
> changes in openstack-infra/{system,project}-config

I would be for adding at least 1-2 general meeting rooms.
> 
>> - should we more proactively add meeting channels in the future ?
> 
> In an attempt to get send the worlds most "on the fence" reply.  I really like
> the current structure, and I think it works well for the parts of the 
> community that
> touch lots of projects.  Having said that in my not very scientific opionion
> that's a very small amount of the community.  I think that most contributors
> would benefit from moving the meetings into $project specific rooms as Amrith,
> Matt and (kinda sorta) Daniel suggested.

Do we know how many of the project level rooms currently have bots?  I know I 
ran into an issue that one of the bots was at its maximum (128 rooms) and, 
therefore, I concerned about the infrastructure necessary to support too many 
new rooms if there is a new wave of changes to add bots.
> 
> Yours Tony.
> __
> OpenStack Development Mailing 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] Creating a new IRC meeting room ?

2016-12-04 Thread Tony Breeds 
On Fri, Dec 02, 2016 at 11:35:05AM +0100, Thierry Carrez wrote:
> Hi everyone,
> 
> There has been a bit of tension lately around creating IRC meetings.
> I've been busy[1] cleaning up unused slots and defragmenting biweekly
> ones to open up possibilities, but truth is, even with those changes
> approved, there will still be a number of time slots that are full:
> 
> Tuesday 14utc -- only biweekly available
> Tuesday 16utc -- full
> Wednesday 15utc -- only biweekly available
> Wednesday 16utc -- full
> Thursday 14utc -- only biweekly available
> Thursday 17utc -- only biweekly available
> 
> [1] https://review.openstack.org/#/q/topic:dec2016-cleanup
> 
> Historically, we maintained a limited number of meeting rooms in order
> to encourage teams to spread around and limit conflicts. This worked for
> a time, but those days I feel like team members don't have that much
> flexibility in picking a time that works for everyone. If the miracle
> slot that works for everyone is not available on the calendar, they tend
> to move the meeting elsewhere (private IRC channel, Slack, Hangouts)
> rather than change time to use a less-busy slot.
> 
> So I'm now wondering how much that artificial scarcity policy is hurting
> us more than it helps us. I'm still convinced it's very valuable to have
> a number of "meetings rooms" that you can lurk in and be available for
> pings, without having to join hundreds of channels where meetings might
> happen. But I'm not sure anymore that maintaining an artificial scarcity
> is helpful in limiting conflicts, and I can definitely see that it
> pushes some meetings away from the meeting channels, defeating their
> main purpose.
> 
> TL;DR:

Shouldn't this have been the headline ;P

> - is it time for us to add #openstack-meeting-5 ?

13:38  info #openstack-meeting-5
13:38 -ChanServ(ChanServ@services.)- Information on #openstack-meeting-5:
13:38 -ChanServ(ChanServ@services.)- Founder: Magni, openstackinfra
13:38 -ChanServ(ChanServ@services.)- Successor  : freenode-staff
13:38 -ChanServ(ChanServ@services.)- Registered : Nov 27 20:02:51 2015 (1y 1w 
1d ago)
13:38 -ChanServ(ChanServ@services.)- Mode lock  : +ntc-slk
13:38 -ChanServ(ChanServ@services.)- Flags  : GUARD
13:38 -ChanServ(ChanServ@services.)- *** End of Info ***

So if we're going to go down that path it's just a matter of the appropriate
changes in openstack-infra/{system,project}-config

> - should we more proactively add meeting channels in the future ?

In an attempt to get send the worlds most "on the fence" reply.  I really like
the current structure, and I think it works well for the parts of the community 
that
touch lots of projects.  Having said that in my not very scientific opionion
that's a very small amount of the community.  I think that most contributors
would benefit from moving the meetings into $project specific rooms as Amrith,
Matt and (kinda sorta) Daniel suggested.

Yours Tony.


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

Re: [openstack-dev] [oslo][monasca] Can we uncap python-kafka ?

2016-12-04 Thread Tony Breeds 
On Fri, Dec 02, 2016 at 06:18:39PM +, Keen, Joe wrote:
> 
> 
> On 12/2/16, 1:29 AM, "Mehdi Abaakouk"  wrote:
> 
> >On Fri, Dec 02, 2016 at 03:29:59PM +1100, Tony Breeds wrote:
> >>On Thu, Dec 01, 2016 at 04:52:52PM +, Keen, Joe wrote:
> >>
> >>> Unfortunately there¹s nothing wrong on the Monasca side so far as we
> >>>know.
> >>>  We test new versions of the kafka-python library outside of Monasca
> >>> before we bother to try integrating a new version.  Since 1.0 the
> >>> kafka-python library has suffered from crashes and memory leaks severe
> >>> enough that we¹ve never attempted using it in Monasca itself.  We
> >>>reported
> >>> the bugs we found to the kafka-python project but they were closed once
> >>> they released a new version.
> >>
> >>So Opening bugs isn't working.  What about writing code?
> >
> >The bug https://github.com/dpkp/kafka-python/issues/55
> >
> >Reopening it would be the right solution here.
> >
> >I can't reproduce the segfault neither and I agree with dpkp, that looks
> >like a
> >ujson issue.
> 
> 
> The bug I had was: https://github.com/dpkp/kafka-python/issues/551
> 
> In the case of that bug ujson was not an issue.  The behaviour remained
> even using the standard json library.  The primary issue I found with it
> was a memory leak over successive runs of the test script.  Eventually the
> leak became so bad that the OOM killer killed the process which caused the
> segfault I was seeing.  The last version I tested was 1.2.1 and it still
> leaked badly.  I¹ll need to let the benchmark script run for a while and
> make sure it¹s not still leaking.

So you write that on Friday so you shoudl know by now if it's leaking care to
give us an update?

> >And my bench seems to confirm the perf issue have been solved:
> >(but not in the pointed version...)
> >
> >$ pifpaf run kafka python kafka_test.py
> >kafka-python version: 0.9.5
> >...
> >fetch size 179200 -> 45681.8728864 messages per second
> >fetch size 204800 -> 47724.3810674 messages per second
> >fetch size 230400 -> 47209.9841092 messages per second
> >fetch size 256000 -> 48340.7719787 messages per second
> >fetch size 281600 -> 49192.9896743 messages per second
> >fetch size 307200 -> 50915.3291133 messages per second
> >
> >$ pifpaf run kafka python kafka_test.py
> >kafka-python version: 1.0.2
> >
> >fetch size 179200 -> 8546.77931323 messages per second
> >fetch size 204800 -> 9213.30958314 messages per second
> >fetch size 230400 -> 10316.668006 messages per second
> >fetch size 256000 -> 11476.2285269 messages per second
> >fetch size 281600 -> 12353.7254386 messages per second
> >fetch size 307200 -> 13131.2367288 messages per second
> >
> >(1.1.1 and 1.2.5 have also the same issue)
> >
> >$ pifpaf run kafka python kafka_test.py
> >kafka-python version: 1.3.1
> >fetch size 179200 -> 44636.9371873 messages per second
> >fetch size 204800 -> 44324.7085365 messages per second
> >fetch size 230400 -> 45235.8283208 messages per second
> >fetch size 256000 -> 45793.1044121 messages per second
> >fetch size 281600 -> 44648.6357019 messages per second
> >fetch size 307200 -> 44877.8445987 messages per second
> >fetch size 332800 -> 47166.9176281 messages per second
> >fetch size 358400 -> 47391.0057622 messages per second
> >
> >Looks like it works well now :)
> 
> It¹s good that the performance problem has been fixed.  The remaining
> issues on the Monasca side are verifying that the batch send method we
> were using in 0.9.5 still works with the new async behaviour, seeing if
> our consumer auto balance still functions or converting to use the Kafka
> internal auto balance in Kafka 0.10, and finding a way to do efficient
> synchronous writes with the new async methods.

Can you +1 https://review.openstack.org/404878 to make it clear we can proceed
down this path.

Yours Tony.


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

Re: [openstack-dev] [Zun] Propose a change of Zun core membership

2016-12-04 Thread Wenzhi Yu 
+1, welcome Pradeep!

> 在 2016年12月4日，下午10:49，Qiming Teng  写道：
> 
> +1 to both.
> 
> On Wed, Nov 30, 2016 at 11:37:59PM +, Hongbin Lu wrote:
>> Hi Zun cores,
>> 
>> I am going to propose the following change of the Zun core reviewers team:
>> + Pradeep Kumar Singh (pradeep-singh-u)
>> - Vivek Jain (vivek-jain-openstack)
>> 
>> Pradeep was proven to be a significant contributor to Zun. He ranked first 
>> at the number of commits, and his patches were non-trivial and with high 
>> quality. His reviews were also very helpful, and often prompted us to 
>> re-think the design. It would be great to have him in the core team. I would 
>> like to thank Vivek for his interest to join the core team when Zun was 
>> found. However, he became inactive in the past a few months, but he is 
>> welcomed to re-join the core team as long as he becomes active again.
>> 
>> According to the OpenStack Governance process [1], we require a minimum of 4 
>> +1 votes from Zun core reviewers within a 1 week voting window (consider 
>> this proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot 
>> get enough votes or there is a veto vote prior to the end of the voting 
>> window, this proposal is rejected.
>> 
>> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
>> 
>> Best regards,
>> Hongbin
> 
> 
> 
> __
> OpenStack Development Mailing 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] [vitrage] datasource driver returnsentities only?

2016-12-04 Thread Yujun Zhang 
Thanks for clarification.

Is `entity_type` equivalent to datasource type? And `entity_id` should be
interpreted by the related datasource, is that right.

For example, "RESOURCE:nova.host:12345678" is from `nova.host` datasource
and `12345678` is how `nova.host` identify a resource.

--
Yujun

On Sun, Dec 4, 2016 at 4:35 PM Weyl, Alexey (Nokia - IL) <
alexey.w...@nokia.com> wrote:

> Hi Yujun,
>
>
>
> I see the confusion.
>
>
>
> The way we find the resource entity (it’s different than finding the alarm
> entity, but it’s ok because the static datasource is defining relationships
> between resource entities) is in the following way:
>
> Each entity has a vitrage_id which is defined by
> “RESOURCE:: (we are planning in the very near
> future to change the vitrage_id to be a UUID, but at the moment your change
> doesn’t need to refer to that), for example: “RESOURCE:nova.host:12345678”.
>
>
>
> So in this way all you need to know about the other entity is it’s
>  and it’s .
>
>
>
> BR,
>
> Alexey
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Thursday, December 01, 2016 4:16 PM
>
>
> *To:* OpenStack Development Mailing List (not for usage questions)
>
> *Subject:* [ALU] Re: [openstack-dev] [ALU] [vitrage] datasource driver
> returnsentities only?
>
>
>
> Another question, how do we describe an entity from *another* datasource
> in static datasource config?
>
>
>
> In the test resources of static_physical datasource, it seems to be
> referred as following. Does it means that it will be `nova.host` to find
> the matched resource? If so, how will `nova.host` identify the resource, by
> name or by id?
>
>
> *relationships:  *- *type: *nova.host
> *name: *host-2
> *id: *2
> *relation_type: *attached
>
>
>
> On Thu, Dec 1, 2016 at 9:50 PM Weyl, Alexey (Nokia - IL) <
> alexey.w...@nokia.com> wrote:
>
> Hi Yujun,
>
>
>
> Get_all does returns a list of entities to be sent.
>
>
>
> Each event that is sent from the driver to the processor contains also all
> the details of the neighbors that it connects to.
>
> For example, the event and data that we receive from nova about an
> instance also contains the host (compute) that it sits on, and that is how
> we decide to connect it to the correct host.
>
>
>
> I think it is ok that the event of static (from driver to the processor)
> will contain for each entity it neighbors that it is supposed to be
> connected to.
>
>
>
> BR,
>
> Alexey
>
>
>
> *From:* Yujun Zhang [mailto:zhangyujun+...@gmail.com]
> *Sent:* Thursday, December 01, 2016 3:20 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [ALU] [openstack-dev] [vitrage] datasource driver returns
> entities only?
>
>
>
> During the implementation of static datasource driver[1], I got a question
> on the return format of `get_all` method.
>
>
>
> If I understand correctly, it should return a list of entities to be sent
> to the queue. Does it infer that the relationship should be embedded in
> entity, just like the legacy static_physical datasource?
>
>
>
> Suppose a link between two switches are created, how should we emit this
> change in `get_all` or `get_changes`?
>
>
>
> Currently I made a compromise by emitting the relationship as an update of
> the connected entity. This is not very elegant and it seems we are going
> back to the legacy static_physical datasource.
>
>
>
> [1] https://review.openstack.org/#/c/405354/
>
> --
>
> 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
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [charms] Default SSL Service Endpoints

2016-12-04 Thread James Beedy 
Running into a few bumps deploying keystone charm with SSL [1].

I'm wondering how others feel about having the Openstack charms account for
a heightened level of security by opting to use SSL endpoints over plain
http endpoints by default?

Something tells me having services default to using SSL endpoints, and have
the option to disable SSL, would be a better model then throwing up a
non-SSL Openstack as the default offering (and making this SSL breaks the
nice openstack story we have).

I'm thinking default SSL endpoints would help shed some light on the whole
SSL provisioning (there is an easyrsa charm now), and testing too, making
SSL Openstack something that is more common then not.

Thoughts?


[1] https://bugs.launchpad.net/charms/+source/keystone/+bug/1647193
__
OpenStack Development Mailing 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] About component having strongest development vibe

2016-12-04 Thread Mayur Patil 
Hi All,

As per status indicated here, most of the components are well developed.
http://www.openstack.org/software/project-navigator

In order to get job in Openstack companies, which component should I
consider to contribute?

Thanks in advance !

-- 

*Cheers,Mayur* S. Patil,
Journey from Program Learner
to Software Engineer,
Pune, India.

Contact : 
 [image: https://www.quora.com/Mayur-Patil-8]
 
 [image:
https://plus.google.com/+MayurPatil/about]





__
OpenStack Development Mailing 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] [Zun] Propose a change of Zun core membership

2016-12-04 Thread Qiming Teng 
+1 to both.

On Wed, Nov 30, 2016 at 11:37:59PM +, Hongbin Lu wrote:
> Hi Zun cores,
> 
> I am going to propose the following change of the Zun core reviewers team:
> + Pradeep Kumar Singh (pradeep-singh-u)
> - Vivek Jain (vivek-jain-openstack)
> 
> Pradeep was proven to be a significant contributor to Zun. He ranked first at 
> the number of commits, and his patches were non-trivial and with high 
> quality. His reviews were also very helpful, and often prompted us to 
> re-think the design. It would be great to have him in the core team. I would 
> like to thank Vivek for his interest to join the core team when Zun was 
> found. However, he became inactive in the past a few months, but he is 
> welcomed to re-join the core team as long as he becomes active again.
> 
> According to the OpenStack Governance process [1], we require a minimum of 4 
> +1 votes from Zun core reviewers within a 1 week voting window (consider this 
> proposal as a +1 vote from me). A vote of -1 is a veto. If we cannot get 
> enough votes or there is a veto vote prior to the end of the voting window, 
> this proposal is rejected.
> 
> [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
> 
> Best regards,
> Hongbin



__
OpenStack Development Mailing 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] [vitrage] datasource driver returnsentities only?

2016-12-04 Thread Weyl, Alexey (Nokia - IL) 
Hi Yujun,

I see the confusion.

The way we find the resource entity (it’s different than finding the alarm 
entity, but it’s ok because the static datasource is defining relationships 
between resource entities) is in the following way:
Each entity has a vitrage_id which is defined by 
“RESOURCE:: (we are planning in the very near future to 
change the vitrage_id to be a UUID, but at the moment your change doesn’t need 
to refer to that), for example: “RESOURCE:nova.host:12345678”.

So in this way all you need to know about the other entity is it’s 
 and it’s .

BR,
Alexey

From: Yujun Zhang [mailto:zhangyujun+...@gmail.com]
Sent: Thursday, December 01, 2016 4:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] Re: [openstack-dev] [ALU] [vitrage] datasource driver 
returnsentities only?

Another question, how do we describe an entity from another datasource in 
static datasource config?

In the test resources of static_physical datasource, it seems to be referred as 
following. Does it means that it will be `nova.host` to find the matched 
resource? If so, how will `nova.host` identify the resource, by name or by id?

relationships:
  - type: nova.host
name: host-2
id: 2
relation_type: attached

On Thu, Dec 1, 2016 at 9:50 PM Weyl, Alexey (Nokia - IL) 
> wrote:
Hi Yujun,

Get_all does returns a list of entities to be sent.

Each event that is sent from the driver to the processor contains also all the 
details of the neighbors that it connects to.
For example, the event and data that we receive from nova about an instance 
also contains the host (compute) that it sits on, and that is how we decide to 
connect it to the correct host.

I think it is ok that the event of static (from driver to the processor) will 
contain for each entity it neighbors that it is supposed to be connected to.

BR,
Alexey

From: Yujun Zhang 
[mailto:zhangyujun+...@gmail.com]
Sent: Thursday, December 01, 2016 3:20 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [ALU] [openstack-dev] [vitrage] datasource driver returns entities 
only?

During the implementation of static datasource driver[1], I got a question on 
the return format of `get_all` method.

If I understand correctly, it should return a list of entities to be sent to 
the queue. Does it infer that the relationship should be embedded in entity, 
just like the legacy static_physical datasource?

Suppose a link between two switches are created, how should we emit this change 
in `get_all` or `get_changes`?

Currently I made a compromise by emitting the relationship as an update of the 
connected entity. This is not very elegant and it seems we are going back to 
the legacy static_physical datasource.

[1] https://review.openstack.org/#/c/405354/
--
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