On 09/08/2015 08:15 PM, Ken'ichi Ohmichi wrote:
> 2015-09-08 19:45 GMT+09:00 Sean Dague <s...@dague.net>:
>> On 09/06/2015 11:15 PM, GHANSHYAM MANN wrote:
>>> Hi All,
>>>
>>> As we all knows, api-paste.ini default setting for /v2 was
>>> changed
of workable solution and figure out what was next. We
should definitely do a summit session on this one to nail down the
details and the path forward.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development
rootwrap, but this suggestion seems pretty non
productive in solving the problems in front of us. Especially given how
deeply the calling interface is embedded in our programs today.
-Sean
--
Sean Dague
http://dague.net
___
bot, assuming that
if we're > 15 minutes late enough of the environment is backed up that
there is no point in waiting. We had some pretty substantial backups in
Elastic Search recently.
-Sean
--
Sean Dague
http://dague.net
___
ns by lots of projects are measured in years at this
point.
I feel like a realistic bit of compromise that won't drive everyone nuts
would be:
config options: n+1
minor features: n+1
major features: at least n+2 (larger is ok)
And come up with some fuzzy words around minor / major features.
I also
going to dump
it. So we don't want to honor 3 different versions of this API,
especially as no one seems written to work against the documentation,
but were written against the code in question. If they write to the
docs, they'l
that the M3 -> N0 drop can be pretty quick, it can be 6
>> weeks (which I've seen happen). However N == six months might make FFE
>> deprecation lands in one release run into FFE in the next. For the CD
>> case my suggestion is > 3 months. Because if you aren't CDing in
>> in
an be 6
weeks (which I've seen happen). However N == six months might make FFE
deprecation lands in one release run into FFE in the next. For the CD
case my suggestion is > 3 months. Because if you aren't CDing in
increments smaller than that, and hence seeing the deprecation, you
aren't real
> such a long-term commitment to downstream consumers.
And, the LTS question is separate from the feature deprecation question.
They are both pro consumer behaviors that have cost on the development
teams, but they are different things.
We rarely get resolution on one thing by entwining a different t
e bug
https://bugs.launchpad.net/python-novaclient/+bug/1491579 has been
updated to hopefully contain all the relevant details of the issue.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for
On 09/04/2015 07:15 AM, Sean Dague wrote:
> On 09/02/2015 05:48 PM, Matt Riedemann wrote:
>>
>>
>> On 9/2/2015 3:40 PM, Jeremy Stanley wrote:
>>> On 2015-09-02 10:55:56 -0400 (-0400), d...@doughellmann.com wrote:
>>>> We are thrilled to announce the rele
all our features. I
> have tried to draft out how that might look here:
> https://review.openstack.org/#/c/215664/
Honestly, it's still got somewhat limited test coverage, and using Cells
means some features of Nova don't work. So Experimental is still the
right state for cells v1.
for everyone because of these patches.
Could heat team members get engaged and get to the bottom of this one?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions
dependent on pulling images directly from upstream, we
don't let it be voting.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
ed to unrelated lock
ups like this really often. So that needs to be prioritized soon.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-r
od enough to push
> the patch in the gate directly.
Correct, the gate enqueue criteria is just that it has a jenkins +1.
Date is irrelevant. So if there is a jenkins +1 from before the netaddr
release, there is a failure condition here.
-Sean
--
Sean Dague
http://dague.net
signature
ersion
> cap for what we did for Neutron.
> I will check it.
>
> Akihiro
>
> 2015-08-31 20:54 GMT+09:00 Sean Dague <s...@dague.net
> <mailto:s...@dague.net>>:
>
> On 08/31/2015 06:48 AM, Ihar Hrachyshka wrote:
> >> On 31 Aug 2015, at 08:19,
the fact
that patches needed to take an extra round trip some times. So the
freshness check no longer exists.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
using Neutron.
>>
>> Cheers
>
> For Juno, we already cap the version of the library to <= 0.7.13. As for
> kilo, I pushed the following change: https://review.openstack.org/#/c/218805/
This looks like it's tanking Horizon unit tests as well -
http://logs.openstack.org/00/2078
and rechecked, can we remove them from the gate definition on
neutron so they aren't damaging the overall flow of the gate?
Thanks,
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List
they
started,
and I pushed that fix a few hours after that. Sadly it's taking time to
get that
through the gate.
When issues like these arrise, please bring them to the infra team in
#openstack-infra. They can promote fixes that unbreak things.
-Sean
--
Sean Dague
http://dague.net
before them actually ran.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
in discovery order.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
is supported on the server -
https://github.com/openstack/python-novaclient/blob/d27568eab50b10fc022719172bc15666f3cede0d/novaclient/__init__.py#L23
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List
in the gate (we've got a
cinder one was well). If other issues are known with fixes posted,
please feel free to add them with comments.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List
.
--
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
.
-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
:
On 19 August 2015 at 03:51, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
So... I'm at Linux Con this week, meaning that things will be slow.
I
think - https://review.openstack.org/#/c/208582/ (slightly updated
this
morning) will get
questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sean Dague
http://dague.net __
OpenStack Development Mailing List
again. And I agree, we really
need devstack and the gate to be convergent on their solution here, not
divergent.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
__
OpenStack
of them and getting to ask real
questions like why is this even a thing?.
Because, right now, I don't think anyone has a good handle on our
configuration space. Providing that global view through such a
reorganization will help us figure out next steps here.
-Sean
--
Sean Dague
http
, and the order in
tackling them. Thanks for taking this on.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
specs (alex_xu, 12:55:52)
* open (alex_xu, 12:56:22)
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
:26 PM, Ken'ichi Ohmichi wrote:
Nice idea :-)
2015年8月8日(土) 9:05 Alex Xu hejie...@intel.com
mailto:hejie...@intel.com:
在 2015年8月8日，上午12:48，Sean Dague s...@dague.net
mailto:s...@dague.net 写道：
Friday's have been kind of a rough day for the Nova API subteam. It's
for me. Having this
earlier in the week I also hope keeps the attention on the items we need
to be looking at over the course of the week.
If current regular attendees could speak up about day preference, please
do. We'll make a change if this is going to work for folks.
-Sean
--
Sean
. So who is up for helping, and what format
this plan will take, are the key bits.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
://docs.openstack.org/developer/nova/api_microversion_dev.html#when-do-i-need-a-new-microversion
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
On 07/29/2015 01:21 PM, Robert Collins wrote:
On 30 July 2015 at 01:39, Sean Dague s...@dague.net wrote:
So, after every release a giant amount of patches all have to land lock
step or everything is broken?
No, its not that bad.
The *tagged* commit is fine forever.
The *first* commit
release a giant amount of patches all have to land lock
step or everything is broken?
That seems pretty fragile. Can we revisit whatever decision caused this
issue?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
On 07/29/2015 09:49 AM, Jeremy Stanley wrote:
On 2015-07-29 09:39:46 -0400 (-0400), Sean Dague wrote:
On 07/29/2015 09:29 AM, Matt Riedemann wrote:
On 7/29/2015 8:17 AM, Matt Riedemann wrote:
[...]
ValueError: git history requires a target version of
pbr.version.SemanticVersion(2015.1.2
in glance. It also points at a missing set of test cases which is
to create images via 1 API and be able to access them over the other. I
don't know if that is in process or not, but it would be really good to
deliver those test cases as part of this work.
-Sean
--
Sean Dague
http://dague.net
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
__
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
--
Sean Dague
http://dague.net
--
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
or not this service
should be tested? That would be where I'd look.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
--
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
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
to pin things, explicitly, like jroll said, do that. And
microversions lets you until your clouds uplift past your legacy code.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
.
-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
On 07/23/2015 01:04 PM, Kevin L. Mitchell wrote:
On Thu, 2015-07-23 at 11:41 -0500, Sean Dague wrote:
On 07/23/2015 11:23 AM, Roman Podoliaka wrote:
Hi all,
FWIW, this is exactly what we have in oslo libs, e.g. in oslo.db [0]
Putting all Nova options into one big file is probably not a good
this to be a big bang, but in chunks as the
help is being improved.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions
of experimental to check on devstack-gate
* extend this approach with neutron grenade multinode jobs
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing
best do so?
-Rob
I'd say review everything outstanding. And we can expand the group over
time.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development
run through, typically I don't look at this more than
once a week because they are usually not time critical unless there is a
gate break.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
://review.openstack.org/#/c/203845/ is a band-aid,
Andreas
That's not the right band aid, because using a regex in tempest means
that the slow tests aren't automatically turned off. So it's going to
bring in other tests you don't want.
-Sean
--
Sean Dague
http://dague.net
. And
given that we've been running full capacity for days now, keeping this
ball moving forward would be great.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions
On 07/15/2015 08:12 PM, GHANSHYAM MANN wrote:
On Thu, Jul 16, 2015 at 3:03 AM, Sean Dague s...@dague.net wrote:
On 07/15/2015 01:44 PM, Matt Riedemann wrote:
The osapi_v3.enabled option is False by default [1] even though it's
marked as the CURRENT API and the v2 API is marked as SUPPORTED
really aren't a thing on first boot unless you have guest agent
code, or only boot with one disk and hot plug the rest carefully.
Neither are really fun answers.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
/__init__.py#n44
Honestly, we should probably deprecate out osapi_v3.enabled make it
osapi_v21 (or osapi_v2_microversions) so as to not confuse people further.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
--
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 07/14/2015 08:32 AM, Jeremy Stanley wrote:
On 2015-07-14 07:03:34 -0400 (-0400), Sean Dague wrote:
I just saw this Nova review come in -
https://review.openstack.org/#/c/200908
Why are we merging 2.6 requirements for projects that don't support 2.6?
That seems potentially confusing to end
had thought we'd adjusted that with all the
branching.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
.
- Issue #15323: improve failure message of Mock.assert_called_once_with
- Issue #14857: fix regression in references to PEP 3135 implicit __class__
closure variable (Reopens issue #12370)
- Issue #14295: Add unittest.mock
-Rob
--
Sean Dague
http://dague.net
seen no activity in the last 60 days
back to Confirmed.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
straight forward. It was another one of those assert_*
doesn't exist issues. I just approved it though.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions
On 07/10/2015 09:34 AM, Markus Zoeller wrote:
Sean Dague s...@dague.net wrote on 07/10/2015 12:32:00 PM:
From: Sean Dague s...@dague.net
To: openstack-dev@lists.openstack.org
Date: 07/10/2015 12:32 PM
Subject: Re: [openstack-dev] [nova] Switching the bug status of ~200
bugs at once
for a segfault in python. This seems like your python
interpreter being broken on your processor / os. I think you will need
to solve that much deeper problem.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
they understand today.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
, not months).
I've proposed https://review.openstack.org/#/c/197464/ to backport that
patch to Juno.
Thanks, +A.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions
On 06/26/2015 07:43 AM, Dmitry Tantsur wrote:
On 06/26/2015 01:14 PM, Sean Dague wrote:
On 06/16/2015 09:51 AM, Dmitry Tantsur wrote:
On 06/16/2015 08:56 AM, Dmitry Tantsur wrote:
To sum this long post up, I'm seeing that hiding new features based on
microversions brings much more problems
of those clouds means we needed to come up with some new models here.
If you have other solutions to the time's arrow issue, that would be
great to here. But it is the crux of why the model looks like it does.
-Sean
--
Sean Dague
http://dague.net
to confusion.
Being extra, and possibly redundantly, explicit here eliminates
confusion. Our API is communication to our users, and I feel like at
every point we should err on the side of what's going to be the most
clear under the largest number of scenarios.
-Sean
--
Sean Dague
http
with their expectations.
That's good feedback, and clearly moves the needle in my head.
It also does open up a question about the big tent nature, because it's
unclear what projects that do not yet have a generic name allocated to
them would use.
-Sean
--
Sean Dague
http://dague.net
On 06/24/2015 07:57 AM, Chris Dent wrote:
On Wed, 24 Jun 2015, Sean Dague wrote:
So on https://review.openstack.org/#/c/194442 ... I was kind of thinking
we'd be able to get keystone-wsgi-public into a bin directory. I put up
a half baked sketch of this idea in
https://review.openstack.org
have the tooling in
place and locked in for constraints everywhere in master.
-Rob
All of these proposals are now failing the requirements check jobs, so
requirements updates are currently blocked.
What's the resolution here?
-Sean
--
Sean Dague
http://dague.net
or symlink.
https://review.openstack.org/#/c/194729/ - Changes devstack to use
keystone/httpd/admin.py and public.py rather than copying
httpd/keystone.py. Grenade is failing so I'll need to figure that out.
Great, thanks much! Reviewing now.
-Sean
--
Sean Dague
http://dague.net
On 06/24/2015 07:19 AM, Sean Dague wrote:
On 06/23/2015 04:07 PM, Brant Knudson wrote:
I've got a few related changes proposed to keystone and devstack:
https://review.openstack.org/#/c/193891/ - Changes Apache Httpd config
so that /identity is the keystone public (aka main) handler
On 06/24/2015 01:51 PM, Brant Knudson wrote:
On Wed, Jun 24, 2015 at 7:27 AM, Chris Dent chd...@redhat.com
mailto:chd...@redhat.com wrote:
On Wed, 24 Jun 2015, Sean Dague wrote:
On 06/24/2015 07:57 AM, Chris Dent wrote:
If the primary reason is so that we can
On 06/24/2015 01:41 PM, Russell Bryant wrote:
On 06/24/2015 01:31 PM, Joe Gordon wrote:
On Tue, Jun 16, 2015 at 9:58 AM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
Back when Nova first wanted to test partial upgrade, we did a bunch of
slightly odd conditionals inside
On 06/24/2015 01:31 PM, Joe Gordon wrote:
On Tue, Jun 16, 2015 at 9:58 AM, Sean Dague s...@dague.net
mailto:s...@dague.net wrote:
Back when Nova first wanted to test partial upgrade, we did a bunch of
slightly odd conditionals inside of grenade and devstack to make it so
at, because everything can't cross gate with
everything else. Otherwise we'll go back to 100 hr gate queues and bugs
that take a week to resolve in the intertwining.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
of the other bug with
wsgi stuff and keystone.
https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh#L341
So a backport to Kilo is all that's required.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
management system to configure the same
thing in 2 different ways, does seem like a long term win. And honestly
just prohibits most of what people seem to want to do with new messaging
approaches.
-Sean
--
Sean Dague
http://dague.net
package installation,
rootwrap setup. We'll expand the set of contract functions over time,
but all those adds need to come with in tree unit tests so that we can
prevent accidental regressions on the contract.
-Sean
--
Sean Dague
http://dague.net
be approved quickly under normal circumstances. Is
there a reason to hold them up, or are we just short of reviewer time for
that repository?
Sorry - I'll take a quick pass through.
I just went through some of the easy ones, we should have a big flush
shortly.
-Sean
--
Sean Dague
/e498d83db191ccd7fe7c1c2e4f9ec201787d1257
Because you don't really want optional-requirements.txt. You want:
pip install nova nova[libvirt] nova[mysql]
(or something... hand wave on call out)
-Sean
--
Sean Dague
http://dague.net
think we've got to go back to the drawing board about a lot
of things. Yes, it's hard to get that right. But that's kind of the
whole point of the project. :)
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
to an actual oslo.config file somewhere instead? That would bring
it in line with the rest of the RPC configuration for services, and
ensure that all connections in a cluster have access to all the same
options.
-Sean
--
Sean Dague
http://dague.net
in a single control plane (no cells). They had to tweak a bunch of
OpenStack for that to work, but it did.
CERN is running around 10K hosts now, they are running cells, I don't
know how many, but they are super open about it, so I'm sure they would
answer if you ask.
-Sean
--
Sean Dague
http
, != next, and
(=)* last so that it reads as a human range?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
the
same file as swift?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
without audience participation, because being too
close to the technology, I forget what other people know or don't know
about it.
Thanks,
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List
the transport protocol semantics, and
the application. Standard HTTP headers are about the transport protocol
of HTTP, and do not care about your application. Here we're asking
something about the application.
-Sean
--
Sean Dague
http://dague.net
relevent resources. If you choose to implement this, you must
document what criteria is used to return resources from the url. And
allow the possibility that their might be different sensible definitions
depending on the resource, I'm happier about it.
-Sean
--
Sean Dague
http://dague.net
.
-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
On 06/18/2015 06:49 AM, Sean Dague wrote:
On 06/18/2015 03:28 AM, ozamiatin wrote:
Hi, please don't remove zmq support from devstack.
We are now in progress of writing a new version of the driver.
I use devstack each time to check the driver functionality.
When the implementation become
or enhancements for your backend on the
timetable that works for you.
It will make getting the devstack-gate jobs working reliably a lot
simpler and quicker for your team.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
allowing 15 connections per python process, and the APIs are
running in a worker mode, which means 8 workers per API server, yes,
that's going to add up really quick.
Perhaps under these scenarios we need to raise this to 1024 in devstack?
-Sean
--
Sean Dague
http://dague.net
it at 128MB and just let operations go to disk
more often.
Yeh, we are trying to stay useful on 4G VMs, we did turn off some
default services for that reason. So lets not up memory unless we have to.
-Sean
--
Sean Dague
http://dague.net
801 - 900 of 1956 matches
Mail list logo
