Re: [openstack-dev] [yaql] Yaql validating performance

[Renat Akhmerov]

Tuan,

I don’t think that Jinja is something that Kirill is responsible for. It’s just 
a coincidence that we in Mistral support both YAQL and Jinja. The latter has 
been requested by many people so we finally did it.

As far as performance, could you please provide some numbers? When you say 
“takes a lot of time” how much time is it? For what kind of input? Why do you 
think it is slow? What are your expectations?Provide as much info as possible. 
After that we can ask YAQL authors to comment and help if we realize that the 
problem really exists.

I’m interested in this too since I’m always looking for ways to speed Mistral 
up.

Thanks

Renat Akhmerov
@Nokia

> On 18 Jan 2017, at 16:25, lương hữu tuấn  > wrote:
> 
> Hi Kirill,
> 
> Do you have any information related to the performance of Jinja and Yaql 
> validating. With the big size of input, yaql runs quite so slow in our case 
> therefore we have plan to switch to jinja.
> 
> Br,
> 
> @Nokia/Tuan
> 
> On Tue, Jan 17, 2017 at 3:02 PM, lương hữu tuấn  > wrote:
> Hi Kirill,
> 
> Thank you for you information. I hope we will have more information about it. 
> Just keep in touch when you guys in Mirantis have some performance results 
> about Yaql.
> 
> Br,
> 
> @Nokia/Tuan 
> 
> On Tue, Jan 17, 2017 at 2:32 PM, Kirill Zaitsev  > wrote:
> I think fuel team encountered similar problems, I’d advice asking them 
> around. Also Stan (author of yaql) might shed some light on the problem =)
> 
> -- 
> Kirill Zaitsev
> Murano Project Tech Lead
> Software Engineer at
> Mirantis, Inc
> 
> On 17 January 2017 at 15:11:52, lương hữu tuấn (tuantulu...@gmail.com 
> ) wrote:
> 
>> Hi,
>> 
>> We are now using yaql in mistral and what we see that the process of 
>> validating yaql expression of input takes a lot of time, especially with the 
>> big size input. Do you guys have any information about performance of yaql? 
>> 
>> Br,
>> 
>> @Nokia/Tuan
>> 
>> __ 
>> 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] [networking-sfc] Does SFC support chaining of Layer 2 devices?

[Vikash Kumar]

Louis,

   Typical L2 IDS devices mostly work in transparent/TAP mode which means
traffic is diverted to these devices without manipulating any packet
header. Interfaces/Ports of these devices are in promiscuous mode. Based on
the filtering rules , these devices take action on packets, most commonly
drop if found malicious otherwise sent out through outgoing interface.





On Sat, Jan 21, 2017 at 12:04 AM, Henry Fourie 
wrote:

> Vikash,
>
>Unclear what you mean by SFC spinning an L2 IDS?
>
> What is the behavior of L2 IDS devices?
>
> -Louis
>
>
>
> *From:* Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
> *Sent:* Wednesday, January 18, 2017 10:49 PM
> *To:* openstack-dev
> *Subject:* [openstack-dev] [networking-sfc] Does SFC support chaining of
> Layer 2 devices?
>
>
>
> All,
>
>I am exploring SFC for chaining an IDS device (strictly in L2 mode). As
> of now, it looks SFC default supports only L3 devices. SFC APIs doesn't
> have any way to specify the nature of device and without that, it seems
> there is no way an operator can spin any device/VNF except L3 mode VNFs. Is
> anything I am missing here ? Can one still spin a L2 IDS with SFC ?
>
>
>
> --
>
> Regards,
>
> Vikash
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare(Geetika Batra)

[Geetika Batra]

Mike

I am glad to hear that Glare is back on track. I would be really happy to
contribute to Glare. I would be able to spend around 8-10 hours a week; I
will try to review some code on daily basis. It might take me a while to
finish of patches and fix bugs because my first priority is my job, but I
will make sure I do not disappoint you with timelines. Please let me know
if anything else is expected from my end.

Regards
Geetika Batra


ᐧ
__
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] [ironic-pyhon-agent][DIB] IPA failed to start on Ubuntu because of modprobe path

[Ian Wienand]

On 01/21/2017 09:31 PM, Moshe Levi wrote:

Added ExecStartPre=/usr/sbin/modprobe vfat to the
ironic-python-agent systemd script The problem is that modprobe
location in Ubuntu / sbin/modprobe (the /usr/sbin/modprobe vfat
works for redhat)



