[openstack-dev] [tacker] December 28th weekly meeting cancelled

[Sridhar Ramaswamy]

We are skipping next week's Tacker meeting, on Dec 28th [1]. We will resume
on Jan 4th.

Happy Holidays!!

[1]
http://eavesdrop.openstack.org/meetings/tacker/2016/tacker.2016-12-21-05.30.log.html
__
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] [acceleration]Team Bi-weekly Meeting 2016.12.21 Agenda

[Zhipeng Huang]

Hi Team,

Please find the agenda at
https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Next_meeting_:_UTC_1500.2C_Dec_21th

Remember that our IRC channel is #openstack-cyborg

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

[openstack-dev] [tricircle]agenda of weekly meeting Dec.21

[joehuang]

Hello, team,

Agenda of Dec.21 weekly meeting:

  1.  one idea to address VxLAN L2 networking/L3 DVR issue
  2.  Ocata feature development review
  3.  Open Discussion

How to join:
#  IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on 
every Wednesday starting from UTC 13:00.


If you  have other topics to be discussed in the weekly meeting, please reply 
the mail.

Best Regards
Chaoyi Huang (joehuang)
__
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] [Vitrage] [aodh] Generig alarm help

[Weyl, Alexey (Nokia - IL)]

Hi,

I have pushed the first code of the generic alarm to the aodhclient.

I encountered an error there in py27 which I don't quite understand why it 
happens because I have changed all the correct places in the client (maybe I 
need to have some appropriate code for this in the aodh project itself as well?)

The error is:
FAIL: 
aodhclient.tests.functional.test_alarm.AodhClientTest.test_generic_scenario
tags: worker-0
--
Empty attachments:
  pythonlogging:''
  stderr
  stdout

Traceback (most recent call last):
  File "aodhclient/tests/functional/test_alarm.py", line 436, in 
test_generic_scenario
'--project-id %s' % project_id))
  File "aodhclient/tests/functional/base.py", line 67, in aodh
return self.clients.aodh(*args, **kwargs)
  File "aodhclient/tests/functional/base.py", line 44, in aodh
merge_stderr, self.cli_dir)
  File 
"/home/jenkins/workspace/gate-python-aodhclient-python27-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/tempest/lib/cli/base.py",
 line 68, in execute
result_err)
tempest.lib.exceptions.CommandFailed: Command 
'['/home/jenkins/workspace/gate-python-aodhclient-python27-ubuntu-xenial/.tox/py27/bin/aodh',
 '--os-auth-plugin', 'aodh-noauth', '--user-id', 
'3862e83e-a752-42fa-8a4f-a66bdd23c503', '--project-id', 
'b4cdce18-f33e-4d6a-9d4f-9e6d4c4437bb', '--aodh-endpoint', 
'http://localhost:8042', 'alarm', 'create', '--type', 'generic', '--name', 
'gen_alarm_1', '--project-id', 'd2243574-8472-46b0-a63b-70f6bba6fd99']' 
returned non-zero exit status 1.
stdout:

stderr:
Unknown attribute for argument data: generic_rule (HTTP 400) (Request-ID: 
req-2e5db4a4-a07b-40fa-92a8-c3eeae6155e4)

You can find it here:
https://review.openstack.org/#/c/413008/

Can any please take a look at it, and knows why it happens?

Thanks in advance,
Alexey


__
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] [FaaS] Function as a service in OpenStack

[Derek Schultz]

Hi all,

We just released Picasso[1][2], an OpenStack API for Functions as a
Service. I think it may be of particular interest to those in this thread,
as it's based on IronFunctions, an open-source alternative to Lambda.

The mission is to provide an API to run functions on OpenStack.

Picasso is comprised of two main components:

   - Picasso API
  - The Picasso API server uses Keystone authentication and
  authorization through its middleware.
   - IronFunctions
  - Picasso leverages the backend container engine provided by
  IronFunctions[3], an open-source Serverless/FaaS platform based on Docker.

You can try out Picasso now on DevStack by following the quick start
guide[4]. Let us know what you think!

If you’re interested in contributing or just have any questions, please
join us on Slack at open-iron.slack.com.

Regards,
Derek

[1] https://launchpad.net/picasso

[2] https://launchpad.net/python-picassoclient

[3] https://github.com/iron-io/functions

[4]
https://github.com/iron-io/picasso/blob/master/README.md#quick-start-guide

On Thu, Nov 3, 2016 at 2:37 PM, Fox, Kevin M  wrote:

> Would Kubernetes be a good fit? It might be possible to hook up a Zaqar
> queue to submit k8s Jobs?
>
> Thanks,
> Kevin
> --
> *From:* Lingxian Kong [anlin.k...@gmail.com]
> *Sent:* Wednesday, November 02, 2016 6:20 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [FaaS] Function as a service in OpenStack
>
> On Thu, Nov 3, 2016 at 10:44 AM, Zane Bitter  wrote:
>
>> This is a really interesting space. There seems to be two main use cases
>> for Lambda that are probably worth talking about separately:
>>
>> The first is for just Lambda alone. You can use it to provide some glue
>> logic between the other AWS services, so you can trigger off various events
>> (e.g. S3 notifications) and write a little bit of conditioning logic that
>> transforms the data and dispatches it to other services (e.g. DynamoDB).
>> This one is particularly interesting to me, and in fact we can support
>> parts of this in OpenStack already[1] because Mistral's functionality is
>> equivalent to something like SWS + parts of Lambda. (Specifically, Mistral
>> can do the data dispatch easily enough, but any data transformation has to
>> be done in YAQL, which is a pretty high bar compared to just writing some
>> code in a language of your choosing.)
>>
>
> ​There is still one thing missing in Mistral​ (maybe it should not be).
> After receieving events from Aodh or Zaqar, what if user just wants to
> trigger some scripts under his/her management, rather than just invoking
> openstack services api? Although actions are pluggable in Mistral, but in
> this case it's definitely not an easy thing as just writing an customized
> action, unless Mistral could include such capatility in its scope which I
> think it too heavy for Mistral to mange such things by itself. So, FaaS
> will be the right answer in this case, and it will also be add-on part to
> empower Mistral to do more things.
>
>
>>
>> The second one is Lambda + the API Gateway, which allows you to have web
>> requests act as triggers, so that you can effectively treat it as a PaaS
>> and build an entire web app by stringing together Lambda functions and the
>> various other services (S3, DynamoDB, ). On the face of it this sounds
>> to me like a gimmicky way of deploying an unmaintainable mess. Naturally
>> this is the one receiving all of the attention, which shows how much I know
>> :D
>
>
> ​I also don't think this one is attractive to me, Lambda is especially
> powerful when it's used together with other AWS services(S3,
> DynamoDB, Kinesis Streams, etc).
> ​​
>
>>
>> I definitely don't think we should try to reimplement this from scratch
>> in OpenStack. IMHO if we're going to add FaaS capabilities we should re-use
>> some existing project (like OpenWhisk), even if we have to write our own
>> native API over the top of it.
>>
>> The things we'd really want it to do would be:
>>
>> * Authenticate against Keystone,
>> * Provide Keystone credentials for the user-supplied functions it runs to
>> access (probably using Keystone trusts), and
>> * Connect to existing OpenStack sources of events, which hopefully means
>> Zaqar queues
>>
>> Which sounds challenging to integrate with an existing standalone
>> project, though still not as bad as writing an equivalent from scratch.
>>
>> TBH I think the appeal, at least for the FaaS-as-a-PaaS (aka #serverless)
>> crowd, is going to be pretty limited until such time as we have an
>> equivalent of DynamoDB in OpenStack. (i.e. no time soon, since the
>> MagnetoDB project is goneburger.) The idea of FaaS is to make the unit of
>> compute power that you're paying for (a) as fine-grained as possible, and
>> (b) scalable to infinity. Swift provides the same thing for storage
>> (Nova:FaaS::Cinder:Swift). What we don't 

[openstack-dev] [nova] Nova API sub-team meeting

[Alex Xu]

Hi,

It is really close to the holidays. But we didn't say we will cancel the
meeting. I will be there if there are people.

Thanks
__
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] A question on the endpoint of Heat

[zengchen]

Zane Bitter:
Thank you for your replay. I read the codes of Keystone by your reminding.  
Maybe the following codes can help us understand. Thanks again!



https://github.com/openstack/keystone/blob/master/keystone/common/utils.py#L633

https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py#L68



cheers
zengchen






At 2016-12-20 22:22:17, "Zane Bitter"  wrote:
>On 20/12/16 02:29, zengchen wrote:
>> Hi, Heat stackers:
>> May I ask a question about the endpoint of Heat. I see the endpoints
>> of Heat registered to Keystone look like this.
>> 'http://10.229.45.150:8004/v1/$(project_id)s' . My question is that why
>> use '$' instead of '%' as the replacement symbol.
>> Is there some kind of rule?
>
>Keystone supports either syntax. IIRC this one is slightly preferred. 
>It's really not important.
>
>- ZB
>
>
>__
>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] [kolla-kubernetes] Dec 28 meeting canceled

[Swapnil Kulkarni]

On Wed, Dec 21, 2016 at 8:31 AM, Michał Jastrzębski  wrote:
> Hello,
>
> Let's cancel meeting at 28 Dec, but 21 Dec and 4 Jan are still on,
> probably more lightweight but try to be there please.
>
> Cheers,
> Michal
>
> __
> 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] Dec 28 meeting canceled

[Michał Jastrzębski]

Hello,

Let's cancel meeting at 28 Dec, but 21 Dec and 4 Jan are still on,
probably more lightweight but try to be there please.

Cheers,
Michal

__
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] [nova] Help: How to make Nova official support AArch64?

[Matt Riedemann]

On 12/20/2016 7:27 AM, Jay Pipes wrote:

