Re: [openstack-dev] [stackalytics] user correction seems not effective

[Yujun Zhang (ZTE)]

Hi, Trinath

What failure are you referring to exactly? It seems all jobs passed
normally.

I know there are some error message in the console logs, but that seems to
be expected failures for negative test cases.

On Mon, Mar 20, 2017 at 12:16 PM Trinath Somanchi 
wrote:

Jenkins is throwing some Failures in new submissions. That might be an
issue.

Get Outlook for iOS 

--
*From:* Yujun Zhang (ZTE) 
*Sent:* Monday, March 20, 2017 8:47:30 AM
*To:* shak...@gmail.com
*Cc:* OpenStack Development Mailing List (not for usage questions); 张玉军
*Subject:* [openstack-dev] [stackalytics] user correction seems not
effective

Hi, Ilya

I submitted a patch for user correction[1] several months ago. It is
supposed to reset the Email list of user `zhangyujun`. But it seems not
effective from the response of stackalytics api.

curl http://stackalytics.com/api/1.0/users/zhangyujun

{"user": {"launchpad_id": "zhangyujun", "user_id": "zhangyujun", "seq":
65434, "company_link": "EasyStack", "text": "Zhang
Yujun", "companies": [{"company_name": "ZTE Corporation", "end_date":
1474588800}, {"company_name": "EasyStack", "end_date": 0}], "id":
"zhangyujun", "static": true, "gerrit_id": "zhangyujun", "user_name":
"Zhang Yujun", "emails": [*"zhangyujun.d...@gmail.com
", "zhangyu...@gmail.com "*,
"284517...@qq.com", "zhangyujun+...@gmail.com", "yujun.zh...@easystack.cn",
"zhang.yuj...@zte.com.cn"]}}

The email address in red should be removed if the patch works as expected.

Is there any way I can make further investigation on this issue? The log
message from the stackalytics server might be helpful.

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

-- 
Yujun Zhang
__
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

-- 
Yujun Zhang
__
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] [stackalytics] user correction seems not effective

[Trinath Somanchi]

Jenkins is throwing some Failures in new submissions. That might be an issue.

Get Outlook for iOS


From: Yujun Zhang (ZTE) 
Sent: Monday, March 20, 2017 8:47:30 AM
To: shak...@gmail.com
Cc: OpenStack Development Mailing List (not for usage questions); 张玉军
Subject: [openstack-dev] [stackalytics] user correction seems not effective

Hi, Ilya

I submitted a patch for user correction[1] several months ago. It is supposed 
to reset the Email list of user `zhangyujun`. But it seems not effective from 
the response of stackalytics api.

curl http://stackalytics.com/api/1.0/users/zhangyujun


{"user": {"launchpad_id": "zhangyujun", "user_id": "zhangyujun", "seq": 65434, 
"company_link": "EasyStack",
 "text": "Zhang Yujun", "companies": [{"company_name": "ZTE Corporation", 
"end_date": 1474588800}, {"company_name": "EasyStack", "end_date": 0}], "id": 
"zhangyujun", "static": true, "gerrit_id": "zhangyujun", "user_name": "Zhang 
Yujun", "emails": 
["zhangyujun.d...@gmail.com", 
"zhangyu...@gmail.com", 
"284517...@qq.com", 
"zhangyujun+...@gmail.com", 
"yujun.zh...@easystack.cn", 
"zhang.yuj...@zte.com.cn"]}}

The email address in red should be removed if the patch works as expected.

Is there any way I can make further investigation on this issue? The log 
message from the stackalytics server might be helpful.


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

--
Yujun Zhang
__
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] [stackalytics] user correction seems not effective

[Yujun Zhang (ZTE)]

Hi, Ilya

I submitted a patch for user correction[1] several months ago. It is
supposed to reset the Email list of user `zhangyujun`. But it seems not
effective from the response of stackalytics api.

curl http://stackalytics.com/api/1.0/users/zhangyujun

{"user": {"launchpad_id": "zhangyujun", "user_id": "zhangyujun", "seq":
65434, "company_link": "EasyStack", "text": "Zhang
Yujun", "companies": [{"company_name": "ZTE Corporation", "end_date":
1474588800}, {"company_name": "EasyStack", "end_date": 0}], "id":
"zhangyujun", "static": true, "gerrit_id": "zhangyujun", "user_name":
"Zhang Yujun", "emails": [*"zhangyujun.d...@gmail.com
", "zhangyu...@gmail.com "*,
"284517...@qq.com", "zhangyujun+...@gmail.com", "yujun.zh...@easystack.cn",
"zhang.yuj...@zte.com.cn"]}}