I have opened this bug in Launchpad

> https://bugs.launchpad.net/diskimage-builder/+bug/1658297


What is the best way to fix this?


This should be just "/sbin"; I've proposed [1].  There may be even
better ways to do this which anyone is welcome to propose :)

-i

[1] https://review.openstack.org/423893

__
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]Can we run cinder-volume and cinder-backup on a same host?

[Rikimaru Honjo]

Hi Michal,

Thank you for explaining!
I could understand the mechanism of cinder-backup.


If you're able to reproduce a scenario that fails these assumptions,
please file a bug report and we'll be happy to investigate and provide
a fix.

Sure.
But, according to your explanation, my assumptions won't be realized.

On 2017/01/20 17:31, Dulko, Michal wrote:

On Fri, 2017-01-20 at 14:15 +0900, Rikimaru Honjo wrote:

Hi Cinder devs,

I have a question about cinder.
Can I run cinder-volume and cinder-backup on a same host when I using
iscsi backend?

I afraid that iscsi operations will be conflicted between cinder-
volume and cinder-backup.
In my understanding, iscsi operations are serialized for each
individual process.
But these could be raced between processes.

e.g.(Caution: This is just a forecast.)
If cinder-backup execute "multipath -r" while cinder-volume is
terminating connection,
a multipath garbage will remain unexpectedly.


Hi,

Before Mitaka it was *required* to place cinder-volume and cinder-
backup on the same node. As both services shared same file lock
directory, it was safe. In fact cinder-backup simply imported cinder-
volume code.

Since Mitaka cinder-backup doesn't do any iSCSI operations directly and
attaches volumes by calling cinder-volume over RPC. This means that
it's possible to place cinder-backup on other node than cinder-volume,
but it's still totally safe to place them together.

If you're able to reproduce a scenario that fails these assumptions,
please file a bug report and we'll be happy to investigate and provide
a fix.

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



--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
ＮＴＴソフトウェア株式会社
クラウド&セキュリティ事業部 第一事業ユニット（CS1BU）
本上力丸
TEL.  :045-212-7539
E-mail:honjo.rikim...@po.ntts.co.jp
〒220-0012
  横浜市西区みなとみらい4丁目4番5号
  横浜アイマークプレイス 13階



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

[openstack-dev] [Neutron] PTL Candidacy

[Kevin Benton]

I would like to propose my candidacy for the Neutron PTL.

I have been contributing to Neutron since the Havana development
cycle working for a network vendor and then a distribution vendor.
I have been a core reviewer since the Kilo development cycle and
I am on the Neutron stable maintenance team as well as the drivers
team.

I have a few priorities that I would focus on as PTL:

* Cleanup and simplification of the existing code: In addition to
supporting the ongoing work of converting all data access into OVO models,
I would like the community to continue breaking down code using the
callback event system. We should eliminate as many extension-specific
mixins and special-cases from the core as possible so it becomes very easy
to reason about and stable from a code-churn perspective. This approach
forces us to add appropriate event notifications to the core to build
service plugins and drivers out of tree without requiriing modifications to
the core.

* Reinstating VPNaaS: this project accomplishes its goals reasonably well
and it solves a clear use case. There has been enough interest from
contributors on the mailing list that we should be able to find enough
resources to at least keep it maintained even if no large features are
added.

* Switch to Pecan and eliminate old API code: we have been working on the
new Pecan rewrite for several cycles now. With the current patches open for
review, we have parity with the existing API and it should be safe to
switch.

* Enhance DVR to solve additional use cases requested by the community: I
would like us to enable SNAT at the compute nodes for cases where
consumption of IPs for each compute ndoe from the external network is not a
concern. I would also like us to allow the central node to provide floating
IP translations for ports unserviced by DVR local nodes (e.g. unbound
ports, baremetal ports, ports on compute nodes not attached directly to the
external network).

* Bring on new core reviewers: we suffered from attrition of our core team
during this last cycle due to some fundamental changes at a few of the
major contributing companies. We have several strong contributors that I
would like to see take on a core reviewer role so we can keep our review
backlog under control.

* Support services being built on Neutron: whether it's BGPVPN, Kuryr, SFC,
Octavia, Ironic, or whatever else, I want Neutron to provide the building
blocks and primitives necessary to fulfill the needs of these projects.
This means supporting initiatives like neutron-lib, agent extensions, and
future API enhancements to provide more control over core resource behavior.