On 12/20/2016 12:45 AM, Kevin Zhao wrote:

Hello Nova,
  Greetings from ARM and Linaro :D
  This is Kevin Zhao from ARM. Nowadays Linaro and other
contributors have submitted some patches to Nova community , fixing bugs
for Nova running on AArch64. Now we can successfully running a OpenStack
cluster on AArch64 and pass much of the tempest test. The
virtuallization hypervisor is based on Libvirt+KVM.

  Actually in Barcelona Keynote(interoperability Challenge
,

at 10:30') one of the OpenStack interoperability cloud is from Linaro,
all based on AArch64 machines.
   I see there is a Nova support matrix
. So my
question is :
*   what do we need to do, so that Nova can official support AArch64
architecture? for example add AArch64 to this support matrix?*

   Sincerely thanks for your help. Any of your response will be
really appreciated.


Hi Kevin,

I think the first thing you would need to do is set up some sort of
continuous integration system that can be notified by upstream patch
changes/pushes and report results of Tempest testing against a build of
OpenStack on AArch64 machines.

You can read about setting up third-party CI for this here:

http://docs.openstack.org/infra/system-config/

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



Yeah as Jay said it's probably 3rd party CI to recognize it in the 
support matrix.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [neutron] Where will Neutron go in future?

[Michael Johnson]

Hi Zhi,

LBaaSv2 as an API will live on.

We are in the process of merging that API into the octavia repository
to merge the two load balancing projects into one and remove our
dependency on the neutron API process/endpoint.

Functionally it is our goal to allow the LBaaSv2 API to continue to
function for users.  For some period of time we will maintain a
pass-through proxy so that calls to the neutron API endpoint will
continue to function as they do today.  In addition, we will be
advertising the octavia endpoint and it will be compatible with the
current LBaaSv2 API.  Over time users can switch the endpoint they use
for LBaaSv2 calls from the neutron endpoint and they will continue to
operate as expected.

As part of this compatibility, the current LBaaSv2 drivers will move
behind the octavia API process as opposed to the current neutron API
process.  The legacy haproxy-namespace driver and the octavia (haproxy
based as well) driver will continue to exist for some time, though we
would like to deprecate the legacy haproxy-namespace driver.

Given the progress we have made up to Ocata-2, I expect Ocata will
release with the same configuration as Newton.  We will have the
LBaaSv2 API in place in octavia, but the driver and pass through work
will not be complete in time.  This means you will continue to use the
neutron endpoint to access neutron-lbaas drivers as you do today.

Michael

On Sun, Dec 18, 2016 at 6:52 PM, zhi  wrote:
> Deal all.
>
> I have some questions about what will Neutron does in next releases.
>
> As far as I know, LBaaSv2 will be deprecated in next 2 releases, maybe P
> release, we will not see LBaaSv2 anymore, isn't it? Instead of LBaaSv2(
> HAProxy driver based ), Octavia will be the only LBaaS solution, isn't it?
>
> What's about namespace based L3 router? Do we have any ideas about NFV
> solution in L3 router just like Octavia?
>
> Finally, where will Neutron *aaS go in future? Now, vpnaas was not part of
> neutron governance. What about fwaas? Do we deprecated it in next releases?
>
> I wish someone could give some exact words about these. I will thanks a lot.
> :)
>
>
> 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

Re: [openstack-dev] [networking-sfc] Intermittent database transaction issues, affecting the tempest gate

[Cathy Zhang]

Hi Bernard,

Thanks for the email. I will take a look at this. Xiaodong has been working on 
tempest test scripts. 
I will work with Xiaodong on this issue. 

Cathy


-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Tuesday, December 20, 2016 3:00 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [networking-sfc] Intermittent database transaction 
issues, affecting the tempest gate

Hi everyone,

we have an open bug (thanks Igor for the report) on DB transaction issues:
https://bugs.launchpad.net/networking-sfc/+bug/1630503

The thing is, I am seeing  quite a few tempest gate failures that follow the 
same pattern: at some point in the test suite, the service gets warnings/errors 
from the DB layer (reentrant call, closed transaction, nested rollback, …), and 
all following tests fail.

This affects both master and stable/newton branches (not many changes for now 
in the DB parts between these branches)

Some examples:
* https://review.openstack.org/#/c/400396/ failed with console log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/console.html#_2016-12-16_12_44_47_564544
and service log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_12_44_32_301
* https://review.openstack.org/#/c/405391/ failed,
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/console.html.gz#_2016-12-16_13_05_17_384323
and 
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_13_04_11_840
* another on master branch: https://review.openstack.org/#/c/411194/
with 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/console.html.gz#_2016-12-15_22_36_15_216260
and 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-15_22_35_53_310

I took a look at the errors, but only found old-and-apparently-fixed pymysql 
bugs, and suggestions like:
* 
http://docs.sqlalchemy.org/en/latest/faq/sessions.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush-or-similar
*  https://review.openstack.org/#/c/230481/
Not really my forte, so if someone could take a look at these logs and fix the 
problem, it would be great! Especially with the upcoming multinode tempest gate

Thanks,
--
Bernard Cafarelli

__
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] [HA] haproxy can't start with manual setup according to the guide

[黑 鹰]

Hi,

haproxy can't start because of its listening ports on vip conflicting 
with openstack services' listening ports on 0.0.0.0.

I opened a bug about it:

https://bugs.launchpad.net/openstack-manuals/+bug/1649902

Could anyone help to check this? Or any workaround about it such as 
change haproxy's listening ports or

change openstack services' listening port to be not 0.0.0.0?

Thanks a lot!

Regards

QingFeng Hao(Johnny)

__
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] [osc][openstackclient][zun] Collision on the keyword 'container'

[Hongbin Lu]

From: Steve Martinelli [mailto:s.martine...@gmail.com]
Sent: December-20-16 5:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [osc][openstackclient][zun] Collision on the 
keyword 'container'

On Tue, Dec 20, 2016 at 4:39 PM, Clay Gerrard 
> wrote:

On Tue, Dec 20, 2016 at 1:00 PM, Hongbin Lu 
> wrote:

$ openstack objectstore container  
$ openstack container container  
$ openstack secret container  

Thoughts?

This is the closest thing I can see that's somewhat reasonable - with the 
obvious exception of "container container " - which is pretty gross.

Here's the best list I could find of what's going on now:

http://docs.openstack.org/developer/python-openstackclient/command-list.html

The collision of top-level resource names is not new.  You see stuff like 
"volume create" & "server create" - but also "volume backup create" & "server 
backup create"- which is an obvious pattern to replicate for disambiguating top 
level name conflicts with similarly named (sub?)-resources between services - 
except apparently in an effort to keep things flat no one saw it coming with a 
name like "container".

But IMHO an object-store "container" is not a top level OpenStack resource, is 
it?  I would think users would be happy to dump stuff into the object store 
using "object create" - and reasonably expect to use "object container create" 
to create a container *for their objects*?  This isn't a generic OpenStack 
"container" - you can't use this generic "container" for anything except 
objects?  Oddly, this pattern is already in use with the pre-existing "object 
store account" command?!

This was my initial thought when discussing the problem with Hongbin last night.

We have three main "swift" resources in OSC -- "object store account", 
"container" and "object". I think renaming "container" to "object store 
container" is totally acceptable. The issue of deprecation comes into play, 
we'll need to deprecate it and give it at least one cycle. Luckily, the zun 
team isn't ready to publish a CLI just yet.

Alternatively, I don't mind "appcontainer".

[Hongbin Lu] I am going to propose ‘appcontainer’ to Zun team. It looks like a 
good alternative to me.

__
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] [osc][openstackclient][zun] Collision on the keyword 'container'

[Dean Troyer]

On Tue, Dec 20, 2016 at 3:39 PM, Clay Gerrard  wrote:
> http://docs.openstack.org/developer/python-openstackclient/command-list.html


> The collision of top-level resource names is not new.  You see stuff like
> "volume create" & "server create" - but also "volume backup create" &
> "server backup create"- which is an obvious pattern to replicate for
> disambiguating top level name conflicts with similarly named
> (sub?)-resources between services - except apparently in an effort to keep
> things flat no one saw it coming with a name like "container".

This is exactly how it should work.  I do want to make an additional
important but subtle point:  while it looks like those are namespaced
commands, we used 'server' not 'compute' because it is not a
compute-namespaced, but a server-specific resource.

> But IMHO an object-store "container" is not a top level OpenStack resource,
> is it?  I would think users would be happy to dump stuff into the object
> store using "object create" - and reasonably expect to use "object container
> create" to create a container *for their objects*?  This isn't a generic
> OpenStack "container" - you can't use this generic "container" for anything
> except objects?  Oddly, this pattern is already in use with the pre-existing
> "object store account" command?!

'object store account' is a hack that I still hate, but due to Swift's
unique ability to not use Keystone we had to do something.  'object
store container' would be consistent, 'object store object' is awful.

> Is it really already too late to apply some sane organization to the object
> store commands in the openstack-cli and make room in the command namespace
> for a top level OpenStack resource to manage a linux-containers' service?
> Because of backwards compatibility issues?

Notice that in the command list lined above the 'backup' resource has
been deprecated and renamed as 'volume backup'.  We could possibly
also do this with 'object' and 'container' from Swift, we will be
doing this with other resources (flavor -> server flavor comes to
mind).

Backward compatibility is very important to us though, so renaming
these resources takes a long time to complete.  Freeing up the
top-level bare container resource would be three cycles out at best.

dt

-- 

Dean Troyer
dtro...@gmail.com

__
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] [osc][openstackclient][zun] Collision on the keyword 'container'

[Steve Martinelli]

On Tue, Dec 20, 2016 at 4:39 PM, Clay Gerrard 
wrote:

