Is there a flag in nova.conf that permits we configure that? In
documentation we can see that exists some algorithms used by scheduler.
But, I don't know how to choose that one best fit our requirements.
Thanks!
:)
On Wed, Nov 9, 2011 at 1:36 PM, Ed Leafe wrote:
> On Nov 9, 2011, at 7:51 AM, Ra
+1 :)
Razique Mahrouarazique.mahr...@gmail.com
Le 10 nov. 2011 à 11:27, Jorge Luiz Correa a écrit :Is there a flag in nova.conf that permits we configure that? In documentation we can see that exists some algorithms used by scheduler. But, I don't know how to choose that one best fit our requireme
We now have a sufficient amount of +1 to go ahead with this. If noone
objects before Tuesday next week, I'll make it so.
--
Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/
_
That brings us to +5. If noone objects by Tuesday next week, I'll make it so.
--
Soren Hansen | http://linux2go.dk/
Ubuntu Developer | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/
___
Mailing list: https://launchpad.
Hi Sandy,
Thanks for taking the time to read this.
My understanding is that a typical Nova deployment would span across multiple
zones, that zones may have subzones, and that child zones will have a number of
availability zones in them; please do correct me if I am wrong :)
That stated, it was
Are you using Diablo or Trunk?
If you're using trunk the default scheduler is MultiScheduler, which uses
Chance scheduler. I think Diablo uses Chance by default?
--scheduler_driver
Unless you've explicitly selected the LeastCostScheduler (which only exists in
Diablo now) I wouldn't worry about
Ok, that helps ... now I see the abstraction your going for (a new layer under
availability zones).
Personally I prefer a tagging approach to a modeled hierarchy. It was something
we debated at great length with Zones. In this case, the "tag" would be in the
capabilities assigned to the host.
The flag (of type list) you can use is "--least_cost_functions"
Multiple algorithms can be specified, the default one is
"compute_fill_first_cost_fn" which gives priority to the compute host
(XenServer/ESX etc.) with more free RAM.
Regards,
Sateesh
--
Hey,
On Wed, 2011-11-09 at 16:50 +0100, Thierry Carrez wrote:
> Hi everyone,
>
> Since there seems to be some confusion around master vs. stable/diablo
> vs. core reviewers, I think it warrants a small thread.
>
> When at the Design Summit we discussed setting up stable branches, I
> warned abou
Hi Nati,
I think it's fair to say there is very strong consensus around the
policy that only changes that have been accepted into master should be
considered for the stable branch.
It's not unusual for people to focus their QA efforts on a stable
branch. However, it is crucial that any fixes for
Hi all.
What are the best practices for HA of the hardware compute-node, and
virtual machines.
After googling I found matahari, pacemaker-cloud, but nothing about
build-in fiches openstack.
1) How do you create such environments?
2) Does it is right way to use pacemaker-cloud with openstack? Is
On 11/10/2011 02:38 PM, Viacheslav Biriukov wrote:
> Hi all.
>
> What are the best practices for HA of the hardware compute-node, and virtual
> machines.
> After googling I found matahari, pacemaker-cloud, but nothing about build-in
> fiches openstack.
>
> 1) How do you create such environmen
2011/11/10 Viacheslav Biriukov :
> Hi all.
> What are the best practices for HA of the hardware compute-node, and virtual
> machines.
> After googling I found matahari, pacemaker-cloud, but nothing about
> build-in fiches openstack.
> 1) How do you create such environments?
> 2) Does it is right w
There is a blueprint that touches these aspects:
https://blueprints.launchpad.net/nova/+spec/guest-ha
This is tailored at use cases where you cannot redesign an existing app.
The work is at the early stages, but you are more than welcome to join the
effort!
Cheers,
Armando
> -Original Me
Mark McLoughlin writes:
>> To mitigate that, we decided that the group doing stable branch
>> maintenance would be a separate group (i.e. *not* core developers), and
>> we decided that whatever ends up in the stable branch must first land in
>> the master branch.
>
> Well, I recall it a little di
Hm
If we planning vm hosting we work on the other level. So if hw node fails
we need fast automatic migration to other node.
2011/11/10 Soren Hansen
> 2011/11/10 Viacheslav Biriukov :
> > Hi all.
> > What are the best practices for HA of the hardware compute-node, and
> virtual
> > machines.
Funny you bring that up today;I spent the day working on that. I've implemented Gluster FS on my openstack running installation and written a script along that.Here is the implementationnode1- 1 instance runningthe node 1 crashes (could be anything atm)the script detect the node is gone (to be defi
Hello pf
thanks for sending this. Did you write this down on a wiki page
somewhere, too? I fear that in the mailing list archive this won't get
the visibility it deserves.
Cheers,
stef
On Wed, 2011-11-09 at 17:00 +1100, pf shineyear wrote:
> openstack swift install on centos 6
>
> 1. proxy inst
The main thing that the idea of host-aggregates provides is the ability to
specify metadata at a group of hosts level. If you put 10 hosts into a single
aggregate, you can specify characteristics for those hosts as a group (i.e.
which san they are backing files onto, whether they support live m
On Nov 10, 2011, at 6:22 AM, Mark McLoughlin wrote:
> But wait! Vish +2ed a stable branch patch yesterday:
>
> https://review.openstack.org/328
I don't mind losing my powers over stable/diablo.
On a related note, is there a way we can change the color scheme in gerrit (to
red??) for stable
Hi Armando!
It is very interesting feature. Are you already have specs for this
blueprints or may be etherpad?
Regards,
Ilya
10 ноября 2011 г. 20:16 пользователь Armando Migliaccio <
armando.migliac...@eu.citrix.com> написал:
> There is a blueprint that touches these aspects:
>
> https://bluepr
On Thu, Nov 10, 2011 at 08:02:23AM -0800, James E. Blair wrote:
>
> > But wait! Vish +2ed a stable branch patch yesterday:
> >
> > https://review.openstack.org/328
> >
> > James, help a poor confused soul out here, would you? :)
> >
> > Right, that makes sense. Only folks that understand the st
On Wed, 2011-11-09 at 14:57 +0100, Thierry Carrez wrote:
> Soren Hansen wrote:
> > 2011/11/9 Nachi Ueno :
> >> I understand your point. Stop QAing stable/diablo and focus on Essex.
> >
> > Oh, no no. That's not the point. I'm thrilled to have you work on
> > QAing Diablo. The only issue is that th
Thanks a lot for your answers. Unfortunately I can't follow the trunk
and I have to use the Diablo release. Is it possible to backport that
new scheduler to Diablo?
Anyway I gave the least cost scheduler a try, it loads but never
schedules a vm correctly.
--compute_scheduler_driver=nova.scheduler.
2011/11/10 Viacheslav Biriukov :
> Hm
> If we planning vm hosting we work on the other level. So if hw node fails we
> need fast automatic migration to other node.
That's the whole point. For most interesting applications, "fast"
automatic migration isn't anywhere near fast enough. Don't try t
Hi everyone,
It's my great pleasure to announce the immediate availability for
Keystone, Glance, Nova and Horizon of the first milestone of the Essex
development cycle, called "essex-1".
This milestone picks up all development made on trunk since Diablo
release branches were cut in early Septembe
Hi folks
Thank you for your help > Mark and Jay and Reviewers
I removed all review request for diablo/stable from Gerrit.
And, We will follow community policy.
Current our test code and bug fix is based on stable/diablo.
For each branch. "forward-porting" is needed.
12 bug patch branch is in pro
2011/11/10 Ryan Lane :
>> That's the whole point. For most interesting applications, "fast"
>> automatic migration isn't anywhere near fast enough. Don't try to
>> avoid failure. Expect it and design around it.
> This assumes all application designers are doing this. Most web
> applications do this
On Thu, 2011-11-10 at 13:22 -0600, Anne Gentle wrote:
> Thanks, Jay. I usually try to be more careful with the API names, so
> thanks for clarifying.
Sorry if I sounded patronizing there.. didn't mean to be.
> I think the landing page containing Draft API docs looks something
> like the attached
> That's the whole point. For most interesting applications, "fast"
> automatic migration isn't anywhere near fast enough. Don't try to
> avoid failure. Expect it and design around it.
>
This assumes all application designers are doing this. Most web
applications do this fairly well, but most ente
> I know. That's what makes them a poor fit for "the cloud".
>
Meh. Private clouds will still use applications like this. I think
"the cloud" is great for cloud providers, but why limit nova's
usefulness to just cloud providers?
"The cloud" way of doing things pushes the responsibility of keeping
Ryan Lane Wrote in response to Soren Hansen:
>> That's the whole point. For most interesting applications, "fast"
>> automatic migration isn't anywhere near fast enough. Don't try to
>> avoid failure. Expect it and design around it.
>>
>This assumes all application designers are doing this. Most
I think we need a straight copy of Nova 1.1 -> Nova 2.0 that simply renames
everything from 1.1 -> 2.0 and changes the endpoint url v1.1 -> v2
Also a big note saying that 2.0 is exactly the same as 1.1 but was renamed to
avoid confusion with 1.0 when we pulled out the minor version from the url.
I'm having problems trying to follow the steps in Gerrit Workflow Quick
Reference (wiki.openstack.org/GerritWorkflow), in fact I'm failing on the first
step. When I try and get the list of available projects I'm getting the
failure:
Permission denied (publickey).
I've uploaded my publ
Nevermind. I'm not sure how I did it but by some magic incantation of
resetting login name/public key it's now working.
Sorry for the noise.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786
-Original Message-
From: Dugger, Donald D
Sent: Thursday, Nov
On Thu, 2011-11-10 at 09:02 -0800, Vishvananda Ishaya wrote:
> On Nov 10, 2011, at 6:22 AM, Mark McLoughlin wrote:
>
> > But wait! Vish +2ed a stable branch patch yesterday:
> >
> > https://review.openstack.org/328
>
>
> I don't mind losing my powers over stable/diablo.
>
> On a related note,
On Thu, 2011-11-10 at 08:02 -0800, James E. Blair wrote:
> Mark McLoughlin writes:
> > Only folks that understand the stable branch policy[1] should be
> > allowed to +2 on the stable branch.
> >
> > Basically, a stable branch reviewer should only +2 if:
> >
> > - It fixes a significant issue,
Hi Dave,
On Thu, 2011-11-10 at 17:33 +, Dave Walker wrote:
> On Thu, Nov 10, 2011 at 08:02:23AM -0800, James E. Blair wrote:
>
> >
> > > But wait! Vish +2ed a stable branch patch yesterday:
> > >
> > > https://review.openstack.org/328
> > >
> > > James, help a poor confused soul out here,
38 matches
Mail list logo
