ssion.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
sean%2540dague.net,n,z
[3] - https://www.ohloh.net/accounts/sdague
[4] - https://github.com/sdague/
[5] - http://mhvlug.org
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
(which should be easy to
backport).
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
small number of actual in flight
blueprints before we start adding more for icehouse.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
arts.
It's good for the project, as it keeps us whole; it's good for everyone
working on the project, because they learn about more parts of
OpenStack, and how their part fits in with the overall system; and it
makes everyone better developers from learning from each other, on both
s
236/
>
>
>
> Thanks,
> *
> MATT RIEDEMANN*
> Advisory Software Engineer
> Cloud Solutions and OpenStack Development
>--
>
> *Phone:* 1-507-253-7622 | *Mobile:* 1-507-990-1889*
> E-mail:* mrie...@us.ibm.com
>
> [image: IBM]
>
> 3605 Hwy 52 N
> Rochester, MN 55901-1407
> United States
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> [attachment "ATT1..gif" deleted by Matt Riedemann/Rochester/IBM]
> [attachment "ATT2..gif" deleted by Matt Riedemann/Rochester/IBM]
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Sean Dague
http://dague.net
<>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
leak for release for a while. All the
people that helped out and got us through this deserve a huge pat on the
back. That's what OpenStack is about.
So I feel pretty strongly that optimizing the contribution process for
people that aren't helping with that larger problem, is the tr
great place to highlight reviews you feel
are critical that need eyes, and it happens every week on a regular
schedule.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
es.
But OpenStack still moves crazy fast, and making process changes with
sweeping future implications is something that needs to not be done
lightly. And there are lots of other things to be done to make this
better, which all kinds of people can help with.
-Sean
--
Sean Dague
http://dague
er so quickly.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ully.
PS did you look at the numbers?
http://www.openstack.org/software/havana/
http://blog.bitergia.com/2013/10/17/the-openstack-havana-release/
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
#x27;s better to react
quickly, then to hide behind a pin, and not realize that we're massively
broken with the latest versions of libraries out there.
That being said, because WSME is in stackforge, I think we could
actually do better than just take our lumps. But I think that&#
ed projects, so that we get our biggest bang
for our buck.
Also, realize in a tempest environment there is only going to be the
latest version of the clients, so this is going to massively reduce your
test environment from what you have today.
-Sean
--
Sean Dague
http://dague.net
tempest scope to include client libs, we really need to do so somewhat
systematically to cover all the clients, so we don't end up with just a
few keystone client tests and that's it.
-Sean
--
Sean Dague
http://dague.net
___
On 10/18/2013 05:09 PM, Dolph Mathews wrote:
On Fri, Oct 18, 2013 at 3:19 PM, David Stanek mailto:dsta...@dstanek.com>> wrote:
On Fri, Oct 18, 2013 at 1:48 PM, Sean Dague mailto:s...@dague.net>> wrote:
On 10/18/2013 12:04 PM, Brant Knudson wrote:
2) &q
On 10/18/2013 09:10 PM, Adam Young wrote:
On 10/18/2013 07:21 PM, Sean Dague wrote:
On 10/18/2013 05:09 PM, Dolph Mathews wrote:
On Fri, Oct 18, 2013 at 3:19 PM, David Stanek mailto:dsta...@dstanek.com>> wrote:
On Fri, Oct 18, 2013 at 1:48 PM, Sean Dague mailto:s...@dague.net&g
On 10/19/2013 04:46 AM, Steven Hardy wrote:
On Fri, Oct 18, 2013 at 01:48:08PM -0400, Sean Dague wrote:
So v3 keystone API is one thing, but I'm a little concerned with
moving the client testing to Tempest haphazardly. If we are testing
the API surface on the servers, the clients shou
interpretations on
this list).
Perhaps it's time to open up that giant can of worms again and try to
get more specific on copyright requirements though I'm not sure the
discussion would end up any differently.
-Sean
--
Sean Dague
http://dague.net
_
than it could be. I'd like us to get the full
bang for our buck out of efforts like this, especially if there is hope
for it to graduate from stackforge into one of our standard toolkits.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e something is wrong in the integration, and would be
really helpful if we could get ceilometer eyes on this one to put ceilo
into a non erroring state.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@list
hon-gerrit.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ke it to summit, and lets come up with a
more holistic plan there.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ff the rails, like we
did last week for a few days, and quantify long term variability and
trends in the stack). It's harder in the short term to do that, because
it means compromises along the way, but the long term benefit to
OpenStack is much greater than another project which duplicate
onal, it's spewing errors, a lot.
This really ought to be a top ceilometer item to address, otherwise we
should probably turn off celiometer in devstack by default, because it's
really not working at the moment.
-Sean
--
Sean Da
On 10/23/2013 10:40 AM, John Griffith wrote:
On Sun, Oct 20, 2013 at 7:38 AM, Sean Dague mailto:s...@dague.net>> wrote:
Dave Kranz has been building a system so that we can ensure that
during a Tempest run services don't spew ERRORs in the logs.
Eventually, we're
would be
happy with a cheet sheet that helps them figure out what log level
different things are presented at.
Comments / rotten fruit are welcomed. Also welcomed are any additional
POV on this issue.
-Sean
--
Sean Dague
http://dague.net
_
more into standard INFO.
Again, more concrete instances like the iscsi case, are probably the
most helpful. I think in the abstract this problem is too hard to solve,
but with examples, we can probably come to some concensus.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
e the network traffix needed for tox.
Also, I believe 1.6.1 will reuse envs by default.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/open
ld that be useful?
I'm not actually trying to pick on conductor here, but it makes a good
example of a service that DEBUG level is extremely useful to
development, and is used heavily, and might make us thing about multi
levels of DEBUG to go deeper down the rabbit hole only if we really
eally quick
when everything blackholes.
In the gate this is slightly funnier because tempest is running on the
same place as the host, however it seems like a sane check to have in there.
-Sean
--
Sean Dague
http://dague.net
___
OpenStac
, it makes it a ton easier
for people that are jumping between tracks to only have one master entry
point to be able to get to everything.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
y reads. So hints at implementing
this would be good.
-Sean
--
Sean Dague
http://dague.net
project_group
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 10/28/2013 06:20 AM, Thierry Carrez wrote:
Sean Dague wrote:
As my searching did not yet return an Icehouse design summit pages in
the wiki with etherpads, I built it here -
https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads
Thanks for creating it.
For consistency it would be
test, only ZUUL knows. And, as you can
see, we've yet to get this whole thing mapped out the first time. :)
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
house/Etherpads#QA
Please make sure to update your etherpads with content as soon as you
can. It's going to be a busy summit, so early prep is always good. :)
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
Ope
-column terminal windows is essential.
-2
-2 as well. Depending on my monitor I'm either doing 2 column or 3
column development in emacs with OpenStack code. Changing from 80
columns would inhibit that.
-Sean
--
Sean Dague
http://dagu
to be really solid discussion about the trade offs here
before contemplating something as dangerous as this.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cg
xt fire.
This was actually as C class problem (which is why no one else had done
it yet), and required building new devstack job to complete. However the
benefits were really high on it.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mai
On 10/31/2013 11:23 AM, Jay Pipes wrote:
On 10/31/2013 08:01 AM, Sean Dague wrote:
So there is a series of patches starting with -
https://review.openstack.org/#/c/53417/ that go back and radically
change existing migration files.
This is really a no-no, unless there is a critical bug fix that
Actually no confusion. :-) Joe Gordon just made me realize that I didn't
really explain why we had that policy.
That really should have been a follow up to my own post, not yours. Sorry
if I made it look like I was arguing with you, which I wasn't.. :-)
We're all good.
ython clients talk JSON). So this isn't
very surprising. Thanks again for diving into it!
Honestly, one of these days we should have another serious conversation
about dropping XML entirely again (across all projects). A single data
payload that works is way better than additional payloa
On 11/01/2013 06:27 AM, John Garbutt wrote:
On 31 October 2013 16:57, Johannes Erdfelt wrote:
On Thu, Oct 31, 2013, Sean Dague wrote:
So there is a series of patches starting with -
https://review.openstack.org/#/c/53417/ that go back and radically
change existing migration files.
I
never
> be touched?
If we have a way to automatically validate the new final results vs. the
old final results, including carrying interesting edge condition data
through it, yes, absolutely.
Many things move from "verboten" to "acceptable" with sufficient
is
needs to be done right, and not even have the appearance that the
groupings were created just to make certain organizations float to the
top. So lets get these right. I'd love to permanently retire gitdm, but
until stackalytics actually counts things the way the project is
organized, it&#x
high race failure rate, it would be really good if
the neutron team could prioritize addressing this. I realize it's summit
week, so things are slow, but please ensure this comes up as part of the
overall discussion.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Descriptio
code.
>>>
>>> But 45% is a really high race failure rate, it would be really good if
>>> the neutron team could prioritize addressing this. I realize it's summit
>>> week, so things are slow, but please ensure this comes up as p
. It has some built in things like
>> coloring the words "warn" or "warning" yellow and "error" red. It would
>> be great to have this filter added as another ccze plugin.
>>
>
> Sean Dague, wrote a really slick tool for logs.openstack.org that is
&g
he code was done in the way it was, so I
> ask. Before I get the answer I'm not really qualified to judge the
> merits.
+1 to this.
Realistically if I have questions in the code and am unsure how I'd
score it I'll often leave a 0 review with questions inline to help me
. (Not with the minor nit though...)
Agreed, the comments are there for a reason. It's also handy to provide
forward looking statements to other reviewers in case you don't get back
to the review queue right away.
For instance when I know that might happen I tend to leave comments lik
Stack (incredible to believe). This is where
non core reviewers can really help in addressing the first couple of
rounds of review to prune and improve the easy stuff.
We're all in this together,
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signatu
end client to mark review threads read that are past.
On Thu, Nov 7, 2013 at 8:40 PM, David Ripton wrote:
> On 11/07/2013 07:54 PM, Sean Dague wrote:
>>
>> On 11/08/2013 01:37 AM, Pedro Roque Marques wrote:
>>>
>>> Radomir,
>>> An extra issue that i don&
yone has any similar experience or suggestions of further steps I
> could take to get to the root of this, I'd be most grateful to hear them.
>
> Tom
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.o
at the code. But I'd hate to have
this giant gauntlet of grammar before the code is getting looked at by
+2ers. That seems a pretty high discouragement to new non native English
speakers.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital si
ople, not vendors".
I really don't want to see us go away from that, I see that as a core
strength of our community. If entities are very concerned that their
name comes with their contribution, get the contributor to land patches
with an email address from the org in question.
neutron team to do that.
So any tempest patch that has a +1 from a neutron core, consider it to
have an exception from the moratorium.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-d
gate story?
- what about an upgrade deprecation path (i.e. nova-network =>
neutron, nova-baremetal => ironic)
1.
http://hackstack.org/x/blog/2013/09/05/openstack-seven-layer-dip-as-a-service/
(the layers pattern is useful from a testing requirements model)
--
Sean D
has ideas about it? Should we remove
>> such testcases?
>>
>> Regards,
>> Zhi Kun
>>
>> _______
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman
from the session -
https://etherpad.openstack.org/p/icehouse-summit-qa-negative-tests -
it's actually probably a little sparser than it should be.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
On 11/13/2013 07:49 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> [...] Proposed Incubation requirements
>> Once something becomes an
>> integrated project, it's important that they are able to run in the
>> gate.
>
>
On 11/13/2013 02:06 PM, Joe Gordon wrote:
>
>
>
> On Wed, Nov 13, 2013 at 8:18 PM, Sean Dague <mailto:s...@dague.net>> wrote:
>
> On 11/12/2013 10:25 PM, Robert Collins wrote:
> > We shouldn't really be changing the config of the cloud we'r
ot useful.
Bringing up for debate the style guide every time it disagrees with your
personal preference isn't a very effective use of people's time.
Especially on settled matters.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
t of their preference), while
> openstack-dev would be focused on openstack official programs (including
> incubated & integrated projects).
+1
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
_
xperienced the different cultures across
projects, the level of coherency in their core teams, and the quality of
software that comes out the other end. Honestly, Nova is doing a better
job than just about anyone else, when we quantify it on the metric I
think we all most care about: final quality. S
d up no longer being majority
north american, or even majority english as first language (that kind of
excites me). Adjusting to both there will be another mailing list thread
about changing our weekly meeting time to make it more friendly to our
APAC contributors.
-Sean
--
Sean Dagu
es upstream to devstack repository.
Thanks
Deepinder
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sean Dague
http://dague.net
___
t;>
>> [1] https://etherpad.openstack.org/p/icehouse-neutron-nova-parity
>> [2] https://etherpad.openstack.org/p/icehouse-summit-qa-neutron
>>
>> --
>> Russell Bryant
>>
>> ___
>> OpenStack-dev mailing
On 11/15/2013 12:57 PM, Mark McLoughlin wrote:
> On Wed, 2013-11-13 at 06:57 -0500, Sean Dague wrote:
>> (Apologies, this started on the TC list, and really should have started
>> on -dev, correctly posting here now for open discussion)
>>
>> There were a few chats at s
ron channel, so I
think right now planning for success is good. But again, we need some
aggressive check points, and people need to realize this is not the
beginning of this work, it is the closing session.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: Ope
we should all wear our "project hats", that our affiliation
> should be secondary to our commitment to our project, ...
>
> Dictating what people can wear to an OpenStack event is not my idea of
> what OpenStack is all about. It's not my idea of the "mutual
subset of us that
would find that useful, and it would move the traffic off of -dev.
Honestly, I don't the QA meeting post to the main list because of
volume, but if we had a separate place for that, it would be cool.
-Sean
--
Sean Dague
http://dague.net
signature
CZFxPEq8%3D%0A&m=VL2%2F41a4nc9qu2UHN5inNr9%2FGGz5
>>>fBDhLKNRNs4pcNw%3D%0A&s=028348b32601b6806fc8e7087b63e4a6858297905224ae85b0
>>>d81a494c39f5fb
>>>
>>>--
>>>
>>>Thanks,
>>>
>>>Matt Riedemann
>>>
>>
>>
&g
t; Bhuvan Arumugam
> www.livecipher.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
To be fair, we test only the subset that is set via devstack on the stable
side. That should be a common subset, but it is far from fully
comprehensive. Nova has over 600 config variables, so additional tooling
here would be goodness.
Sean Dague
http://dague.net
On Nov 18, 2013 7:35 AM, &quo
ck.
Can someone from the quantum team get engaged here to help figure out
what's going on?
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
that really reduces your
ability to debug the issue.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ill cause it to exit
on first failure.
Martina
You can always got out to zuul directly and see patch status in progress
- http://status.openstack.org/zuul/
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@list
ough to organize the rest
of those and get them banged out.
I'm sure there are other issues once we get past this class. But that
would go a long way.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing lis
83436
*
CURL: GET
http://$IP:8774/v2/$PROJECT_ID/servers/$SERVER/os-virtual-interfaces
*
Explanation: This HTTP request calls the Quantum API
(nova/nova/network/quantumv2/api.py) and specifically the
get_vifs_by_* methods which are not implemented (raise
NotImplementedEr
l have an entry point
to getting to the bottom of issues found in the gate.
Help is always appreciated in fleshing these out with more tribal
knowledge, but it is a beginning.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev m
__
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
7;ll let
the test change into Tempest. If not, we probably need to call that out
on API standards.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
stinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sean Dague
http://dague.net
___
OpenStack-
simplicity I'd still use the opportunistic db user / pass, as that will
mean it could run upstream today.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
is style thing to go write Java to
fix it.
50 chars is common enough that vim syntax highlighting groks it. I see
no reason to choose a different thing.
Why 50? NO CLUE
As long as it gets auto enforced in hacking, I'll adapt to whatever. I
admit I've been bleeding my first line to 72
stack, not teststack or
tempeststack)
Does everything need to live under a program to get accounted for?
Devstack isn't really a natural fit into the existing categories. Those
of us that work on it tend to span a lot of categories anyway. I think
as long as we acknowledge that it's
part of an openstack* github tree. Which on the one hand is just naming,
on the other hand if heat's going to need that to get through the gate,
maybe we should rethink it being on stackforge vs. openstack-dev?
-Sean
--
Sean Dague
h
, only sort of. Remember the actual translation efforts happen in
transifex - https://www.transifex.com/projects/p/openstack/ and Jenkins
completely strips attribution when it brings them in in chunks to the
projects (as it's an automated job)
https://review.openstack.org/#/q/reviewer:782,n,z
https://launchpad.net/~johngarbutt/+specs?role=assignee
https://launchpad.net/~johngarbutt/+bugs?role=assignee
Thanks,
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstac
n/mailman/listinfo/openstack-dev
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
actly which), which causes some build fails. Because it was around a
freeze the cap was the right approach.
However, projects really should be getting themselves on 0.8 in the
Havana time frame. AFAIK it's really minor changes to work, so should be
a simple review to bump it up.
ap, execution is what's really important. :)
So credit back to Doug for actually getting this done.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bi
resources it can't damage them when we want to give them to a
different guest.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
the
ways to get SQLA to do the right thing in mysql.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
me:
from openstack_dashboard.dashboards.project.images_and_snapshots import
views
(tacking in at 78 chars)
I'm sure there will still be a few which break the limit... but that
will fix a lot of them (from what I see in the review).
-Sean
--
Sean Dague
http://dague.net
__
across projects. Currently bug prioritization is very project specific,
which makes it easy for a bug like this to exist for 3 weeks, be our top
gate reset issue, and not be triaged yet.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev
supervisor to set priority,
which in most cases means adding yourself to the PROJECT-bugs group on
LP. Some of those groups are still moderated, but most of them are open.
neutron-bugs is a moderated group.
-Sean
--
Sean Dague
http://dague.net
regardless). However there is probably going to be a bit of pain getting
from where we are today, to this world.
This is both a heads up, and a time for discussion, before we start
figuring out how to make this better in the gate.
-Sean
--
Sean Dague
http:/
be it DB / python-fooclient) -> Nova
internal exception -> Webobj exception to create our 40x / 50x returns.
-Sean
--
Sean Dague
http://dague.net
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
er/glance/ironic all
already do here. If it has to land through oslo first, that's a thing to
do, however nova's been gating on mysql in unit tests since early in
Grizzly, so it's been proved out pretty well.
-Sean
--
Sean Dague
http://dague.net
__
On 07/11/2013 05:06 AM, Thierry Carrez wrote:
Sean Dague wrote:
I think we need to get strict on projects and prevent them from capping
their client requirements. That will also put burden on clients that
they don't break backwards compatibility (which I think was a goal
regardless).
I
801 - 900 of 2095 matches
Mail list logo