>
> On Tue, Dec 20, 2016 at 1:00 PM, Hongbin Lu  wrote:
>
>>
>>
>> $ openstack objectstore container  
>>
>> $ openstack container container  
>>
>> $ openstack secret container  
>>
>>
>>
>> Thoughts?
>>
>
> This is the closest thing I can see that's somewhat reasonable - with the
> obvious exception of "container container " - which is pretty gross.
>
> Here's the best list I could find of what's going on now:
>
> http://docs.openstack.org/developer/python-openstackclient/command-list.
> html
>
> The collision of top-level resource names is not new.  You see stuff like
> "volume create" & "server create" - but also "volume backup create" &
> "server backup create"- which is an obvious pattern to replicate for
> disambiguating top level name conflicts with similarly named
> (sub?)-resources between services - except apparently in an effort to keep
> things flat no one saw it coming with a name like "container".
>
> But IMHO an object-store "container" is not a top level OpenStack
> resource, is it?  I would think users would be happy to dump stuff into the
> object store using "object create" - and reasonably expect to use "object
> container create" to create a container *for their objects*?  This isn't a
> generic OpenStack "container" - you can't use this generic "container" for
> anything except objects?  Oddly, this pattern is already in use with the
> pre-existing "object store account" command?!
>

This was my initial thought when discussing the problem with Hongbin last
night.

We have three main "swift" resources in OSC -- "object store account",
"container" and "object". I think renaming "container" to "object store
container" is totally acceptable. The issue of deprecation comes into play,
we'll need to deprecate it and give it at least one cycle. Luckily, the zun
team isn't ready to publish a CLI just yet.

Alternatively, I don't mind "appcontainer".
__
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] [osc][openstackclient][zun] Collision on the keyword 'container'

[Clay Gerrard]

On Tue, Dec 20, 2016 at 1:00 PM, Hongbin Lu  wrote:

>
>
> $ openstack objectstore container  
>
> $ openstack container container  
>
> $ openstack secret container  
>
>
>
> Thoughts?
>

This is the closest thing I can see that's somewhat reasonable - with the
obvious exception of "container container " - which is pretty gross.

Here's the best list I could find of what's going on now:

http://docs.openstack.org/developer/python-openstackclient/command-list.html

The collision of top-level resource names is not new.  You see stuff like
"volume create" & "server create" - but also "volume backup create" &
"server backup create"- which is an obvious pattern to replicate for
disambiguating top level name conflicts with similarly named
(sub?)-resources between services - except apparently in an effort to keep
things flat no one saw it coming with a name like "container".

But IMHO an object-store "container" is not a top level OpenStack resource,
is it?  I would think users would be happy to dump stuff into the object
store using "object create" - and reasonably expect to use "object
container create" to create a container *for their objects*?  This isn't a
generic OpenStack "container" - you can't use this generic "container" for
anything except objects?  Oddly, this pattern is already in use with the
pre-existing "object store account" command?!

Is it really already too late to apply some sane organization to the object
store commands in the openstack-cli and make room in the command namespace
for a top level OpenStack resource to manage a linux-containers' service?
Because of backwards compatibility issues?

-Clay
__
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] [osc][openstackclient][zun] Collision on the keyword 'container'

[Dean Troyer]

On Tue, Dec 20, 2016 at 3:00 PM, Hongbin Lu  wrote:
> In the long-term, I am going to propose to follow the style of AWS CLI, that
> is prefixing each command with a project name. For example:

We have been down this particular path multiple times, and this is not
how the OSC commands work.  Some plugins have already chosen to
'namespace' their commands, which I think is a bad idea, rather than
use specific descriptive names for their resources.  The vast majority
of plugins have managed to find specific descriptive names.

You should also please keep in mind that resources should be named
from the point of view of the OSC user, not an OpenStack developer.
The implementation of the service often has no meaning to CLI users so
you want to consider what they will be looking for first.

Honestly I think the word 'container' is already so overused, and has
at least two specific and distinct meanings in OpenStack to only add
confusion for yet another use at all.

dt

-- 

Dean Troyer
dtro...@gmail.com

__
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] December 27th - meeting cancelled

[Emilien Macchi]

We won't hold our weekly meeting on December 27th.
Next meeting is schedule on January 3rd.

Happy holidays everyone,

-- 
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] [osc][openstackclient][zun] Collision on the keyword 'container'

[Ian Cordasco]

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

Date: December 20, 2016 at 15:01:33
To: OpenStack Development Mailing List (not for usage questions)

Subject:  [openstack-dev] [osc][openstackclient][zun] Collision on the
keyword 'container'

> Hi OpenStackClients Team,
>
> I am from the Zun team, and my team encountered a name collision issue when 
> implementing
> a OSC plugin [1]. We wanted to use the keyword 'container' to represent a 
> linux container
> used to host a containerized application. In particular, the commands our 
> contributor
> wanted to implement was listed in the etherpad [2]. Unfortunately, this 
> keyword has
> already been taken in OSC, so we need to figure out a short-term walk round 
> and a long-term
> solution. Below are the short-term solution I can think of:
>
> * openstack appcontainer
> * openstack linuxcontainer
> * openstack zun container
> * openstack containerservice container
> * openstack containermgmt container
>
> In the long-term, I am going to propose to follow the style of AWS CLI, that 
> is prefixing
> each command with a project name. For example:
>
> $ openstack swift container
> $ openstack zun container
> $ openstack barbican container

I would be strongly opposed to using project names (which are already
confusing enough to users) in the openstackcli. That's just taking
good UX and throwing it out.

> Or
>
> $ openstack objectstore container

$ openstack object container

That could work, but forcing users to have to learn a new path to the
same functionality is incredibly bad.

> $ openstack container container

And this explains to me, rather well, why this would be a bad idea.
"container container" is terrible UX.

> $ openstack secret container

I don't think using service names is going to work better either,
especially provided that to retrofit that would be a *severe* breaking
change.

> Thoughts?
>
> [1] https://review.openstack.org/#/c/411786/
> [2] https://etherpad.openstack.org/p/zunclient_openstack-client-cli
>
> 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
>

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

[openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'

[Hongbin Lu]

Hi OpenStackClients Team,

I am from the Zun team, and my team encountered a name collision issue when 
implementing a OSC plugin [1]. We wanted to use the keyword 'container' to 
represent a linux container used to host a containerized application. In 
particular, the commands our contributor wanted to implement was listed in the 
etherpad [2]. Unfortunately, this keyword has already been taken in OSC, so we 
need to figure out a short-term walk round and a long-term solution. Below are 
the short-term solution I can think of:

* openstack appcontainer  
* openstack linuxcontainer  
* openstack zun container  
* openstack containerservice container  
* openstack containermgmt container  

In the long-term, I am going to propose to follow the style of AWS CLI, that is 
prefixing each command with a project name. For example:

$ openstack swift container  
$ openstack zun container  
$ openstack barbican container  

Or

$ openstack objectstore container  
$ openstack container container  
$ openstack secret container  

Thoughts?

[1] https://review.openstack.org/#/c/411786/
[2] https://etherpad.openstack.org/p/zunclient_openstack-client-cli

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-dev] [Neutron][networking-sfc] Next networking-sfc meeting on 1/5/2017

[Henry Fourie]

All,
   As many people will be away over the holiday season we will have the next 
networking-sfc meeting on 1/5/2017.
Best wishes for the season.

-Louis
__
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][nova]Accessing nullable, not set versioned object field

[Balázs Gibizer]

From: Dan Smith 
Sent: 16 December 2016 16:33
>> NotImplementedError: Cannot load 'nullable_string' in the base class
>>
>> Is this the correct behavior?
> 
> Yes, that's the expected behaviour.

Yes.

>> Then what is the expected behavior if the field is also defaulted to
>> None?
>>
>> fields = {
>> 'nullable_string': fields.StringField(nullable=True,
>> default=None),
>> }
>>
>> The actual behavior is still the same exception above. Is it the
>> correct behavior?
> 
> Yes. So, what the default=None does is describe the behaviour of the
> field when obj_set_defaults() is called. It does *not* describe what is
> returned if the field *value* is accessed before being populated.
>
> What you're looking for is the obj_attr_is_set() method:
>
> 
> if MyObject.obj_attr_is_set('nullable_string'):
> print my_obj.nullable_string

I think you meant s/MyObject/my_obj/ above. However, in modern times,
it's better to use:

 if 'nullable_string' in myobj

On a per-object basis, it may also be reasonable to define
obj_load_attr() to provide the default for a field if it's not set and
attempted to be loaded.

> In addition to the obj_attr_is_set() method, use the obj_set_defaults()
> method to manually set all fields that have a default=XXX value to XXX
> if those fields have not yet been manually set:

There's another wrinkle here. The default=XXX stuff was actually
introduced before we had obj_set_defaults(), and for a very different
reason. That reason was confusing and obscure, and mostly supportive of
the act of converting nova from dicts to objects. If you look in fields,
there is an obscure handling of default, where if you _set_ a field to
None that has a default and is not nullable, it will gain the default value.

It's confusing and I wish we had never done it, but.. it's part of the
contract now and I'd have to do a lot of digging to see if we can remove
it (probably can from Nova, but...).

Your use above is similar to this, so I just wanted to point it out in
case you came across it and it led you to thinking your original example
would work.

--Dan

Thank you for the answers. Following up on this. Is it considered a good
practice to instantiate an ovo but keeping some non-lazy loaded
fields unset?

I think the user of the ovo instance should be able to assume that the
fields declared in the ovo are accessible after the ovo is instantiated
without manually checking obj_attr_is_set().

I know that lazy-loaded fields are a special case because the user of 
the ovo instance will see that the lazy-loaded field is not set if calls 
obj_attr_is_set() but as soon as user code tries to access it the 
backend will fetch and return the value of the field.