The email address in red should be removed if the patch works as expected.

Is there any way I can make further investigation on this issue? The log
message from the stackalytics server might be helpful.

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

-- 
Yujun Zhang
__
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][lbaasv2] Migrate LBaaS instance

[zhi]

hi, Saverio

Thanks for your reply. I have uploaded a patch at [1]. But I met some
problems about the implementation about the migration of LBaaS.
Please take a look at it if you have time. I'll very welcome about any
advices. :-)


Thanks
Zhi Chang


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

2017-03-17 19:54 GMT+08:00 Saverio Proto :

> Hello there,
>
> I am just back from the Ops Midcycle where Heidi Joy Tretheway reported
> some data from the user survey.
>
> So if we look at deployments with more than 100 servers NO ONE IS USING
> NEWTON yet. And I scream this loud. Everyone is still in Liberty or Mitaka.
>
> I am just struggling to upgrade to LBaaSv2 to hear that is already going
> into deprecation. The feature Zhi is proposing is important also for me
> once I go to production.
>
> I would encourage devs to listen more to operators feedback. Also you
> devs cant just ignore that users are running still Liberty/Mitaka so you
> need to change something in this way of working or all the users will
> run away.
>
> thank you
>
> Saverio
>
>
> On 16/03/17 16:26, Kosnik, Lubosz wrote:
> > Hello Zhi,
> > Just one small information. Yesterday on Octavia weekly meeting we
> > decided that we’re gonna add new features to LBaaSv2 till Pike-1 so the
> > windows is very small.
> > This decision was made as LBaaSv2 is currently Octavia delivery, not
> > Neutron anymore and this project is going into deprecations stage.
> >
> > Cheers,
> > Lubosz
> >
> >> On Mar 16, 2017, at 5:39 AM, zhi  >> > wrote:
> >>
> >> Hi, all
> >> Currently, LBaaS v2 doesn't support migration. Just like router
> >> instances, we can remove a router instance from one L3 agent and add
> >> it to another L3 agent.
> >>
> >> So, there is a single point failure in LBaaS agent. As far as I know,
> >> LBaaS supports " allow_automatic_lbaas_agent_failover ". But in many
> >> cases, we want to migrate LBaaS instances manually. Do we plan to do
> this?
> >>
> >> I'm doing this right now. But I meet a question. I define a function
> >> in agent_scheduler.py like this:
> >>
> >> def remove_loadbalancer_from_lbaas_agent(self, context, agent_id,
> >> loadbalancer_id):
> >> self._unschedule_loadbalancer(context, loadbalancer_id,
> agent_id)
> >>
> >> The question is, how do I notify LBaaS agent?
> >>
> >> Hope for your reply.
> >>
> >>
> >>
> >> Thanks
> >> Zhi Chang
> >> 
> __
> >> 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
> >
>
>
> --
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
>
> http://www.switch.ch/stories
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] A lot of instack-haproxy zombie processes

[Sagi Shnaidman]

Hi, all

while investigating periodic jobs failure, I mentioned a lot of Z processes
on undercloud:

bash-4.2# ps aux | grep " Z " | less
root 28481  0.0  0.0  0 0 ?Z17:41   0:00
[instack-haproxy] 
root 28494  0.0  0.0  0 0 ?Z17:41   0:00
[instack-haproxy] 
root 28509  0.0  0.0  0 0 ?Z17:41   0:00
[instack-haproxy] 
root 28522  0.0  0.0  0 0 ?Z17:41   0:00
[instack-haproxy] 
...
bash-4.2# ps aux | grep " Z " | wc -l
979

About a thousand same zombie processes. I don't think it's appropriate
behavior, although not sure it's the reason for failing jobs. Any ideas why
it could happen?

Thanks

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

Re: [openstack-dev] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

[Jay Pipes]

Also, I gave a stab at an etcd3 tooz coordination driver:

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

Can't figure out how to get the tests to run properly, but meh, I'll get 
to it in a bit :)


-jay

On 03/19/2017 04:34 PM, Davanum Srinivas wrote:

Quick update: We have 3 options to talk to etcd:

1) existing V2 HTTP API - still not deprecated in etcd 3.1.x, so
existing code in tooz still works.
2) grpc based V3 API - We can use the etcd3 package, discussion in
review[1], problem is that this will not work currently with eventlet
based services
3) v3alpha HTTP API - See details in [2], quick prototype requests
based code [3]