* Add tooling to keep the review backlog under control: I would like to
look into a bot that can harass us in the channel if a patch sits for too
long without feedback. I want to avoid having patches sit in our queue for
months at a time because it results in fixes falling through the cracks.


Cheers,
Kevin Benton (kevinbenton)
__
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] [all][survey] open source collaboration practices

[Allison Randal]

Hi all,

I’m running a brief (10 question) survey on the collaboration practices
common to companies participating in open source today. I’d greatly
appreciate a moment of your time to share your experience:

https://www.surveymonkey.com/r/os-participation

This survey is part of my academic research, and not related to my
affiliation with any other employers, foundations, or projects. I’m
capturing company names for the purpose of statistical correlation, but
will anonymize these to unidentifiable numbers in the data published
with the research.

Thanks,
Allison

__
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-ansible] [kolla] Am I doing this wrong?

[Steven Dake (stdake)]

Kris,

Thanks for adding the kolla tag.  As we reach milestone 3, every kolla dev is 
knee deep in development and probably not reading mails not directly tagged 
with [kolla].

IOutlook 2016 has a bug where I cannot respond inline.  I am replying here so 
my gmail account picks up the email so that I can respond inline.

It will take me several hours to process your email and I’m not certain I can 
answer all of the questions to your satisfaction as kolla is a pretty large 
project and it is difficult for any one person to know all of the details.  I 
will hopefully have a response sometime this evening for the things I can 
answer.  Hopefully others in the community can fill in the gaps.

Regards
-steve



From: "Kris G. Lindgren" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, January 20, 2017 at 6:03 PM
To: "openstack-dev@lists.openstack.org" 
Cc: "openstack-operat...@lists.openstack.org" 

Subject: Re: [openstack-dev] [kolla-ansible] [kolla] Am I doing this wrong?

Adding [kolla] tag.


___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren" 
Date: Friday, January 20, 2017 at 4:54 PM
To: "openstack-dev@lists.openstack.org" 
Cc: "openstack-operat...@lists.openstack.org" 

Subject: Re: [kolla-ansible] Am I doing this wrong?

Poke.  Bueller?


___
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: "Kris G. Lindgren" 
Date: Tuesday, January 10, 2017 at 5:34 PM
To: "openstack-dev@lists.openstack.org" 
Subject: [kolla-ansible] Am I doing this wrong?

Hello Kolla/Kolla-ansible peoples.

I have been trying to take kolla/kolla-ansible and use it to start moving our 
existing openstack deployment into containers.  At the same time also trying to 
fix some of the problems that we created with our previous deployment work 
(everything was in puppet).  Where we had puppet doing *everything* which 
eventually created a system that effectively performed actions at a distance.  
As we were never really 100% what puppet was going to do when we ran it.  Even 
with NOOP mode enabled.  So taking an example of building and deploying glance 
via kolla-ansible. I am running into some problems/concerns and wanted to reach 
out to make sure that I am not missing something.

Things that I am noticing:
 * I need to define a number of servers in my inventory outside of the specific 
servers that I want to perform actions against.  I need to define groups 
baremetal, rabbitmq, memcached, and control (IN addition to the glance specific 
groups) most of these seem to be gathering information for config? (Baremetal 
was needed soley to try to run the bootstrap play).  Running a change 
specifically against "glance" causes fact gathering on a number of other 
servers not specifically where glance is running?  My concern here is that I 
want to be able to run kola-ansible against a specific service and know that 
only those servers are being logged into.

* I want to run a dry-run only, being able to see what will happen before it 
happens, not during; during makes it really hard to see what will happen until 
it happens. Also supporting  `ansible --diff` would really help in 
understanding what will be changed (before it happens).  Ideally, this wouldn’t 
be 100% needed.  But the ability to figure out what a run would *ACTUALLY* do 
on a box is what I was hoping to see.

* Database task are ran on every deploy and status of change DB permissions 
always reports as changed? Even when nothing happens, which makes you wonder 
"what changed"?  Seems like this is because the task either reports a 0 or a 1, 
where it seems like there is 3 states, did nothing, updated something, failed 
to do what was required.  Also, Can someone tell me why the DB stuff is done on 
a deployment task?  Seems like the db checks/migration work should only be done 
on a upgrade or a bootstrap?

* Database services (that at least we have) our not managed by our team, so 
don't want kolla-ansible touching those (since it won't be able to). No way to 
mark the DB as "externally managed"?  IE we dont have permissions to create 
databases or add users.  But we got all other permissions on the databases that 
are created, so normal db-manage tooling works.