However there are cases in nova where an instantiated ovo has some
not set, not lazy-loaded field. For example Service.availability_zone  is
not lazy-loaded [2] but it is allowed to be not set by [1].
Is it considered a bug? Should the code [1] set Serivce.availability_zone to 
None instead of keeping it not set?

Cheers,
gibi

[1] https://github.com/openstack/nova/blob/master/nova/objects/service.py#L197
[2] https://github.com/openstack/nova/blob/master/nova/objects/service.py#L221

__
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 mailing list
lists.openstack.org
This list for the developers of OpenStack to discuss development issues and 
roadmap. It is focused on the next release of OpenStack: you should post on 
this list if ...


__
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 Ryan Tidwell and Nate Johnston as service LTs

[Doug Wiegley]

Belated but enthusiastic +1

doug

> On Dec 15, 2016, at 4:58 PM, Armando M.  wrote:
> 
> Hi neutrinos,
> 
> I would like to propose Ryan and Nate as the go-to fellows for 
> service-related patches.
> 
> Both are core in their repos of focus, namely neutron-dynamic-routing and 
> neutron-fwaas, and have a good understanding of the service framework, the 
> agent framework and other bits and pieces. At this point, entrusting them 
> with the responsibility is almost a formality.
> 
> Cheers,
> Armando
> 
> [1] https://review.openstack.org/#/c/411536/ 
> __
> 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] [picasso] Picasso (FaaS) project release!

[Derek Schultz]

Hi all,

I’m very pleased to announce a new project, Picasso[1][2] - Functions as a
Service (FaaS).

The mission is to provide an API for running FaaS on OpenStack, abstracting
away the infrastructure layer while enabling simplicity, efficiency and
scalability for both developers and operators.

Picasso can be used to trigger functions from OpenStack services, such as
Telemetry (via HTTP callback) or Swift notifications. This means no long
running applications, as functions are only executed when called.

Picasso is comprised of two main components:

   - Picasso API
  - The Picasso API server uses Keystone authentication and
  authorization through its middleware.
   - IronFunctions
  - Picasso leverages the backend container engine provided by
  IronFunctions , an open-source
  Serverless/FaaS platform based on Docker.

*Resources*

   - Wiki
  - https://wiki.openstack.org/wiki/Picasso

  - Architecture
  - Picasso deployment architecture
  

  - Picasso/IronFunctions inter-component architecture
  



   - Examples
  - Triggering functions from Telemetry and Aodh
  


  - Application that queries Nova for a list of running servers
  


We’ve created some initial blueprints
 to show what the future roadmap
looks like for the project.

You can try out Picasso now on DevStack by following the quick start guide
here
.
Let us know what you think!

If you’re interested in contributing or just have any questions, please
join us on Slack at open-iron.slack.com.


[1] https://launchpad.net/picasso

[2] https://launchpad.net/python-picassoclient


Regards,

Derek Schultz
__
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] Does cinder use novaclient?

[Erlon Cruz]

Hi Jane, there is also some other uses, I know. In migration[1]  when
Cinder needs to migrate an attached volume, in some remotefs drivers [2],
when Cinder needs to take a snapshot of an attached volume. Both seems to
work fine with me.

[1] http://bit.ly/2i6m1Pb
[2] http://bit.ly/2i6m3GM


On Tue, Dec 20, 2016 at 4:44 AM, lij...@gohighsec.com 
wrote:

> Hi Cinder community,
>
> Does cinder use novaclient? What's the use of cinder/compute/nova.py?
>
> I find that there seems to have some problems when construct novaclient in
> the file  cinder/compute/nova.py,
>  but I think the file is not being used.
>
> Would you explain the use of this file or how does cinder communicate with
> nova?
>
> Looking forward to your comments. Thanks.
>
>
> BR,
>
> Jane
>
> --
>
>
> __
> 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][rdo][kolla] Recommending the RDO tag for the mailing list

[Steven Dake (stdake)]

Erno,

As David mentioned I had certainly not suggested moving all discussion from RDO 
list.  This is why I invited the Kolla community to join rdo-list if they so 
choose.  I think some heads up around “these are issues you may face” is 
warranted as David’s email [1] points out.  It is very difficult for everyone 
to be on all lists and pay attention to everything.

It is easy for OpenStack community members to set a [rdo] filter for low volume 
traffic like David’s heads up around RDO that lacked a tag for those that need 
that information.  Most of the kolla community who is deeply affected by this 
particular problem wasn’t aware of it and tracking it down in our mail clients 
is a little onerous without any tag at all.

Hope that clears things up ☺

Regards
-steve


-Original Message-
From: David Moreau Simard 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, December 20, 2016 at 7:02 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [all][rdo][kolla] Recommending the RDO tag for the 
mailing list

Hi Erno,

I believe Steven is referring to the recent post regarding issues with
CentOS 7.3 [1].
Arguably, that particular email was sent to openstack-dev,
openstack-operators as well as rdo-list.

I think it's okay to tag things relevant to RDO in openstack-dev but
that doesn't mean we're moving the discussions from rdo-list to
openstack-dev.

[1]: 
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108884.html

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Tue, Dec 20, 2016 at 5:19 AM, Erno Kuvaja  wrote:
> On Mon, Dec 19, 2016 at 2:21 PM, Steven Dake (stdake)  
wrote:
>> Folks,
>>
>>
>>
>> I am in favor of using a new tag called [rdo] such that RDO (or its
>> transitive dependencies) can be discussed and filtered by email clients 
as
>> it relates to development topics that affect the broader OpenStack
>> ecosystem.  As RDO is a community driven project which is very much 
related
>> to OpenStack, I think sharing a little bit of OpenStack list bandwidth 
isn’t
>> too much to ask.
>>
>>
>>
>> Further I’d invite the broader Kolla team to subscribe to the rdo-list,
>> which is a much more comprehensive coverage of RDO (both users and devs 
with
>> significant traffic) and filter rdo-list as you prefer:
>>
>>
>>
>> https://www.redhat.com/mailman/listinfo/rdo-list
>>
>>
>>
>> Thanks!
>>
>> -steve
>>
>>
>>
>>
>> 
__
>> 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
>>
>
> Hi Steven,
>
> I'm not sure I understand the intention fully here. openstack-dev is
> super gluttered already as it is, can you give an example what would
> be appropriate discussion in openstack-dev [rdo] rather than having
> that discussion on rdo-project mailing list?
>
> My initial thought is that I'd very much would not like to open the
> openstack-dev to any 3rd party projects (yes I'm fully aware that rdo
> is very much related to OpenStack and my employer, it does not make it
> any less 3rd party to OS development) to discuss their matters. So my
> initial reaction would be "Please no".
>
> - Erno 'jokke' Kuvaja
>
> __
> 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] OpenStack Dev Digest 10- 16

[Matt Riedemann]

On 12/19/2016 10:54 PM, Kendall Nelson wrote:


Upgrade readiness check in Nova [11]

  *

New, separate service


Clarification here, it's not a new separate service, it's a new CLI 
(nova-status). Right now we're developing it within the nova repo, just 
like nova-manage.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] Proposing Steve Martinelli for project-team-guide core

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2016-12-20 16:18:15 +0100:
> Hi everyone,
> 
> As you probably know, the OpenStack Project Team Guide is a piece of
> documentation geared towards project teams, to help them navigate the
> troubled and complex waters of being an official OpenStack team:
> 
> http://docs.openstack.org/project-team-guide/
> 
> Steve Martinelli has been doing a great job of proposing and reviewing
> changes proposed to the guide, and we can always use some help there, so
> I'd like to propose that he joins the core team.
> 

+1, Steve has been helpful with reviews lately.

Doug

__
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][fwaas] Weekly FWaaS meetings cancelled next 2 weeks.

[Sridar Kandaswamy (skandasw)]

Hi All:

We will skip the weekly FWaaS meetings on Dec 27 and Jan 3 with the Holiday 
Season. We will start back on Jan 10 as usual.

Happy Holidays to all.

Thanks

Sridar
__
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] Where will Neutron go in future?

[Sridar Kandaswamy (skandasw)]

Hi Zhi:

With the L3 implementation, FWaaS acts on traffic that is seen by the router 
(we have some issues with DVR) so it is really constrained to N - S. SG will of 
course see all traffic. Once we have the FWaaS L2 implementation - it opens up 
the possibilities to be applied on a VM port and hence can see all traffic.

Thanks

Sridar

From: zhi >
Reply-To: OpenStack List 
>
Date: Monday, December 19, 2016 at 10:43 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] Where will Neutron go in future?

Hi, Srider.

Thanks for your reply. I still have a question about SG and FWaaS. VM's 
east-west traffic belongs to FWaaS or SG? What about VM's north-south traffic?

I think that VM's east-west traffic belongs to SG and the north-south traffic 
belongs to FWaaS, isn't it? :)


Thanks
Zhi Chang

2016-12-20 1:45 GMT+08:00 Sridar Kandaswamy (skandasw) 
>:
Hi Zhi:

FWaaS has been seen more as an edge (on L3 ports) use case as opposed to SG 
which is on a VM port. Also, as u can see there are differences in the 
attributes on the Rule specification at the most basic level. At this point, we 
are working thru the implementation of FWaaS on L2 ports so that makes ur 
question more relevant. At least one school of thought that we have been 
working with is that the FWaaS API can be more open and continue to evolve to 
support for instance L4-L7 use cases amongst others, but the SG API will 
continue to stay a simpler model (some have also pointed the need for SG to be 
aligned with AWS).

This is still in evolution and we would welcome participation, if u can - pls 
do drop in to our weekly team meeting [1] and we can discuss further.

Thanks

