On 03/05/2014 04:52 PM, Everett Toews wrote:
> On Mar 5, 2014, at 8:16 AM, Russell Bryant wrote:
>
>> I think SDK support is critical for the success of v3 long term. I
>> expect most people are using the APIs through one of the major SDKs, so
>> v3 won't take off
ity on its technical merits. The other
angle is to increase your general karma in the dev community so that
reviewers are compelled to help the *developer*, even if they are
ambivalent about the particular code.
--
Russell Bryant
___
OpenStack-dev mailin
focussed on the API design independent of
> implementation and Nova internals.
Yes, I would absolutely like to get better about doing this as a part of
our blueprint review process.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@l
or this FFE.
>
> This one borders on the bug side, so if it merges early enough, I'm +1
> on it.
>
I'd still want it to land ASAP. I'm OK with it as long there are
reviewers signed up. I'm still waiting for confirmation on sponsorship
of this one.
--
Russ
be -1 on this one.
>
This is actually a novaclient patch anyway, so it's not really relevant
to the feature freeze. novaclient changes can go in anytime as it's not
part of the integrated release.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ants it and it lands early
> enough to limit the distraction, I guess it's fine.
>
I'm fine with it as long as the sponsors confirm their sponsorship and
are ready to get it merged this week.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
review this to
get it merged ASAP? If so, could you comment on how close you think it is?
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ne should wait for Juno, so -1 on the FFE.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 03/06/2014 08:45 AM, Russell Bryant wrote:
> On 03/06/2014 05:37 AM, Thierry Carrez wrote:
>> Gary Kotton wrote:
>>> Hi,
>>> Unfortunately we did not get the ISO support approved by the deadline.
>>> If possible can we please get the FFE.
>>>
>
On 03/06/2014 07:08 AM, John Garbutt wrote:
> But I do worry about having too many FFEs, so we get distracted from bugs.
Fair concern.
To mitigate it we need to have a hard deadline on these. We should aim
for this week and an absolute hard deadline of Tuesday.
--
Russell Bry
On 03/06/2014 03:00 AM, Nikola Đipanov wrote:
> On 03/05/2014 07:59 PM, Russell Bryant wrote:
>> On 03/05/2014 12:27 PM, Andrew Laski wrote:
>>> On 03/05/14 at 07:37am, Tracy Jones wrote:
>>>> Hi - Please consider the image cache aging BP for FFE
>>>&g
with the idea, I'm happy to work on getting a
repo set up. The base template could be the first review against the
repo.
[1] https://wiki.openstack.org/wiki/Blueprints
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
coming Tuesday, though.
We have a pretty hefty list of exceptions already, so I want to make
sure it doesn't drag out very long.
Thanks,
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-b
l contained within the RBD driver.
>>
>> This is needed as it implements an essential functionality that has
>> been missing in the RBD driver and this will become the second release
>> it's been attempted to be merged into.
>
> Add me as a sponsor.
OK, great. T
ame in too late and is too risky at this point, so let's
> revisit in Juno and get it turned on early so everyone can be
> comfortable with it.
OK. Thanks a lot to everyone who helped evaluate this. Hopefully we
can get it sorted early in Juno, then.
--
Russell Bryant
__
report any problems here:
https://bugs.launchpad.net/python-novaclient
Thanks,
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I do think we should move forward here. +1 to forcing
all Juno to go through this. Thanks for going through all the launchpad
blueprints. Next up will be to get the repo created. I'll look into
that part.
--
Russell Bryant
___
OpenStack
On 03/10/2014 11:41 AM, Russell Bryant wrote:
> On 03/10/2014 08:20 AM, John Garbutt wrote:
>> We probably need a mass un-approve of all the blueprints in Nova, so
>> all new blueprints in Juno go through the new process. I can take
>> charge of that part, and helping with joi
river=novadocker.virt.docker.driver.DockerDriver
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 03/12/2014 08:02 AM, Sean Dague wrote:
> On 03/12/2014 07:36 AM, Russell Bryant wrote:
>> Note that devstack is going to break for docker and Nova master
>> right now. We're in the middle of moving the docker driver. In
>> the meantime, use a rev of Nova befor
nd Nova, but for that we could look at creating a shared library of
code to ease implementing this sort of thing in each API that needs it.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 03/12/2014 12:14 PM, Sylvain Bauza wrote:
> Hi Russell,
> Thanks for replying,
>
>
> 2014-03-12 16:46 GMT+01:00 Russell Bryant <mailto:rbry...@redhat.com>>:
> The biggest concern seemed to be that we weren't sure whether Climate
> makes sense as
Es at all. It's a
distraction during critical time as we work toward the RC.
The focus right now has to be on high/critical priority bugs and
regressions. We can revisit this properly in Juno.
--
Russell Bryant
___
OpenStack-dev mailing lis
t postgres doesn't allow implicit casts. If I
> change the line to:
>
> filters = {'uuid': filter_uuids, 'deleted': 0}
>
>
> Then it seems to work.
Looks right. Thanks!
Can you please open a bug and submit a patch? We should target t
g races today. We do the
final claiming and validation on the compute node itself and kick back
to the scheduler if something doesn't work out. Alternatives are *way*
too risky to be doing in feature freeze, IMO.
I think it's great to see discussion of better ways to approach these
thin
proceed with this change, or any remarks
> to the contrary.
Happy to be removed. I haven't been active in the last few months.
Best wishes!
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lis
of Trove. I'm not sure that
actually makes sense (an application template you can deploy may
suffice here). In any case, I view OpenStack's use case and anyone
wanting to use qpid/rabbit/whatever directly separate and out of scope
of Marconi.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> significant change.
>
FWIW, we've also discussed it for Nova. We approved converting to use
it for the v3 API that is still being worked on. I hope to see that get
movement again during Juno.
--
Russell Bryant
___
OpenStack-dev mailing l
"different than everything else" issues than just library
choices. It's a real problem IMO, but I'd rather separate that
discussion from this thread.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rch/029232.html
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
m now going back to my cave.
I think the current process and system and *so* broken that we can't
afford to wait. Further, after talking to Thierry, it seems quite
likely that we would continue using this exact process, even with
Storyboard. Storyboard isn't a review tool and won&#
easier to
provide clear examples of what the reviews will look like. We can use
that to help show how to get involved and provide feedback.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
uot;Dependencies" section above the list of patch versions.
That's where you see the patches linked together. Our other tools that
do testing and merging of changes respect these dependencies. Changes
will only be tested with the other changes they depend on
seeing this quite a bit this cycle, and
> the only thing I can think of is perhaps it's developers getting some
> sort of points for number of commits).
>
Some related good docs on splitting up changes:
https://wiki.openstack.org/wiki/GitCommitMessages
--
Russell Bryant
eps to create a new spec and make
>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.
>
adding* the use of gerrit
as a centralized and organized place to do design reviews.
We will continue to use blueprints for tracking what we plan to go into
each release, as well as it's current status.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 03/24/2014 02:19 PM, Monty Taylor wrote:
> On 03/24/2014 10:07 AM, Russell Bryant wrote:
>> On 03/24/2014 12:34 PM, James E. Blair wrote:
>>> Hi,
>>>
>>> So recently we started this experiment with the compute and qa programs
>>> to try using Gerrit
On 03/25/2014 12:01 AM, Stefano Maffulli wrote:
> On 03/24/2014 09:20 AM, Russell Bryant wrote:
>> Another critical point of clarification ... we are *not* moving out of
>> blueprints at all. We're still using them for tracking, just as before.
>> We are *adding* the u
> month earlier before we went into the cycle of review/fix/format etc.
I think the key point is the current timing. We're aiming to do RC1 for
projects this week if possible. FFEs were really only allowed weeks ago.
--
Russell Bryant
we have completed v3 support within OpenStack itself,
it's premature to mark the API deprecated since that's a signal to end
users and deployers that says action is required.
Thoughts?
[1]
http://eavesdrop.openstack.org/meetings/project/2014/project.2014-03-25-21
in master.
I think it should be reverted completely. Otherwise, the problem hasn't
been solved. Some deployments chase trunk and we'd still have this
confusion in the dev community, as well.
--
Russell Bryant
___
OpenStack-dev
On 03/26/2014 06:30 AM, Thierry Carrez wrote:
> Russell Bryant wrote:
>> [...]
>> First, it seems there isn't a common use of "deprecated". To me,
>> marking something deprecated means that the deprecated feature:
>>
>> - has been complete
-project session at the summit, and collaborating
> with the SDK team, to brainstorm solutions to that problem.
Logging on half of the API calls is obviously bad, but logging a single
time seems reasonable. Deployers need to know it's deprecated, too. If
an API is going away, they have
txt
Related, adding instructions to generate without tox:
https://review.openstack.org/#/c/82533/
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
rivers/+members#active
[4] https://wiki.openstack.org/wiki/Nova#Nova_subteams
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
.
I feel confident that Dan would be a fantastic PTL for Nova.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
severe, so I'm not sure this
sounds like something we would want to include in that state.
If the gaps were closed, the biggest blocker to considering it for
merging would be a CI platform that's running Nova in this setup against
every patch. We require that for all hypervisor drivers no
adequately documented.
Thanks,
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
needed versus
new modules. The patches would be more painful to maintain out of tree.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
qemu, uml,
# xen) (string value)
# Deprecated group/name - [DEFAULT]/libvirt_type
#virt_type=kvm
So, the old option was:
[DEFAULT]
libvirt_type=kvm
The new option is:
[libvirt]
virt_type=kvm
--
Russell Bryant
___
Open
On 04/01/2014 11:16 AM, Daniel P. Berrange wrote:
> On Mon, Mar 31, 2014 at 01:17:39PM -0400, Russell Bryant wrote:
>> On 03/31/2014 01:01 PM, Michał Dubiel wrote:
>>> Hi All,
>>>
>>> I have prepared commits I would like to have it reviewed and eventually
ts as a separate driver?
It's not a new driver in the technical sense, but it is a new column in
our support matrix, so I was thinking the same testing requirements
should apply.
https://wiki.openstack.org/wiki/HypervisorSupportMatrix
--
Russell Bryant
_
jects around here, so I wanted to make that process
easier for everyone. Renaming your OpenStack project will become as
simple as a single request to the v4 REST API using XML encoded JSON.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev
related note, it would be really nice to have a status page for
every CI system, like this:
https://wiki.openstack.org/wiki/NovaVMware/Minesweeper/Status
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lis
er, just like we're doing here, I (and others) are happy to help
discuss the project's direction and approach to help make sure it ends
up in a state that Nova is happy with.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 04/02/2014 09:20 AM, Dolph Mathews wrote:
>
> On Tue, Apr 1, 2014 at 7:40 PM, Anne Gentle <mailto:a...@openstack.org>> wrote:
>
>
>
>
> On Wed, Mar 26, 2014 at 5:30 AM, Thierry Carrez
> mailto:thie...@openstack.org>> w
ly ready to use config files.
>
> Is there a chance you can push something to gerrit?
How about auto generate the sample config like most other projects?
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://l
But in any case, it seems to make sense to handle sample
config files consistently across projects. If a usability enhancement
related to examples is made, it will then make its way to all projects.
--
Russell Bryant
___
OpenStack-dev mailing list
Ope
t.
In the meantime, I have added this as a known issue for Nova here:
https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
created in Keystone for trove and have trove use that for
managing all of its instances.
If that is sufficient, trove would need some changes to use its service
credentials instead of the user credentials. I don't think any changes
are needed in Nova.
Is there anything missing to support your use ca
o very specifically won't work with that
approach.
For example, is it a billing thing? As it stands, all notifications for
trove managed instances will have the user's info in them. Do you not
want to lose that? If that's the problem, that seems solvable with a
much simple
On 04/06/2014 03:22 PM, Vipul Sabhaya wrote:
>
>
>
> On Sun, Apr 6, 2014 at 9:36 AM, Russell Bryant <mailto:rbry...@redhat.com>> wrote:
>
> On 04/06/2014 09:02 AM, Christopher Yeoh wrote:
> > On Sun, Apr 6, 2014 at 10:06 AM, Hopper, Justin
ble the
filters by default. It's harmless when the API isn't used. That was
just an oversight.
The list of instances in a group through the API only shows non-deleted
instances.
There are some implementation details that could be improved (the check
on the server is the big one).
--
R
On 04/07/2014 02:12 PM, Russell Bryant wrote:
> On 04/07/2014 01:43 PM, Day, Phil wrote:
>> Generally the scheduler’s capabilities that are exposed via hints can be
>> enabled or disabled in a Nova install by choosing the set of filters
>> that are configured. However the
On 04/08/2014 06:16 AM, Day, Phil wrote:
>> https://bugs.launchpad.net/nova/+bug/1303983
>>
>> --
>> Russell Bryant
>
> Wow - was there really a need to get that change merged within 12 hours and
> before others had a chance to review and comment on it ?
It was
On 04/08/2014 06:29 AM, Day, Phil wrote:
>
>
>> -Original Message-----
>> From: Russell Bryant [mailto:rbry...@redhat.com]
>> Sent: 07 April 2014 19:12
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [nova] Server Groups are not an
notes. Please let me know if I missed anything
else that should be listed.
https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse#Hyper-V
Thanks,
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.ope
On 04/09/2014 10:45 AM, Robert Collins wrote:
> On 10 April 2014 02:32, Chris Friesen wrote:
>> On 04/09/2014 03:45 AM, Day, Phil wrote:
>>>>
>>>> -Original Message- From: Russell Bryant
>>
>>
>>>> We were thinking that there
ion is very valuable.
> I've made a start on a page for Heat, feedback welcome!
>
> https://wiki.openstack.org/wiki/Security/Icehouse/Heat
I wonder if it would be easier to keep up if we restructure this a bit.
In particular, I'm wondering if havi
ut that was because
of timing and infra review availability. I think a re-focus on doing it
in openstack's infra is the right approach.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
we should add those."
So, I think we should proceed with the support in the nova-docker repo
for now. That will unblock CI progress against nova-docker, which is
the #1 blocker for eventually re-proposing the driver to nova itself.
--
Russell Bryant
installed within the testing image); This is something that could be
> easily fixed if should it be essential.
>
> If you're interested, I'd be willing to entertain adding Fedora support
> to Dockenstack.
I think part of the issue is how quickly we can get this wor
On 04/11/2014 04:58 PM, Sean Dague wrote:
> On 04/11/2014 04:39 PM, Russell Bryant wrote:
>> On 04/11/2014 04:29 PM, Eric Windisch wrote:
>>>
>>> What I hope to do is setup a check doing CI on devstack-f20
>>> nodes[3], this will setup a devstack based nova wit
usly, and
> still take less time than running private infrastructure.
>
> I look forward to seeing docker tests running in OpenStack
> infrastructure soon.
Thanks a bunch for the support, Jim. Hopefully we can get this all up
and running as early as possible in the cycle so t
ssary information and actions through the
API to make implementing this possible. However, I think the
functionality generally belongs as something outside of Nova.
If it's something that lives outside of Nova, then we should discuss it
in terms of pu
ended for consumption by other apps.
We currently try to make sure that all changes to the body of these
messages are backwards compatible. You should be safe within a version,
but as usual, please watch the release notes for changes.
At some point we really need to d
in code review.
If we can do more up front work that will reduce re-work later, it's
going to be a *huge* help to our primary project bottleneck: the code
review queue.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
process on [2].
[1] https://launchpad.net/~nova-drivers/+members#active
[2] https://wiki.openstack.org/wiki/Blueprints#Creation
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
it makes sense to just upload them to
the wiki and include links to them from the spec using the image directive.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
x27;ll get better about how we use this guidance as we get more
experience reviewing against it. Another consistency area we need to
keep an eye on is how these processes and critera are evolving in each
project. The *-specs processes have evolved quickly, and we should try
to make sure we're
ile doing a spec review.
b) Allow images in nova-specs, perhaps in a subdirectory with
the same name as the spec as a new convention. The benefit
is the images are more guaranteed to stay static with the
spec, as it was during review. The downside is it's more of
On 04/16/2014 12:00 PM, Balázs Gibizer wrote:
> Thanks for the pointer to the Neutron thread. After reading it through
> I decided to move the image to wiki.
OK. I think your diagram is probably doable in ascii, though. :-)
--
Russell
equired just to view a template as well.
Yeah, that's right. I'd honestly really prefer simple ascii diagrams in
almost all cases anyway. Requiring an external diagram should be a rare
exception, not the rule, IMO.
--
Russell Bryant
___
Open
On 04/16/2014 12:55 PM, Russell Bryant wrote:
> On 04/16/2014 12:42 PM, Kevin Benton wrote:
>> The only downside to putting it on the wiki is that it no longer has a
>> shared fate with the specification in the repo. If someone deletes it or
>> replaces it on the wiki, inform
On 04/16/2014 09:51 AM, Russell Bryant wrote:
> On 04/16/2014 09:39 AM, Salvatore Orlando wrote:
>> if the image you're adding is a diagram, I would think about
>> asciiflow.com <http://asciiflow.com> first!
>
> In all seriousness, I think that's a ver
check tool. I
do think we should be lenient on minor grammar issues, unless the
mistake is serious enough to impact understanding.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
be
> explicit about what parts of the API it's ok to throw a Not
> Supported. Because I don't think it's a blanket ok. On API
> endpoints where this is ok, we can convert not supported to a
> skip.
Definitely agreed with Dan's points here.
We alre
>
> Is this a bug, or is the expectation that we would only ever use this
> wrapper for functions that don't return a value?
Looks like a bug to me. Nice catch.
Want to submit a patch for this?
--
Russell Bryant
___
OpenStack-dev mailin
ed features,
>>> as the test suite would just do the right thing whenever the driver is
>>> updated.
>>
>> Agreed. Though I think we probably want the Nova API to be explicit
>> about what parts of the API it's ok to throw a Not Supported. Because I
>> don't think it's a blanket ok. On API endpoints where this is ok, we can
>> convert not supported to a skip.
>
> Yep, this ties into a discussion I recall elsewhere about specifying
> exactly which parts of the Nova API are considered mandatory features
> for drivers to implement.
I put that in as a proposal to discuss at the design summit.
http://summit.openstack.org/cfp/details/55
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
s a proof of concept: https://review.openstack.org/#/c/89725/
John originally mentioned this on the review, but Phil and I both seem
to agree.
Most novaclient work can just be a work item of a nova blueprint. How
about we just handle it that way?
I don't real
k.org/pipermail/openstack-dev/2014-February/026450.html
[14]
https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage
[15] http://www.openstack.org/legal/community-code-of-conduct/
--
Russell Bryant
___
OpenStack-dev mailing list
Open
ttps://github.com/jogo/gerrit-fun
Some related stats on open code reviews:
http://russellbryant.net/openstack-stats/nova-openreviews.html
I don't have historical data, which would be really useful. However,
based on my memory and an old ML post [1], these numbers have tripled
for Nova since m
its own merit rather than have the TC just grant
it up front. I'd say let's give the group a cycle to build up, generate
guidelines, and participate in API design reviews. I'd rather see it as
the TC making something official that was effectively already happening
in practice.
--
p://clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Remote/
[2] https://review.openstack.org/#/c/127281/
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
of
Congress being far too big (so early, and maybe period).
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
m you use to react to a
failing host could use the tag as part of the criteria to figure out
which instances to evacuate and which to leave as dead.
--
Russell Bryant
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 10/13/2014 05:59 PM, Russell Bryant wrote:
> Nice timing. I was working on a blog post on this topic.
which is now here:
http://blog.russellbryant.net/2014/10/15/openstack-instance-ha-proposal/
--
Russell Bryant
___
OpenStack-dev mailing l
On 10/15/2014 03:16 PM, Florian Haas wrote:
> On Wed, Oct 15, 2014 at 7:20 PM, Russell Bryant wrote:
> (4) Per-guest HA.
>
> This is the idea of just doing "nova boot --keep-this running", i.e.
> setting a per-guest flag that still means the machine is to be kept up
&
On 10/15/2014 06:30 PM, Jay Pipes wrote:
>
>
> On 10/15/2014 04:50 PM, Florian Haas wrote:
>> On Wed, Oct 15, 2014 at 9:58 PM, Jay Pipes wrote:
>>> On 10/15/2014 03:16 PM, Florian Haas wrote:
>>>>
>>>> On Wed, Oct 15, 2014 at 7:20 PM, Russell Bry
On 10/15/2014 05:07 PM, Florian Haas wrote:
> On Wed, Oct 15, 2014 at 10:03 PM, Russell Bryant wrote:
>>> Am I making sense?
>>
>> Yep, the downside is just that you need to provide a new set of flavors
>> for "ha" vs "non-ha". A benefit though
301 - 400 of 884 matches
Mail list logo
