the way we document that things work. If you feel we need to be more
explicit in documentation about it, I think that would be appropriate.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Ma
structure will be figured out later once the content is there.
Remember, the Design Summit sessions work best when this is the middle
of the conversation, not the beginning of one.
If you have any questions, feel free to ask on this email thread.
Happy Stacking,
-Sean
--
Sean Dague
http
ent, the docs are pretty
straight forward about what the correct links are, and we only generate
working links in our references.
There are many issues that we should address in the API, this one
probably doesn't cr
an provide more
> insight into where we are losing time during the tempest test runs.
Subunit logs aren't the full story here. Activity in addCleanup doesn't
get added to the subunit time accounting for the test, which causes some
interesting issues when waiting for resources to delete. I woul
maintenance is a bit of a corner case too.
> Matt would have stayed PTL for stable if he wasn't elected for Nova, and
> Tony, being an election official, couldn't really throw his name in the
> PTL election hat at the last minute. I think this is a case where the TC
> looking at the potential
f not I'll close them too.
> 5. Continously double-check if wishlist bug reports get created
>
> Doubts? Thoughts? Concerns? Agreements?
This sounds like a very reasonable plan to me. Thanks for summarizing
all the concerns and coming up with a pretty balanced plan here. +1.
wer" we have to solve "can the underlying projects
guaruntee consistent quota answers".
There is a giant pile of bugs in Nova about these races, has been
forever, until we solve this in the lower level projects the
maint core and he's done a great job
> there (as expected) and is very active, which is again much appreciated.
>
> Please respond with ack/nack.
ACK
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
pling proposal -- does this mean the
> upgrades of all services would be linked (potentially)?
Not if this was a library that defined tables inside the projects in
question, not in some 3rd db place.
This has to live
project in OpenStack.
A common library with it's own db tables and migration train is the only
way I can imagine this every getting accomplished given the atomicity
and two phase commit constraints of getting quota on long lived, async
created resources, with sub resources that also have quota. Def
a bugs in every release, and have to hunt for a new bug lead twice
as often? That's my gut feel on the break down here.
To get the bug backlog under control, we have to make hard calls here.
This is one of them. Once we're working with < 400 open issues, deciding
to reopen the Wishlist mechanism i
Yes, this is a library. Changing the return value on existing functions
isn't a thing you can do. If you want a different return, introduce a
new method which does that, and we can deprecate the old one out over time.
-Sean
n your head at once to know things are really issues or not,
and once they get old enough they are lost to the mists of time. Having
a smaller high quality bug list would make it more of a todo list, which
would be nice for both experienced folks in the project, and new people
looking to contribut
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://li
ept.httplib2_intercept import install as
wsgi_install
python-muranoclient lists it as a requirement, there is no reference in
the source tree for it.
I suspect Glance is really the lynchpin here (as it actually does some
low level stuff with it). If there can be a Glance plan to get off of
it, the re
cs-specs/specs/mitaka/app-guides-mitaka-vision.html
> 2.
> http://specs.openstack.org/openstack/docs-specs/specs/liberty/api-site.html
>
>
> ______
> OpenStack Development Mailing List (not for usage questi
On 03/10/2016 08:40 AM, Thomas Herve wrote:
> On Thu, Mar 10, 2016 at 2:28 PM, Chris Dent <cdent...@anticdent.org> wrote:
>> On Thu, 10 Mar 2016, Sean Dague wrote:
>>
>>> These are HTTP services. They really shoudn't be claiming new ports,
>>> they shou
gurations with multiple services on a
> single box.
>
> This does assume that there are less big tent projects than available
> TCP/IP ports :-)
These are HTTP services. They really shoudn't be claiming new ports,
they should be running on a real webserver on 80 or 443.
There is
t
it's short and/or demonstrates a piece of cloud function that if broken
we'd consider the whole cloud to be non functional.
It's used in the gate for grenade testing, so needs to stay at about 5
minutes overall run time when running 4 way.
-Sean
--
Sean Dague
http
.
>>
>> The thing that is extremely important and valuable about them is a
>> trained facilitator that has a ton of experience with groups of many
>> different dynamics. And, more importantly, is outside of the group
>> dynamic. A good trainer/facilitator know
ow to get groups to go to
uncomfortable places to let them challenge themselves, but can pull them
back from spiralling into unproductive places. That is much harder than
your realize. And having professional experience there is really important.
I'm quite looking forward to the event regardless of
On 02/16/2016 03:38 PM, Matthew Treinish wrote:
> On Tue, Feb 09, 2016 at 07:41:18PM -0500, Sean Dague wrote:
>> As proposed in this patch - https://review.openstack.org/#/c/271467/
>>
>> These tests do some manipulation of the request URI to attempt to
>> r
kinds of things that are currently being
rejected? And if we think those REST API calls are valid? I'd like to
know what we started blocking in Option 3 that no one noticed until now.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP di
t;>
>> Paul Murray
>>
>> Technical Lead, HPE Cloud
>>
>> Hewlett Packard Enterprise
>>
>> +44 117 316 2527
>>
>>
>>
>> __
>>
>> OpenStack Development Maili
back summit /
conference weeks would be. 2 weeks away from family is really tough.
Hopefully there will be some later opportunity.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not fo
forward to stop needing this plug point.
However, deprecating these helps signal that even if not immediately
removed, these are not things people should be building off of.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
t the headache of some nut jobs who are willing to
> take up the impossible task of defining and nurturing these libraries.
> There's a lot of great work ahead of us and i am looking forward to
> continue to work with you all.
>
> Thanks,
> Dims
Thanks much for your hard w
norms are that
this is allowed, and OpenStack clouds do the opposite, they will be
considered broken compared to the norms.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage que
sts.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 Ma
of
the boot from volumes tests is not accounted for.
Can we get that folded in correctly? I do realize the complexities of
tearDownClass accounting. But it seems like that should be done here
otherwise we don't really realize how bad our hot spots are.
-Sean
--
Sean Dague
http://dague.net
tests take over 2 minutes each.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://l
ivation here? Maybe if we start with that I can point you
in a fruitful direction.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openst
gration tests between Heat and
> python-cinderclient too.
You can add any new tests that you want in additional test jobs.
Cinder can not remove the python-cinderclient src job anytime soon.
That's table stakes for being part of openstack given how deeply that is
coupled between Nova / Neutron / C
On 03/02/2016 03:01 AM, Juan Antonio Osorio wrote:
>
>
> On Tue, Mar 1, 2016 at 2:14 PM, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 02/29/2016 05:23 PM, Matt Riedemann wrote:
> >
> >
> > On 2/29/2016 2:54
On 03/01/2016 02:04 PM, Rob Crittenden wrote:
> Daniel P. Berrange wrote:
>> On Mon, Feb 29, 2016 at 11:59:06AM -0500, Sean Dague wrote:
>>> The nova/hooks.py infrastructure has been with us since early Nova. It's
>>> currently only annotated on a few
On 02/29/2016 05:23 PM, Matt Riedemann wrote:
>
>
> On 2/29/2016 2:54 PM, Sean Dague wrote:
>> On 02/29/2016 11:59 AM, Sean Dague wrote:
>>> The nova/hooks.py infrastructure has been with us since early Nova. It's
>>> currently only annotated on
On 02/29/2016 11:59 AM, Sean Dague wrote:
> The nova/hooks.py infrastructure has been with us since early Nova. It's
> currently only annotated on a few locations - 'build_instance',
> 'create_instance', 'delete_instance', and 'instance_network_info'. It's
> got a couple o
is nice, it isn't, but I'd prefer a replace
>> then deprecate model instead.
>>
>> I'm not entirely sure that the notifications contain all the same
>> information as is available now in the hooks.
>
> This is something we can and should address if there is useful
> inf
a
little hard by the way all exceptions are caught when hooks go wrong.
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
types names we will hand out.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
34567890/tags/qux to update them
You should not PUT to any url that you can't GET. And it looks like GET
/servers/1234567890/tags/qux would be a 404 here.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Develo
t on old setuptools, work on any version. There is
a setuptools bug registered for this, which should hopefully be fixed today.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for us
On 02/25/2016 06:49 AM, Sean Dague wrote:
> It looks like a new ansible release overnight breaks devstack-gate
> (something we assumed was a success, empty subnode commands, is now a
> failure when going from 2.0.0.2 to 2.0.1.0), which is why there is a
> massive failure acro
h, I would certainly never do any event which spanned 2 weeks, even if
> both weeks were relevant to my work.
Agreed. For folks that need to get in time for the board meeting, the
Summit is basically already an 8 day event (counting travel days). I
know I wouldn't do back to back weeks.
-
global
requirements. I've proposed a fix with explicit versioning here -
https://review.openstack.org/#/c/284652/
Assuming tests patch I'll fast approve this through to get people up and
running. Most of infra is at the meetup and not around to review patches.
-Sean
--
Sean Dague
http
58
>
> I wonder if all the failures share a common python? perhaps 3.4?
Most of that is non-voting. It's not impacting kolla. This only exposes
on Red Hat platforms, and only is actually downvoting ansible and
oslo.messaging.
-Sean
--
Sean Dague
http://dague.net
__
64000s
>
Add voting:1 to the query.
Very few of those are voting jobs. It's only affecting olso.messaging
and ansible.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not f
On 02/24/2016 06:56 PM, Chris Friesen wrote:
> On 02/24/2016 02:34 PM, Sean Dague wrote:
>
>> There are no urls stored here. This is content coming through the body.
>> While I do appreciate many folks weighing in that haven't read the bug
>> yet, I would be even better if
On 02/24/2016 03:13 PM, Mooney, Sean K wrote:
>
>
>> -Original Message-
>> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
>> Sent: Wednesday, February 24, 2016 5:46 PM
>> To: Sean Dague <s...@dague.net>; openstack-dev@lists.open
On 02/24/2016 11:28 AM, James Bottomley wrote:
> On Wed, 2016-02-24 at 07:48 -0500, Sean Dague wrote:
>> We have a specific bug around aggregrate metadata setting in Nova
>> which
>> exposes a larger issue with our mysql schema.
>> https://bugs.launchpad.net/nova/
APIs to clean up in a similar way. I
don't think this comes in under a microversion because of how deep in
the db api layer this is, and it's just not viable to keep both paths.
-Sean
--
Sean Dague
http://dague.net
___
t 2 open API bugs in Nova that can't be reproduced on
SQLite in tests, but can with mysql.
And prefixing in all cases would at least make it more clear in case
something failed to cleanup.
[1] -
https://www.openstack.org/assets/survey/Public-User-Surv
On 02/23/2016 11:29 AM, Mike Bayer wrote:
>
>
> On 02/22/2016 08:18 PM, Sean Dague wrote:
>> On 02/22/2016 08:08 PM, Davanum Srinivas wrote:
>>> Sean,
>>>
>>> You need to set the env variable like so. See testenv:mysql-python
>>> f
of session.configure() -
https://github.com/openstack/nova/blob/d8ddecf6e3ed1e8193e5f6dba910eb29bbe6dac6/nova/tests/fixtures.py#L205
to reset the global session.
Pointers would be welcomed.
-Sean
--
Sean Dague
http://dague.net
uld require a
> keystone session, and the versions API must be lightweight?
If you put a proxy in front of things you need to also set
osapi_compute_link_prefix -
https://github.com/openstack/nova/blob/d8ddecf6e3ed1e8193e5f6dba910eb29bbe6dac6/nova/api/openstack/common.py#L45-L47
This Temp
you need.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.open
test code is a bit concerning. Tempest ran into a similar
issue and addressed this by allowing for preallocation of accounts. That
kind of approach seems like it would work here given that you could do
grants on well known names.
-Sean
--
Sean Dague
http://dague.net
signature.as
not entirely
evident what the new required setup is. Can someone point me to the docs
to use this? Or explain what the setup for local testing is now? We've
got some bugs which expose on mysql and not sqlite in nova that we'd
like to get some test cases written for.
-Sean
--
Sean Dague
http
On 02/22/2016 12:20 PM, Daniel P. Berrange wrote:
> On Mon, Feb 22, 2016 at 12:07:37PM -0500, Sean Dague wrote:
>> On 02/22/2016 10:43 AM, Chris Friesen wrote:
>>> Hi all,
>>>
>>> We've recently run into some interesting behaviour that I thought I
>>
.
So there has to be a tradeoff of the complexity of any new code vs. what
it gains. I think individual patches should be evaluated as such, or a
spec if this is going to get really invasive.
-Sean
--
Sean Dague
http://dague.net
___
oncern.
Overall this seems like a great plan. And the only places it concerns me
is around existing issues of key folks just being pulled in too many
directions at once. This doesn't make this really any better or worse,
just a different contention point.
number of things, including this. I *do* think it
> would be great to just use OpenStack-API-Version: $SERVICE_TYPE X.Y,
> however we'll need to add another microversion to support that of
> course. Isn't it ironic? Don't you think?
Actually, the headers can't be fully fixed in a microversion
r of CLI tools should default to
nic auto being implied. The user experience there is different. You use
cli tools for one off boots of things, so should be as easy as possible.
I think this is one of the places where the UX needs of the API and the
CLI are definitely different.
-Sean
--
back and forth between the two options. At first, /v3 made
> the most sense to me ... at least it did at the meetup. With people
> like Sean Dague and Morgan Fainberg weighing in with concerns, it
> seems like we should reconsider. Duncan, your comment here about
> custom
On 02/19/2016 11:20 AM, Sean McGinnis wrote:
> On Fri, Feb 19, 2016 at 10:57:38AM -0500, Sean Dague wrote:
>> The concern as I understand it is that by extending the v2 API with
>> microversions the following failure scenario exists
>>
>> If:
>>
>> 1) a c
On 02/19/2016 11:15 AM, Ben Swartzlander wrote:
> On 02/19/2016 10:57 AM, Sean Dague wrote:
>> On 02/18/2016 10:38 AM, D'Angelo, Scott wrote:
>>> Cinder team is proposing to add support for API microversions [1]. It
>>> came up at our mid-cycle that we shoul
. One day, we'll
have an API we love, hopefully. Doing so means that we do need to make
changes to defaults. Deprecate some weird and unmaintained bits.
The principle of least surprise to me is that you don't need that
attribute at all. Do the right thing with the least amount of work.
Instead of
kinds of applications basically break for no good reason.
So my recommendation is to extend out from the /v2 endpoint. This is
conceptually what you are actually doing. The base microversion will be
v2 API as it exists today, and you are negotiating up from there.
-Sean
--
Sean Dague
http://da
a
server is one of the least tested components we've got on the Nova side,
so I'll be looking at ways to fix that problem and hopefully avoid
situations like this again.
-Sean
--
Sean Dague
http://dague.net
__
still
>> have enough time and people to test it before. All patches are split
>> into small
>> commits (100 LOC max), so they should be relatively easy to review.
>>
>> I wonder if Nova community members may change their decision and
>> unblock this
>> patches? T
On 02/18/2016 12:17 PM, Michael Krotscheck wrote:
> Clarifying:
>
> On Thu, Feb 18, 2016 at 2:32 AM Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> Ok, to make sure we all ended up on the same page at the end of this
> discussion, this is
es, but keystone is defcore. Making the keystone case worse for the
non keystone case seems like fundamentally the wrong tradeoff.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for
On 02/12/2016 07:01 AM, Sean Dague wrote:
> Ok... this is going to be one of those threads, but I wanted to try to
> get resolution here.
>
> OpenStack is wildly inconsistent in it's use of tenant vs. project. As
> someone that wasn't here at the beginning, I'm not even sure
.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
e're going to want some better tests for bumping
upper-constraints.txt, even if it's tests we only run for certain touchy
packages like eventlet. However we should make sure it wasn't just our
tests being kind of bonkers.
-Sean
--
Sean Dague
http://dague.net
_
On 02/16/2016 06:49 AM, Sean Dague wrote:
> This was needed originally for ec2 support (which requires an integer
> id). It's not really the db index per say, just another id value which
> is valid (though hidden) for the server.
>
> Before unwinding this issue we *must* make sure tha
ering the minimum version we support, since we have >=0.18.2
> now.
>
> What was the last version of eventlet known to work?
0.18.2 works. On the Nova side we had a failure around unit tests which
was quite synthetic that we fixed. I don' know what the keystone issue
turned
in the base cors
middleware?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
e've actually been making here
instead of theoretical examples. The amount of effort to make an
application use 2.20 instead of 2.1 is pretty minimal.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Ma
constraints protecting the
> gates.
I think due to the limitations on pip and python packaging we've largely
said (maybe too implictly) that you have to have an installer layer in
OpenStack, and it has to understand requirements at the install layer.
That might be distro packages. That might be any
On 02/16/2016 09:34 AM, Andrew Laski wrote:
>
>
>
> On Tue, Feb 16, 2016, at 07:54 AM, Alex Xu wrote:
>>
>>
>> 2016-02-16 19:53 GMT+08:00 Sean Dague <s...@dague.net
>> <mailto:s...@dague.net>>:
>>
>> On 02/12/2016
r/2015/cinder.2015-12-16-16.00.log.html
> [3] https://review.openstack.org/#/c/279432/8
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsu
y use and the version they want (and if so,
>> if it was implemented).
>>
>> Call me dumb, it's just a thought.
>> -Sylvain
>>
>
> One slight improvement could be to consider hundreds and not tens for
> major versions. That would leave 99 'minor' versions be
t semver. Each
version is just that.
Semver only makes sense when you are always talking to one installation,
and the version numbers can only increase. When your code retargets to
multiple installations version numbers can very easily go backwards. So
unless a change in compatible forward and backw
.openstack.org?subject:unsubscribe>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
&
up as to which is the deprecated
term and which is the term moving forward.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-r
f you don't think that's the API WG, that's fine (it is why this went
to the mailing list last week), we can create a different subgroup for
this. The core team is a dedicated group so it doesn't need to overlap
with API WG.
-Sean
--
Sean Dague
http://dague.net
___
On 02/12/2016 08:30 AM, Dean Troyer wrote:
> On Fri, Feb 12, 2016 at 6:01 AM, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> OpenStack is wildly inconsistent in it's use of tenant vs. project. As
> someone that wasn't here at the beginning,
-network VLAN manager.
>
> I think this pushes our microversions meaning a bit further than
> intended. I don't think the API should flip behaviors simply based on a
> microversion.
>
> What about requiring nic information with the microversion? Make users
> indicate expl
that becomes deprecated now, and removed in Newton. If there
are folks that would like to carry it on from there, I think we should
spin it into a dedicated repository and just have it require tempest.
-Sean
--
Sean Dague
http://dague.net
running this job a while ago because it was
just noise. And I agree with their call there. We should do the same
across OpenStack.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usa
.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo
On 02/04/2016 06:38 AM, Sean Dague wrote:
> 2) Have a registry of "common" names.
>
> Upside, we can safely use common names everywhere and not fear collision
> down the road.
>
> Downside, yet another contention point.
>
> A registry would clearly be u
?id=d754a830861fb55b047e7b4d43ba7f485fc120dd
Thanks much for shepharding this Chris.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack
in most cases. Tests without a path forward, that are failing
good patches a lot, are very much the kind of thing we should remove
from the system.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing
in the url it's actively harmful to moving forward.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
On 02/07/2016 08:30 AM, Jay Pipes wrote:
> On 02/04/2016 06:38 AM, Sean Dague wrote:
>> What options do we have?
>
>> 2) Have a registry of "common" names.
>>
>> Upside, we can safely use common names everywhere and not fear collision
>> down the road
On 02/07/2016 08:13 PM, Monty Taylor wrote:
> On 02/07/2016 07:30 AM, Jay Pipes wrote:
>> On 02/04/2016 06:38 AM, Sean Dague wrote:
>>> What options do we have?
>>
>>> 2) Have a registry of "common" names.
>>>
>>> Upside, we can safel
at's in OpenStack
today.
I think this is a place where there are lots of reasonable and different
points of view. And if it was clear cut there wouldn't be the need for
discussion.
-Sean
--
Sean Dague
http://dague.net
__
O
f understanding for what it takes to do events at that
scale. And massively underestimates the effort and skill the Foundation
has at making our events run as smoothly as they do.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
501 - 600 of 1956 matches
Mail list logo