Sridar
[1] http://eavesdrop.openstack.org/#Firewall_as_a_Service_(FWaaS)_Team_Meeting


From: zhi >
Reply-To: OpenStack List 
>
Date: Sunday, December 18, 2016 at 7:36 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [neutron] Where will Neutron go in future?

Hi, Nate, thanks for your reply.

May I ask a little stupid question? What's the difference between fwaas and 
security group? In my opinion, fwaas and security group are both using linux 
iptables now. So, what's the differences between them?

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

Re: [openstack-dev] [api][zun] Effective URL for resource actions

[Ed Leafe]

On Dec 19, 2016, at 9:34 PM, Qiming Teng  wrote:
> 
> Then we should stop identifying actions based on URL. :)
> The following URL for representing a 'pause' action is really ugly:
> 
>   /containers//pause
> 
> First of all, 'pause' is a verb. I cannot persuade myself that doing a
> POST to a verb is a ReST call. And I cannot do a 'GET', 'DELETE' not
> due to I'm not an admin ... rather, it is because I cannot explain what
> it means by 'deleting a pause'.  

Like the rest of the options, this is not ideal, but it is worth consideration:

POST /containers/ID?action=pause

with a body that is either empty or contains some other non-related information.

You don't have the problem of a single URL for multiple actions, and while it's 
not 100% RESTish, it's not illegal either. 


-- 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] [storlets] End of year IRC team meetings

[eran]

Unless there is some objection we will skip next week's meeting and  
meet again on Tuesday January 3rd in the usual place and time.


Thanks,
Eran



__
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] Proposing Steve Martinelli for project-team-guide core

[Thierry Carrez]

Hi everyone,

As you probably know, the OpenStack Project Team Guide is a piece of
documentation geared towards project teams, to help them navigate the
troubled and complex waters of being an official OpenStack team:

http://docs.openstack.org/project-team-guide/

Steve Martinelli has been doing a great job of proposing and reviewing
changes proposed to the guide, and we can always use some help there, so
I'd like to propose that he joins the core team.

-- 
Thierry Carrez (ttx)

__
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] [puppet] Dec 27, Jan 3 meetings canceled

[Alex Schultz]

Hey,

Given that the next few meetings will be right after some holidays,
we're going to go ahead and cancel the meetings on Dec 27 and Jan 3.
Our next meeting will be on Jan 10.  See you then.

Thanks,
-Alex

__
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] [nova] [placement] Which service is using port 8778?

[Sylvain Bauza]

Le 20/12/2016 14:30, Jay Pipes a écrit :
> On 12/20/2016 08:03 AM, Sean Dague wrote:
>> On 12/20/2016 07:53 AM, Sylvain Bauza wrote:
>>> Le 20/12/2016 10:26, Sylvain Bauza a écrit :
 Le 20/12/2016 10:20, Chris Dent a écrit :
> On Tue, 20 Dec 2016, Sylvain Bauza wrote:
>
>> Before moving forward and picking yet another port that could trample
>> another service, I'd rather prefer first that Senlin jobs would
>> temporarely disable the placement-* services so that the gate
>> would be
>> happy, while in the same time we try to identify a free port
>> number that
>> the placement API can safely bind.
>
> Another option here may be to not have the placement api bind to two
> ports. The current set up binds 8778 with the API at /, but what's
> registered in the service catalog is port 80 with the API at
> /placement.
>
> So perhaps only use the http://1.2.3.4/placement and disable the
> virtualhost that listens on 8778?
>
> I'd experiment with this myself but I'm going to be away from a
> compute all day. If people think it is a good idea but nobody has a
> chance to do it today I'll look into it tomorrow.
>

 Oh good catch. Since we register the service catalog with port 80, then
 there is no reason to consume an application port.
 Chris, don't worry, I'll play with that today.

>>>
>>> So, after some investigation, I totally understand why we're using
>>> virtualhosts for running the WSGI apps corresponding to each service,
>>> since we want to keep the service catalog entries unchanged if the
>>> operator wants to move from eventlet to mod_wsgi.
>>>
>>> Given that devstack was deploying a service catalog entry pointing to
>>> HTTP port, should we just assume to drop the use of port 8778 ?
>>> I'm a bit afraid of any possible impact it could have for operators
>>> using the placement API with the virtualhost support which also provide
>>> a WSGI daemon mode compared to the embedded mode that is executing calls
>>> to :80/placement...
>>>
>>> Thoughts ? I mean, I can do the cut and drop that, but that will
>>> certainly have impact for other deployers that were reproducing the
>>> devstack install, like for TripleO :
>>> https://review.openstack.org/#/c/406300/13/manifests/wsgi/apache_placement.pp
>>>
>>
>> Yes, we should stop with the magic ports. Part of the reason of
>> switching over to apache was to alleviate all of that.
> 
> +100
> 
> -jay
> 

Change is up, comments welcome : https://review.openstack.org/#/c/413118/

-Sylvain

> __
> 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] A question on the endpoint of Heat

[Zane Bitter]

On 20/12/16 02:29, zengchen wrote:

Hi, Heat stackers:
May I ask a question about the endpoint of Heat. I see the endpoints
of Heat registered to Keystone look like this.
'http://10.229.45.150:8004/v1/$(project_id)s' . My question is that why
use '$' instead of '%' as the replacement symbol.
Is there some kind of rule?


Keystone supports either syntax. IIRC this one is slightly preferred. 
It's really not important.


- ZB


__
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][rdo][kolla] Recommending the RDO tag for the mailing list

[David Moreau Simard]

Hi Erno,

I believe Steven is referring to the recent post regarding issues with
CentOS 7.3 [1].
Arguably, that particular email was sent to openstack-dev,
openstack-operators as well as rdo-list.

I think it's okay to tag things relevant to RDO in openstack-dev but
that doesn't mean we're moving the discussions from rdo-list to
openstack-dev.

[1]: 
http://lists.openstack.org/pipermail/openstack-dev/2016-December/108884.html

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Tue, Dec 20, 2016 at 5:19 AM, Erno Kuvaja  wrote:
> On Mon, Dec 19, 2016 at 2:21 PM, Steven Dake (stdake)  
> wrote:
>> Folks,
>>
>>
>>
>> I am in favor of using a new tag called [rdo] such that RDO (or its
>> transitive dependencies) can be discussed and filtered by email clients as
>> it relates to development topics that affect the broader OpenStack
>> ecosystem.  As RDO is a community driven project which is very much related
>> to OpenStack, I think sharing a little bit of OpenStack list bandwidth isn’t
>> too much to ask.
>>
>>
>>
>> Further I’d invite the broader Kolla team to subscribe to the rdo-list,
>> which is a much more comprehensive coverage of RDO (both users and devs with
>> significant traffic) and filter rdo-list as you prefer:
>>
>>
>>
>> https://www.redhat.com/mailman/listinfo/rdo-list
>>
>>
>>
>> Thanks!
>>
>> -steve
>>
>>
>>
>>
>> __
>> 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
>>
>
> Hi Steven,
>
> I'm not sure I understand the intention fully here. openstack-dev is
> super gluttered already as it is, can you give an example what would
> be appropriate discussion in openstack-dev [rdo] rather than having
> that discussion on rdo-project mailing list?
>
> My initial thought is that I'd very much would not like to open the
> openstack-dev to any 3rd party projects (yes I'm fully aware that rdo
> is very much related to OpenStack and my employer, it does not make it
> any less 3rd party to OS development) to discuss their matters. So my
> initial reaction would be "Please no".
>
> - Erno 'jokke' Kuvaja
>
> __
> 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] [nova] [placement] Which service is using port 8778?

[Jay Pipes]

On 12/20/2016 08:03 AM, Sean Dague wrote:

On 12/20/2016 07:53 AM, Sylvain Bauza wrote:

Le 20/12/2016 10:26, Sylvain Bauza a écrit :

Le 20/12/2016 10:20, Chris Dent a écrit :

On Tue, 20 Dec 2016, Sylvain Bauza wrote:


Before moving forward and picking yet another port that could trample
another service, I'd rather prefer first that Senlin jobs would
temporarely disable the placement-* services so that the gate would be
happy, while in the same time we try to identify a free port number that
the placement API can safely bind.


Another option here may be to not have the placement api bind to two
ports. The current set up binds 8778 with the API at /, but what's
registered in the service catalog is port 80 with the API at
/placement.

So perhaps only use the http://1.2.3.4/placement and disable the
virtualhost that listens on 8778?

I'd experiment with this myself but I'm going to be away from a
compute all day. If people think it is a good idea but nobody has a
chance to do it today I'll look into it tomorrow.



Oh good catch. Since we register the service catalog with port 80, then
there is no reason to consume an application port.
Chris, don't worry, I'll play with that today.



So, after some investigation, I totally understand why we're using
virtualhosts for running the WSGI apps corresponding to each service,
since we want to keep the service catalog entries unchanged if the
operator wants to move from eventlet to mod_wsgi.

Given that devstack was deploying a service catalog entry pointing to
HTTP port, should we just assume to drop the use of port 8778 ?
I'm a bit afraid of any possible impact it could have for operators
using the placement API with the virtualhost support which also provide
a WSGI daemon mode compared to the embedded mode that is executing calls
to :80/placement...

Thoughts ? I mean, I can do the cut and drop that, but that will
certainly have impact for other deployers that were reproducing the
devstack install, like for TripleO :
https://review.openstack.org/#/c/406300/13/manifests/wsgi/apache_placement.pp


Yes, we should stop with the magic ports. Part of the reason of
switching over to apache was to alleviate all of that.


+100

-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

Re: [openstack-dev] [nova] Help: How to make Nova official support AArch64?

[Jay Pipes]

On 12/20/2016 12:45 AM, Kevin Zhao wrote:

Hello Nova,
  Greetings from ARM and Linaro :D
  This is Kevin Zhao from ARM. Nowadays Linaro and other
contributors have submitted some patches to Nova community , fixing bugs
for Nova running on AArch64. Now we can successfully running a OpenStack
cluster on AArch64 and pass much of the tempest test. The
virtuallization hypervisor is based on Libvirt+KVM.

  Actually in Barcelona Keynote(interoperability Challenge
,
at 10:30') one of the OpenStack interoperability cloud is from Linaro,
all based on AArch64 machines.
   I see there is a Nova support matrix
. So my
question is :
*   what do we need to do, so that Nova can official support AArch64
architecture? for example add AArch64 to this support matrix?*

   Sincerely thanks for your help. Any of your response will be
really appreciated.


Hi Kevin,

I think the first thing you would need to do is set up some sort of 
continuous integration system that can be notified by upstream patch 
changes/pushes and report results of Tempest testing against a build of 
OpenStack on AArch64 machines.


You can read about setting up third-party CI for this here:

http://docs.openstack.org/infra/system-config/

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

Re: [openstack-dev] [tripleo] [ci]

[Wesley Hayutin]

On Fri, Dec 16, 2016 at 9:12 AM, Flavio Percoco  wrote:

> On 14/12/16 21:44 -0500, Emilien Macchi wrote:
>
>> On Wed, Dec 14, 2016 at 7:22 PM, Wesley Hayutin 
>> wrote:
>>
>>>
>>>
>>> On Fri, Dec 2, 2016 at 12:04 PM, Wesley Hayutin 
>>> wrote:
>>>

 Greetings,

 I wanted to send a status update on the quickstart based containerized
 compute ci.

 The work is here:
 https://review.openstack.org/#/c/393348/

 I had two passes on the morning of Nov 30 in a row, then later that day
 the deployment started to fail due the compute node loosing it's
 networking
 and became unpingable.   After poking around and talking to a few folks
 its
 likely that we're hitting at least one of two possible bugs [1-2]

 I am on pto next week but will periodically check in and can easily
 retest
 if these resolve.

 Thank you!

 [1] https://bugs.launchpad.net/ironic/+bug/1646477
 [2] https://bugs.launchpad.net/tripleo/+bug/1646897 just filed



>>> Just a quick update,
>>> The container CI is successfully deploying the overcloud with the
>>> containerized compute node.
>>>
>>
>> Do we have the job in place in tripleo CI? I might have missed the
>> info, but I don't see it yet.
>> Thanks!
>>
>> Once we have it, we might want to run it for every patch in THT that
>> touch docker/* files.
>>
>
> +1 for this, although I'm starting to think that we should just run it.
> Last
> time it broke, it was caused by a patch that didn't touch files under
> `docker`
>
> Flavio
>
>
>
>> I need to update the instructions a bit so you may want to hold off on
>>> trying it out until you see an update.
>>>
>>> The heat ping test is failing, but this is progress and we're back on
>>> track
>>> :)
>>> The environment is running and logs are available, ping me personally if
>>> you
>>> need access.
>>>
>>> Thanks..
>>>
>>>
>>> Ping test failure:
>>>
>>> | stack_name| pingtest_stack
>>> | stack_owner   | None
>>> | stack_status  | CREATE_FAILED
>>> | stack_status_reason   | Resource CREATE failed: ResourceInError:
>>> |   | resources.server1: Went to status ERROR due to
>>> |   | "Message: No valid host was found. There are
>>> not
>>> enough
>>> |   | hosts available., Code: 500"
>>> | stack_user_project_id | e5fcd903a5004d59b8d3ad22aba0ae27
>>>
>>>
>>
>>
>> --
>> Emilien Macchi
>>
>> 
>> __
>> 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
>



Greetings,

After pulling in a few unmerged changes via devmode tripleo-quickstart the
container CI is passing the deployment and ping test.

Updated docs at

https://review.openstack.org/#/c/400983/17/roles/overcloud-prep-containers/README.md

The two patch sets are brought into the build with

export OPT_ADDITIONAL_PARAMETERS=" -e
overcloud_templates_refspec=refs/changes/80/395880/12 -e
overcloud_tripleo_common_refspec=refs/changes/08/411908/2"

I'll be working w/ the tripleo-quickstart core to try and get a merge on
the three patches required.

Thanks
__
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] [nova] [placement] Which service is using port 8778?

[Sean Dague]

On 12/20/2016 07:53 AM, Sylvain Bauza wrote:
> 
> 
> Le 20/12/2016 10:26, Sylvain Bauza a écrit :
>>
>>
>> Le 20/12/2016 10:20, Chris Dent a écrit :
>>> On Tue, 20 Dec 2016, Sylvain Bauza wrote:
>>>
 Before moving forward and picking yet another port that could trample
 another service, I'd rather prefer first that Senlin jobs would
 temporarely disable the placement-* services so that the gate would be
 happy, while in the same time we try to identify a free port number that
 the placement API can safely bind.
>>>
>>> Another option here may be to not have the placement api bind to two
>>> ports. The current set up binds 8778 with the API at /, but what's
>>> registered in the service catalog is port 80 with the API at
>>> /placement.
>>>
>>> So perhaps only use the http://1.2.3.4/placement and disable the
>>> virtualhost that listens on 8778?
>>>
>>> I'd experiment with this myself but I'm going to be away from a
>>> compute all day. If people think it is a good idea but nobody has a
>>> chance to do it today I'll look into it tomorrow.
>>>
>>
>> Oh good catch. Since we register the service catalog with port 80, then
>> there is no reason to consume an application port.
>> Chris, don't worry, I'll play with that today.
>>
> 
> So, after some investigation, I totally understand why we're using
> virtualhosts for running the WSGI apps corresponding to each service,
> since we want to keep the service catalog entries unchanged if the
> operator wants to move from eventlet to mod_wsgi.
> 
> Given that devstack was deploying a service catalog entry pointing to
> HTTP port, should we just assume to drop the use of port 8778 ?
> I'm a bit afraid of any possible impact it could have for operators
> using the placement API with the virtualhost support which also provide
> a WSGI daemon mode compared to the embedded mode that is executing calls
> to :80/placement...
> 
> Thoughts ? I mean, I can do the cut and drop that, but that will
> certainly have impact for other deployers that were reproducing the
> devstack install, like for TripleO :
> https://review.openstack.org/#/c/406300/13/manifests/wsgi/apache_placement.pp

Yes, we should stop with the magic ports. Part of the reason of
switching over to apache was to alleviate all of that.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [nova] [placement] Which service is using port 8778?

[Sylvain Bauza]

Le 20/12/2016 10:26, Sylvain Bauza a écrit :
> 
> 
> Le 20/12/2016 10:20, Chris Dent a écrit :
>> On Tue, 20 Dec 2016, Sylvain Bauza wrote:
>>
>>> Before moving forward and picking yet another port that could trample
>>> another service, I'd rather prefer first that Senlin jobs would
>>> temporarely disable the placement-* services so that the gate would be
>>> happy, while in the same time we try to identify a free port number that
>>> the placement API can safely bind.
>>
>> Another option here may be to not have the placement api bind to two
>> ports. The current set up binds 8778 with the API at /, but what's
>> registered in the service catalog is port 80 with the API at
>> /placement.
>>
>> So perhaps only use the http://1.2.3.4/placement and disable the
>> virtualhost that listens on 8778?
>>
>> I'd experiment with this myself but I'm going to be away from a
>> compute all day. If people think it is a good idea but nobody has a
>> chance to do it today I'll look into it tomorrow.
>>
> 
> Oh good catch. Since we register the service catalog with port 80, then
> there is no reason to consume an application port.
> Chris, don't worry, I'll play with that today.
> 

So, after some investigation, I totally understand why we're using
virtualhosts for running the WSGI apps corresponding to each service,
since we want to keep the service catalog entries unchanged if the
operator wants to move from eventlet to mod_wsgi.

Given that devstack was deploying a service catalog entry pointing to
HTTP port, should we just assume to drop the use of port 8778 ?
I'm a bit afraid of any possible impact it could have for operators
using the placement API with the virtualhost support which also provide
a WSGI daemon mode compared to the embedded mode that is executing calls
to :80/placement...

Thoughts ? I mean, I can do the cut and drop that, but that will
certainly have impact for other deployers that were reproducing the
devstack install, like for TripleO :
https://review.openstack.org/#/c/406300/13/manifests/wsgi/apache_placement.pp

-Sylvain

> -Sylvain
> 
> 
>>
>>
>> __
>> 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] [networking-sfc] Intermittent database transaction issues, affecting the tempest gate

[Bernard Cafarelli]

Hi everyone,

we have an open bug (thanks Igor for the report) on DB transaction issues:
https://bugs.launchpad.net/networking-sfc/+bug/1630503

The thing is, I am seeing  quite a few tempest gate failures that
follow the same pattern: at some point in the test suite, the service
gets warnings/errors from the DB layer (reentrant call, closed
transaction, nested rollback, …), and all following tests fail.

This affects both master and stable/newton branches (not many changes
for now in the DB parts between these branches)

Some examples:
* https://review.openstack.org/#/c/400396/ failed with console log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/console.html#_2016-12-16_12_44_47_564544
and service log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_12_44_32_301
* https://review.openstack.org/#/c/405391/ failed,
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/console.html.gz#_2016-12-16_13_05_17_384323
and 
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_13_04_11_840
* another on master branch: https://review.openstack.org/#/c/411194/
with 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/console.html.gz#_2016-12-15_22_36_15_216260
and 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-15_22_35_53_310

I took a look at the errors, but only found old-and-apparently-fixed
pymysql bugs, and suggestions like:
* 
http://docs.sqlalchemy.org/en/latest/faq/sessions.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush-or-similar
*  https://review.openstack.org/#/c/230481/
Not really my forte, so if someone could take a look at these logs and
fix the problem, it would be great! Especially with the upcoming
multinode tempest gate

Thanks,
-- 
Bernard Cafarelli

__
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][rdo][kolla] Recommending the RDO tag for the mailing list

[Erno Kuvaja]

On Mon, Dec 19, 2016 at 2:21 PM, Steven Dake (stdake)  wrote:
> Folks,
>
>
>
> I am in favor of using a new tag called [rdo] such that RDO (or its
> transitive dependencies) can be discussed and filtered by email clients as
> it relates to development topics that affect the broader OpenStack
> ecosystem.  As RDO is a community driven project which is very much related
> to OpenStack, I think sharing a little bit of OpenStack list bandwidth isn’t
> too much to ask.
>
>
>
> Further I’d invite the broader Kolla team to subscribe to the rdo-list,
> which is a much more comprehensive coverage of RDO (both users and devs with
> significant traffic) and filter rdo-list as you prefer:
>
>
>
> https://www.redhat.com/mailman/listinfo/rdo-list
>
>
>
> Thanks!
>
> -steve
>
>
>
>
> __
> 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
>

Hi Steven,

I'm not sure I understand the intention fully here. openstack-dev is
super gluttered already as it is, can you give an example what would
be appropriate discussion in openstack-dev [rdo] rather than having
that discussion on rdo-project mailing list?

My initial thought is that I'd very much would not like to open the
openstack-dev to any 3rd party projects (yes I'm fully aware that rdo
is very much related to OpenStack and my employer, it does not make it
any less 3rd party to OS development) to discuss their matters. So my
initial reaction would be "Please no".

- Erno 'jokke' Kuvaja

__
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] [nova] [placement] Which service is using port 8778?

[Sylvain Bauza]

Le 20/12/2016 10:20, Chris Dent a écrit :
> On Tue, 20 Dec 2016, Sylvain Bauza wrote:
> 
>> Before moving forward and picking yet another port that could trample
>> another service, I'd rather prefer first that Senlin jobs would
>> temporarely disable the placement-* services so that the gate would be
>> happy, while in the same time we try to identify a free port number that
>> the placement API can safely bind.
> 
> Another option here may be to not have the placement api bind to two
> ports. The current set up binds 8778 with the API at /, but what's
> registered in the service catalog is port 80 with the API at
> /placement.
> 
> So perhaps only use the http://1.2.3.4/placement and disable the
> virtualhost that listens on 8778?
> 
> I'd experiment with this myself but I'm going to be away from a
> compute all day. If people think it is a good idea but nobody has a
> chance to do it today I'll look into it tomorrow.
> 

Oh good catch. Since we register the service catalog with port 80, then
there is no reason to consume an application port.
Chris, don't worry, I'll play with that today.

-Sylvain


> 
> 
> __
> 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] [nova] [placement] Which service is using port 8778?

[Chris Dent]

On Tue, 20 Dec 2016, Sylvain Bauza wrote:


Before moving forward and picking yet another port that could trample
another service, I'd rather prefer first that Senlin jobs would
temporarely disable the placement-* services so that the gate would be
happy, while in the same time we try to identify a free port number that
the placement API can safely bind.


Another option here may be to not have the placement api bind to two
ports. The current set up binds 8778 with the API at /, but what's
registered in the service catalog is port 80 with the API at
/placement.

So perhaps only use the http://1.2.3.4/placement and disable the
virtualhost that listens on 8778?

I'd experiment with this myself but I'm going to be away from a
compute all day. If people think it is a good idea but nobody has a
chance to do it today I'll look into it tomorrow.

--
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] [nova] [placement] Which service is using port 8778?

[Sylvain Bauza]

Le 20/12/2016 09:29, Sylvain Bauza a écrit :
> 
> 
> Le 20/12/2016 09:12, Sylvain Bauza a écrit :
>>
>>
>> Le 20/12/2016 07:31, Ghanshyam Mann a écrit :
>>> Changing placement API port to 8780 [1], hope this is not being used by any 
>>> services.
>>>
>>> But I am not sure how to check all used port currently as wiki does not 
>>> seems to have all.
>>>
>>> .. [1] https://review.openstack.org/#/c/412770/ 
>>>
>>
>>
>> FWIW, we recently merged a devstack-gate change yesterday that now runs
>> the placement service by default, which is why it's breaking Senlin gate
>> now.
>> https://review.openstack.org/#/c/409871/
>>
>> We also have a change up for modifying stackrc to start kicking the
>> placement service by default too https://review.openstack.org/#/c/412537/
>>
>> Before moving forward and picking yet another port that could trample
>> another service, I'd rather prefer first that Senlin jobs would
>> temporarely disable the placement-* services so that the gate would be
>> happy, while in the same time we try to identify a free port number that
>> the placement API can safely bind.
>>
> 
> Yeah confirmed.
> 
> A working job doesn't show the placement-api service [a] to be run while
> a failing one does [b]
> 
> I'm just writing a change against [c] to temporarely disable the
> placement-api service. That will need to be reverted very soon since we
> want to have the placement API mandatory for Ocata anyway but that will
> help your gate while we identify a correct port number.
> 
> 
> [a]
> http://logs.openstack.org/31/412331/1/check/gate-senlin-dsvm-tempest-api/b1dfbf9/logs/localrc.txt.gz
> 
> [b]
> http://logs.openstack.org/43/412843/1/check/gate-senlin-dsvm-tempest-api/cff7c55/logs/localrc.txt.gz
> 
> [c]
> https://github.com/openstack-infra/project-config/blob/d86338e968b84d119a59a6873b1d9c7ea17c37a8/jenkins/jobs/senlin.yaml
> 


Okay, so surprinsingly, I just noticed that Senlin was not correctly
declaring the services to start with their d-g jobs.
Since it was using ENABLED_SERVICES and not OVERRIDE_ENABLED_SERVICES,
it was defaulting the services to start by the default d-g ones,
including then Nova and now the placement-api.

https://review.openstack.org/#/c/412915/ should fix that.
https://review.openstack.org/#/c/412930/ is a canary patch for showing
whether the gate is fixed by the above change.


-Sylvain

> 
> -Sylvain
> 
>> -Sylvain
>>
>>
>>> -gmann
>>>
>>>
 -Original Message-
 From: Ghanshyam Mann [mailto:ghanshyam.m...@nectechnologies.in]
 Sent: 20 December 2016 15:17
 To: OpenStack Development Mailing List (not for usage questions)
 
 Subject: Re: [openstack-dev] Which service is using port 8778?

 Yes, it seems placement API using it [1]

> 1. Recent changes to tempest is breaking our plugin. This is being
>fixed.
 Tempest patch should fix issue but port issue blocking that[2]

 For port think, I think we can change the placement API port to something
 else. I will propose and we can get unused port there.
 But OpenStack port used by services are maintained here[3], may be it will
 be good for each project to add their port in this list.

 .. [1] - https://github.com/openstack-
 dev/devstack/blob/master/lib/placement#L50
 ..[2] https://review.openstack.org/#/c/412658/
 ..[3] http://docs.openstack.org/newton/config-reference/firewalls-default-
 ports.html

 -gmann


> -Original Message-
> From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com]
> Sent: 20 December 2016 14:45
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] Which service is using port 8778?
>
> Hi, all,
>
> Starting yesterday, Senlin's gate jobs kept failing due to two reasons:
>
> 1. Recent changes to tempest is breaking our plugin. This is being
>fixed.
>
> 2. Senlin API cannot bind it to port 8778 now.
>
> So, we are wondering which service else is using port 8778?
>
> Thanks in advance for any hints.
>
> Regards,
>   Qiming
>
>
>
 __
> 
> 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: 

Re: [openstack-dev] [nova] [placement] Which service is using port 8778?

[Ghanshyam Mann]

Yea, that is also options to disable the placement api in senlin setup.

But for long term we should have different ports for each service and should be 
maintained here
- 
http://docs.openstack.org/newton/config-reference/firewalls-default-ports.html 

But I have no clue how to confirm the free port as lots of service running for 
OpenStack. 1 idea is to get default port entry
Somewhere during adding project to governance or somewhere where it can  be 
maintained actively. 

-gmann


> -Original Message-
> From: Sylvain Bauza [mailto:sba...@redhat.com]
> Sent: 20 December 2016 17:30
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [nova] [placement] Which service is using port
> 8778?
> 
> 
> 
> Le 20/12/2016 09:12, Sylvain Bauza a écrit :
> >
> >
> > Le 20/12/2016 07:31, Ghanshyam Mann a écrit :
> >> Changing placement API port to 8780 [1], hope this is not being used by
> any services.
> >>
> >> But I am not sure how to check all used port currently as wiki does not
> seems to have all.
> >>
> >> .. [1] https://review.openstack.org/#/c/412770/
> >>
> >
> >
> > FWIW, we recently merged a devstack-gate change yesterday that now
> > runs the placement service by default, which is why it's breaking
> > Senlin gate now.
> > https://review.openstack.org/#/c/409871/
> >
> > We also have a change up for modifying stackrc to start kicking the
> > placement service by default too
> > https://review.openstack.org/#/c/412537/
> >
> > Before moving forward and picking yet another port that could trample
> > another service, I'd rather prefer first that Senlin jobs would
> > temporarely disable the placement-* services so that the gate would be
> > happy, while in the same time we try to identify a free port number
> > that the placement API can safely bind.
> >
> 
> Yeah confirmed.
> 
> A working job doesn't show the placement-api service [a] to be run while a
> failing one does [b]
> 
> I'm just writing a change against [c] to temporarely disable the placement-api
> service. That will need to be reverted very soon since we want to have the
> placement API mandatory for Ocata anyway but that will help your gate while
> we identify a correct port number.
> 
> 
> [a]
> http://logs.openstack.org/31/412331/1/check/gate-senlin-dsvm-tempest-
> api/b1dfbf9/logs/localrc.txt.gz
> 
> [b]
> http://logs.openstack.org/43/412843/1/check/gate-senlin-dsvm-tempest-
> api/cff7c55/logs/localrc.txt.gz
> 
> [c]
> https://github.com/openstack-infra/project-
> config/blob/d86338e968b84d119a59a6873b1d9c7ea17c37a8/jenkins/jobs/se
> nlin.yaml
> 
> 
> -Sylvain
> 
> > -Sylvain
> >
> >
> >> -gmann
> >>
> >>
> >>> -Original Message-
> >>> From: Ghanshyam Mann [mailto:ghanshyam.m...@nectechnologies.in]
> >>> Sent: 20 December 2016 15:17
> >>> To: OpenStack Development Mailing List (not for usage questions)
> >>> 
> >>> Subject: Re: [openstack-dev] Which service is using port 8778?
> >>>
> >>> Yes, it seems placement API using it [1]
> >>>
>  1. Recent changes to tempest is breaking our plugin. This is being
> fixed.
> >>> Tempest patch should fix issue but port issue blocking that[2]
> >>>
> >>> For port think, I think we can change the placement API port to
> >>> something else. I will propose and we can get unused port there.
> >>> But OpenStack port used by services are maintained here[3], may be
> >>> it will be good for each project to add their port in this list.
> >>>
> >>> .. [1] - https://github.com/openstack-
> >>> dev/devstack/blob/master/lib/placement#L50
> >>> ..[2] https://review.openstack.org/#/c/412658/
> >>> ..[3]
> >>> http://docs.openstack.org/newton/config-reference/firewalls-default-
> >>> ports.html
> >>>
> >>> -gmann
> >>>
> >>>
>  -Original Message-
>  From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com]
>  Sent: 20 December 2016 14:45
>  To: openstack-dev@lists.openstack.org
>  Subject: [openstack-dev] Which service is using port 8778?
> 
>  Hi, all,
> 
>  Starting yesterday, Senlin's gate jobs kept failing due to two reasons:
> 
>  1. Recent changes to tempest is breaking our plugin. This is being
> fixed.
> 
>  2. Senlin API cannot bind it to port 8778 now.
> 
>  So, we are wondering which service else is using port 8778?
> 
>  Thanks in advance for any hints.
> 
>  Regards,
>    Qiming
> 
> 
> 
> >>>
> __
>  
>  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 

Re: [openstack-dev] [nova] [placement] Which service is using port 8778?

[Sylvain Bauza]

Le 20/12/2016 09:12, Sylvain Bauza a écrit :
> 
> 
> Le 20/12/2016 07:31, Ghanshyam Mann a écrit :
>> Changing placement API port to 8780 [1], hope this is not being used by any 
>> services.
>>
>> But I am not sure how to check all used port currently as wiki does not 
>> seems to have all.
>>
>> .. [1] https://review.openstack.org/#/c/412770/ 
>>
> 
> 
> FWIW, we recently merged a devstack-gate change yesterday that now runs
> the placement service by default, which is why it's breaking Senlin gate
> now.
> https://review.openstack.org/#/c/409871/
> 
> We also have a change up for modifying stackrc to start kicking the
> placement service by default too https://review.openstack.org/#/c/412537/
> 
> Before moving forward and picking yet another port that could trample
> another service, I'd rather prefer first that Senlin jobs would
> temporarely disable the placement-* services so that the gate would be
> happy, while in the same time we try to identify a free port number that
> the placement API can safely bind.
> 

Yeah confirmed.

A working job doesn't show the placement-api service [a] to be run while
a failing one does [b]

I'm just writing a change against [c] to temporarely disable the
placement-api service. That will need to be reverted very soon since we
want to have the placement API mandatory for Ocata anyway but that will
help your gate while we identify a correct port number.


[a]
http://logs.openstack.org/31/412331/1/check/gate-senlin-dsvm-tempest-api/b1dfbf9/logs/localrc.txt.gz

[b]
http://logs.openstack.org/43/412843/1/check/gate-senlin-dsvm-tempest-api/cff7c55/logs/localrc.txt.gz

[c]
https://github.com/openstack-infra/project-config/blob/d86338e968b84d119a59a6873b1d9c7ea17c37a8/jenkins/jobs/senlin.yaml


-Sylvain

> -Sylvain
> 
> 
>> -gmann
>>
>>
>>> -Original Message-
>>> From: Ghanshyam Mann [mailto:ghanshyam.m...@nectechnologies.in]
>>> Sent: 20 December 2016 15:17
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> 
>>> Subject: Re: [openstack-dev] Which service is using port 8778?
>>>
>>> Yes, it seems placement API using it [1]
>>>
 1. Recent changes to tempest is breaking our plugin. This is being
fixed.
>>> Tempest patch should fix issue but port issue blocking that[2]
>>>
>>> For port think, I think we can change the placement API port to something
>>> else. I will propose and we can get unused port there.
>>> But OpenStack port used by services are maintained here[3], may be it will
>>> be good for each project to add their port in this list.
>>>
>>> .. [1] - https://github.com/openstack-
>>> dev/devstack/blob/master/lib/placement#L50
>>> ..[2] https://review.openstack.org/#/c/412658/
>>> ..[3] http://docs.openstack.org/newton/config-reference/firewalls-default-
>>> ports.html
>>>
>>> -gmann
>>>
>>>
 -Original Message-
 From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com]
 Sent: 20 December 2016 14:45
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] Which service is using port 8778?

 Hi, all,

 Starting yesterday, Senlin's gate jobs kept failing due to two reasons:

 1. Recent changes to tempest is breaking our plugin. This is being
fixed.

 2. Senlin API cannot bind it to port 8778 now.

 So, we are wondering which service else is using port 8778?

 Thanks in advance for any hints.

 Regards,
   Qiming



>>> __
 
 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 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] [Cinder] Does cinder use novaclient?

[Dulko, Michal]

On Tue, 2016-12-20 at 14:44 +0800, lij...@gohighsec.com wrote:
> Hi Cinder community,
> 
> Does cinder use novaclient? What's the use of cinder/compute/nova.py?
> 
> I find that there seems to have some problems when construct
> novaclient in the file  cinder/compute/nova.py,
>  but I think the file is not being used. 
> 
> Would you explain the use of this file or how does cinder communicate
> with nova?
> 
> Looking forward to your comments. Thanks.
> 
> 
> BR,
> 
> Jane

Hi,

Quick check tells me that the module is used in
cinder.scheduler.filters.InstanceLocalityFilter [1]. It's a cinder-
scheduler filter that tries to schedule volumes on nodes where the
instance that is being booted will be located.

It's likely we're not exercising this filter in the gate. Can you
elaborate on what's broken in the cinder.compute.nova module and file a
bug so we can track and fix it?

Thanks,
Michal

[1] 
https://github.com/openstack/cinder/blob/41bbdbc8a9d445cda51b61d81abbd0e427216c59/cinder/scheduler/filters/instance_locality_filter.py
__
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] [nova] [placement] Which service is using port 8778?

[Sylvain Bauza]

Le 20/12/2016 07:31, Ghanshyam Mann a écrit :
> Changing placement API port to 8780 [1], hope this is not being used by any 
> services.
> 
> But I am not sure how to check all used port currently as wiki does not seems 
> to have all.
> 
> .. [1] https://review.openstack.org/#/c/412770/ 
> 


FWIW, we recently merged a devstack-gate change yesterday that now runs
the placement service by default, which is why it's breaking Senlin gate
now.
https://review.openstack.org/#/c/409871/

We also have a change up for modifying stackrc to start kicking the
placement service by default too https://review.openstack.org/#/c/412537/

Before moving forward and picking yet another port that could trample
another service, I'd rather prefer first that Senlin jobs would
temporarely disable the placement-* services so that the gate would be
happy, while in the same time we try to identify a free port number that
the placement API can safely bind.

-Sylvain


> -gmann
> 
> 
>> -Original Message-
>> From: Ghanshyam Mann [mailto:ghanshyam.m...@nectechnologies.in]
>> Sent: 20 December 2016 15:17
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] Which service is using port 8778?
>>
>> Yes, it seems placement API using it [1]
>>
>>> 1. Recent changes to tempest is breaking our plugin. This is being
>>>fixed.
>> Tempest patch should fix issue but port issue blocking that[2]
>>
>> For port think, I think we can change the placement API port to something
>> else. I will propose and we can get unused port there.
>> But OpenStack port used by services are maintained here[3], may be it will
>> be good for each project to add their port in this list.
>>
>> .. [1] - https://github.com/openstack-
>> dev/devstack/blob/master/lib/placement#L50
>> ..[2] https://review.openstack.org/#/c/412658/
>> ..[3] http://docs.openstack.org/newton/config-reference/firewalls-default-
>> ports.html
>>
>> -gmann
>>
>>
>>> -Original Message-
>>> From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com]
>>> Sent: 20 December 2016 14:45
>>> To: openstack-dev@lists.openstack.org
>>> Subject: [openstack-dev] Which service is using port 8778?
>>>
>>> Hi, all,
>>>
>>> Starting yesterday, Senlin's gate jobs kept failing due to two reasons:
>>>
>>> 1. Recent changes to tempest is breaking our plugin. This is being
>>>fixed.
>>>
>>> 2. Senlin API cannot bind it to port 8778 now.
>>>
>>> So, we are wondering which service else is using port 8778?
>>>
>>> Thanks in advance for any hints.
>>>
>>> Regards,
>>>   Qiming
>>>
>>>
>>>
>> __
>>> 
>>> 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 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