* Maintenance level operations; doesn't seem to be any built-in to say 'take a 
server out  of a production state, deploy to it, test it, put it back into 
production'  Seems like if kola-ansible is doing haproxy for API's, it should 
be managing this?  Or an extension point to allow us to run our own 
maintenance/testing scripts?

* Config must come from kolla-ansible and generated templates.  I know we have 
a patch up for externally managed service configuration.  But if we aren't 
suppose to use kolla-ansible for generating configs (see below), why cant we 
override this piece?

Hard to determine what kolla-a

[openstack-dev] [nova] [placement] [operators] Optional resource asking or not?

[Sylvain Bauza]

Hey folks,

tl;dr: should we GET /resource_providers for only the related resources
that correspond to enabled filters ? Explanation below why even if I
know we have a current consensus, maybe we should discuss again about it.


I'm still trying to implement https://review.openstack.org/#/c/417961/
but when trying to get the functional job being +1, I discovered that we
have at least one functional test [1] asking for just the RAMFilter (and
not for VCPUs or disks).

Given the current PS is asking for *all* both CPU, RAM and disk, it's
trampling the current test by getting a NoValidHost.

Okay, I could just modify the test and make sure we have enough
resources for the flavors but I actually now wonder if that's all good
for our operators.

I know we have a consensus saying that we should still ask for both CPU,
RAM and disk at the same time, but I imagine our users coming back to us
saying "eh, look, I'm no longer able to create instances even if I'm not
using the CoreFilter" for example. It could be a bad day for them and
honestly, I'm not sure just adding documentation or release notes would
help them.

What are you thinking if we say that for only this cycle, we still try
to only ask for resources that are related to the enabled filters ?
For example, say someone is disabling CoreFilter in the conf opt, then
the scheduler shouldn't ask for VCPUs to the Placement API.

FWIW, we have another consensus about not removing
CoreFilter/RAMFilter/MemoryFilter because the CachingScheduler is still
using them (and not calling the Placement API).

Thanks,
-Sylvain

[1]
https://github.com/openstack/nova/blob/de0eff47f2cfa271735bb754637f979659a2d91a/nova/tests/functional/test_server_group.py#L48

__
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] [octavia] Nominating German Eichberger for Octavia core reviewer

[Nir Magnezi]

I don't get a vote here, but it is indeed nice to see German back in the
Octavia community.

Nir

On Fri, Jan 20, 2017 at 7:41 PM, Michael Johnson 
wrote:

>
> Hello Octavia Cores,
>
> I would like to nominate German Eichberger (xgerman) for reinstatement as
> an
> Octavia core reviewer.
>
> German was previously a core reviewer for Octavia and neutron-lbaas as well
> as a former co-PTL for Octavia.  Work dynamics required him to step away
> from the project for a period of time, but now he has moved back into a
> position that allows him to contribute to Octavia.  His review numbers are
> back in line with other core reviewers [1] and I feel he would be a solid
> asset to the core reviewing team.
>
> Current Octavia cores, please respond with your +1 vote or an objections.
>
> Michael
>
> [1] http://stackalytics.com/report/contribution/octavia-group/90
>
>
> __
> 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] [octavia] Nominating German Eichberger for Octavia core reviewer

[Kosnik, Lubosz]

+1, welcome back.

Lubosz

On Jan 20, 2017, at 2:11 PM, Miguel Lavalle 
mailto:mig...@mlavalle.com>> wrote:

Well, I don't vote here but it's nice to see German back in the community. 
Welcome!

On Fri, Jan 20, 2017 at 1:26 PM, Brandon Logan 
mailto:brandon.lo...@rackspace.com>> wrote:
+1, yes welcome back German.
On Fri, 2017-01-20 at 09:41 -0800, Michael Johnson wrote:
> Hello Octavia Cores,
>
> I would like to nominate German Eichberger (xgerman) for
> reinstatement as an
> Octavia core reviewer.
>
> German was previously a core reviewer for Octavia and neutron-lbaas
> as well
> as a former co-PTL for Octavia.  Work dynamics required him to step
> away
> from the project for a period of time, but now he has moved back into
> a
> position that allows him to contribute to Octavia.  His review
> numbers are
> back in line with other core reviewers [1] and I feel he would be a
> solid
> asset to the core reviewing team.
>
> Current Octavia cores, please respond with your +1 vote or an
> objections.
>
> Michael
>
> [1] http://stackalytics.com/report/contribution/octavia-group/90
>
>
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] [tc] Re: [kolla] A new kolla-salt deliverable

