specially as they may not have
access to the source code to know which algo was in effect.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
On 06/11/2014 08:12 PM, Mathieu Gagné wrote:
> On 2014-06-11, 7:52 PM, Sean Dague wrote:
>>
>> Honestly, I really like
>>
>> [nova]
>>
>> better than
>>
>> [clients_nova]
>>
>> And as we're going to have to live with this for a
rg/#/c/99630/
The ironic team needs to go back to the drawing board a little here and
work on getting all the packages and repositories they need pulled down
into nodepool so we can isolate from network effects before we can make
this job gating again.
-Sean
--
Sean Dague
http://dague.ne
On 06/12/2014 07:42 AM, Chmouel Boudjnah wrote:
> On Thu, Jun 12, 2014 at 12:58 PM, Chmouel Boudjnah <mailto:chmo...@enovance.com>> wrote:
>
>
> On Wed, Jun 11, 2014 at 9:47 PM, Sean Dague <mailto:s...@dague.net>> wrote:
>
> Actually swiftcl
hange to devstack -
https://review.openstack.org/#/c/97442/ and backport it to past devstack
branches.
Then we drop the pg jobs, as the differences between the 2 configs
should then be very minimal. All the *actual* failures we've seen
between the 2 were completely about this strict SQL mode interpreta
On 06/12/2014 08:15 AM, Julien Danjou wrote:
> On Thu, Jun 12 2014, Sean Dague wrote:
>
>> However Monty brought up a good point at Summit, that MySQL has a strict
>> mode. That should actually enforce the same strictness.
>
> I would vote -1 on that, simply because us
by the testr commands that are generated
here -
http://logs.openstack.org/48/99648/2/check/gate-heat-python27/aa8fead/console.html
vs. what you see in a Nova unit test run.
Is there some particular wrappers you have kicking off in the unit tests?
-Sean
--
Sean Dague
http://dague.net
On 06/12/2014 10:38 AM, Mike Bayer wrote:
>
> On 6/12/14, 8:26 AM, Julien Danjou wrote:
>> On Thu, Jun 12 2014, Sean Dague wrote:
>>
>>> That's not cacthable in unit or functional tests?
>> Not in an accurate manner, no.
>>
>>> Keeping jobs
or that? I'm thinking specifically of things we've turned off in
> the gate before like multi-backend volume tests and
> allow_tenant_isolation=False.
It's getting emailed to the otherwise defunct openstack-qa list.
Subscribe there for nightlies.
Also agreed, the scenario tests
On 06/12/2014 01:22 PM, Tim Bell wrote:
>> -Original Message-
>> From: Sean Dague [mailto:s...@dague.net]
>> Sent: 12 June 2014 17:37
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] Gate proposal - drop Po
ent) over what is being installed.
>
> The problem is that bash8 doesn't express anything but "bash version 8",
> unless you know pep8.
Impinging on the bash namespace is something I'll almost buy, except
that bash never ships with a version number.
I'd be
e tokens are generated in a
> very predictable manner that exclude a ton of possibilities, we
> shouldn't have to worry about rainbow tables.
>
> --
> Kevin Benton
>
>
> On Fri, Jun 13, 2014 at 12:52 AM, Robert Collins
> mailto:robe...@robertcollins.net>>
___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 06/12/2014 10:18 PM, Dan Prince wrote:
> On Thu, 2014-06-12 at 09:24 -0700, Joe Gordon wrote:
>>
>> On Jun 12, 2014 8:37 AM, "Sean Dague" wrote:
>>>
>>> On 06/12/2014 10:38 AM, Mike Bayer wrote:
>>>>
>>>> On 6/12/14, 8:26 A
On 06/13/2014 02:36 AM, Mark McLoughlin wrote:
> On Thu, 2014-06-12 at 22:10 -0400, Dan Prince wrote:
>> On Thu, 2014-06-12 at 08:06 -0400, Sean Dague wrote:
>>> We're definitely deep into capacity issues, so it's going to be time to
>>> start making tougher de
On 06/12/2014 10:10 PM, Dan Prince wrote:
> On Thu, 2014-06-12 at 08:06 -0400, Sean Dague wrote:
>> We're definitely deep into capacity issues, so it's going to be time to
>> start making tougher decisions about things we decide aren't different
>> enough to bot
On 06/13/2014 08:13 AM, Mark McLoughlin wrote:
> On Fri, 2014-06-13 at 07:31 -0400, Sean Dague wrote:
>> On 06/13/2014 02:36 AM, Mark McLoughlin wrote:
>>> On Thu, 2014-06-12 at 22:10 -0400, Dan Prince wrote:
>>>> On Thu, 2014-06-12 at 08:06 -0400, Sean Dague wrot
On 06/13/2014 04:38 AM, Giulio Fidente wrote:
> On 05/31/2014 03:56 PM, Sean Dague wrote:
>> We're still working on a way to make it possible to review in server
>> side gerrit dashboards more easily to gerrit. In the mean time I've put
>> together a tool that
rk on some easy code to get it merged, but
now is really not the time.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.opensta
oting process outlined at
> https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our
> core team.
>
> Thanks,
> Michael
>
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 06/13/2014 06:47 PM, Joe Gordon wrote:
>
>
>
> On Thu, Jun 12, 2014 at 7:18 PM, Dan Prince <mailto:dpri...@redhat.com>> wrote:
>
> On Thu, 2014-06-12 at 09:24 -0700, Joe Gordon wrote:
> >
> > On Jun 12, 2014 8:37 AM, "Sea
's definitely not a name we want, because
we aren't doing that (or ever plan to do that).
bashate ftw.
Because if you can't have an inside joke buried within your naming of an
open source project, what's the point. :)
-Sean
--
Sean Dague
http://dague.net
si
gate window to impact them.
It's also that a new issue tends to take 12 hrs to see and figure out if
it's a ZOMG issue, and 3 - 5 days to see if it's any lower level of
severity. And given that we merge 50 - 100 patches a day, across 40
projects, across branches, the rol
eview here - https://review.openstack.org/#/c/100231/
I also think in future hacking major releases need to happen within one
week of release, or not at all for that series.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital
On 06/16/2014 12:44 PM, Ben Nemec wrote:
> On 06/16/2014 08:37 AM, Thierry Carrez wrote:
>> Sean Dague wrote:
>>> Hacking 0.9 series was released pretty late for Juno. The entire
>>> check queue was flooded this morning with requirements proposals
>>> failing
On 06/16/2014 05:06 PM, Ben Nemec wrote:
> On 06/16/2014 12:01 PM, Sean Dague wrote:
>> On 06/16/2014 12:44 PM, Ben Nemec wrote:
>>> On 06/16/2014 08:37 AM, Thierry Carrez wrote:
>>>> Sean Dague wrote:
>>>>> Hacking 0.9 series was released pretty la
ust query all changes in that topic to find easy stuff
> to approve.
It could go in the commit message:
TrivialFix
Then could be queried with -
https://review.openstack.org/#/q/message:TrivialFix,n,z
If a reviewer felt it wasn't a trivial fix, they could just edit the
commit message inline to drop it out.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
tually a pretty good time to put and keep it under
load to help evaluate where we stand.
Thanks all,
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@list
ers. Because you have context on an issue, and if it takes weeks
for people to get to it, by the time they do you are off to something else.
Honestly, what I really wish gerrit would do is sort based on # of lines
changed, from small to large. That would provide a good feedback loop to
make things reviewable chunks.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 06/18/2014 05:24 AM, Steven Hardy wrote:
> On Wed, Jun 18, 2014 at 11:04:15AM +0200, Thierry Carrez wrote:
>> Russell Bryant wrote:
>>> On 06/17/2014 08:20 AM, Daniel P. Berrange wrote:
>>>> On Tue, Jun 17, 2014 at 01:12:45PM +0100, Matthew Booth wrote:
>>>
regularly install / uninstall python-keystone
client 6 times over the course of a devstack run, based on conflicting
project requirements.
It was *awesome*... (not)
The end result is you may or may not be testing with what you thought
you were supposed to be, and if a project used entry point plugins and
2 +2s you do the wrong thing. Yesterday we landed baremetal
tests that broke ironic. It has a ton of +1s from people that have been
working on those tests.
People throw +1s around with 'please do this thing', and miss the part
about 'and this current way of doing this thing is actua
penStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
This does not seem small or low risk in any way. And the blueprint is
not currently approved.
Also, as far as I can tell you never actually talked with Joe Gordon
about him supporting the F
Because like it seems like it makes both things
slower to try them at the same time (as there are a limited number of
people here). So I think at least in this case scheduler really should
be split then improve, or improve then split, and everyone interested in
either side of that equation needs
ova, neutron or whatever change would break Heat in git.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing lis
On 03/06/2014 08:11 AM, Steven Hardy wrote:
> On Thu, Mar 06, 2014 at 07:53:03AM -0500, Sean Dague wrote:
>> We're at Freeze, so I want to pick up and understand where we currently
>> stand with both Neutron and Heat actually getting tested fully in the gate.
>>
&
n that
content and get to agreement on approach.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStac
ange about this.
> Matt has agreed to be a sponsor.
If this is enabled in other projects, where is the Tempest scenario test
that actually demonstrates that this is working on real installs?
I get that everyone has features that didn't hit. BHowever now is not
that time for that, now is t
On 03/07/2014 06:30 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> One of the issues that the Nova team has definitely hit is Blueprint
>> overload. At some point there were over 150 blueprints. Many of them
>> were a single sentence.
>>
>> The results of this h
then I approve.
But remember, project meeting on Tuesday is hard deadline. If it's not
merged by then it needs to be defered.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Description: OpenPGP digital signat
second release
>>> it's been attempted to be merged into.
>>
>> Add me as a sponsor.
>
> OK, great. That's two.
>
> We have a hard deadline of Tuesday to get these FFEs merged (regardless
> of gate status).
>
As alt release manager, FFE approv
ith.
And SQLA looks solid now.
Please update the commit message for that change then I'm +2.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
On 03/08/2014 05:53 AM, Sean Dague wrote:
> On 03/08/2014 05:00 AM, Thomas Goirand wrote:
>> Hi,
>>
>> I just tried this:
>> https://review.openstack.org/#/c/79129/
>>
>> and it seems everything works. \o/
>>
>> Shall we lift the SQLA cap right aw
it
requires an UpgradeImpact tag in the commit. And those should be limited
really aggressively. This is the whole point of the deprecation cycle.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Description: OpenPGP dig
On 03/11/2014 07:48 AM, Steven Hardy wrote:
> On Tue, Mar 11, 2014 at 07:04:32AM -0400, Sean Dague wrote:
>> On 03/04/2014 12:39 PM, Steven Hardy wrote:
>>> Hi all,
>>>
>>> As some of you know, I've been working on the instance-users blueprint[1].
>&
d to be in by the
meeting today.
For folks in the US (in all the places which do DST), remember, the
meeting time is in UTC, so now an hour later for us all.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Descriptio
(incubated projects are currently best effort).
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
Ope
On 03/11/2014 09:48 AM, Kenichi Oomichi wrote:
>
> Hi Sean,
>
>> -Original Message-
>> From: Sean Dague [mailto:s...@dague.net]
>> Sent: Tuesday, March 11, 2014 10:06 PM
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [qa] Te
On 03/11/2014 10:15 AM, Steven Dake wrote:
> On 03/11/2014 04:04 AM, Sean Dague wrote:
>> On 03/04/2014 12:39 PM, Steven Hardy wrote:
>>> Hi all,
>>>
>>> As some of you know, I've been working on the instance-users blueprint[1].
>>>
>>> T
0/2014 11:20 AM, Dmitry Borodaenko wrote:
>>>>> On Fri, Mar 7, 2014 at 8:55 AM, Sean Dague wrote:
>>>>>> On 03/07/2014 11:16 AM, Russell Bryant wrote:
>>>>>>> On 03/07/2014 04:19 AM, Daniel P. Berrange wrote:
>>>>>>>> O
Because of where we are in the freeze, I think this should wait until
Juno opens to fix. Icehouse will only be compatible with SQLA 0.8, which
I think is fine. I expect the rest of the issues can be addressed during
Juno 1.
-Sean
--
Sean Dague
Samsung Research America
s...@dagu
elease. That would let you move
forward, and provide some user signally.
That is definitely more effort, but as a community we've decided to
support the CD method for OpenStack, which means we need to take account
of these kinds of cases.
-Sean
--
Sean Dague
Samsung
bunch of
operations don't need to sit under transactions. Like the ability to do
a list_images while and image is being deleted, especially given that we
denormalize a lot of these things over multiple tables. That, however,
may be an out of date concept here. I haven't stayed u
ze being some random
assembly tool for things out of tree. If the driver isn't good enough
for Nova, I don't see why we'd be encouraging people to use it in devstack.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@sams
> https://review.openstack.org/#/c/79935/
ACK. Looks pretty good. You might want to consider using one of the oslo
deprecation functions to make it consistent on the deprecation side.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dagu
On 03/12/2014 01:10 PM, Jay Pipes wrote:
> On Wed, 2014-03-12 at 07:18 -0400, Sean Dague wrote:
>> On 03/12/2014 06:38 AM, Flavio Percoco wrote:
>>> On 11/03/14 16:25 -0700, Clint Byrum wrote:
>>>> Hi. I asked in #openstack-glance a few times today but got no respon
eck/check-tempest-dsvm-neutron/11f8293/
The gate at 7am EST is 43 items deep with a 10hr backlog, and this is
the primary reason for that.
Until this gets resolved we're looking at a completely jammed gate. So
you're code won't merge in any reasonable amount of time.
-Sean
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
We're over a week past freeze, it is really time to focus on existing
issues, and not trying to bring in additional new feature freezes.
This should wait until the Juno tree opens up.
-Sean
--
Sean Dague
Samsung Researc
lib/jenkins/devstack/lib/nova:618:git_clone
> 2014-03-11 14:14:02.324 |
> /var/lib/jenkins/devstack/functions-common:543:git_timed
> 2014-03-11 14:14:02.326 | /var/lib/jenkins/devstack/functions-common:596:die
> 2014-03-11 14:14:02.327 | [ERROR]
> /var/lib/jenkins/devstack/funct
nough to make us fail a bunch of Nova Tempest tests.
That seems dangerous to address during freeze.
I consider this something which should be dealt with in Juno 1 though,
as I'm very interested in whether the new optimizer in sqla 0.9 helps us
on performance.
-Sean
--
Sean Dague
Sa
On 03/13/2014 12:31 PM, Thomas Goirand wrote:
> On 03/12/2014 07:07 PM, Sean Dague wrote:
>> Because of where we are in the freeze, I think this should wait until
>> Juno opens to fix. Icehouse will only be compatible with SQLA 0.8, which
>> I think is fine. I expect the rest
full plan about how to get there,
including the python 3 story for everything in requirements.txt and
test-requirements.txt being resolved first.
Because partial work is pretty pointless, it bit rots. And if we can't
get to running tempest regularly with python3 then it will regress (I
would
That 2 week window needs to happen within milestone 1 or 2 of a cycle.
After that, it's a distraction. So if the python 3 team doesn't have the
ducks in a row by then, we punt to next release.
Because I think the one of patch model on changes like this just doesn't
work, and leaves
res doesn't allow implicit casts. If I
> change the line to:
>
> filters = {'uuid': filter_uuids, 'deleted': 0}
>
>
> Then it seems to work. Is this change valid?
Yes, postgresql is strongly typed with it's data. That's a valid bug you
fo
'm not sure how to fix that apart from
> expecting the author to create a comment in the launchpad blueprint
> manually, but perhaps that's good enough.
>
> Michael
>
I believe this will give you the behavior you are looking for -
https://review.openstack.org/#/c/80
mands return within x seconds. As a first pass
> we can say x=60 and than crank it down in the future.
So, the last thing I want to do is trigger a race here by us
artificially timing out on tests. However I do think cli tests should be
returning in < 2s otherwise they are no
those all
seem to be sailing through. I think for incorrect reasons. No one's
objected at this point, so maybe that's ok. But it's probably worth a
huddle up.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.as
and from 120s to 2s, so that doesn't really seem to
be the core issue (and is likely to just cause db deadlocks).
As long as Ceilometer says it supports SQL backends, it needs to do so
in a sane way. So that should still be gating.
-Sean
--
Sean Dague
Samsung Research America
s...@da
On 03/18/2014 09:02 AM, Julien Danjou wrote:
> On Tue, Mar 18 2014, Sean Dague wrote:
>
>> There is a fundamental problem here that the Ceilometer team requires a
>> version of Mongo that's not provided by the distro. We've taken a pretty
>> hard line on not requ
t about the combinations
we're going to actually validate, because with the various limitations
we've got (concurrency limits, quota limits, upstream package limits,
kinds of tests we want to run) we're going to have to make a bunch o
On 03/18/2014 12:09 PM, Chmouel Boudjnah wrote:
>
> On Tue, Mar 18, 2014 at 2:09 PM, Sean Dague <mailto:s...@dague.net>> wrote:
>
> We've not required UCA for any other project to pass the gate.
>
>
>
> Is it that bad to have UCA in default d
is ready. I think
that sounds like as good a week as any for the transition.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
O
On 03/18/2014 08:15 PM, Joe Gordon wrote:
>
>
>
> On Tue, Mar 18, 2014 at 8:12 AM, Sean Dague <mailto:s...@dague.net>> wrote:
>
> On 03/18/2014 10:11 AM, Daniel P. Berrange wrote:
> > On Tue, Mar 18, 2014 at 07:50:15AM -0400, Davanum
that the majority of our cpu has to be handed over to the metric
collector to make it function responsively. I thought the design point
was that this was low impact.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Des
be something other than
horizontal scaling. Because we're talking about the collector being the
3rd highest utilized process on the box right now (we should write a
dstat plugin to give us cumulative data, just haven't gotten there yet).
So right now, I think performance analysis for cei
at requires a base piece
of software that is outside of that list is a pretty big deal.
Forget license for a moment, just specifying that you have to run and
maintain and monitor a nosql environment in addition to a RDBMS is
definitely adding substantial burden to OpenS
On 03/20/2014 11:35 AM, David Kranz wrote:
> On 03/20/2014 06:15 AM, Sean Dague wrote:
>> On 03/20/2014 05:49 AM, Nadya Privalova wrote:
>>> Hi all,
>>> First of all, thanks for your suggestions!
>>>
>>> To summarize the discussions here:
>>&g
rate about it. Also, the burden,
and thus concern, would go way down if the service actually used heat
and/or nova to deploy it's backend as well. Like Savana and Trove do. It
seems like we've got all this infrastructure in OpenStack already to
deploy and manage things on computes prog
here are certain cases where having a project specific
>> functional test makes sense. For example swift has a functional test job
>> that
>> starts swift in devstack. But, those things are normally handled on a per
>> case
>> basis. In general if the project is meant to be part of the larger
>> Open
On 03/20/2014 01:01 PM, David Kranz wrote:
> On 03/20/2014 12:31 PM, Sean Dague wrote:
>> On 03/20/2014 11:35 AM, David Kranz wrote:
>>> On 03/20/2014 06:15 AM, Sean Dague wrote:
>>>> On 03/20/2014 05:49 AM, Nadya Privalova wrote:
>>>>> Hi all,
&g
's write path be highly tuned and not
use SQLA (and written for every back end natively) is probably appropriate.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Description: OpenPGP digital signature
is is a look at
some place rootwrap is used with such an open policy, that it's
completely moot. For instance the nova-cpu policy includes tee & dd with
no arg limitting (which has been that way forever from my look in git
annotate)
Which is basically game over.
So in the nova-cpu case I
t debates and it basically remains civil and
constructive.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
Ope
workflow will be very similar given any tracker. And I
expect the workflow might evolve over time if Storyboard can help more.
I honestly think spec review was completely outside of it's use case. So
I look forward to evolving the process with Storyboard once it's
actually a tool we use and n
On 03/21/2014 05:11 PM, Joe Gordon wrote:
>
>
>
> On Fri, Mar 21, 2014 at 4:04 AM, Sean Dague <mailto:s...@dague.net>> wrote:
>
> On 03/20/2014 06:18 PM, Joe Gordon wrote:
> >
> >
> >
> > On Thu, Mar 20, 2014 at 3:0
ur feedback on how we can make this better for everyone.
>
> [0]
> http://cacti.openstack.org/cacti/graph.php?action=view&local_graph_id=717&rra_id=all
>
> Thank you,
> Clark Boylan
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists
sure it also exists and is tracked correctly in launchpad?
>
> For nova-specs, the first piece of info in the template is a blueprint URL.
>
> On the launchpad side, nothing will be allowed to be targeted to a
> milestone with an approved spec attached to it.
>
>> [1] https://
On 03/24/2014 12:20 PM, Russell Bryant wrote:
> On 03/24/2014 11:42 AM, Stefano Maffulli wrote:
>> On 03/22/2014 03:14 AM, Sean Dague wrote:
>>> Honestly, I largely disagree. This is applying some process where there
>>> clearly wasn't any before.
>>
>&
nce Storyboard is available, except we
could probably get story board to pick up the specs links much nicer
than we have the ability to do with launchpad.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Description: Open
On 03/24/2014 01:40 PM, Michael Krotscheck wrote:
> On Sat, Mar 22, 2014 at 3:14 AM, Sean Dague <mailto:s...@dague.net>> wrote:
>
> Storyboard remains vaporware. I will be enormously happy when it is not.
>
>
> You could, oh, I dunno, maybe contribute to the code
at's fine if long term this whole thing is optimized. I just
do very much worry that StoryBoard keeps going under progressive scope
creep before we've managed to ship the base case. That's a dangerous
situation to be in, as it means it's evolving without a feedback loop.
I'd muc
1 goal?
The Trove team said last week they could probably land the remove in
trove this week for mockito (it was on their roadmap anyway). So unless
they feel that's not doable, I think we're good.
-Sean
--
Sean Dague
Samsung Research America
s...@
fix
>> the Tempest test run error)
>> - https://review.openstack.org/#/c/80432/
>>
>> Thanks,
>> Roman
>>
>> On Thu, Mar 13, 2014 at 7:41 PM, Thomas Goirand wrote:
>>> On 03/14/2014 02:06 AM, Sean Dague wrote:
>>>> On 03/13/2014
est results for a project change - assuming
the tempest change was applied, that would prevent all these changes
from being -1ed until the tempest change is landed.
-Sean
--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net
signature.asc
Des
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> <mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ___
> OpenStack-d
gt; latest version, I suggest we limit the version of psutil to 1.x (currently
> there's a lower bound in the 1.x
> range, just not an upper bound).
Which code will be broken by this if it's not done? Is there an RC bug
tracking it?
-Sean
--
Sean Dague
Samsung Rese
stros yet.
>
> Best Regards,
> Solly Ross
>
> - Original Message -
> From: "Sean Dague"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Wednesday, March 26, 2014 10:39:41 AM
> Subject: Re: [openstack-dev] [
to file such a bug.
>
> Best Regards,
> Solly Ross
>
> - Original Message -
> From: "Sean Dague"
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Sent: Wednesday, March 26, 2014 3:28:32 PM
> Subject: Re: [opensta
gt;
> - to say nothing of the increased effort required to develop functional
> tests in an integration envirequired to maintain tests in Tempest splinters
> their efforts unnecessarily. I'm not suggesting that
The beginning of this thread largely came from the fact that Marc
to go
through to get a working config out of tox -e genconfig.
So I think it's a fair concern that we did just move a burden back onto
users because we dug a hole by letting libraries declare arbitrary
required variables in our config files.
-Sean
--
Sean Dague
Samsung Res
501 - 600 of 2095 matches
Mail list logo