Thanks,
Dims

[1] https://review.openstack.org/#/c/446983/
[2] 
https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md
[3] https://gist.github.com/dims/19ceaf9472ef54aa3011d7a11e809371

On Sun, Mar 19, 2017 at 9:32 AM, Jay Pipes  wrote:

On 03/18/2017 07:48 PM, Mike Perez wrote:


On 12:35 Mar 14, Jay Pipes wrote:


On 03/14/2017 08:57 AM, Julien Danjou wrote:


On Tue, Mar 14 2017, Davanum Srinivas wrote:


Let's do it!! (etcd v2-v3 in tooz)



Hehe. I'll move that higher in my priority list, I swear. But anyone is
free to beat me to it in the meantime. ;)



A weekend experiment:

https://github.com/jaypipes/os-lively

Not tooz, because I'm not interested in a DLM nor leader election library
(that's what the underlying etcd3 cluster handles for me), only a fast
service liveness/healthcheck system, but it shows usage of etcd3 and
Google
Protocol Buffers implementing a simple API for liveness checking and host
maintenance reporting.

My plan is to push some proof-of-concept patches that replace Nova's
servicegroup API with os-lively and eliminate Nova's use of an RDBMS for
service liveness checking, which should dramatically reduce the amount of
both DB traffic as well as conductor/MQ service update traffic.



As Monty has mentioned, I'd love for us to decide on one thing. As being
a moderator of that discussion I was trying not to be one-sided.

Whether or not a decision was made 1.5 years ago, the community that was
present at that time of the decision at the summit decided on an
abstraction
layer to have options. Forcing an option on the community without
gathering
feedback of what the community currently looks like is not a good idea.

I'd recommend if you want to make this base service, start the discussions
in
somewhere other than the dev list, like the Forum.



Mike, it was an experiment :)

But, yes, happy to participate in a discussion at the forum.


Best,
-jay

__
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] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

[Davanum Srinivas]

Quick update: We have 3 options to talk to etcd:

1) existing V2 HTTP API - still not deprecated in etcd 3.1.x, so
existing code in tooz still works.
2) grpc based V3 API - We can use the etcd3 package, discussion in
review[1], problem is that this will not work currently with eventlet
based services
3) v3alpha HTTP API - See details in [2], quick prototype requests
based code [3]

Thanks,
Dims

[1] https://review.openstack.org/#/c/446983/
[2] 
https://github.com/coreos/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md
[3] https://gist.github.com/dims/19ceaf9472ef54aa3011d7a11e809371

On Sun, Mar 19, 2017 at 9:32 AM, Jay Pipes  wrote:
> On 03/18/2017 07:48 PM, Mike Perez wrote:
>>
>> On 12:35 Mar 14, Jay Pipes wrote:
>>>
>>> On 03/14/2017 08:57 AM, Julien Danjou wrote:

 On Tue, Mar 14 2017, Davanum Srinivas wrote:

> Let's do it!! (etcd v2-v3 in tooz)


 Hehe. I'll move that higher in my priority list, I swear. But anyone is
 free to beat me to it in the meantime. ;)
>>>
>>>
>>> A weekend experiment:
>>>
>>> https://github.com/jaypipes/os-lively
>>>
>>> Not tooz, because I'm not interested in a DLM nor leader election library
>>> (that's what the underlying etcd3 cluster handles for me), only a fast
>>> service liveness/healthcheck system, but it shows usage of etcd3 and
>>> Google
>>> Protocol Buffers implementing a simple API for liveness checking and host
>>> maintenance reporting.
>>>
>>> My plan is to push some proof-of-concept patches that replace Nova's
>>> servicegroup API with os-lively and eliminate Nova's use of an RDBMS for
>>> service liveness checking, which should dramatically reduce the amount of
>>> both DB traffic as well as conductor/MQ service update traffic.
>>
>>
>> As Monty has mentioned, I'd love for us to decide on one thing. As being
>> a moderator of that discussion I was trying not to be one-sided.
>>
>> Whether or not a decision was made 1.5 years ago, the community that was
>> present at that time of the decision at the summit decided on an
>> abstraction
>> layer to have options. Forcing an option on the community without
>> gathering
>> feedback of what the community currently looks like is not a good idea.
>>
>> I'd recommend if you want to make this base service, start the discussions
>> in
>> somewhere other than the dev list, like the Forum.
>
>
> Mike, it was an experiment :)
>
> But, yes, happy to participate in a discussion at the forum.
>
>
> Best,
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [infra][tripleo] initial discussion for a new periodic pipeline