[Michał Jastrzębski]

Our voting ends in 2 days, but it's more about process how to include
code rather than if Kolla-salt stays. Kolla-salt resonates with Kolla
mission very well, whether it's under Kolla umbrella or outside of it,
I don't think anybody will block it:)

Bottom line - if there will be people working on it - it's going to stay.

On 22 January 2017 at 08:36, Daniel Comnea  wrote:
> So what the conclusion with kolla-salt deliverable, has this work started,
> if yes where is the code etc etc ?
>
> On Mon, Jan 2, 2017 at 1:12 PM, Thierry Carrez 
> wrote:
>>
>> Michał Jastrzębski wrote:
>> > I agree this would make good PTG discussion for us, and maybe someone
>> > from TC could join in. We are somehow special beast as Kolla itself is
>> > just meant to be consumed. Kolla to me is similar to Oslo in that
>> > matter. But still we don't have oslo-compute projects, we have nova,
>> > but we would have kolla-salt, even tho core teams would be totally
>> > different potentially. As Britt said, growing pains.
>>
>> Happy to join in any discussion at the PTG on that topic.
>>
>> As far as our governance is concerned, "teams" decide what git
>> repositories they vouch for -- the team's opinion being represented by
>> the PTL. Each team is of course free to add more complex ways of
>> gathering the "team's opinion" :)
>>
>> Cheers,
>>
>> --
>> 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 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] [ocatvia]Newton Octavia lbaas creation error

[Santhosh Fernandes]

Hi all,

I am getting driver connection error while creation the LB from octavia.

Stack trace -

2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource
[req-c6f19e4c-dfbd-4b1c-8198-925d05f9fcdf cf13e167c1884e7a8d63293a454ca774
48ab507e206741c4ba304efaf5209963 - - -] create failed: No details.
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource Traceback (most
recent call last):
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/neutron/api/v2/resource.py",
line 79, in resource
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource result =
method(request=request, **args)
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/neutron/api/v2/base.py",
line 430, in create
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource return
self._create(request, body, **kwargs)
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/neutron/db/api.py",
line 88, in wrapped
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource setattr(e,
'_RETRY_EXCEEDED', True)
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource
self.force_reraise()
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource
six.reraise(self.type_, self.value, self.tb)
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/neutron/db/api.py",
line 84, in wrapped
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource return
f(*args, **kwargs)
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/oslo_db/api.py",
line 151, in wrapper
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource ectxt.value
= e.inner_exc
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource
self.force_reraise()
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource
six.reraise(self.type_, self.value, self.tb)
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/oslo_db/api.py",
line 139, in wrapper
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource return
f(*args, **kwargs)
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/neutron/db/api.py",
line 124, in wrapped
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource
traceback.format_exc())
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource
self.force_reraise()
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 196, in force_reraise
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource
six.reraise(self.type_, self.value, self.tb)
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/neutron/db/api.py",
line 119, in wrapped
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource return
f(*dup_args, **dup_kwargs)
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/neutron/api/v2/base.py",
line 543, in _create
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource obj =
do_create(body)
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/neutron/api/v2/base.py",
line 525, in do_create
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource
request.context, reservation.reservation_id)
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource   File
"/openstack/venvs/neutron-14.0.3/lib/python2.7/site-packages/oslo_utils/excutils.py",
line 220, in __exit__
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource
self.force_reraise()
2017-01-22 12:21:51.569 14448 ERROR neutron.api.v2.resource  

[openstack-dev] [trove] gate currently broken, rechecking is pointless

[Amrith Kumar]

The Trove gate appears to be currently broken and rechecking things on the
trove or trove-client projects is pointless. There was some speculation that
this current failure relates to some change in the nova client. I haven't
verified this myself but a fix[1] has been proposed to (ostensibly) fix the
gate but it hasn't worked. I also found that a change was pushed up some
time back[2] and it has successfully fallen through the cracks.

 

I'll be looking into this tomorrow and hopefully we can get the gate
unwedged again.

 

But in the meanwhile, please refrain from just rechecking stuff; it isn't
going to do any good to warm the planet faster than it is already.

 

-amrith

 

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

[2] https://review.openstack.org/#/c/412497/

 

--

Amrith Kumar

