Re: [openstack-dev] [Fuel][Fuel-Library] Fuel CI issues

[Dmitry Borodaenko]

Aleksandra,

Very good point on separating the concerns about integration tests for
Fuel as a whole and verifying commits to a single component such as
fuel-library. In theory, it could support the right balance between
stable CI and up-to-date code, but only if we resolve the two remaining
problems: one small and technical and the other large and social.

You've already pointed out the first problem: update of fuel-library CI
environment is not yet fully automated, and so the environment is liable
to lag behind all involved components for days if not weeks.

This by itself is simple enough, if labourous, to work around (update it
manually every day, or after every successful BVT), but still leaves us
with the problem of motivation.

We've been discussing the CI duty for fuel-library integration with
puppet-openstack since more than a month ago [0], and it has
continuously failed to materialize. Within days of getting an action
item in that IRC meeting to arrange it, Andrew Maksimov has responded
privately that nobody in his team has time for this. And we all know
what "I don't have time" actually means [1]. Two weeks later, we were
ready to launch the integration and the question of CI duty came up
again [2], with the same result.

[0] 
http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-02-04-16.02.log.html#l-66
[1] 
http://lifehacker.com/5892948/instead-of-saying-i-dont-have-time-say-its-not-a-priority
[2] 
http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-02-18-16.00.log.html#l-190

Here we are two more weeks later, the integration is on, and the first
reaction from fuel-library core reviewers is "we don't have time to deal
with this, turn it back off right now". And I'm not just summarizing
Vladimir's email, on Friday we had a long thread on an internal mailing
list with exactly this in the subject line (my apologies, but my disgust
at the fact that it was started behind closed doors drowns any qualms
about dragging it back into the open).

After we change Fuel CI to use fixed, most recent to have passed BVT,
revisions of puppet-openstack modules, first thing that will happen is
that BVT on Fuel ISO will start failing again, while fuel-library CI
will continue to work. Without the pressure of failing commit
verification CI, fuel-library developers will have even less incentive
to keep fuel-library up to date with puppet-openstack (not to mention
pro-actively reviewing puppet-openstack commits to catch potential
regressions before they happen), and very soon Fuel QA team will get fed
up with not having a stable ISO for the swarm test, and will demand that
we go back to using fixed puppet-openstack revisions for the ISO, too.

Both here and on the internal thread, many technical and organizational
concerns were raised, and I'll get to them in a bit, but a concern
without the will to resolve it is only an excuse, we won't get far if we
don't want to make it work.

So why don't fuel-library developers want to spend time on
puppet-openstack integration?

I see two dimensions to this problem. On one axis, there's the
cost/benefit balance: how much work does it take, and what do we gain
from doing it? On the other is the question of who benefits and who
carries the costs?

Without tracking HEAD of puppet-openstack in fuel-library, the primary
cost is carried by puppet-openstack developers who maintain the upstream
modules in the first place, and a small fraction of fuel-library
contributors (5+ out of 50+ [3][4]) who periodically have to spend
significant amount of effort to bring fuel-library up to date with the
current state of puppet-openstack. Even though the conversion to
librarian has made the upstream sync simpler and safer, preparing the
update to Mitaka still took a full month of work for 5-7 people.

[3] 
http://stackalytics.com/?module=puppet%20openstack-group=mirantis=commits
[4] http://stackalytics.com/?module=fuel-library=mirantis=commits

Secondary costs are carried by Fuel Infra and QA teams who have to
support CI based on two OpenStack releases in parallel during that
month, fuel-library and puppet-openstack developers who have to deal
with a spike in code churn, all Fuel contributors who are blocked by
merge freeze during transition, and once again Fuel QA team who
occasionally get blocked by bugs that were fixed in upstream and not yet
pulled into fuel-library.

In short, under that model, most fuel-library developers don't have to
do much to gain the benefit of being up to date with upstream, such us
getting support of the next OpenStack release. The integration cost,
around 7-10 man-months per release, is carried mostly by other people.

Transition to full integration with upstream via tracking HEAD of
puppet-openstack in fuel-library dramatically alters this balance.
Massive upstream sync is gone, and so are the associated costs of
parallel CI, transition merge freeze, and missing upstream bugfixes. The
code churn is still there, but more evenly spread over time.

Re: [openstack-dev] [ceilometer] Unable to get IPMI meter readings

[Lu, Lianhao]

On Mar 5, 2016 04:10, Kapil wrote:
> Yes, I had to look through the source code of the ipmi pollster class 
> to figure out why the error was being raised. Apparently, I don't have 
> Intel node manager installed, so power plugin was not being loaded.
> I had to write my own plugin to get that data using ipmi-dcmi command 
> which is not specific to Intel I guess.
> Is there any plan to add dcmi support to ceilometer ?
> 
Currently no, but welcome to contribute dcmi support.

-Lianhao Lu

__
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-operators] OpenStack Contributor Awards

[Hugh Blemings]

On 2/03/2016 07:04, Tim Bell wrote:


Just to check, does OpenStack run on a Raspberry Pi ? Could cause some negative 
comments if it was
not compatible/sized for a basic configuration.


Actually for what it's worth, in my original thinking I didn't see this 
as a big issue.  The point kinda being to intentionally give folk 
something at the opposite end of the computing scale continuum than 
you're average DC full of humming kit :)


Cheers,
Hugh




__
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] Reg: Configuration Management tool for Openstack.

[cool dharma06]

Hi all,

i have the following questions in Openstack deployment.

1. i need some configuration management tool for OpenStack. After some
searches i got some tools like Puppet, Ansible, Chef, Fuel and tripleO. i
am confused to which one to go.

2. And also i checked the Github repository for openstack-puppet, i think
its not active.

Suggest some tool for openstack. i am newbie for this large scale deploment
and also for configuration management.


thanks & regards,
cooldharma06  .. :)
__
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] [Kolla] DocImpact in reviews

[Swapnil Kulkarni]

Hello,

I was triaging some of the bugs reported to Kolla and I found a couple
of bugs [1] [2] created due to incorrect usage of DocImpact[1] tag in
reviews. The DocImapct tag should only be used in case if you have
done some change which requires following two,

1) Update in some existing documentation
2) Add some new documentation

which are not addressed in the current changeset where you are adding
the DocImapct.


[1] https://wiki.openstack.org/wiki/Documentation/DocImpact
[2] https://bugs.launchpad.net/kolla/+bug/1553291
[3] https://bugs.launchpad.net/kolla/+bug/1553405

Best Regards,
Swapnil Kulkarni
irc : coolsvap

__
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] [sahara]FFE Request for resume EDP job

[lu jander]

Hi folks,

I would like to request a FFE for the feature “Resume EDP job”:



BP:
https://blueprints.launchpad.net/sahara/+spec/add-suspend-resume-ability-for-edp-jobs





Spec has been merged. https://review.openstack.org/#/c/198264/


Suspend EDP patch has been merged.
https://review.openstack.org/#/c/201448/





Code Review: https://review.openstack.org/#/c/285839/




code is ready for review.



The Benefits for this change: after suspend job, we can resume this job.



The Risk: The risk would be low for this patch, since the code of suspend
patch has been long time reviewed.



Thanks,

luhuichun
__
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][cinder] Limits on volume read throughput?

[Preston L. Bannister]

Should add that the physical host of the moment is Centos 7 with a
packstack install of OpenStack. The instance is Ubuntu Trusty. Centos 7 has
a relatively old 3.10 Linux kernel.

>From the last week (or so) of digging, I found there were substantial
claimed improvements in *both* flash support in Linux and the block I/O
path in QEMU - in more recent versions. How much that impacts the current
measures, I do not (yet) know.

Which suggests a bit of tension. Redhat folk are behind much of these
improvements, but RHEL (and Centos) are rather far behind. Existing RHEL
customers want and need careful, conservative changes. Folk deploying
OpenStack need more aggressive release content, for which Ubuntu is
currently the best base.

Will we see a "Redhat Cloud Base" as an offering with RHEL support levels,
and more aggressive QEMU and Linux kernel inclusion?

At least for now, building OpenStack clouds on Ubuntu might be a much
better bet.


Are those claimed improvements in QEMU and the Linux kernel going to make a
difference in my measured result? I do not know. Still reading, building
tests, and collecting measures...




On Thu, Mar 3, 2016 at 11:28 AM, Chris Friesen 
wrote:

> On 03/03/2016 01:13 PM, Preston L. Bannister wrote:
>
> > Scanning the same volume from within the instance still gets the same
>> > ~450MB/s that I saw before.
>>
>> Hmmm, with iSCSI inbetween that could be the TCP memcpy limitation.
>>
>>
>> Measuring iSCSI in isolation is next on my list. Both on the physical
>> host, and
>> in the instance. (Now to find that link to the iSCSI test, again...)
>>
>
> Based on earlier comments it appears that you're using the qemu built-in
> iSCSI initiator.
>
> Assuming that's the case, maybe it would make sense to do a test run with
> the in-kernel iSCSI code and take qemu out of the picture?
>
> Chris
>
>
> __
> 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] [nova] How to fix the wrong usage of 'format' jsonschema keyword in server create API

[Alex Xu]

Hi,

Due to this regression bug https://launchpad.net/bugs/1552888, found we are
using 'formart' jsonschema keyword in wrong way. The 'format' is not only
for string instance, but all the types.

So checking the server create API, we have problem at
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/servers.py#L38.
The original purpose of jsonschema want to allow 'null' value by the 'type'
keywordl. Actually the 'null' value isn't allowed, as the 'uuid' format
will return fault for 'null' value.

