ted does impose a
tax on the rate the team can change the project so that stable contracts
are kept up.
Honestly, I don't want this to be about stigma of "kicking something
out", but more about openning up freedom and flexibility to research out
this space, which has shown to b
A state.
> If the '--strict' arg is added it will also filter out any patches which
> have a -1 code review comment.
>
> Regards,
> Daniel
>
> [1] http://russellbryant.net/openstack-stats/nova-reviewers-30.txt
> [2]
> https://github.com/berrange/ger
it message (static) but by
our system that understands what are the gate issues *right now* (dynamic).
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
public
> integration testing at this time for the modules, although I know some
> parties have developed and maintain their own.
>
> The Chef modules may be in a different state, but it's hard for me to
> recommend the Puppet modules become part of an official program at this
> s
in a non functional state, 100%
of things will fail, and not have people approve things that can't pass?
These kind of issues are the ones that make me uncomfortable with the
Glance team taking on more mission until basic review hygiene is under
control for the existing code.
-Sean
On 08/22/2014 07:22 AM, Daniel P. Berrange wrote:
> On Fri, Aug 22, 2014 at 07:09:10AM -0500, Sean Dague wrote:
>> Earlier this week the freshness checks (the ones that required passing
>> results within 24 hrs for a change to go into the gate) were removed to
>> try to conser
tent,
large ecosystem. The Linux Kernel stops at a certain function point for
a reason. That didn't prevent a ton of exceptionally useful function to
exist above it. But it also mean that things like c library / init
system / packaging / compilers were things where innovation could pla
lks -1 for things that they feel are wrong
(or missing to the point that this isn't useful if it lands without it).
Additional enhancements can come as follow ons. But having a basic
upgrade of this readme should help a lot on clarity.
-Sean
--
Sean Dague
h
+2 on this moving forward. I feel that the keystone team answered
the questions needed.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 08/26/2014 11:40 AM, Anne Gentle wrote:
>
>
>
> On Mon, Aug 25, 2014 at 8:36 AM, Sean Dague <mailto:[email protected]>> wrote:
>
> On 08/20/2014 12:37 PM, Zane Bitter wrote:
> > On 11/08/14 05:24, Thierry Carrez wrote:
> >> So the idea th
should lose a slot from days 1 - 3 and expand the
hallway time. Hallway track is always pretty interesting, and honestly
at a lot of interesting ideas spring up. The 10 minute transitions often
seem to feel like you are rushing between places too quickly some times.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
it editable (because it's a part that's under more interesting
rapid development).
So I'd like us to revisit using a namespace for glance, and honestly,
for other places in OpenStack, because these kinds of violations of the
principle of least sur
On 08/27/2014 11:14 AM, Flavio Percoco wrote:
> On 08/27/2014 04:31 PM, Sean Dague wrote:
>> So this change came in with adding glance.store -
>> https://review.openstack.org/#/c/115265/5/lib/glance, which I think is a
>> bad direction to be headed.
>>
>> Her
to learn" at the generic level something that's hard to grasp onto
or figure out how we turn it into action. I'd love to hear more ideas
from folks about ways we might do that better.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 08/27/2014 03:33 PM, David Kranz wrote:
> On 08/27/2014 02:54 PM, Sean Dague wrote:
>> Note: thread intentionally broken, this is really a different topic.
>>
>> On 08/27/2014 02:30 PM, Doug Hellmann wrote:>
>>> On Aug 27, 2014, at 1:30 PM, Chris Dent wrote:
&
On 08/27/2014 05:27 PM, Doug Hellmann wrote:
>
> On Aug 27, 2014, at 2:54 PM, Sean Dague wrote:
>
>> Note: thread intentionally broken, this is really a different topic.
>>
>> On 08/27/2014 02:30 PM, Doug Hellmann wrote:>
>>> On Aug 27, 2014, at 1:30 PM,
think
reflects reality.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 08/28/2014 12:22 PM, Doug Hellmann wrote:
>
> On Aug 28, 2014, at 6:41 AM, Radomir Dopieralski
> wrote:
>
>> On 27/08/14 16:31, Sean Dague wrote:
>>
>> [snip]
>>
>>> In python 2.7 (using pip) namespaces are a bolt on because of the way
>>
On 08/28/2014 12:48 PM, Doug Hellmann wrote:
>
> On Aug 27, 2014, at 5:56 PM, Sean Dague wrote:
>
>> On 08/27/2014 05:27 PM, Doug Hellmann wrote:
>>>
>>> On Aug 27, 2014, at 2:54 PM, Sean Dague wrote:
>>>
>>>> Note: thread intentionally bro
On 08/28/2014 01:48 PM, Doug Hellmann wrote:
>
> On Aug 28, 2014, at 1:17 PM, Sean Dague wrote:
>
>> On 08/28/2014 12:48 PM, Doug Hellmann wrote:
>>>
>>> On Aug 27, 2014, at 5:56 PM, Sean Dague wrote:
>>>
>>>> On 08/27/2014 05:27 PM, Doug H
On 08/28/2014 02:07 PM, Joe Gordon wrote:
>
>
>
> On Thu, Aug 28, 2014 at 10:17 AM, Sean Dague <mailto:[email protected]>> wrote:
>
> On 08/28/2014 12:48 PM, Doug Hellmann wrote:
> >
> > On Aug 27, 2014, at 5:56 PM, Sean Dague <mailto:s
ke open unscheduled time to
>>> discuss whatever is hot at this point.
>>>
>>> There are still details to work out (is it possible split the
>>> space, should we use the usual design summit CFP website to
>>> organize the "scheduled" time...), but
On 08/28/2014 03:06 PM, Jay Pipes wrote:
> On 08/28/2014 02:21 PM, Sean Dague wrote:
>> On 08/28/2014 01:58 PM, Jay Pipes wrote:
>>> On 08/27/2014 11:34 AM, Doug Hellmann wrote:
>>>>
>>>> On Aug 27, 2014, at 8:51 AM, Thierry Carrez
>>>>
es or directories to throw out of the walk.
I think that would handle the concerns that everyone is having, and
hopefully provides a more clear set of semantics in integrating.
Anyone up for taking a stab at this patch?
-Sean
--
Sean Dague
http://dagu
On 08/29/2014 08:53 AM, Dean Troyer wrote:
> On Fri, Aug 29, 2014 at 7:42 AM, Sean Dague <mailto:[email protected]>> wrote:
>
> Integrating bashate into something as complicated as devstack, the file
> ignore problem has come up.
>
> We seem to have 3 approa
(which is usually what you want),
and the response object is accessible if needed to examine headers.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/01/2014 01:38 AM, Ian Wienand wrote:
> On 08/29/2014 10:42 PM, Sean Dague wrote:
>> I'm actually kind of convinced now that none of these approaches are
>> what we need, and that we should instead have a .bashateignore file in
>> the root dir for the project ins
drivers team on whether getting
the API on track is deemed important enough to go this approach during
the Juno RC phase. All opinions welcome.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
the order it is. Changing the order has impacts
on the overall integration which can cause wedges later.
So please stop.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openst
m
>
>
>
> ___
> OpenStack-dev mailing list
> [email protected]
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/03/2014 09:03 AM, Daniel P. Berrange wrote:
> On Wed, Sep 03, 2014 at 08:37:17AM -0400, Sean Dague wrote:
>> I'm not sure why people keep showing up with "sort requirements" patches
>> like - https://review.openstack.org/#/c/76817/6, however, they do.
>>
erwise we would be
> blocked on cutting an os-collect-config release).
Ok, given the details of the bug, I'd be ok with a != 2.4.0, it looks
like they are working on a merge now.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
branch:master+topic:bp/branchless-tempest-extensions,n,z
> [4] https://bugs.launchpad.net/nova/+bug/1305892
> [5] https://review.openstack.org/#/c/115022/
> [6] https://review.openstack.org/#/c/115023/
+1
I realistically think that we should think about neutron as 2 things.
The L2
side of it's control, and that's kind of unfortunate, as
Flavio and team have been doing a bang up job of late. But we need to
stop considering "integration" as the end game of all interesting
software in the OpenStack ecosystem, and I think it's better to have
that conversation sooner rather than later.
Anyway, my $0.02.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
arbutt
> Me
Sign me up as a sponsor as well. I think the scope is highly constrained
here, and risk to the rest of the project is low.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
arty/user testing for those).
This statement bugs me. It seems kind of backwards to say we should
merge a thing that we don't have a good upstream test plan on and put it
in a release so that the testing will happen only in the downstream case.
Anyway, not enough to -1 it, but enough
one" we could take this, but this
needs to become a larger overall push for the project as a whole, as I
think our use exposed interface here is inhibiting adoption.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/04/2014 09:21 AM, Daniel P. Berrange wrote:
> On Thu, Sep 04, 2014 at 03:07:24PM +0200, Nikola Đipanov wrote:
>> On 09/04/2014 02:31 PM, Sean Dague wrote:
>>> On 09/04/2014 07:58 AM, Nikola Đipanov wrote:
>>>> Hi team,
>>>>
>>>> I am req
es and added my +2 to them, so
they are ready to merge should the FFE be approved.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ated feature so risk to other existing code is low.
I'm happy to sponsor this one. The last patch is pretty straight
forward, I think one change around the way barbican is included should
make it ready (reviewed yesterday).
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t forward, I just reviewed it, and am
happy with it in it's current state, so can sponsor.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
equation, because the point is in core is to have trust over the
judgement of your fellow core members so that they can land code when
you aren't looking. I'm not sure how I manage to build up half trust in
someone any quicker.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
before.
Agreed. Honestly, this has been a really nice flow. I'd love to figure
out what part of this focus is capturable for normal cadence. This
realistically is what I was hoping slots would provide, because I feel
like we actually move really fast when we call out 5-10 things to go
look at this week.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
s by the
CI requirements: let's let Class C back in tree. I believe in the
Freebsd case you were one of the original opponents to a top level
driver, and that they should go through libvirt instead. But I'm cool
with them just showing up as a Class C.
But I honestly don'
d for the cells path.
The Scheduler has a ton of debt as has been pointed out by the efforts
in and around Gannt. The focus has been on the split, but realistically
I'm with Jay is that we should focus on the debt, and exposing a REST
interface in Nova.
What about the Nova objects transition? That continues to be slow
because it's basically Dan (with a few other helpers from time to time).
Would it be helpful if we did an all hands on deck transition of the
rest of Nova for K1 and just get it done? Would be nice to have the bulk
of Nova core working on one thing like this and actually be in shared
context with everyone else for a while.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
tack-dev] [Zaqar] Comments on the concerns arose during
>>> the TC meeting
>>>
>>> Sean Dague wrote:
>>>> [...]
>>>> So, honestly, I'll probably remain -1 on the final integration vote,
>>>> not because Zaqar is bad, but because
On 09/05/2014 07:26 AM, Daniel P. Berrange wrote:
> On Fri, Sep 05, 2014 at 07:00:44AM -0400, Sean Dague wrote:
>> On 09/05/2014 06:22 AM, Daniel P. Berrange wrote:
>>> On Fri, Sep 05, 2014 at 07:31:50PM +0930, Christopher Yeoh wrote:
>>>> On Thu, 4 Sep 2014 11:24:29
On 09/05/2014 07:40 AM, Daniel P. Berrange wrote:
> On Fri, Sep 05, 2014 at 07:12:37AM -0400, Sean Dague wrote:
>> On 09/05/2014 06:40 AM, Nikola Đipanov wrote:
>>> A handy example of this I can think of is the currently granted FFE for
>>> serial consoles - consider how
gt;>
>> The patch has got a +2 from the core and pretty close to merge, but FF came.
>
> ACK, I'll sponsor this.
>
> It is such a simple & useful patch it is madness to reject it on a process
> technicality.
>
> Regards,
> D
gt;>
>> The patch has got a +2 from the core and pretty close to merge, but FF came.
>
> ACK, I'll sponsor this.
>
> It is such a simple & useful patch it is madness to reject it on a process
> technicality.
>
> Regards,
> D
On 09/05/2014 07:39 AM, Robert Collins wrote:
> On 5 September 2014 23:33, Sean Dague wrote:
>
>> I think realistically a self certification process that would have
>> artifacts in a discoverable place. I was thinking something along the
>> lines of a baseball car
yption blueprint
> which I've already sponsor. So we should consider FFE for both those
> blueprints together, rather than in isolation.
Agreed, I kind of assumed we were thinking about them as one thing.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/05/2014 08:11 AM, Sean Dague wrote:
> On 09/05/2014 07:51 AM, Daniel P. Berrange wrote:
>> On Thu, Sep 04, 2014 at 05:19:45PM +, Coffman, Joel M. wrote:
>>> A major concern about several encryption features within Nova [1, 2] has
>>> been the lack of secure
x27;m happy to sponsor these extra changesets - I've reviewed them all
> previously. Risk to the rest of Nova is very low.
I'll also sponsor them, they also have the nice effect of being negative
KLOC patches.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
x27;s easy enough to
spin up that dev env that has it.
Which feels like we need some decoupling on our requirements vs. tox
targets to get there. CC to Monty and Clark as our super awesome tox
hackers to help figure out if there is a path forward here that makes sense.
-Sean
--
Sean Da
enstack.org/cgi-bin/mailman/listinfo/openstack-dev
These look like they are also all blocked by Tempest because it's
changing return chunks. How does one propose to resolve that, as I don't
think there is an agreed path up there for to get this into a passing
state from my r
hink it could wind up
>> being a pretty useful tool for folks outside of OpenStack too if we
>> get it right.
>
> Given availability (currently an unknown) I'd like to help with this.
I think all this is very cool, I'd say if we're going to put it in
gerrit d
> On Sat, Sep 6, 2014 at 2:20 AM, Day, Phil wrote:
>> The corresponding Tempest change is also ready to roll (thanks to Ken'inci):
>> https://review.openstack.org/#/c/112474/1 so its kind of just a question
>> of getting the sequence right.
>>
>> Phil
&g
ng in here doubles the
review bandwidth, it just provides us with less review coverage.
I'm currently less convinced that raw core merge speed is our primary
issue right now. I think it's a symptom of accumulated debt, and
complexity growth from the features over the last couple of
On 09/08/2014 11:07 AM, Alexis Lee wrote:
> Sean Dague said on Mon, Sep 08, 2014 at 09:22:56AM -0400:
>>> On 09/08/2014 05:17 AM, Steven Hardy wrote:
>>>> I think this may be a sensible move, but only if it's used primarily to
>>>> land the less complex/r
On 09/08/2014 08:18 PM, James E. Blair wrote:
> Sean Dague writes:
>
>> The crux of the issue is that zookeeper python modules are C extensions.
>> So you have to either install from packages (which we don't do in unit
>> tests) or install from pip, which means f
it easy for
everyone to have access to the code, and makes the testability by other
systems viable.
I currently don't see any designate changes that are passing Jenkins
that need to be addressed, is there something that got missed?
-Sean
--
Sean Dague
http://dague.net
On 09/09/2014 10:41 AM, Doug Hellmann wrote:
>
> On Sep 8, 2014, at 8:18 PM, James E. Blair wrote:
>
>> Sean Dague writes:
>>
>>> The crux of the issue is that zookeeper python modules are C extensions.
>>> So you have to either install from packages (
On 09/09/2014 12:23 PM, Mac Innes, Kiall wrote:
>> -Original Message-
>> From: Sean Dague [mailto:[email protected]]
>> Sent: 09 September 2014 15:13
>> To: [email protected]
>> Subject: Re: [openstack-dev] [Designate][Horizon][Tempest][De
point unless there is a high priority bug
around them.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
token
expiration boundary.
Anyone closer to the clients that can comment here?
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
fact that the old APIs are going away, we should be fine.
>
> In summary, +1 to moving forward without the API proxy requirement.
The thing is, we have the patch -
https://review.openstack.org/#/c/120433/, so it's not like there is a
zomg run around to get the patch.
I think we should
e service client itself.
>
> 2014-09-10 16:14 GMT+02:00 Sean Dague <mailto:[email protected]>>:
>
> Going through the untriaged Nova bugs, and there are a few on a similar
> pattern:
>
> Nova operation in progress takes a while
> Crosses keystone
ld we just purge those links?
Thanks,
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
nd
> then having them discover later that something broke because they tried to
> create a node.
>
> Best Regards,
> Solly Ross
>
> - Original Message -
>> From: "Sean Dague"
>> To: [email protected]
>> Sent: Wednesday, Sep
rything? Is it too
> difficult/impossible due to the differences between Baremetal and
> Ironic? And if they're that different, does it still make sense to
> allow one to look like the other? As it stands, this isn't going to
> let deployers use their existing tools withou
ewhere. I think more common
infrastructure for virt drivers would be a good thing, and make the code
a lot more understandable. And as it's the prereq for any of this, so
let's do it.
Why don't we start with "let's clean up the virt interface and make it
more sane", as I d
7;t see 'tox -epy27 libvirt' to be an unreasonable
invocation, but we can create some additional targets in tox to make
life simpler.
Anyway, at the end of the day, my feeling is:
* Pay down debt in virt layer abstraction: +1
* Speed up tests in common ways (especially pep8): +1
* Don't have 3rd Party team run non relevant tests: +1
* Split out the virt drivers into separate repos: -1
That being said that split is at least 7 months (if not 12 or 15) away.
So I don't think we even need to make that decision at this point. There
is a ton of stuff that needs to get done regardless. Paying down that
debt in the virt layer will make the whole thing easier to review and in
6 months time we can assess if we think that the biggest inhibitor to
Nova is really that split.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
: Re: [openstack-dev] [all] [clients] [keystone] lack of retrying
>> tokens leads to overall OpenStack fragility
>>
>> On Wed, Sep 10, 2014 at 10:14:32AM -0400, Sean Dague wrote:
>>> Going through the untriaged Nova bugs, and there are a few on a similar
>>> pattern
On 09/10/2014 11:55 AM, Steven Hardy wrote:
> On Wed, Sep 10, 2014 at 10:14:32AM -0400, Sean Dague wrote:
>> Going through the untriaged Nova bugs, and there are a few on a similar
>> pattern:
>>
>> Nova operation in progress takes a while
>> Crosses keystone
On 09/11/2014 09:09 AM, Gary Kotton wrote:
>
>
> On 9/11/14, 2:55 PM, "Thierry Carrez" wrote:
>
>> Sean Dague wrote:
>>> [...]
>>> Why don't we start with "let's clean up the virt interface and make it
>>> more sane",
On 09/11/2014 11:14 AM, Gary Kotton wrote:
>
>
> On 9/11/14, 4:30 PM, "Sean Dague" wrote:
>
>> On 09/11/2014 09:09 AM, Gary Kotton wrote:
>>>
>>>
>>> On 9/11/14, 2:55 PM, "Thierry Carrez" wrote:
>>>
>>>>
d destroys usability of the code because there is so much
garbage printed out.
> The best i can say for standardization is that when glanceclient adopts the
> session it will be handled the same way as all the other clients and
> improvements can happen there without you having to worr
critical bug fixes
only, as we start to stabalize the tree. Releasing dependent libraries
that can cause breaks, for whatever reason, should be soundly avoided.
If this was August, fine. But it's feature freeze.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP
r git tree (win!). It
doesn't seem to impact what pip installs... and if anyone knows how to
prevent those pyc files from getting created, that would be great.
But it's something which hopefully causes less perceived developer
fragility of the system.
-Sean
--
Sean Da
On 09/12/2014 11:21 AM, Mike Bayer wrote:
>
> On Sep 12, 2014, at 7:39 AM, Sean Dague wrote:
>
>> I assume you, gentle OpenStack developers, often find yourself in a hair
>> tearing out moment of frustration about why local unit tests are doing
>> completely insane
On 09/12/2014 11:19 AM, Doug Hellmann wrote:
>
> On Sep 12, 2014, at 9:23 AM, Ihar Hrachyshka wrote:
>
>> Signed PGP part
>> On 12/09/14 13:20, Sean Dague wrote:
>>> On 09/12/2014 06:41 AM, Ihar Hrachyshka wrote:
>>>> Some updates/concerns/questions.
On 09/12/2014 11:33 AM, Mike Bayer wrote:
>
> On Sep 12, 2014, at 11:24 AM, Sean Dague wrote:
>
>> On 09/12/2014 11:21 AM, Mike Bayer wrote:
>>>
>>> On Sep 12, 2014, at 7:39 AM, Sean Dague wrote:
>>>
>>>> I assume you, gentle OpenStack deve
On 09/12/2014 11:52 AM, Doug Hellmann wrote:
>
> On Sep 12, 2014, at 11:21 AM, Mike Bayer wrote:
>
>>
>> On Sep 12, 2014, at 7:39 AM, Sean Dague wrote:
>>
>>> I assume you, gentle OpenStack developers, often find yourself in a hair
>>> tearing o
On 09/12/2014 12:07 PM, Mike Bayer wrote:
>
> On Sep 12, 2014, at 12:03 PM, Sean Dague wrote:
>
>> On 09/12/2014 11:33 AM, Mike Bayer wrote:
>>>
>>> On Sep 12, 2014, at 11:24 AM, Sean Dague wrote:
>>>
>>>> On 09/12/2014 11:21 AM, Mike Baye
On 09/12/2014 01:14 PM, Doug Hellmann wrote:
>
> On Sep 12, 2014, at 12:03 PM, Sean Dague wrote:
>
>> On 09/12/2014 11:52 AM, Doug Hellmann wrote:
>>>
>>> On Sep 12, 2014, at 11:21 AM, Mike Bayer wrote:
>>>
>>>>
>>>> On Se
." and "!"
>
> On v2.1 API, we have applied the same restriction rule[1] for whole resource
> names for API consistency, so maybe we need to consider this topic for whole
> names.
>
> [1]:
> https://github.com/openstack/nova/blob/master/nova/api/validation/param
ial explosion
> of test jobs is going to kill us.
One of the top issues killing Nova patches last week was a unit test
race (the wsgi worker one). There is no one to blame but Nova for that.
Jay was really the only team member digging into it.
I don't disagree on the disaggregation problem,
same behavior as Icehouse, I'm fine with a bug fix at
this point in the cycle. If this reverses behavior in Icehouse, I feel
like we should wait until Kilo.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
t: When you call that API you need to also call this other
> API to poll for it to be done... is nova doing that?
> nova-expert: Nope. Fix on the way.
Honestly, the #openstack-qa channel is a completely appropriate place
for that. Plus it already has a lot of the tempest experts.
Realistically anyone that works on these kinds of fixes tend to be there.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
pefully a part of the solution to address that.
As I've told others, if nothing else, I'm looking forward to learning a
ton in the process.
Final links for the hangout + etherpad will be posted a little later in
the week. Mostly wanted to make people aware it was coming.
ilure of the service, so
> perhaps it is excessive to log it at WARN or ERROR.
>
> Please provide feedback to help us resolve this dispute if you feel you can!
My feeling is this is an INFO level. There is really nothing the admin
should care about here
ontext, it's running in
the Nova context. Which means it needs to think of itself in that context.
In that context we got the exception back from Glance, we know the image
wasn't there. And we know whether or not that's a problem (glanceclient
actually has no idea if it's a proble
anceclient's logging is rediculous, and you
should ignore it (for instance), because it spews a ton of ERRORS for no
good reason.
Basically that's the key skill. Understanding the request flows that go
through OpenStack, understanding how to read OpenStack logs, and bei
ocks are moved from the iptables
>> firewall driver to IpsetManager, and the corresponding tests are moved too.
>> [...]
>
> IMHO code refactoring should be considered a superfluous change at this
> point in the cycle. The risk/benefit ratio is too high, and focus
bugs of varying difficulties to point people to. Make this a
>> regular fortnightly or even weekly event which we publicise in advance
>> on mailing lists, etc.
>
> +1, I've suggested similar in the past.
+1 a weekly event would be great.
I've spent the bulk of
On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
>> -Original Message-
>> From: Sean Dague [mailto:[email protected]]
>> Sent: 16 September 2014 12:40
>> To: [email protected]
>> Subject: Re: [openstack-dev] [glance][all] Help with interpreting t
On 09/16/2014 12:07 PM, Kuvaja, Erno wrote:
>> -Original Message-
>> From: Sean Dague [mailto:[email protected]]
>> Sent: 16 September 2014 15:56
>> To: [email protected]
>> Subject: Re: [openstack-dev] [glance][all] Help with interpreting t
omeone creates a job in infra, the magic elves are
responsible for it.
But there are no magic elves. So jobs like this need sponsors.
Maybe the right thing to do is not conflate this configuration and put
an eventlet version of the keystone job only on keystone (because the
keystone team was the one that proposed having a config like that, but
it's so far away from their project they aren't ever noticing when it's
regressing).
Same issue with the metadata server split. That's really only a thing
Nova cares about. It shouldn't impact anyone else.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 09/18/2014 06:38 AM, Christopher Yeoh wrote:
> On Sat, 13 Sep 2014 06:48:19 -0400
> Sean Dague wrote:
>
>> On 09/13/2014 02:28 AM, Kenichi Oomichi wrote:
>>>
>>> Hi Chris,
>>>
>>> Thanks for bring it up here,
>>>
>>>&
1 - 100 of 2095 matches
Mail list logo
