every project with outstanding "dibs" to check that they still
> exist and want that name.
>
> I think a 1 year TTL would be a good starting spot, does that help?
>
> [snipped more]
Personally, I don't feel like reservations should exist for non
OpenStack projects. That
se of open washing anything,
> or holding back features in order to sell a more advanced version.
> It happens that for Poppy to be useful, you have to buy another
> service for it to talk to (and to serve your data), but all of the
> Poppy code is actually open and there
ats).
I'd ask for folks to try to stay on the original question:
What possible naming standards could we adopt, and what are the preferences.
>From that we can move towards any implementation needed for that.
-Sean
--
Sean Dague
http://dague.net
_
On 02/05/2016 03:00 PM, michael mccune wrote:
> On 02/03/2016 10:23 AM, Morgan Fainberg wrote:
>>
>>
>> On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague <s...@dague.net
>> <mailto:s...@dague.net>> wrote:
>>
>> I've been looking through the re
On 02/05/2016 04:44 AM, Grasza, Grzegorz wrote:
>
>
>> -Original Message-----
>> From: Sean Dague [mailto:s...@dague.net]
>>
>> On 02/04/2016 10:25 AM, Grasza, Grzegorz wrote:
>>>
>>> Keystone is just one service, but we want to run a tes
oesn't feel intentional, and is a good catch.
https://review.openstack.org/#/c/276738/ was pushed this morning to fix
it. I think that's fine (and can be backported) but needs tests.
It would be good to know if there were other situations that were
different here between the old policy enforcement and the new o
ago, but has not been reaped by Jenkins.
I'm kicking the patch out now, so there will be no log on the log
servers, but the console log above remains for post mortem.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
a - status quo)
Upside, no long mailing list thread to figure out the answer. Downside,
it sucks.
Are there other options missing? Where are people leaning at this point?
Personally I'm way less partial to any particular answer as long as it's
not #3.
-Sean
--
Sean Dague
http:/
On 02/04/2016 09:35 AM, Anne Gentle wrote:
>
>
> On Thu, Feb 4, 2016 at 7:33 AM, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
> On 02/04/2016 08:18 AM, Doug Hellmann wrote:
> > Excerpts from Hayes, Graham's message of 2016-02-04 12
On 02/04/2016 08:18 AM, Doug Hellmann wrote:
> Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +:
>> On 04/02/2016 11:40, Sean Dague wrote:
>>> A few issues have crept up recently with the service catalog, API
>>> headers, API end points, and eve
the same DB.
Let me understand the scenario correctly.
There would be Keystone Liberty and Keystone Mitaka, both talking to a
Liberty DB?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (no
other projects)
+ all the downsides of #2 (we still need a naming registry).
I do agree it is a 4th option, but the downsides seem higher than either
#1 or #2.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
out. Having a
project just start using 'monitoring' or 'policy' as a service type is
going to go poorly in the long term when they get told they have to
change that, and now all their clients are broken.
-Sean
--
Sean Dague
http://dague.net
ot a
valid reason to keep a test. Unreliable tests that don't have anyone
looking into them should be deleted. They are providing negative value.
Because people just recheck past them even if their code made the race
worse. So any legitimate issues th
topology that people may not have.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
r on *current rule*.
> However, such microversion seems a little overkill for me.
> So I'm not sure when we can change these 501 code.
My assumption is we'd change them in the same version when we cut over
to structured JSON error responses. That would be next cycle some time.
-S
s being
reverted - https://review.openstack.org/#/c/274703/
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsub
, but like the removal of
extras.d, we need to be explicit about it.
So, first off, we need a volunteer to step up to pull together this
plan. Any volunteers here?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
s, which
include a glance image url directly.
Keeping that header in place is extremely helpful from a clarity
perspective instead of using heuristics of manually splitting apart urls
and guessing. That second approach is one of the reasons the devstack
keystone v3 patches keep being disruptive.
> release. It became common to see regression on eventlet releases, it
> looks like eventlet test suite is too small.
Thanks everyone for getting to the bottom of this. 0.18.1 seems to have
fixed everything, and we're back in business now.
-Sean
--
Sean Dague
http://d
it would be appreciated. I know a lot of us are traveling
over the next 24 hours, so not sure who is going to have time to dig in.
But it will be massively appreciated.
-Sean
--
Sean Dague
http://dague.net
in this review)
By trending up we mean above 75% failure rate - http://tinyurl.com/zrq35e8
All the spot checking of jobs I've found is the job dying on the liberty
side validation with test_volume_boot_pattern, which means we've never
even gotten to the any of the real grenade logic.
+2 on non-voti
When your bus lights on fire you don't just keep driving with the bus
full of passengers. You pull over, let them get off, and deal with the
fire separately from the passengers.
If there is in flight work, by a set of people that are all going to
bed, handing that off with an email needs to happen. E
On 01/20/2016 10:03 AM, Matthew Treinish wrote:
> On Wed, Jan 20, 2016 at 07:45:16AM -0500, Sean Dague wrote:
>> The large-ops jobs jumped to a 50% fail in check, 25% fail in gate in
>> the last 24 hours.
>>
>> http://tinyurl.com/j5u4nf5
>>
>> There isn't an
evelopment Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <http://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 (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo
__
> 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 Dagu
uot; track.
So everyone should think about the 1 thing that they really wish they
knew more about in OpenStack, especially if it's something slightly
outside their normal experience in the community. The real goal here is
to cross educate each other on the project.
-Sean
--
Sean Dague
http
ble/liberty+project:openstack/nova
>
> [3]
> https://review.openstack.org/#/q/reviewer:%22Tony+Breeds%22+branch:stable/kilo+project:openstack/nova
+1
-Sean
--
Sean Dague
http://dague.net
__
OpenStack De
est nodes, which
slows down development for everyone.
There is no full machine solution here. There are sets of helpers, and
then there is the need for reviewers to be cognizant of the downstream
effects of software releases, and that
. Either route set on it's own is fine.
This was caught by one stray functional test and took a while to figure
out what was going on. But if we come up with a resolution here we can
move forward on this work (which is part of what's needed in revising
the service catalog).
-Sean
--
Sean
On 01/13/2016 10:31 AM, Chris Dent wrote:
> On Wed, 13 Jan 2016, Sean Dague wrote:
>
>> Because this regex is built from a dictionary, hash seed matters, and it
>> is not stable which will get precedence.
>
> Ow[1].
>
>> I'd like to propose for Nova we restrict
On 01/11/2016 07:55 AM, Tom Fifield wrote:
> On 11/01/16 20:08, Sean Dague wrote:
>> On 01/10/2016 11:31 PM, Lana Brindley wrote:
>>
>>> Wow. That'll make the release notes process painful this round ... o.O
>>
>> Hmmm. In my mind it will make it a lot easi
d DocImpact but
wouldn't need a reno. I can see bugs filed against Docs explicitly
because there is a mismatch.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubsc
g the oslo.messaging in memory driver and in mem sqlite db. This
kind of approach is what we use in Nova functional tests to setup a
whole stack fake cloud inside a single test process.
At the end of the day it's the choice of the Ironic team. Just something
to thi
On 01/07/2016 06:21 PM, Lana Brindley wrote:
>
>> On 7 Jan 2016, at 2:09 AM, Sean Dague <s...@dague.net> wrote:
>>
>> On 01/06/2016 09:02 AM, Jeremy Stanley wrote:
>>> On 2016-01-06 07:52:48 -0500 (-0500), Sean Dague wrote:
>>> [...]
>>>&g
ot; as the link and we exposed
> the flavor information stored with the instance on that endpoint then we
> no longer need to expose deleted flavors.
>
> So for an instance booted with flavor 8 https://example.com/flavors/8
> would be equivalent to https://example.com/servers//flavor excep
s
manually (with details added by humans) would be fine.
It's not clear to me why a new job was required for that.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
On 01/06/2016 09:02 AM, Jeremy Stanley wrote:
> On 2016-01-06 07:52:48 -0500 (-0500), Sean Dague wrote:
> [...]
>> I think auto openning against a project, and shuffling it to
>> manuals manually (with details added by humans) would be fine.
>>
>> It's not clear to
pace compressed out of it.
If it's possible to recover, the code that is generating the exception
shouldn't be logging it, but instead should do some kind of structured
recovery.
-Sean
--
Sean Dague
http://dague.net
___
sages and keep Jenkins votes).
Voting based on commit messages is a thing we need to not be doing.
You can score based on content in tree, just not commit messages.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack D
sh)
>
> mjs10:devstack mspreitz$ git checkout stable/liberty
> error: pathspec 'stable/liberty' did not match any file(s) known to git.
The first time you do this you need to set up a tracking branch:
git checkout -t origin/stable/liberty
will get you one.
https://review.openstack.org/
given the following alternate recipe
> in a discussion on #openstack-neutron; I assume it is pretty much
> equivalent.
>
> "do something like 'git checkout -b libery/backport/###
> remotes/origin/stable/liberty' then 'git pull' then 'git review -X
> ###' th
cide it's going to call v2 vs. v1 from
it's side.
As a bonus, having *some* testing added to this path would be great as
well. The xenserver glance plugins have no tests right now, and doing
something like v2 vs. v1 would be good to get somethin
The fixed key manager is useful for easy testing (we're using it in the
gate in places where barbican isn't available). Is there anything
equivalent with Catellan?
-Sean
--
Sean Dague
http://dague.net
__
OpenSta
e any reasonable
sense of the logs by humans. The devstack overrides are probably better
defaults for the projects than their current defaults.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack D
atellan?
>>>
>>> -Sean
>>>
>>> --
>>> Sean Dague
>>> http://dague.net
>>
>> There is no fixed-key back end with Castellan. I agree that using a
>> fixed key makes for very easy testing, but the tests use a
>> confi
gt; If you encounter any problems, please let us know here or in
>> #openstack-infra on Freenode.
>
> Thanks! One small feature request: is it possible to highlight V-1 from
> Jenkins in red, just like review -1? It used to be handy to quickly
> check the status of the patch.
Thi
ay the old dashboard was.
If you find this dashboard useful, enjoy. If not, hopefully you take
some ideas out of it for your own review pattern.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing Lis
UpgradeImpact for
an upgrade comment in reno, which is *so* much better.
It seems like using reno instead of commit message tags would be much
better for everyone here.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack
On 12/18/2015 01:34 PM, Andreas Jaeger wrote:
> On 12/18/2015 07:03 PM, Sean Dague wrote:
>> Recently noticed that a new job ended up on all nova changes that was
>> theoertically processing commit messages for DocImpact. It appears to be
>> part of this spec -
>>
ht text,
> right-button click, Copy, right-button click, Paste, is a pain.
>
> Maybe someone has a simple work-around for that.
Odd. I'm using chromium browser and
* highlight
* middle click elsewhere
Works fine. Is it firefox specific? Given that the behavior works in
Chromium I suspect no
On 12/18/2015 02:31 PM, Andreas Jaeger wrote:
> On 12/18/2015 07:45 PM, Sean Dague wrote:
>> On 12/18/2015 01:34 PM, Andreas Jaeger wrote:
>>> On 12/18/2015 07:03 PM, Sean Dague wrote:
>>>> Recently noticed that a new job ended up on all nova changes that was
>&g
ck.org/dashboard/db/tempest-failure-rate
> [2] logstash query: http://bit.ly/1O8qjtn
>
> Regards, Markus Zoeller (markus_z)
That graph is a pretty narrow time slice. What's the rolling average on
that?
-S
ed to some of the new widgets.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http:
On 12/16/2015 11:37 AM, Sean Dague wrote:
> On 12/16/2015 11:22 AM, Mike Bayer wrote:
>>
>>
>> On 12/16/2015 09:10 AM, Sylvain Bauza wrote:
>>>
>>>
>>> Le 16/12/2015 14:59, Sean Dague a écrit :
>>>> oslo.db test_migrations is using
There is an oslo.db patch out there
https://review.openstack.org/#/c/258478 to fix it, but #openstack-oslo
has been pretty quiet this morning, so no idea how fast this can get out
into a release.
-Sean
--
Sean Dague
http://dague.net
On 12/16/2015 11:22 AM, Mike Bayer wrote:
>
>
> On 12/16/2015 09:10 AM, Sylvain Bauza wrote:
>>
>>
>> Le 16/12/2015 14:59, Sean Dague a écrit :
>>> oslo.db test_migrations is using methods for alembic, which changed in
>>> the 0.8.4 release. This
deprecated
during the liberty cycle, and fixed accordingly.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.op
;
> https://docs.python.org/2/library/warnings.html#the-warnings-filter
>
> Turn that CLI switch from off to on and I'm pretty sure usage of
> deprecated things will become pretty evident real quick ;)
It needs to be more targetted than that. There is a long standing
warnin
On 12/02/2015 12:37 PM, Rosa, Andrea (HP Cloud Services) wrote:
> Hi
>
> thanks Sean for bringing this point, I have been working on the change and on
> the (abandoned) spec.
> I'll try here to summarize all the discussions we had and what we decided.
>
>> Fr
g the flip side as well.
>>sdague:I don't think anything should be extending the neutron API that
> isn't controlled by the neutron core team.
>
> The core should be about the core, why would what's built on top be
> controlled by the core? By comparison, it's like saying a SIG o
ble to make the validation strict again.
Yeh, that was my thinking. As someone that did a lot of the jsonschema
work, is that something you could prototype?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development
ppy to buy
> drinks if you helped with LB in San Antonio if there is a neutron social
> event (in addition to paying back amotoki for the Tokyo social).
>
> [1]: http://lists.openstack.org/pipermail/openstack-dev/2015-July/068859.html
> [2]: https://review.openstack.org/205674
&g
a weekly drum beat to ensure we don't fall off the wagon and
have stuff forgotten.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
ink this might have happened." What is an application supposed to do
with that information? Ask again until it is sure?
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usag
package version update
> failure.
I don't think that change impacts any of the jobs that are failing. The
plugin jobs are new job names, and non voting.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Deve
.2). There
> is a newer version of libvirt in the fc21 job in the experimental queue,
> but ovmf isn't available from Fedora [1].
>
> [1]
> https://fedoraproject.org/wiki/Using_UEFI_with_QEMU#EDK2_Licensing_Issues
Can someone explain the licensing issue here? The
On 12/04/2015 08:34 AM, Daniel P. Berrange wrote:
> On Fri, Dec 04, 2015 at 07:43:41AM -0500, Sean Dague wrote:
>> Can someone explain the licensing issue here? The Fedora comments make
>> this sound like this is something that's not likely to end up in distros.
>
> The
On 12/04/2015 12:43 PM, Sean M. Collins wrote:
> On Mon, Nov 30, 2015 at 07:00:07AM EST, Sean Dague wrote:
>> On 11/25/2015 11:42 AM, Sean M. Collins wrote:
>>> The first run for the multinode grenade job completed.
>>>
>>> http://logs.openstack.org/35/1872
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> I agree with Jeremy. We might be able to consider something like this
> for stable/liberty, since that's when we started doi
the new interface, will need to
construct the urls themselves.
So, for Cinder, Glance, Ironic, Manila, Magnum (and others I might have
missed) where are you standing on this one? And are there volunteers in
those projects to help move this forward?
-Sean
--
Sean Dague
http://dague.net
ister
it's jsonschema in?
-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.ope
, that if we failed
with a partially setup volume, we have too many safety latches to tear
it down again.
Do we have some detailed bugs about how that happens? Is it possible to
just fix DELETE to work correctly even when we're in these odd states?
-Sean
--
Sean Dague
http://dague.net
On 12/01/2015 08:08 AM, Duncan Thomas wrote:
>
>
> On 1 December 2015 at 13:40, Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
>
>
> The current approach means locks block on their own, are processed in
> the order they come in, but de
On 11/30/2015 05:25 PM, Clint Byrum wrote:
> Excerpts from Ben Nemec's message of 2015-11-30 13:22:23 -0800:
>> On 11/30/2015 02:15 PM, Sean Dague wrote:
>>> On 11/30/2015 03:01 PM, Robert Collins wrote:
>>>> On 1 December 2015 at 08:37, Ben Nemec <openst...@ne
-cells that Nova's or nova-net / neutron bifurcation.
Whatever the reference architecture is, it should support Federation. A
non federation capable keystone should be the exception.
> - uWSGI could help to support multiple web servers.
--
Sean D
have less than 20 such named locks.
Cinder uses a parametrized version for all volume operations -
https://github.com/openstack/cinder/blob/7fb767f2d652f070a20fd70d92585d61e56f3a50/cinder/volume/manager.py#L143
Nova also does something similar in image cache
https://github.com/openstack/nova/blob
uot;pip install websockify[fastHyBi]",
> and package builders can also specify numpy as hard dependency for
> websockify package in package specs.
I went down this same path before. That masking is mandatory in the spec
- https://github.com/kanaka/websockify/pull/163
The right answ
20_846
>
> I see no tests running, is it normal?
The final tempest run is handled by devstack-gate, so it's not in the
grenade log, it's in console.html
-Sean
--
Sean Dague
http://dague.net
__
Op
indows.
Right, so to me this seems that privsep just needs a NULL mode, and
we're done. If oslo.rootrwap was never supported on windows, I don't
think privsep really needs to be in a real way.
-Sean
--
Sean Dague
http://dague.net
m what the minimum version of ovs-ctl we are
> meant to support is.
> Given the US holiday we may not get answers till next week and I've
> spent long enough on this for now!
If this is really a min dep, it should be specified as such.
Wheezy is listed supported because it hap
On 11/16/2015 11:09 AM, michael mccune wrote:
> On 11/16/2015 09:42 AM, Sean Dague wrote:
>> On 11/16/2015 09:34 AM, michael mccune wrote:
>>> On 11/13/2015 07:58 AM, Sean Dague wrote:
>>>> The #openstack-api IRC channel is quite quiet most days. As such it's
e second o.vo then our white list needs to be
>>>> able to handle not just first level fields but subfields too. I guess
>>>> this is doable but I'm wondering if we can avoid inventing a syntax
>>> expressing something like 'field.subfield.subsubfield'
>>&
the job to do something else
here.
Often times there are breaks due to upstream changes that require fixes
on the old side, which is now impossible.
Juno being eol means we expect you are already off of it, not that you
should be soon.
-Sean
t; to figure out what happened.
I'd suggest the following:
1. soft deleting and instance does nothing with instance actions.
2. archiving instance (soft delete -> actually deleted) also archives
off instance actions.
3. update instance_actions API so that you can get instance_actions
larly look into grenade failures to
determine root cause?
Because a periodic job that fails and isn't looked at, is just a waste
of resources. And from past experience very very few people look at
these job results.
-Sean
--
Sean Dague
http://dague.net
__
On 11/20/2015 11:36 AM, Matt Riedemann wrote:
>
>
> On 11/20/2015 10:04 AM, Andrew Laski wrote:
>> On 11/20/15 at 09:51am, Matt Riedemann wrote:
>>>
>>>
>>> On 11/20/2015 8:18 AM, Sean Dague wrote:
>>>> On 11/17/2015 10:51 PM, Matt Riedem
On 11/17/2015 05:31 PM, Matt Riedemann wrote:
>
>
> On 11/17/2015 2:05 PM, Sylvain Bauza wrote:
>>
>>
>> Le 17/11/2015 20:25, Sean Dague a écrit :
>>> On 11/17/2015 01:48 PM, Matt Riedemann wrote:
>>>>
>>>> On 11/17/2015 11:28 AM,
and have the gate-dsvm-tempest-sahara test
do something besides burn nodes. :)
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List
On 11/17/2015 06:11 AM, David Pursehouse wrote:
> On Tue, Nov 10, 2015 at 9:53 PM Sean Dague <s...@dague.net
> <mailto:s...@dague.net>> wrote:
> <...>
>
>
> Is there any update on label:Code-Review<=-1,group:nova-core ? The group
> search suppo
obably just add a release note in
when we add it. That's more likely for us to not loose a thing like that.
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscri
>
> Regards,
>
> Artur
>
> *From:*Armando M. [mailto:arma...@gmail.com]
> *Sent:* Friday, November 13, 2015 9:37 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [nova][neutron][upgrade] Grenade
> multin
On 11/16/2015 09:34 AM, michael mccune wrote:
> On 11/13/2015 07:58 AM, Sean Dague wrote:
>> The #openstack-api IRC channel is quite quiet most days. As such it's
>> not something that people are regularly checking in on, or often forget
>> about (I know I've been guilty of
rs through clients should use the system
CA for sure.
That will have a knock on effect about using it for python clients
directly, but that seems like the right option.
What's the expected way that a user would add a cert for a self signed
cloud to their laptop
On 11/13/2015 01:16 PM, Sean M. Collins wrote:
> On Fri, Nov 13, 2015 at 07:42:12AM EST, Sean Dague wrote:
>> Ok, I top responded with the details of the job, honestly I think it's
>> just a project-config change to get up and running, and then hacking at
>> the bugs that
also believe that the first step to get the job set is making
>> neutron own
>> > its grenade future, by migrating to grenade plugin maintained in
>> neutron
>> > tree.
>>
>> I'd like to see what Sean Dague thinks of this - my worry is that if we
>> sta
should definitely decide over ML instead.
Please express your feelings here and lets make it happen. :)
-Sean
--
Sean Dague
http://dague.net
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe
ecause of existing
jobs, so getting a multinode grenade job should just be a matter of a
project-config stanza. No additional code needs to be written. I'm sure
there might be some bugs (there always are), but getting rolling
shouldn't be too bad.
-Sean
--
a
lot of HA orchestration bits outside of Nova by a bunch of folks in the
NFV space.
So it's also not just theory that Zookeeper is keeping up here, many
OpenStack deploys already are using it quite heavily.
-Sean
--
Sean Dague
http://dague.net
_
601 - 700 of 1956 matches
Mail list logo