So what we need to do for this:

Option1: Fix it with microversion
Option2: Fix it without microversion
Option3: Keep it as 'null' isn't allowed.

If we choice to fix it, I think we need Microversion, due to this bug is
introduced before v2.1 API release.

But I prefer to not fix it, as we said v2.1 strict the API input. And
'null' isn't valuable valid value(If port isn't provided by user, user can
just ignore this parameter.). I think we can just disable it, keep this
current behaviour as the v2.1 API behaviour.

What would you think?

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] [kolla][vote] Proposing Alicja Kwasniewska for core reviewer

[Angus Salkeld]

+1

On Sat, 5 Mar 2016 2:58 am Steven Dake (stdake)  wrote:

> Core Reviewers,
>
> Alicja has been instrumental in our work around jinja2 docker file
> creation, removing our symlink madness.  She has also been instrumental in
> actually getting Diagnostics implemented in a sanitary fashion.  She has
> also done a bunch of other work that folks in the community already know
> about that I won't repeat here.
>
> I had always hoped she would start reviewing so we could invite her to the
> core review team, and over the last several months she has reviewed quite a
> bit!  Her 90 day stats[1] place her at #9 with a solid ratio of 72%.  Her
> 30 day stats[2] are even better and place her at #6 with an improving ratio
> of 67%.  She also just doesn't rubber stamp reviews or jump in reviews at
> the end; she sticks with them from beginning to end and finds real
> problems, not trivial things.  Finally Alicja is full time on Kolla as
> funded by her employer so she will be around for the long haul and always
> available.
>
> Please consider my proposal to be a +1 vote.
>
> To be approved for the core reviewer team, Alicja requires a majority vote
> of 6 total votes with no veto within the one week period beginning now and
> ending Friday March 11th.  If your on the fence, you can always abstain.
> If the vote is unanimous before the voting ends, I will make appropriate
> changes to gerrit's acls.  If their is a veto vote, voting will close prior
> to March 11th.
>
> Regards,
> -steve
>
> [1] http://stackalytics.com/report/contribution/kolla-group/90
> [2] http://stackalytics.com/report/contribution/kolla-group/30
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Common RPC Message Trace Mechanism

[Xuanzhou Perry Dong]

Hi, Boris,

Thanks for your response.

I refer to the very simple type of "trace": just print out the RPC messages to 
stdout/stderr/syslog. I have checked the osprofiler project and think that it 
is very good and could solve my problem if it is used by the Openstack projects 
to trace their RPC calls.

Best Regards,
Xuanzhou Perry Dong


At 2016-03-07 12:27:12, "Boris Pavlovic"  wrote:

Xuanzhou, 



I am not sure what do you mean by "trace". But if you need something that 
allows to do cross service/project tracing then you should take a look at 
osprofiler:
https://github.com/openstack/osprofiler



Best regards,
Boris Pavlovic 


On Sun, Mar 6, 2016 at 8:15 PM, Xuanzhou Perry Dong  wrote:

Hi,

I am looking for a common RPC message trace mechanism in oslo_messaging. This 
message trace mechanism needs to be common to all drivers. Currently some 
documentation mentions that oslo_messaging_amqp.trace can activate the message 
trace (say, 
http://docs.openstack.org/liberty/config-reference/content/networking-configuring-rpc.html).
 But it seems that this oslo_messaging_amqp.trace is only available to the 
Proton driver.

Do I miss any existing common RPC message trace mechanism in oslo? If there is 
no such mechanism, I would propose to create such a mechanism for oslo.

Any response is appreciated.
Thanks.
Best Regards,
Xuanzhou Perry Dong





 


__
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] [Manila] nfs-over-vsock (was: Concurrent execution of drivers)

[Shinobu Kinjo]

Thank you for your reply.

I googled and researched "nfs over vsock", especially vsock before.
I saw thread you put comments on as well.

I'm very positive to implement this feature and hope we realize this.

Cheers,
Shinobu


On Mon, Mar 7, 2016 at 1:04 PM, Ben Swartzlander  wrote:
> On 03/05/2016 05:34 AM, Shinobu Kinjo wrote:
>>
>> Are we still going to think of nfs-over-vsock?
>> Never mind. It's just coming from my curiosity.
>
>
> A lot of work outside Manila has to happen before we can actually deliver
> that feature in OpenStack. If you google about nfs over vsock you can learn
> about the current state of things. It's going to be a while before nfs over
> vsock is implemented and it's going to even longer before that support is
> shipping on plaforms where people run OpenStack. I'm very optimistic, but we
> need to be patient.
>
> -Ben
>
>
>> Cheers,
>> S
>>
>> On Fri, Mar 4, 2016 at 11:08 PM, Valeriy Ponomaryov
>>  wrote:

 Thanks - so if I understand you correctly, each share instance is
 uniquely associated with a single instance of the driver at one time,
 right?  So while I might have two concurrent calls to ensure_share,
 they are guaranteed to be for different shares?
>>>
>>>
>>> Yes.
>>>
 Is this true for the whole driver interface?
>>>
>>>
>>> Yes.
>>>

 Two instances of the
 driver will never both be asked to do operations on the same share at
 the same time?
>>>
>>>
>>>
>>> Yes.
>>>
>>> Each instance of a driver will have its own unique list of shares to be
>>> 'ensure'd.
>>>
>>> --
>>> Kind Regards
>>> Valeriy Ponomaryov
>>> www.mirantis.com
>>> vponomar...@mirantis.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 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



-- 
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] Common RPC Message Trace Mechanism

[Boris Pavlovic]

Xuanzhou,

I am not sure what do you mean by "trace". But if you need something that
allows to do cross service/project tracing then you should take a look at
osprofiler:
https://github.com/openstack/osprofiler

Best regards,
Boris Pavlovic

On Sun, Mar 6, 2016 at 8:15 PM, Xuanzhou Perry Dong 
wrote:

> Hi,
>
> I am looking for a common RPC message trace mechanism in oslo_messaging.
> This message trace mechanism needs to be common to all drivers. Currently
> some documentation mentions that oslo_messaging_amqp.trace can activate the
> message trace (say,
> http://docs.openstack.org/liberty/config-reference/content/networking-configuring-rpc.html).
> But it seems that this oslo_messaging_amqp.trace is only available to the
> Proton driver.
>
> Do I miss any existing common RPC message trace mechanism in oslo? If
> there is no such mechanism, I would propose to create such a mechanism for
> oslo.
>
> Any response is appreciated.
> Thanks.
> Best Regards,
> Xuanzhou Perry Dong
>
>
>
>
> __
> 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] [oslo] Common RPC Message Trace Mechanism

[Xuanzhou Perry Dong]

Hi,

I am looking for a common RPC message trace mechanism in oslo_messaging. This 
message trace mechanism needs to be common to all drivers. Currently some 
documentation mentions that oslo_messaging_amqp.trace can activate the message 
trace (say, 
http://docs.openstack.org/liberty/config-reference/content/networking-configuring-rpc.html).
 But it seems that this oslo_messaging_amqp.trace is only available to the 
Proton driver.

Do I miss any existing common RPC message trace mechanism in oslo? If there is 
no such mechanism, I would propose to create such a mechanism for oslo.

Any response is appreciated.
Thanks.
Best Regards,
Xuanzhou Perry Dong
__
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] [Manila] Concurrent execution of drivers

[Ben Swartzlander]

On 03/04/2016 08:15 AM, John Spray wrote:

On Fri, Mar 4, 2016 at 12:11 PM, Shinobu Kinjo  wrote:

What are you facing?


In this particular instance, I'm dealing with a case where we may add
some metadata in ceph that will get updated by the driver, and I need
to know how I'm going to be called.  I need to know whether e.g. I can
expect that ensure_share will only be called once at a time per share,
or whether it might be called multiple times in parallel, resulting in
a need for me to do more synchronisation a lower level.

This is more complicated than locking, because where we update more
than one thing at a time we also have to deal with recovery (e.g.
manila crashed halfway through updating something in ceph and now I'm
recovering it), especially whether the places we do recovery will be
called concurrently or not.

My very favourite answer here would be a pointer to some
documentation, but I'm guessing much this stuff is still at a "word of
mouth" stage.


Concurrency is the area where most of our problems are coming from. 
There was a time, I believe, when concurrency issues were largely taken 
care of, but that was before we forked Manila from Cinder and before 
Cinder forked from Nova. Over time, lack of test coverage has allowed 
race conditions to creep in, and architectural decisions have been made 
that failed to account for HA (highly available) deployments, where 
multiple services might be managing the very same backends. The Cinder 
team has been working on fixing these issues and we need to catch up.


As I start to turn my attention from wrapping up Mitaka to thinking 
about Newton, concurrency is the most urgent focus area I can see. Much 
of our gate stability problems are likely due to concurrency issues. 
This can be easily verified by changing the concurrency value to 1 when 
running tempest and noting that it runs flawlessly every time, yet when 
it's set to >1 we have occasional failures.


-Ben



John


On Fri, Mar 4, 2016 at 9:06 PM, John Spray  wrote:

Hi,

What expectations should driver authors have about multiple instances
of the driver being instantiated within different instances of
manila-share?

For example, should I assume that when one instance of a driver is
having ensure_share called during startup, another instance of the
driver might be going through the same process on the same share at
the same time?  Are there any rules at all?

Thanks,
John

__
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




--
Email:
shin...@linux.com
GitHub:
shinobu-x
Blog:
Life with Distributed Computational System based on OpenSource