GPG: 0x5e48849a9d21a29b

 



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

Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable

[Daniel Comnea]

So what the conclusion with kolla-salt deliverable, has this work started,
if yes where is the code etc etc ?

On Mon, Jan 2, 2017 at 1:12 PM, Thierry Carrez 
wrote:

> Michał Jastrzębski wrote:
> > I agree this would make good PTG discussion for us, and maybe someone
> > from TC could join in. We are somehow special beast as Kolla itself is
> > just meant to be consumed. Kolla to me is similar to Oslo in that
> > matter. But still we don't have oslo-compute projects, we have nova,
> > but we would have kolla-salt, even tho core teams would be totally
> > different potentially. As Britt said, growing pains.
>
> Happy to join in any discussion at the PTG on that topic.
>
> As far as our governance is concerned, "teams" decide what git
> repositories they vouch for -- the team's opinion being represented by
> the PTL. Each team is of course free to add more complex ways of
> gathering the "team's opinion" :)
>
> Cheers,
>
> --
> 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 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] [congress] ocata client causes feature regression with pre-ocata server

[Monty Taylor]

On 01/21/2017 04:07 AM, Eric K wrote:
> Hi all,
> 
> I was getting ready to request release of congress client, but I
> remembered that the new client causes feature regression if used with
> older versions of congress. Specifically, new client with pre-Ocata
> congress cannot refer to datasource by name, something that could be done
> with pre-Ocata client.
> 
> Here¹s the patch of interest: https://review.openstack.org/#/c/407329/
> 
> 
> A few questions:
> 
> Are we okay with the regression? Seems like it could cause a fair bit of
> annoyance for users.

This is right. New client lib should always continue to work with old
server. (A user should be able to just pip install python-congressclient
and have it work regardless of when their operator decides to upgrade or
not upgrade their cloud)

>1. If we¹re okay with that, what¹s the best way to document that
> pre-Ocata congress should be used with pre-Ocata client?
>2. If not, how we avoid the regression? Here are some candidates I can
> think of. 
>   a. Client detects congress version and act accordingly. I don¹t
> think this is possible, nor desirable for client to be concerned with
> congress version not just API version.
>   b. Release backward compatible API version 1.1 that supports
> getting datasource by name_or_id. Then client will take different paths
> depending on API version.
>   c. If datasource not found, client falls back on old method of
> retrieving list of datasources to resolve name into UUID. This would work,
> but causes extra API & DB call in many cases.
>   d. Patch old versions of Congress to support getting datasource
> by name_or_id. Essentially, it was always a bug that the API didn¹t
> support name_or_id.

I'm a fan of d - but I don't believe it will help - since the problem
will still manifest for users who do not have control over the server
installation.

I'd suggest c is the most robust. It _is_ potentially more expensive -
but that's a good motivation for the deployer to upgrade their
installation of congress without negatively impacting the consumer in
the  meantime.

Monty

__
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][ptl] PTL Candidacy for Tricircle Pike cycle

[joehuang]

Hello,

I would like to announce my self nomination for the PTL candidacy for
Tricircle Pike cycle. My name is Chaoyi Huang, IRC handle joehuang.

It's great step that the Tricircle project joined the OpenStack big-tent
ecosystem in Ocata cycle, thanks to the effort from every Tricircle
contributor, and the help from TCs/PTLs/other project contributors.

Being one big-tent project is one very important milestone to build the
open community, attract more contributors, to accelrate the Tricircle
being more and more mature. Although lots of fundatemental features
and documentations are ready[1][2], it's time for us to think about
the question: when will Tricircle will be ready for production use?

Here are some ideas to make Tricircle to reach the goal for
production deployment in Pike cycle:

* function test ready, enhance scenario test cases and code coverage.
* encourage cloud operator to try Tricircle and get feedback from
cloud operators for quality, features, and what's to improvement.
* feature compliment - shared_vxlan supported L2/L3 networking,
  advanced networking features like QoS, LBaaS, python client etc.
* performance, reliability review and enhancement as needed.
* upgradable before production.
* keep community as open as any other team, make the contribution
  in Tricircle is comfortable for anyone, attract more and more
  contributors.
* help and grow any one who wants to try PTL in Queens cycle.

Hope everyone will enjoy the contribution in Tricircle.

Thank you for your kind consideration of my candidacy.

[1]https://github.com/openstack/tricircle/tree/master/releasenotes/notes
[2]http://docs.openstack.org/developer/tricircle/


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