[Sagi Shnaidman]

Hi, Paul
I would say that real worthwhile try starts from "normal" priority, because
we want to run promotion jobs more *often*, not more *rarely* which happens
with low priority.
In addition the initial idea in the first mail was running them each after
other almost, not once a day like it happens now or with "low" priority.

Thanks

On Wed, Mar 15, 2017 at 11:16 PM, Paul Belanger 
wrote:

> On Wed, Mar 15, 2017 at 03:42:32PM -0500, Ben Nemec wrote:
> >
> >
> > On 03/13/2017 02:29 PM, Sagi Shnaidman wrote:
> > > Hi, all
> > >
> > > I submitted a change: https://review.openstack.org/#/c/443964/
> > > but seems like it reached a point which requires an additional
> discussion.
> > >
> > > I had a few proposals, it's increasing period to 12 hours instead of 4
> > > for start, and to leave it in regular periodic *low* precedence.
> > > I think we can start from 12 hours period to see how it goes, although
> I
> > > don't think that 4 only jobs will increase load on OVB cloud, it's
> > > completely negligible comparing to current OVB capacity and load.
> > > But making its precedence as "low" IMHO completely removes any sense
> > > from this pipeline to be, because we already run experimental-tripleo
> > > pipeline which this priority and it could reach timeouts like 7-14
> > > hours. So let's assume we ran periodic job, it's queued to run now 12 +
> > > "low queue length" - about 20 and more hours. It's even worse than
> usual
> > > periodic job and definitely makes this change useless.
> > > I'd like to notice as well that those periodic jobs unlike "usual"
> > > periodic are used for repository promotion and their value are equal or
> > > higher than check jobs, so it needs to run with "normal" or even "high"
> > > precedence.
> >
> > Yeah, it makes no sense from an OVB perspective to add these as low
> priority
> > jobs.  Once in a while we've managed to chew through the entire
> experimental
> > queue during the day, but with the containers job added it's very
> unlikely
> > that's going to happen anymore.  Right now we have a 4.5 hour wait time
> just
> > for the check queue, then there's two hours of experimental jobs queued
> up
> > behind that.  All of which means if we started a low priority periodic
> job
> > right now it probably wouldn't run until about midnight my time, which I
> > think is when the regular periodic jobs run now.
> >
> Lets just give it a try? A 12 hour periodic job with low priority. There is
> nothing saying we cannot iterate on this after a few days / weeks / months.
>
> > >
> > > Thanks
> > >
> > >
> > > On Thu, Mar 9, 2017 at 10:06 PM, Wesley Hayutin  > > > wrote:
> > >
> > >
> > >
> > > On Wed, Mar 8, 2017 at 1:29 PM, Jeremy Stanley  > > > wrote:
> > >
> > > On 2017-03-07 10:12:58 -0500 (-0500), Wesley Hayutin wrote:
> > > > The TripleO team would like to initiate a conversation about
> the
> > > > possibility of creating a new pipeline in Openstack Infra to
> allow
> > > > a set of jobs to run periodically every four hours
> > > [...]
> > >
> > > The request doesn't strike me as contentious/controversial.
> Why not
> > > just propose your addition to the zuul/layout.yaml file in the
> > > openstack-infra/project-config repo and hash out any resulting
> > > concerns via code review?
> > > --
> > > Jeremy Stanley
> > >
> > >
> > > Sounds good to me.
> > > We thought it would be nice to walk through it in an email first :)
> > >
> > > Thanks
> > >
> > >
> > > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > >  unsubscribe>
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-dev  openstack-dev>
> > >
> > >
> > >
> > > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > >  unsubscribe>
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >  >
> > >
> > >
> > >
> > >
> > > --
> > > Best regards
> > > Sagi Shnaidman
> > >
> > >
> > > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: 

Re: [openstack-dev] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

[Jay Pipes]

On 03/18/2017 07:48 PM, Mike Perez wrote:

On 12:35 Mar 14, Jay Pipes wrote:

On 03/14/2017 08:57 AM, Julien Danjou wrote:

On Tue, Mar 14 2017, Davanum Srinivas wrote:


Let's do it!! (etcd v2-v3 in tooz)


Hehe. I'll move that higher in my priority list, I swear. But anyone is
free to beat me to it in the meantime. ;)


A weekend experiment:

https://github.com/jaypipes/os-lively