__
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] [Manila] nfs-over-vsock (was: Concurrent execution of drivers)

[Ben Swartzlander]

On 03/05/2016 05:34 AM, Shinobu Kinjo wrote:

Are we still going to think of nfs-over-vsock?
Never mind. It's just coming from my curiosity.


A lot of work outside Manila has to happen before we can actually 
deliver that feature in OpenStack. If you google about nfs over vsock 
you can learn about the current state of things. It's going to be a 
while before nfs over vsock is implemented and it's going to even longer 
before that support is shipping on plaforms where people run OpenStack. 
I'm very optimistic, but we need to be patient.


-Ben



Cheers,
S

On Fri, Mar 4, 2016 at 11:08 PM, Valeriy Ponomaryov
 wrote:

Thanks - so if I understand you correctly, each share instance is
uniquely associated with a single instance of the driver at one time,
right?  So while I might have two concurrent calls to ensure_share,
they are guaranteed to be for different shares?


Yes.


Is this true for the whole driver interface?


Yes.



Two instances of the
driver will never both be asked to do operations on the same share at
the same time?



Yes.

Each instance of a driver will have its own unique list of shares to be
'ensure'd.

--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.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 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][vote] Proposing Alicja Kwasniewska for core reviewer

[Jeffrey Zhang]

+1 nice job!

On Sun, Mar 6, 2016 at 8:57 PM, Ryan Hallisey  wrote:

> +1 Nice Job Alicja!
>
> -Ryan
>
> - Original Message -
> From: "Eric LEMOINE" 
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Sent: Friday, March 4, 2016 5:04:10 PM
> Subject: Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska
> for core reviewer
>
>
>
> +1
>
> Looking forward to more collaboration on Diagnostics and other stuff :)
>
>
> Le 4 mars 2016 17:58, "Steven Dake (stdake)" < std...@cisco.com > a écrit
> :
> >
> > Core Reviewers,
> >
> > Alicja has been instrumental in our work around jinja2 docker file
> creation, removing our symlink madness. She has also been instrumental in
> actually getting Diagnostics implemented in a sanitary fashion. She has
> also done a bunch of other work that folks in the community already know
> about that I won't repeat here.
> >
> > I had always hoped she would start reviewing so we could invite her to
> the core review team, and over the last several months she has reviewed
> quite a bit! Her 90 day stats[1] place her at #9 with a solid ratio of 72%.
> Her 30 day stats[2] are even better and place her at #6 with an improving
> ratio of 67%. She also just doesn't rubber stamp reviews or jump in reviews
> at the end; she sticks with them from beginning to end and finds real
> problems, not trivial things. Finally Alicja is full time on Kolla as
> funded by her employer so she will be around for the long haul and always
> available.
> >
> > Please consider my proposal to be a +1 vote.
> >
> > To be approved for the core reviewer team, Alicja requires a majority
> vote of 6 total votes with no veto within the one week period beginning now
> and ending Friday March 11th. If your on the fence, you can always abstain.
> If the vote is unanimous before the voting ends, I will make appropriate
> changes to gerrit's acls. If their is a veto vote, voting will close prior
> to March 11th.
> >
> > Regards,
> > -steve
> >
> > [1] http://stackalytics.com/report/contribution/kolla-group/90
> > [2] http://stackalytics.com/report/contribution/kolla-group/30
> >
> >
> __
> > 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
>



-- 
Jeffrey Zhang
Blog: http://xcodest.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] [nova] Non-Admin user can show deleted instances using changes-since parameter when calling list API

[Zhenyu Zheng]

Thanks a lot for the reply.

I have already registered a BP for this, and will submit a spec for N, we
can discuss the details in the spec then.



On Sun, Mar 6, 2016 at 2:01 AM, Matt Riedemann 
wrote:

>
>
> On 3/5/2016 9:48 AM, Adam Young wrote:
>
>> On 03/05/2016 12:27 AM, Chris Friesen wrote:
>>
>>> On 03/04/2016 03:42 PM, Matt Riedemann wrote:
>>>


 On 3/3/2016 9:14 PM, Zhenyu Zheng wrote:

> Hm, I found out the reason:
>
> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L1139-L1145
>
>
> here we filtered out parameters like "deleted", and that's why the API
> behavior is like above mentioned.
>
> So should we simple add "deleted" to the tuple or a microversion is
> needed?
>

>>> Nice find. This is basically the same as the ip6 case which required
 microversion 2.5 [1]. So I think this is going to require a
 microversion in
 Newton to fix it (which means a blueprint and a spec since it's an
 API change).
 But it's pretty trivial, the paperwork is the majority of the work.

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

>>>
>>> Does it really need a spec given that microversions are documented in
>>> the codebase?
>>>
>>> That almost seems like paperwork for the sake of following the rules
>>> rather than to serve any useful purpose.
>>>
>>> Is anyone really going to argue about the details?
>>>
>>>
>> I've been lurking on this discussion. I was worried that you were going
>> to try to hard code "admin" somewhere in here.
>>
>> If the only change is that the currently accepted set of params is
>> enforced with the current set of policy rules, just in a slightly
>> different place, it will not break people, and thus I would think no
>> microversion is essential.  However, if the the user might need to test
>> which way policy is enforced in order to use the right code path when
>> doing a client call, then a microversion would be needed.
>>
>>
>>
>> Chris
>>>
>>>
>>>
>>> __
>>>
>>> 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
>>
>>
> The ip6 case and microversion 2.5 is exactly the same scenario and sets
> precedent here, so yes we need a microversion which makes it an API change
> which according to our policy requires a spec. I realize it's trivial, but
> them's the rules.
>
> As far as I can tell, this is latent behavior since forever and no one has
> freaked out about it before, so I don't think doing things by the book and
> doing that in Newton is going to cause any problems.
>
> --
>
> 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
>
__
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] Proposal: changes to our current testing process

[John Griffith]

On Sat, Mar 5, 2016 at 4:27 PM, Jay S. Bryant  wrote:

> Ivan,
>
> I agree that our testing needs improvement.  Thanks for starting this
> thread.
>
> With regards to adding a hacking check for tests that run too long ... are
> you thinking that we would have a timer that checks or long running jobs or
> something that checks for long sleeps in the testing code?  Just curious
> your ideas for tackling that situation.  Would be interested in helping
> with that, perhaps.
>
> Thanks!
> Jay
>
>
> On 03/02/2016 05:25 AM, Ivan Kolodyazhny wrote:
>
> Hi Team,
>
> Here are my thoughts and proposals how to make Cinder testing process
> better. I won't cover "3rd party CI's" topic here. I will share my opinion
> about current and feature jobs.
>
>
> Unit-tests
>
>- Long-running tests. I hope, everybody will agree that unit-tests
>must be quite simple and very fast. Unit tests which takes more than 3-5
>seconds should be refactored and/or moved to 'integration' tests.
>Thanks to Tom Barron for several fixes like [1]. IMO, we it would be
>good to have some hacking checks to prevent such issues in a future.
>
>- Tests coverage. We don't check it in an automatic way on gates.
>Usually, we require to add some unit-tests during code review process. Why
>can't we add coverage job to our CI and do not merge new patches, with
>will decrease tests coverage rate? Maybe, such job could be voting in a
>future to not ignore it. For now, there is not simple way to check coverage
>because 'tox -e cover' output is not useful [2].
>
>
> Functional tests for Cinder
>
> We introduced some functional tests last month [3]. Here is a patch to
> infra to add new job [4]. Because these tests were moved from unit-tests, I
> think we're OK to make this job voting. Such tests should not be a
> replacement for Tempest. They even could tests Cinder with Fake Driver to
> make it faster and not related on storage backends issues.
>
>
> Tempest in-tree tests
>
> Sean started work on it [5] and I think it's a good idea to get them in
> Cinder repo to run them on Tempest jobs and 3-rd party CIs against a real
> backend.
>
>
> Functional tests for python-brick-cinderclient-ext
>
> There are patches that introduces functional tests [6] and new job [7].
>
>
> Functional tests for python-cinderclient
>
> We've got a very limited set of such tests and non-voting job. IMO, we can
> run them even with Cinder Fake Driver to make them not depended on a
> storage backend and make it faster. I believe, we can make this job voting
> soon. Also, we need more contributors to this kind of tests.
>
>
> Integrated tests for python-cinderclient
>
> We need such tests to make sure that we won't break Nova, Heat or other
> python-cinderclient consumers with a next merged patch. There is a thread
> in openstack-dev ML about such tests [8] and proposal [9] to introduce them
> to python-cinderclient.
>
>
> Rally tests
>
> IMO, it would be good to have new Rally scenarios for every patches like
> 'improves performance', 'fixes concurrency issues', etc. Even if we as a
> Cinder community don't have enough time to implement them, we have to ask
> for them in reviews, openstack-dev ML, file Rally bugs and blueprints if
> needed.
>
>
> [1] https://review.openstack.org/#/c/282861/
> [2] http://paste.openstack.org/show/488925/
> [3] https://review.openstack.org/#/c/267801/
> [4] https://review.openstack.org/#/c/287115/
> [5] https://review.openstack.org/#/c/274471/
> [6] https://review.openstack.org/#/c/265811/
> [7] https://review.openstack.org/#/c/265925/
> [8]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088027.html
> [9] https://review.openstack.org/#/c/279432/
>
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
> ​We could just parse out the tox slowest tests output we already have.  Do
something like pylint where we look at existing/current slowest test and
balk if that's exceeded.

Thoughts?

John​
__
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] [docs] Octavia configuration options were deleted but needed for Mitaka

[Lana Brindley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Michael,

Thanks for this. I'm looking into it now and will get back to you on next steps.

Lana

On 04/03/16 05:57, Michael Johnson wrote:
> This is in reference to bug:
> 
> https://bugs.launchpad.net/openstack-manuals/+bug/1552797
> 
> The liberty documentation set has the octavia.conf section:
> http://docs.openstack.org/liberty/config-reference/content/networking-plugin-lbaas.html
> 
> The current Mitaka documentation does not have an octavia.conf section:
> http://docs.openstack.org/draft/config-reference/networking/networking_options_reference.html
> 
> It appears that the octavia.conf settings documentation was deleted
> from the Mitaka docs here:
> https://review.openstack.org/#/c/259889
> 
> It has been pointed out that this was due to this e-mail chain:
> http://lists.openstack.org/pipermail/openstack-docs/2015-December/008026.html
> 
> That said, Octavia is the reference driver implementation for
> neutron-lbaas and it is important that we continue to provide
> documentation for users of neutron-lbaas.  Armando is asking us to
> update this documentation for the Mitaka release, but we are unable to
> do so.
> 
> Can someone help me with instructions on what I need to do to restore
> this documentation for the Mitaka release?
> 
> I am not familiar with the xml->rst changes that have occurred so I
> need some help.
> 
> In the docs channel and on the bug I have had advice to use pandoc to
> convert the liberty xml to rst and check it in.  This does not seem
> right as the other files say they are auto-generated.
> 
> I'm just looking for a way to get this restored so we can update them
> for the Mitaka release.
> 
> Thanks,
> Michael
> 
> __
> 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
> 

- -- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJW3NUDAAoJELppzVb4+KUy46gIAIo9DTgXYv912tPxdL/d3Bwq
cfeYvr3Q0YRjD+HSX3AUuydtT8+awBTiPBeymkNqGuaeL4vkf+VgjifyoNrAnhoM
RBK8pk4QwajIqT/cr12jRxuATRGTfgWwB0KA8pSXax5t3QtTcesS4c0Vafx+TDNV
yrMaaeMLz8G7M3+DzxIXVObXUgABanRPH5H3IbKCW+KJ/I1cWZOGfk6A4mvkLENY
9yuKGnuLEG3gck1660QSGHMLK+bIglCZ2yJm9PScGqLnCx8oiuJmSGhQerPJ3c2W
phIMnw00URgJY9THPCyKdtNI6mOdvMYzfMj0y9rxANvp0Gzr5S3ztf40xyvh6wY=
=EgmZ
-END PGP SIGNATURE-

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

Re: [openstack-dev] [OpenStack-docs] Fwd: [Neutron][LBaaS][Octavia][Docs] Need experienced contributor documentation best-practices and how-tos

[Lana Brindley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

(Snipping throughout)

On 04/03/16 15:39, Stephen Balukoff wrote:
> Hello Lana!
> 
> Thank you for your prompt reply--  I found it extremely helpful!  Comments
> inline:
> 



>>> Anyway, so then I went to try to figure out how I get this auto-generated
>>> output updated, and haven't found much (ha!) documented on the process...
>>> when I sought help from Sam-I-Am, I was told that these essentially get
>>> generated once per release by "somebody." So...  I'm done, right?
>>
>> That 'somebody', to be more specific, is the speciality team in charge of
>> the book in question. We also do a full refresh of the scripts before each
>> release.
>>
>>
> Cool! Is that process documented anywhere? Or better yet, is there a way
> for developers to do a "check experimental" or similar operation on any
> given patch so we can see what the manual will look like after our API /
> CLI updates (presumably in said patch)?
> 

To be honest, this is seriously underdocumented, and we're well aware of that. 
I do know that a few people are working on rectifying that situation, and I 
believe that Brian Moss will have a patch up soon to add some more info to the 
Contributor's Guide. Docs infra (like so much other infra) has been built up 
over time, and it's a big beast to untangle and document. 

I'm not aware of a tool to check for automated docs updates, though, sorry.



>> Depending on the feature and project in question, I would usually
>> recommend you add it to the appropriate documentation in your project repo.
>> These are then published to
>> http://docs.openstack.org/developer/[yourproject] and are considered
>> official OpenStack documentation.
>>
>> If you want it added to the broader OpenStack documentation (the top level
>> on the docs.openstack.org), then I suggest you open a bug, wait for a
>> docs person to triage it (we can help advise on book/chapter, etc), and
>> then create a patch against the book in the same way as you do for your
>> project. If you don't want to write it yourself, that's fine. Open the bug,
>> give as much detail as you can, and we'll take it from there.
>>
>>
> Aah--  so I knew that the Octavia documentation we've committed thus far
> showed up that way but I'd been given the impression that we were doing the
> wrong thing: That it was generally not considered a good thing to have your
> documentation live in your own custom non-openstack-manual space and that
> you should instead work to get all of it moved into the openstack manual.

Not at all, docs.openstack.org/developer is considered official, and is 
absolutely the right place for developer documentation :)

> 
> In any case it's good to know about how you prefer people contribute
> changes to the manual: I expected y'all to want full editorial control over
> everything the goes into the manual, but I didn't know you'd just go write
> excerpts yourself on features that developers add and then open
> documentation bug reports for. That sounds like a lot of work for you!
> 

It's what tech writers do :P




>>
>> There's not a lot of content here to share. You commit docs in exactly the
>> same way as you commit code. If you already have the skills to commit code
>> to an OpenStack project, then you know everything you need to know to
>> commit to docs.
>>
> 
> ...except for the stuff that's in there right now that's auto-generated. :)
> I wonder if there's a better way to communicate that developers generally
> won't have to worry about updating API / CLI references manually as this is
> all auto-generated... other than having been here long enough to know
> that's the case. (FWIW, I dislike relying on tribal knowledge...)
> 

This is mentioned explicitly in the Contributor Guide: 
http://docs.openstack.org/contributor-guide/docs-builds.html I do acknowledge, 
though, that we don't go into detail on how the automation works. The best we 
really have at the moment is this: 
http://git.openstack.org/cgit/openstack/openstack-doc-tools/tree/autogenerate_config_docs/README.rst
 which isn't a great solution. As I mentioned earlier, we're working on it. 
Happy to take suggestions on where you think we should have more content around 
this.




> 
> Aah-- you're right that a good portion of this is already documented there.
> Sorry-- I looked through the guide but didn't see what I was after in a lot
> of it.
> 
> I guess the piece that was missing for me here was an opinionated guideline
> on where documentation should go that is not necessarily appropriate for
> the general openstack manual. You already told me above it should go in
> project-specific documentation repositories, but perhaps it would be
> helpful to mention something about that in this contributor guide? More on
> this later...
> 

I agree that this probably isn't explicit in the Contributor Guide. I'll go 
ahead and do something about that this week.

It is mentioned in the Infra Guide here: 

Re: [openstack-dev] [nova] Do we need a microversion to return a 501 from GET os-virtual-interfaces?

[Jay Pipes]

On 03/06/2016 02:21 PM, Matt Riedemann wrote:

Thanks, good point. I think 400 would be best here. And according to our
handy-dandy docs [1] it should be OK to do this without a microversion.


Yup, 400 is correct and yes, you should not need a new microversion 
addition to the API.


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] [Neutron][tempest] Timestamp service extension breaks CI

[Kevin Benton]

Keep in mind that fix for ML2 is the correct behavior, not a workaround. It
was not including extension data in create calls so there was an API
difference between a create and a get/update of the same object. It's now
calling the extensions to let them populate their fields of the dict.

If you're plugin does not exhibit the correct behavior in this case, I
would just disable the test in question because it sounds like a bug in the
plugin, not the test. It's reasonable to expect the timestamps that will be
visible on every other API call to also be visible in create calls.
Hi,
Gal Sagie pointed me to patch in ML2 and OVN that address this by
re-reading the networks and ports to ensure that the information is read.
For those interested and whom it affects please see:
ML2 - https://review.openstack.org/#/c/276219/
*OVN - https://review.openstack.org/#/c/277844/
*

Thanks
Gary

From: Gary Kotton 
Reply-To: OpenStack List 
Date: Sunday, March 6, 2016 at 4:04 PM
To: OpenStack List 
Subject: [openstack-dev] [Neutron][tempest] Timestamp service extension
breaks CI

Hi,
The commit
https://review.openstack.org/#q,4c2c983618ddb7a528c9005b0d7aaf5322bd198d,n,z
causes
the CI to fail. This is due to the fact that the port creation does not
return the created_at and updated_at keys. The tempest test that the keys
are the same. Please see [I]
I posted patch https://review.openstack.org/289017 to address this. I am
not sure if this is the correct way to go.
There are far too many API changes that should not be breaking things at
this very stage in the cycle.
Thanks
Gary

[I]

ft29.11: 
tempest.api.network.test_ports.PortsTestJSON.test_show_port[id-c9a685bd-e83f-499c-939f-9f7863ca259f,smoke]_StringException:
Empty attachments:
  stderr
  stdout