Not tooz, because I'm not interested in a DLM nor leader election library
(that's what the underlying etcd3 cluster handles for me), only a fast
service liveness/healthcheck system, but it shows usage of etcd3 and Google
Protocol Buffers implementing a simple API for liveness checking and host
maintenance reporting.

My plan is to push some proof-of-concept patches that replace Nova's
servicegroup API with os-lively and eliminate Nova's use of an RDBMS for
service liveness checking, which should dramatically reduce the amount of
both DB traffic as well as conductor/MQ service update traffic.


As Monty has mentioned, I'd love for us to decide on one thing. As being
a moderator of that discussion I was trying not to be one-sided.

Whether or not a decision was made 1.5 years ago, the community that was
present at that time of the decision at the summit decided on an abstraction
layer to have options. Forcing an option on the community without gathering
feedback of what the community currently looks like is not a good idea.

I'd recommend if you want to make this base service, start the discussions in
somewhere other than the dev list, like the Forum.


Mike, it was an experiment :)

But, yes, happy to participate in a discussion at the forum.

Best,
-jay

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

[openstack-dev] [os-upstream-institute] Meeting time selected

[Ildiko Vancsa]

Hi All,

Based on the results of the Doodle poll I sent out earlier the most favorite 
slot for the meeting is __Mondays, 2000 UTC__.

In order to get progress with the training preparation for Boston we will hold 
our first meeting on __March 20, at 2000 UTC__. The meeting channel is 
__#openstack-meeting-3__. You can find and extend the agenda on the meetings 
etherpad [2].

I uploaded a patch for review [1] to register the meeting slot as a permanent 
meeting on this channel.

We will look into alternatives to keep those of you involved and up to date for 
whom this slot is unfortunately does not work.

Please let me know if you have any questions or comments.

Thanks and Best Regards,
Ildikó
IRC: ildikov


[1] https://review.openstack.org/447291 
[2] https://etherpad.openstack.org/p/openstack-upstream-institute-meetings __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [os-client-config] get_session_endpoint() and Keystone admin endpoint

[Akira Yoshiyama]

Hi all,

I have developed Yakumo, a pythonic unified OpenStack client library:

  PyPI: https://pypi.python.org/pypi/yakumo
  Git: https://github.com/yosshy/python-yakumo

and I found that
os_client_config.cloud_config.CloudConfig.get_session_endpoint()
didn't return Keystone admin endpoint because of below:

  
https://github.com/openstack/os-client-config/blob/master/os_client_config/cloud_config.py#L258

Why is it so?

Thank you,
Akira

__
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] questions about Openstack Ocata replacement API

[Chris Dent]

On Sun, 19 Mar 2017, zhihao wang wrote:


I am trying the new version openstack ocata in Ubuntu 1604

But I got some problem with nova placement API, there is nothing on the 
Openstack Ubuntu Installation Doc


The docs for that are being updated to include the necessary
information. If you at https://review.openstack.org/#/c/438328/
you'll see the new information there. A rendered version will be at
http://docs-draft.openstack.org/28/438328/12/check/gate-openstack-manuals-tox-doc-publish-checkbuild/846ac33//publish-docs/draft/install-guide-ubuntu/nova.html


I already have the endpoint, but it always said there is no placement API 
endpoint  , please see below


As one of the responses on ask.openstack says, depending on which
version of the packages you have you may need to add to your apache2
config something like:


 Require all granted


I believe this has been resolved in newer versions of the packaging.


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

[openstack-dev] [publiccloud-wg]Public Cloud WG Boston Forum Brainstorming CFP

[Zhipeng Huang]

Hi Devs,

We in the Public Cloud WG is now drafting our Boston Forum session at
https://etherpad.openstack.org/p/publiccloud-boston-forum-session, if you
are interested in public cloud implementation or want to share some past
experience or best practices, you are more than welcome to add your topics
on the etherpad.

Thank you very much :)

-- 
Zhipeng (Howard) Huang

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

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

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

Re: [openstack-dev] [vitrage] what is "API to register on Vitrage notificaitons"

[Afek, Ifat (Nokia - IL)]

Yes, that’s the right blueprint.

Best Regards,
Ifat.

From: "Yujun Zhang (ZTE)" 
Date: Thursday, 16 March 2017 at 18:14

Hi root causers

I want to confirm some detail about one subject in vitrage Pike roadmap

· API to register on Vitrage notificaitons

Is it linked to blueprint 
https://blueprints.launchpad.net/vitrage/+spec/configurable-notifications ?

--
Yujun Zhang
__
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