pythonlogging:'': {{{
2016-03-06 01:05:00,301 27371 INFO
[tempest.lib.common.rest_client] Request
(PortsTestJSON:test_show_port): 200 GET
http://192.168.254.234:9696/v2.0/ports/f00d5dcc-4143-4f63-8c7c-0ea8d566c87b
0.245s
2016-03-06 01:05:00,302 27371 DEBUG
[tempest.lib.common.rest_client] Request - Headers: {'Content-Type':
'application/json', 'Accept': 'application/json', 'X-Auth-Token':
''}
Body: None
Response - Headers: {'status': '200', 'content-length': '532',
'content-location':
'http://192.168.254.234:9696/v2.0/ports/f00d5dcc-4143-4f63-8c7c-0ea8d566c87b',
'connection': 'close', 'date': 'Sun, 06 Mar 2016 09:05:00 GMT',
'content-type': 'application/json; charset=UTF-8',
'x-openstack-request-id': 'req-2825ed72-1417-4cf9-b37f-4894fa5b0b0f'}
Body: {"port": {"status": "ACTIVE", "description": "",
"allowed_address_pairs": [], "admin_state_up": true, "network_id":
"4545014d-1e11-4b73-a5e3-bcdcd992478e", "name": "", "created_at":
"2016-03-06T09:01:56", "mac_address": "fa:16:3e:08:a4:90",
"updated_at": "2016-03-06T09:01:56", "vnic_index": null,
"device_owner": "", "tenant_id": "e66f0c1efb664b05b34afc3d51903a1e",
"port_security_enabled": true, "binding:vnic_type": "normal",
"fixed_ips": [], "id": "f00d5dcc-4143-4f63-8c7c-0ea8d566c87b",
"security_groups": [], "device_id": ""}}
}}}

Traceback (most recent call last):
  File "/opt/stack/tempest/tempest/api/network/test_ports.py", line
139, in test_show_port
(port, excluded_keys=['extra_dhcp_opts']))
  File 
"/opt/stack/tempest/.venv/local/lib/python2.7/site-packages/testtools/testcase.py",
line 447, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: Only in expected:
  {'created_at': 2016-03-06T09:01:56, 'updated_at': 2016-03-06T09:01:56}


__
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] Do we need a microversion to return a 501 from GET os-virtual-interfaces?

[Matt Riedemann]

On 3/6/2016 12:47 PM, Chris Dent wrote:

On Sat, 5 Mar 2016, Matt Riedemann wrote:


A GET request from the os-virtual-interfaces API returns a 500 today
if neutron is the networking backend.

It would be more accurate to return a 501, but do we need a
microversion for that?


Keep this in mind:
http://specs.openstack.org/openstack/api-wg/guidelines/http.html#use-of-501-not-implemented


501 isn't something api code should be intentionally generating.

400 or 404 is probably what you want.



__
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



Thanks, good point. I think 400 would be best here. And according to our 
handy-dandy docs [1] it should be OK to do this without a microversion.


[1] 
http://docs.openstack.org/developer/nova/api_microversion_dev.html#when-do-i-need-a-new-microversion


--

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] [nova] Do we need a microversion to return a 501 from GET os-virtual-interfaces?

[Chris Dent]

On Sat, 5 Mar 2016, Matt Riedemann wrote:

A GET request from the os-virtual-interfaces API returns a 500 today if 
neutron is the networking backend.


It would be more accurate to return a 501, but do we need a microversion for 
that?


Keep this in mind:
http://specs.openstack.org/openstack/api-wg/guidelines/http.html#use-of-501-not-implemented

501 isn't something api code should be intentionally generating.

400 or 404 is probably what you want.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://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] [Neutron][tempest] Timestamp service extension breaks CI

[Armando M.]

On 6 March 2016 at 06:04, Gary Kotton  wrote:

> Hi,
> The commit
> https://review.openstack.org/#q,4c2c983618ddb7a528c9005b0d7aaf5322bd198d,n,z 
> causes
> the CI to fail. This is due to the fact that the port creation does not
> return the created_at and updated_at keys. The tempest test that the keys
> are the same. Please see [I]
> I posted patch https://review.openstack.org/289017 to address this. I am
> not sure if this is the correct way to go.
> There are far too many API changes that should not be breaking things at
> this very stage in the cycle.
> Thanks
>
Gary
>

As much as one can be careful, there's always a danger for a fallout,
that's why there's an RC window/feature freeze. I think we totally played
this by the rules, especially if there's no CI alerting us for the failure.

That said, thanks for the notice, we'll get this fixed.


>
> [I]
>
> ft29.11: 
> tempest.api.network.test_ports.PortsTestJSON.test_show_port[id-c9a685bd-e83f-499c-939f-9f7863ca259f,smoke]_StringException:
>  Empty attachments:
>   stderr
>   stdout
>
> pythonlogging:'': {{{
> 2016-03-06 01:05:00,301 27371 INFO [tempest.lib.common.rest_client] 
> Request (PortsTestJSON:test_show_port): 200 GET 
> http://192.168.254.234:9696/v2.0/ports/f00d5dcc-4143-4f63-8c7c-0ea8d566c87b 
> 0.245s
> 2016-03-06 01:05:00,302 27371 DEBUG[tempest.lib.common.rest_client] 
> Request - Headers: {'Content-Type': 'application/json', 'Accept': 
> 'application/json', 'X-Auth-Token': ''}
> Body: None
> Response - Headers: {'status': '200', 'content-length': '532', 
> 'content-location': 
> 'http://192.168.254.234:9696/v2.0/ports/f00d5dcc-4143-4f63-8c7c-0ea8d566c87b',
>  'connection': 'close', 'date': 'Sun, 06 Mar 2016 09:05:00 GMT', 
> 'content-type': 'application/json; charset=UTF-8', 'x-openstack-request-id': 
> 'req-2825ed72-1417-4cf9-b37f-4894fa5b0b0f'}
> Body: {"port": {"status": "ACTIVE", "description": "", 
> "allowed_address_pairs": [], "admin_state_up": true, "network_id": 
> "4545014d-1e11-4b73-a5e3-bcdcd992478e", "name": "", "created_at": 
> "2016-03-06T09:01:56", "mac_address": "fa:16:3e:08:a4:90", "updated_at": 
> "2016-03-06T09:01:56", "vnic_index": null, "device_owner": "", "tenant_id": 
> "e66f0c1efb664b05b34afc3d51903a1e", "port_security_enabled": true, 
> "binding:vnic_type": "normal", "fixed_ips": [], "id": 
> "f00d5dcc-4143-4f63-8c7c-0ea8d566c87b", "security_groups": [], "device_id": 
> ""}}
> }}}
>
> Traceback (most recent call last):
>   File "/opt/stack/tempest/tempest/api/network/test_ports.py", line 139, in 
> test_show_port
> (port, excluded_keys=['extra_dhcp_opts']))
>   File 
> "/opt/stack/tempest/.venv/local/lib/python2.7/site-packages/testtools/testcase.py",
>  line 447, in assertThat
> raise mismatch_error
> testtools.matchers._impl.MismatchError: Only in expected:
>   {'created_at': 2016-03-06T09:01:56, 'updated_at': 2016-03-06T09:01:56}
>
>
> __
> 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] Do we need a microversion to return a 501 from GET os-virtual-interfaces?

[Matt Riedemann]

On 3/5/2016 8:51 PM, Matt Riedemann wrote:

A GET request from the os-virtual-interfaces API returns a 500 today if
neutron is the networking backend.

It would be more accurate to return a 501, but do we need a microversion
for that?

I intend on implementing the method for the neutronv2 API in nova [1]
but it will require a microversion and until then, I was thinking it
should return a 501 rather than a 500 but don't want to go through the
paperwork if that requires a microversion.

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



Furthermore, I'd hope that a microversion isn't needed to return a 501 
rather than a 500. That's because then we could backport that change to 
the stable branches and change the skip on the tempest test [1] to 
expect a result or a 501. Then we can also test the microversion change 
that returns a result in the case of Neutron (and fail if a 501 is 
returned after the microversion).


[1] 
https://github.com/openstack/tempest/blob/db9672e3473cd6046f269d63435e102a477d8cdd/tempest/api/compute/servers/test_virtual_interfaces.py#L45


--

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] [tripleo] CI jobs failures

[James Slagle]

On Sat, Mar 5, 2016 at 11:15 AM, Emilien Macchi  wrote:
> I'm kind of hijacking Dan's e-mail but I would like to propose some
> technical improvements to stop having so much CI failures.
>
>
> 1/ Stop creating swap files. We don't have SSD, this is IMHO a terrible
> mistake to swap on files because we don't have enough RAM. In my
> experience, swaping on non-SSD disks is even worst that not having
> enough RAM. We should stop doing that I think.

We have been relying on swap in tripleo-ci for a little while. While
not ideal, it has been an effective way to at least be able to test
what we've been testing given the amount of physical RAM that is
available.

The recent change to add swap to the overcloud nodes has proved to be
unstable. But that has more to do with it being racey with the
validation deployment afaict. There are some patches currently up to
address those issues.

>
>
> 2/ Split CI jobs in scenarios.
>
> Currently we have CI jobs for ceph, HA, non-ha, containers and the
> current situation is that jobs fail randomly, due to performances issues.
>
> Puppet OpenStack CI had the same issue where we had one integration job
> and we never stopped adding more services until all becomes *very*
> unstable. We solved that issue by splitting the jobs and creating scenarios:
>
> https://github.com/openstack/puppet-openstack-integration#description
>
> What I propose is to split TripleO jobs in more jobs, but with less
> services.
>
> The benefit of that:
>
> * more services coverage
> * jobs will run faster
> * less random issues due to bad performances
>
> The cost is of course it will consume more resources.
> That's why I suggest 3/.
>
> We could have:
>
> * HA job with ceph and a full compute scenario (glance, nova, cinder,
> ceilometer, aodh & gnocchi).
> * Same with IPv6 & SSL.
> * HA job without ceph and full compute scenario too
> * HA job without ceph and basic compute (glance and nova), with extra
> services like Trove, Sahara, etc.
> * ...
> (note: all jobs would have network isolation, which is to me a
> requirement when testing an installer like TripleO).

Each of those jobs would at least require as much memory as our
current HA job. I don't see how this gets us to using less memory. The
HA job we have now already deploys the minimal amount of services that
is possible given our current architecture. Without the composable
service roles work, we can't deploy less services than we already are.



>
> 3/ Drop non-ha job.
> I'm not sure why we have it, and the benefit of testing that comparing
> to HA.

In my opinion, I actually think that we could drop the ceph and non-ha
job from the check-tripleo queue.

non-ha doesn't test anything realistic, and it doesn't really provide
any faster feedback on patches. It seems at most it might run 15-20
minutes faster than the HA job on average. Sometimes it even runs
slower than the HA job.

The ceph job we could move to the experimental queue to run on demand
on patches that might affect ceph, and it could also be a daily
periodic job.

The same could be done for the containers job, an IPv6 job, and an
upgrades job. Ideally with a way to run an individual job as needed.
Would we need different experimental queues to do that?

That would leave only the HA job in the check queue, which we should
run with SSL and network isolation. We could deploy less testenv's
since we'd have less jobs running, but give the ones we do deploy more
RAM. I think this would really alleviate a lot of the transient
intermittent failures we get in CI currently. It would also likely run
faster.

It's probably worth seeking out some exact evidence from the RDO
centos-ci, because I think they are testing with virtual environments
that have a lot more RAM than tripleo-ci does. It'd be good to
understand if they have some of the transient failures that tripleo-ci
does as well.

We really are deploying on the absolute minimum cpu/ram requirements
that is even possible. I think it's unrealistic to expect a lot of
stability in that scenario. And I think that's a big reason why we get
so many transient failures.

In summary: give the testenv's more ram, have one job in the
check-tripleo queue, as many jobs as needed in the experimental queue,
and as many periodic jobs as necessary.


>
>
> Any comment / feedback is welcome,
> --
> 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
>



-- 
-- James Slagle
--

__
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][tempest] Timestamp service extension breaks CI

[Gary Kotton]

Hi,
Gal Sagie pointed me to patch in ML2 and OVN that address this by re-reading 
the networks and ports to ensure that the information is read.
For those interested and whom it affects please see:
ML2 - https://review.openstack.org/#/c/276219/
OVN - https://review.openstack.org/#/c/277844/

Thanks
Gary

From: Gary Kotton >
Reply-To: OpenStack List 
>
Date: Sunday, March 6, 2016 at 4:04 PM
To: OpenStack List 
>
Subject: [openstack-dev] [Neutron][tempest] Timestamp service extension breaks 
CI

Hi,
The commit 
https://review.openstack.org/#q,4c2c983618ddb7a528c9005b0d7aaf5322bd198d,n,z 
causes the CI to fail. This is due to the fact that the port creation does not 
return the created_at and updated_at keys. The tempest test that the keys are 
the same. Please see [I]
I posted patch https://review.openstack.org/289017 to address this. I am not 
sure if this is the correct way to go.
There are far too many API changes that should not be breaking things at this 
very stage in the cycle.
Thanks
Gary

[I]

ft29.11: 
tempest.api.network.test_ports.PortsTestJSON.test_show_port[id-c9a685bd-e83f-499c-939f-9f7863ca259f,smoke]_StringException:
 Empty attachments:
  stderr
  stdout

pythonlogging:'': {{{
2016-03-06 01:05:00,301 27371 INFO [tempest.lib.common.rest_client] Request 
(PortsTestJSON:test_show_port): 200 GET 
http://192.168.254.234:9696/v2.0/ports/f00d5dcc-4143-4f63-8c7c-0ea8d566c87b 
0.245s
2016-03-06 01:05:00,302 27371 DEBUG[tempest.lib.common.rest_client] Request 
- Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 
'X-Auth-Token': ''}
Body: None
Response - Headers: {'status': '200', 'content-length': '532', 
'content-location': 
'http://192.168.254.234:9696/v2.0/ports/f00d5dcc-4143-4f63-8c7c-0ea8d566c87b', 
'connection': 'close', 'date': 'Sun, 06 Mar 2016 09:05:00 GMT', 'content-type': 
'application/json; charset=UTF-8', 'x-openstack-request-id': 
'req-2825ed72-1417-4cf9-b37f-4894fa5b0b0f'}
Body: {"port": {"status": "ACTIVE", "description": "", 
"allowed_address_pairs": [], "admin_state_up": true, "network_id": 
"4545014d-1e11-4b73-a5e3-bcdcd992478e", "name": "", "created_at": 
"2016-03-06T09:01:56", "mac_address": "fa:16:3e:08:a4:90", "updated_at": 
"2016-03-06T09:01:56", "vnic_index": null, "device_owner": "", "tenant_id": 
"e66f0c1efb664b05b34afc3d51903a1e", "port_security_enabled": true, 
"binding:vnic_type": "normal", "fixed_ips": [], "id": 
"f00d5dcc-4143-4f63-8c7c-0ea8d566c87b", "security_groups": [], "device_id": ""}}
}}}

Traceback (most recent call last):
  File "/opt/stack/tempest/tempest/api/network/test_ports.py", line 139, in 
test_show_port
(port, excluded_keys=['extra_dhcp_opts']))
  File 
"/opt/stack/tempest/.venv/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 447, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: Only in expected:
  {'created_at': 2016-03-06T09:01:56, 'updated_at': 2016-03-06T09:01:56}

__
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][tempest] Timestamp service extension breaks CI

[Gary Kotton]

Hi,
The commit 
https://review.openstack.org/#q,4c2c983618ddb7a528c9005b0d7aaf5322bd198d,n,z 
causes the CI to fail. This is due to the fact that the port creation does not 
return the created_at and updated_at keys. The tempest test that the keys are 
the same. Please see [I]
I posted patch https://review.openstack.org/289017 to address this. I am not 
sure if this is the correct way to go.
There are far too many API changes that should not be breaking things at this 
very stage in the cycle.
Thanks
Gary

[I]

ft29.11: 
tempest.api.network.test_ports.PortsTestJSON.test_show_port[id-c9a685bd-e83f-499c-939f-9f7863ca259f,smoke]_StringException:
 Empty attachments:
  stderr
  stdout

pythonlogging:'': {{{
2016-03-06 01:05:00,301 27371 INFO [tempest.lib.common.rest_client] Request 
(PortsTestJSON:test_show_port): 200 GET 
http://192.168.254.234:9696/v2.0/ports/f00d5dcc-4143-4f63-8c7c-0ea8d566c87b 
0.245s
2016-03-06 01:05:00,302 27371 DEBUG[tempest.lib.common.rest_client] Request 
- Headers: {'Content-Type': 'application/json', 'Accept': 'application/json', 
'X-Auth-Token': ''}
Body: None
Response - Headers: {'status': '200', 'content-length': '532', 
'content-location': 
'http://192.168.254.234:9696/v2.0/ports/f00d5dcc-4143-4f63-8c7c-0ea8d566c87b', 
'connection': 'close', 'date': 'Sun, 06 Mar 2016 09:05:00 GMT', 'content-type': 
'application/json; charset=UTF-8', 'x-openstack-request-id': 
'req-2825ed72-1417-4cf9-b37f-4894fa5b0b0f'}
Body: {"port": {"status": "ACTIVE", "description": "", 
"allowed_address_pairs": [], "admin_state_up": true, "network_id": 
"4545014d-1e11-4b73-a5e3-bcdcd992478e", "name": "", "created_at": 
"2016-03-06T09:01:56", "mac_address": "fa:16:3e:08:a4:90", "updated_at": 
"2016-03-06T09:01:56", "vnic_index": null, "device_owner": "", "tenant_id": 
"e66f0c1efb664b05b34afc3d51903a1e", "port_security_enabled": true, 
"binding:vnic_type": "normal", "fixed_ips": [], "id": 
"f00d5dcc-4143-4f63-8c7c-0ea8d566c87b", "security_groups": [], "device_id": ""}}
}}}

Traceback (most recent call last):
  File "/opt/stack/tempest/tempest/api/network/test_ports.py", line 139, in 
test_show_port
(port, excluded_keys=['extra_dhcp_opts']))
  File 
"/opt/stack/tempest/.venv/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 447, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: Only in expected:
  {'created_at': 2016-03-06T09:01:56, 'updated_at': 2016-03-06T09:01:56}

__
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][LBaaS]Removing LBaaS v1 - are weready?

[Samuel Bercovici]

As for a migration tool.
Due to model changes and deployment changes between LBaaS v1 and LBaaS v2, I am 
in favor for the following process:

1. Download LBaaS v1 information (Tenants, Flavors, VIPs, Pools, Health 
Monitors , Members) into some JSON format file(s)
2. Delete LBaaS v1 
3. Uninstall LBaaS v1
4. Install LBaaS v2
5. Import the data from 1 back over LBaaS v2 (need to allow moving from 
falvor1-->flavor2, need to make room to some custom modification for mapping 
between v1 and v2 models)

What do you think?

-Sam.




-Original Message-
From: Fox, Kevin M [mailto:kevin@pnnl.gov] 
Sent: Friday, March 04, 2016 2:06 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Ok. Thanks for the info.

Kevin

From: Brandon Logan [brandon.lo...@rackspace.com]
Sent: Thursday, March 03, 2016 2:42 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?

Just for clarity, V2 did not reuse tables, all the tables it uses are only for 
it.  The main problem is that v1 and v2 both have a pools resource, but v1 and 
v2's pool resource have different attributes.  With the way neutron wsgi works, 
if both v1 and v2 are enabled, it will combine both sets of attributes into the 
same validation schema.

The other problem with v1 and v2 running together was only occurring when the 
v1 agent driver and v2 agent driver were both in use at the same time.  This 
may actually have been fixed with some agent updates in neutron, since that is 
common code.  It needs to be tested out though.

Thanks,
Brandon

On Thu, 2016-03-03 at 22:14 +, Fox, Kevin M wrote:
> Just because you had thought no one was using it outside of a PoC doesn't 
> mean folks aren''t using it in production.
>
> We would be happy to migrate to Octavia. We were planning on doing just that 
> by running both v1 with haproxy namespace, and v2 with Octavia and then pick 
> off upgrading lb's one at a time, but the reuse of the v1 tables really was 
> an unfortunate decision that blocked that activity.
>
> We're still trying to figure out a path forward.
>
> We have an outage window next month. after that, it could be about 6 
> months before we could try a migration due to production load picking 
> up for a while. I may just have to burn out all the lb's switch to v2, 
> then rebuild them by hand in a marathon outage :/
>
> And then there's this thingy that also critically needs fixing:
> https://bugs.launchpad.net/neutron/+bug/1457556
>
> Thanks,
> Kevin
> 
> From: Eichberger, German [german.eichber...@hpe.com]
> Sent: Thursday, March 03, 2016 12:47 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
> Kevin,
>
>  If we are offering a migration tool it would be namespace -> 
> namespace (or maybe Octavia since [1]) - given the limitations nobody 
> should be using the namespace driver outside a PoC so I am a bit 
> confused why customers can't self migrate. With 3rd party Lbs I would 
> assume vendors proving those scripts to make sure their particular 
> hardware works with those. If you indeed need a migration from LBaaS 
> V1 namespace -> LBaaS V2 namespace/Octavia please file an RfE with 
> your use case so we can discuss it further...
>
> Thanks,
> German
>
> [1] https://review.openstack.org/#/c/286380
>
> From: "Fox, Kevin M" >
> Reply-To: "OpenStack Development Mailing List (not for usage 
> questions)" 
>  k.org>>
> Date: Wednesday, March 2, 2016 at 5:17 PM
> To: "OpenStack Development Mailing List (not for usage questions)" 
>  k.org>>
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
> no removal without an upgrade path. I've got v1 LB's and there still isn't a 
> migration script to go from v1 to v2.
>
> Thanks,
> Kevin
>
>
> 
> From: Stephen Balukoff 
> [sbaluk...@bluebox.net]
> Sent: Wednesday, March 02, 2016 4:49 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron][LBaaS]Removing LBaaS v1 - are weready?
>
> I am also on-board with removing LBaaS v1 as early as possible in the Newton 
> cycle.
>
> On Wed, Mar 2, 2016 at 9:44 AM, Samuel Bercovici 
> > wrote:
> Thank you all for your response.
>
> In my opinion given that UI/HEAT will make Mitaka and will have one cycle to 
> mature, it makes sense to remove LBaaS v1 in Newton.
> Do we want do discuss an upgrade process in the summit?
>
> -Sam.
>
>
> From: Bryan Jones 

Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for core reviewer

[Ryan Hallisey]

+1 Nice Job Alicja!

-Ryan

- Original Message -
From: "Eric LEMOINE" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, March 4, 2016 5:04:10 PM
Subject: Re: [openstack-dev] [kolla][vote] Proposing Alicja Kwasniewska for 
core reviewer



+1 

Looking forward to more collaboration on Diagnostics and other stuff :) 


Le 4 mars 2016 17:58, "Steven Dake (stdake)" < std...@cisco.com > a écrit : 
> 
> Core Reviewers, 
> 
> Alicja has been instrumental in our work around jinja2 docker file creation, 
> removing our symlink madness. She has also been instrumental in actually 
> getting Diagnostics implemented in a sanitary fashion. She has also done a 
> bunch of other work that folks in the community already know about that I 
> won't repeat here. 
> 
> I had always hoped she would start reviewing so we could invite her to the 
> core review team, and over the last several months she has reviewed quite a 
> bit! Her 90 day stats[1] place her at #9 with a solid ratio of 72%. Her 30 
> day stats[2] are even better and place her at #6 with an improving ratio of 
> 67%. She also just doesn't rubber stamp reviews or jump in reviews at the 
> end; she sticks with them from beginning to end and finds real problems, not 
> trivial things. Finally Alicja is full time on Kolla as funded by her 
> employer so she will be around for the long haul and always available. 
> 
> Please consider my proposal to be a +1 vote. 
> 
> To be approved for the core reviewer team, Alicja requires a majority vote of 
> 6 total votes with no veto within the one week period beginning now and 
> ending Friday March 11th. If your on the fence, you can always abstain. If 
> the vote is unanimous before the voting ends, I will make appropriate changes 
> to gerrit's acls. If their is a veto vote, voting will close prior to March 
> 11th. 
> 
> Regards, 
> -steve 
> 
> [1] http://stackalytics.com/report/contribution/kolla-group/90 
> [2] http://stackalytics.com/report/contribution/kolla-group/30 
> 
> __ 
> 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] [Fuel] Fuel 8 crashes when using Advanced Install

[Razvan Rosca]

Hey,

Tried this on 4 Dell machines, issue is present on all. Each server has 2
SSDs in no RAID.

What I'm doing:
- mount ISO
- select Advanced Install
- error


​
Is this a known bug?

Thanks,
Razvan Rosca

Email: raz...@webhipo.com
Skype: razvan.rosca
Tel.: +4 0731 059 660
Web: http://www.webhipo.com
Facebook: http://www.fb.com/webhipo
Twitter: http://www.twitter.com/webhipo
__
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] (no subject)

[郝启臣]

I have a blueprint for glance,can anybody give me some advice?

blueprint link:

https://blueprints.launchpad.net/glance-store/+spec/image-compress

When we make a qcow2 image and prepare to upload it to glance,the image
usually be large and can be compress,so it's better to compress the image
in the client side and upload the compressed image to glance,which will
save much store space.
compress wiki--https://pve.proxmox.com/wiki/Shrink_Qcow2_Disk_Files

Also,the image store is not safe in glance,if someone can access the
directory,he can get the image file and steal the information of the
image,so we'd better encrypt the image(use libvirt,
https://libvirt.org/formatstorageencryption.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] [Kuryr] IRC Meeting Tuesday (3/8) - 0300 UTC

[Gal Sagie]

Hello All

We will have an IRC meeting in Tuesday (3/8) at 0300 UTC
in #openstack-meeting-4

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Kuryr

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-02-29-15.01.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][Dragonflow] IRC Meeting tomorrow (3/7) - 0900 UTC

[Gal Sagie]

Hello All,

We will have an IRC meeting tomorrow (Monday, 3/7) at 0900 UTC
in #openstack-meeting-4

I personally will not be able to attend, Eran Gampel will chair it instead.

Please review the expected meeting agenda here:
https://wiki.openstack.org/wiki/Meetings/Dragonflow

You can view last meeting action items and logs here:
http://eavesdrop.openstack.org/meetings/dragonflow/2016/dragonflow.2016-02-29-09.00.html

Please update the agenda if you have any subject you would like to discuss
about.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Heads up: add description to resources breaks decomposed plugin

[Gary Kotton]

Thanks! I have updated the code locally and it address the issue.
Thanks for the quick turnaround!

From: Kevin Benton >
Reply-To: OpenStack List 
>
Date: Sunday, March 6, 2016 at 12:26 PM
To: OpenStack List 
>
Subject: Re: [openstack-dev] [Neutron] Heads up: add description to resources 
breaks decomposed plugin

Fix: https://review.openstack.org/288999

On Sun, Mar 6, 2016 at 2:17 AM, Kevin Benton 
> wrote:
Looking into it now. The filtering seems to be messed up on the association 
proxy that references the other table.

On Sun, Mar 6, 2016 at 2:07 AM, Gary Kotton 
> wrote:
The tests that are failing are those where the security groups are being 
searched by the ‘description’. When running these tests individually they pass 
but when running all of the tests together they fail.

From: Gary Kotton >
Reply-To: OpenStack List 
>
Date: Sunday, March 6, 2016 at 11:12 AM
To: OpenStack List 
>
Subject: [openstack-dev] [Neutron] Heads up: add description to resources 
breaks decomposed plugin

Hi,
The resent addition of https://review.openstack.org/#/c/269887/ has broken our 
unit tests with random tests with listing of security groups – for example – 
test_list_security_groups
Has anyone else also hit this issue?
Thanks
Gary

__
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] [tripleo] Contributing to TripleO is challenging

[Shinobu Kinjo]

Any comment?

Cheers,
S

On Sat, Mar 5, 2016 at 11:03 AM, Adam Young  wrote:
> On 03/04/2016 09:23 AM, Emilien Macchi wrote:
>
> That's not the name of any Summit's talk, it's just an e-mail I wanted
> to write for a long time.
>
> It is an attempt to expose facts or things I've heard a lot; and bring
> constructive thoughts about why it's challenging to contribute in
> TripleO project.
>
>
> 1/ "I don't review this patch, we don't have CI coverage."
>
> One thing I've noticed in TripleO is that a very few people are involved
> in CI work.
> In my opinion, CI system is more critical than any feature in a product.
> Developing Software without tests is a bit like http://goo.gl/OlgFRc
> All people - specially core - in the project should be involved in CI
> work. If you are TripleO core and you don't contribute on CI, you might
> ask yourself why.
>
>
> OK...so what is the state of Tripleo CI?  My experience with Tripleo has
> shown that it is quite resource intesive, far more so than, say, Keystone,
> and so I could see that being the gating factor.
>
>
> In order for me to be able to get into Tripleo coding, I needed a new
> machine, with 32 Gb of Ram, separate from my everyday work machine.  Not a
> killer outlay, but enough to hold me up until I got the HW allocated.
>
> If we could split up the testing undercloud vs. overcloud, it might be more
> feasable.  I see no fundamental reason that the majority of the Overcloud
> development and testing could not be done on top of a non-ironic based
> OpenStack deployment.
>
> That leaves just the undercloud, which could, possibly, also run onto top of
> an existing OpenStack deployment for much of the development.
>
> A true end to end run of Tripleo with HA requires a lot:  3 Physical
> machines plus a little overhead for the Overcloud.  But this is what is
> really needed.  Ideally, on multiple vendors' systems, so that we identify
> some aspect of the Hardware variation.
>
>
>
>
> 2/ "I don't review this patch, CI is broken."
>
> Another thing I've noticed in TripleO is that when CI is broken, again,
> a very few people are actually working on fixing failures.
> My experience over the last years taught me to stop my daily work when
> CI is broken and fix it asap.
>
>
> Puppet and Heat are black boxes to me still.  I don't clearly understand how
> they fit together.
>
> I think we need to start depuppetifying Tripleo. I know we have a lot of
> sunk costs in to it, but we went with Puppet because it was all we had, not
> that it well matched the problem set.
>
> I'd recommend a freeze on all new Puppet development, and start doing all
> new features in Ansible. Fully acknowledging the havoc this will wreak,  I
> think it is important strategically.   It is really hard to swap between two
> languages, and the rest of OpenStack in Python.  Switching to Ruby is hard.
>
> All of our Client support is in Python.
>
> The number of people that know Puppet that actively contribute to OpenStack
> is small. The number of real Ruby experts is smaller.
>
>
>
> 3/ "I don't review it, because this feature / code is not my area".
>
> My first though is "Aren't we supposed to be engineers and learn new areas?"
> My second though is that I think we have a problem with TripleO Heat
> Templates.
> THT or TripleO Heat Templates's code is 80% of Puppet / Hiera. If
> TripleO core say "I'm not familiar with Puppet", we have a problem here,
> isn't?
> Maybe should we split this repository? Or revisit the list of people who
> can +2 patches on THT.
>
> I am more than happy to review anything Keystone related, but again, I
> struggle with Puppet.
>
> Not really knowing Heat as well makes it even tougher. We need a better
> overall orientation guide if people are going to come up to speed quicker.
>
>
>
>
> 4/ Patches are stalled. Most of the time.
>
> Over the last 12 months, I've pushed a lot of patches in TripleO and one
> thing I've noticed is that if I don't ping people, my patch got no
> review. And I have to rebase it, every week, because the interface
> changed. I got +2, cool ! Oh, merge conflict. Rebasing. Waiting for +2
> again... and so on..
>
> Same is true on Keystone.  There is just a lot to get done on this project.
> All these projects.
>
>
> I personally spent 20% of my time to review code, every day.
> I wrote a blog post about how I'm doing review, with Gertty:
> http://my1.fr/blog/reviewing-puppet-openstack-patches/
> I suggest TripleO folks to spend more time on reviews, for some reasons:
>
>
> Nice of you to write that up.
>
> * decreasing frustration from contributors
> * accelerate development process
> * teach new contributors to work on TripleO, and eventually scale-up the
> core team. It's a time investment, but worth it.
>
> In Puppet team, we have weekly triage sessions and it's pretty helpful.
>
>
> 5/ Most of the tests are run... manually.
>
> How many times I've heard "I've tested this patch locally, and it does
> not work so -1".
>
> 

Re: [openstack-dev] [Neutron] Heads up: add description to resources breaks decomposed plugin

[Shinobu Kinjo]

Thx.

Cheers,
S

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

Sent: Sunday, March 6, 2016 7:26:46 PM
Subject: Re: [openstack-dev] [Neutron] Heads up: add description to resources 
breaks decomposed plugin

Fix: https://review.openstack.org/288999 

On Sun, Mar 6, 2016 at 2:17 AM, Kevin Benton < ke...@benton.pub > wrote: 



Looking into it now. The filtering seems to be messed up on the association 
proxy that references the other table. 

On Sun, Mar 6, 2016 at 2:07 AM, Gary Kotton < gkot...@vmware.com > wrote: 



The tests that are failing are those where the security groups are being 
searched by the ‘description’. When running these tests individually they pass 
but when running all of the tests together they fail. 

From: Gary Kotton < gkot...@vmware.com > 
Reply-To: OpenStack List < openstack-dev@lists.openstack.org > 
Date: Sunday, March 6, 2016 at 11:12 AM 
To: OpenStack List < openstack-dev@lists.openstack.org > 
Subject: [openstack-dev] [Neutron] Heads up: add description to resources 
breaks decomposed plugin 

Hi, 
The resent addition of https://review.openstack.org/#/c/269887/ has broken our 
unit tests with random tests with listing of security groups – for example – 
test_list_security_groups 
Has anyone else also hit this issue? 
Thanks 
Gary 

__ 
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] [Neutron] Heads up: add description to resources breaks decomposed plugin

[Kevin Benton]

Fix: https://review.openstack.org/288999

On Sun, Mar 6, 2016 at 2:17 AM, Kevin Benton  wrote:

> Looking into it now. The filtering seems to be messed up on the
> association proxy that references the other table.
>
> On Sun, Mar 6, 2016 at 2:07 AM, Gary Kotton  wrote:
>
>> The tests that are failing are those where the security groups are being
>> searched by the ‘description’. When running these tests individually they
>> pass but when running all of the tests together they fail.
>>
>> From: Gary Kotton 
>> Reply-To: OpenStack List 
>> Date: Sunday, March 6, 2016 at 11:12 AM
>> To: OpenStack List 
>> Subject: [openstack-dev] [Neutron] Heads up: add description to
>> resources breaks decomposed plugin
>>
>> Hi,
>> The resent addition of https://review.openstack.org/#/c/269887/ has
>> broken our unit tests with random tests with listing of security groups –
>> for example – test_list_security_groups
>> Has anyone else also hit this issue?
>> Thanks
>> Gary
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Heads up: add description to resources breaks decomposed plugin

[Kevin Benton]

Looking into it now. The filtering seems to be messed up on the association
proxy that references the other table.

On Sun, Mar 6, 2016 at 2:07 AM, Gary Kotton  wrote:

> The tests that are failing are those where the security groups are being
> searched by the ‘description’. When running these tests individually they
> pass but when running all of the tests together they fail.
>
> From: Gary Kotton 
> Reply-To: OpenStack List 
> Date: Sunday, March 6, 2016 at 11:12 AM
> To: OpenStack List 
> Subject: [openstack-dev] [Neutron] Heads up: add description to resources
> breaks decomposed plugin
>
> Hi,
> The resent addition of https://review.openstack.org/#/c/269887/ has
> broken our unit tests with random tests with listing of security groups –
> for example – test_list_security_groups
> Has anyone else also hit this issue?
> Thanks
> Gary
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Heads up: add description to resources breaks decomposed plugin

[Gary Kotton]

The tests that are failing are those where the security groups are being 
searched by the ‘description’. When running these tests individually they pass 
but when running all of the tests together they fail.

From: Gary Kotton >
Reply-To: OpenStack List 
>
Date: Sunday, March 6, 2016 at 11:12 AM
To: OpenStack List 
>
Subject: [openstack-dev] [Neutron] Heads up: add description to resources 
breaks decomposed plugin

Hi,
The resent addition of https://review.openstack.org/#/c/269887/ has broken our 
unit tests with random tests with listing of security groups – for example – 
test_list_security_groups
Has anyone else also hit this issue?
Thanks
Gary
__
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] Heads up: add description to resources breaks decomposed plugin

[Gary Kotton]

Hi,
The resent addition of https://review.openstack.org/#/c/269887/ has broken our 
unit tests with random tests with listing of security groups – for example – 
test_list_security_groups
Has anyone else also hit this issue?
Thanks
Gary
__
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] [magnum-ui] Proposed Core addition, and removal notice

[Jay Lau]

+1, thanks for the great work on magnum UI,  Shu Muto!

On Sun, Mar 6, 2016 at 12:52 AM, Hongbin Lu  wrote:

> +1
>
> BTW, I am magnum core, not magnum-ui core. Not sure if my vote is counted.
>
> Best regards,
> Hongbin
>
> -Original Message-
> From: Adrian Otto [mailto:adrian.o...@rackspace.com]
> Sent: March-04-16 7:29 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [magnum-ui] Proposed Core addition, and removal
> notice
>
> Magnum UI Cores,
>
> I propose the following changes to the magnum-ui core group [1]:
>
> + Shu Muto
> - Dims (Davanum Srinivas), by request - justified by reduced activity
> level.
>
> Please respond with your +1 votes to approve this change or -1 votes to
> oppose.
>
> Thanks,
>
> Adrian
> __
> 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
>



-- 
Thanks,

Jay Lau (Guangya Liu)
__
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