Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Wed, 2017-06-21 at 07:01 -0400, Sean Dague wrote: > On 06/21/2017 04:43 AM, sfinu...@redhat.com wrote: > > On Tue, 2017-06-20 at 16:48 -0600, Chris Friesen wrote: > > > On 06/20/2017 09:51 AM, Eric Fried wrote: > > > > Nice Stephen! > > > > > > > > For those who aren't aware, the rendered versi

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On 06/21/2017 04:43 AM, sfinu...@redhat.com wrote: > On Tue, 2017-06-20 at 16:48 -0600, Chris Friesen wrote: >> On 06/20/2017 09:51 AM, Eric Fried wrote: >>> Nice Stephen! >>> >>> For those who aren't aware, the rendered version (pretty, so pretty) can >>> be accessed via the gate-nova-docs-ubuntu-

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Tue, 2017-06-20 at 16:48 -0600, Chris Friesen wrote: > On 06/20/2017 09:51 AM, Eric Fried wrote: > > Nice Stephen! > > > > For those who aren't aware, the rendered version (pretty, so pretty) can > > be accessed via the gate-nova-docs-ubuntu-xenial jenkins job: > > > > http://docs-draft.openst

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On 06/20/2017 09:51 AM, Eric Fried wrote: Nice Stephen! For those who aren't aware, the rendered version (pretty, so pretty) can be accessed via the gate-nova-docs-ubuntu-xenial jenkins job: http://docs-draft.openstack.org/10/475810/1/check/gate-nova-docs-ubuntu-xenial/25e5173//doc/build/html/s

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

Nice Stephen! For those who aren't aware, the rendered version (pretty, so pretty) can be accessed via the gate-nova-docs-ubuntu-xenial jenkins job: http://docs-draft.openstack.org/10/475810/1/check/gate-nova-docs-ubuntu-xenial/25e5173//doc/build/html/scheduling.html?highlight=scheduling On 06/2

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On 06/20/2017 09:51 AM, Alex Xu wrote: 2017-06-19 22:17 GMT+08:00 Jay Pipes >: * Scheduler then creates a list of N of these data structures, with the first being the data for the selected host, and the the rest being data structures representing

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Mon, 2017-06-19 at 09:36 -0500, Matt Riedemann wrote: > On 6/19/2017 9:17 AM, Jay Pipes wrote: > > On 06/19/2017 09:04 AM, Edward Leafe wrote: > > > Current flow: > > As noted in the nova-scheduler meeting this morning, this should have  > been called "original plan" rather than "current flow",

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Jun 20, 2017, at 8:38 AM, Jay Pipes wrote: > >>> The example I posted used 3 resource providers. 2 compute nodes with no >>> local disk and a shared storage pool. >> Now I’m even more confused. In the straw man example >> (https://review.openstack.org/#/c/471927/ >>

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

2017-06-19 22:17 GMT+08:00 Jay Pipes : > On 06/19/2017 09:04 AM, Edward Leafe wrote: > >> Current flow: >> * Scheduler gets a req spec from conductor, containing resource >> requirements >> * Scheduler sends those requirements to placement >> * Placement runs a query to determine the root RPs that

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On 06/20/2017 08:43 AM, Edward Leafe wrote: On Jun 20, 2017, at 6:54 AM, Jay Pipes > wrote: It was the "per compute host" that I objected to. I guess it would have helped to see an example of the data returned for multiple compute nodes. The straw man example was for

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Jun 20, 2017, at 6:54 AM, Jay Pipes wrote: > >>> It was the "per compute host" that I objected to. >> I guess it would have helped to see an example of the data returned for >> multiple compute nodes. The straw man example was for a single compute node >> with SR-IOV, NUMA and shared storage

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On 06/19/2017 09:26 PM, Boris Pavlovic wrote: Hi, Does this look too complicated and and a bit over designed. Is that a question? For example, why we can't store all data in memory of single python application with simple REST API and have simple mechanism for plugins that are filtering. Bas

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On 06/19/2017 08:05 PM, Edward Leafe wrote: On Jun 19, 2017, at 5:27 PM, Jay Pipes > wrote: It was from the straw man example. Replacing the $FOO_UUID with UUIDs, and then stripping out all whitespace resulted in about 1500 bytes. Your example, with whitespace includ

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

Hi, Does this look too complicated and and a bit over designed. For example, why we can't store all data in memory of single python application with simple REST API and have simple mechanism for plugins that are filtering. Basically there is no any kind of problems with storing it on single host.

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Jun 19, 2017, at 5:27 PM, Jay Pipes wrote: > >> It was from the straw man example. Replacing the $FOO_UUID with UUIDs, and >> then stripping out all whitespace resulted in about 1500 bytes. Your >> example, with whitespace included, is 1600 bytes. > > It was the "per compute host" that I ob

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On 06/19/2017 05:24 PM, Edward Leafe wrote: On Jun 19, 2017, at 1:34 PM, Jay Pipes > wrote: OK, thanks for clarifying that. When we discussed returning 1.5K per compute host instead of a couple of hundred bytes, there was discussion that paging would be necessary.

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Jun 19, 2017, at 1:34 PM, Jay Pipes wrote: > >> OK, thanks for clarifying that. When we discussed returning 1.5K per compute >> host instead of a couple of hundred bytes, there was discussion that paging >> would be necessary. > > Not sure where you're getting the whole 1.5K per compute hos

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On 06/19/2017 01:59 PM, Edward Leafe wrote: While we discussed the fact that there may be a lot of entries, we did not say we'd immediately support a paging mechanism. OK, thanks for clarifying that. When we discussed returning 1.5K per compute host instead of a couple of hundred bytes, there

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On Jun 19, 2017, at 9:17 AM, Jay Pipes wrote: As Matt pointed out, I mis-wrote when I said “current flow”. I meant “current agreed-to design flow”. So no need to rehash that. >> * Placement returns a number of these data structures as JSON blobs. Due to >> the size of the data, a page size wil

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On 6/19/2017 9:17 AM, Jay Pipes wrote: On 06/19/2017 09:04 AM, Edward Leafe wrote: Current flow: As noted in the nova-scheduler meeting this morning, this should have been called "original plan" rather than "current flow", as Jay pointed out inline. * Scheduler gets a req spec from conduct

Re: [openstack-dev] [nova][scheduler][placement] Trying to understand the proposed direction

On 06/19/2017 09:04 AM, Edward Leafe wrote: Current flow: * Scheduler gets a req spec from conductor, containing resource requirements * Scheduler sends those requirements to placement * Placement runs a query to determine the root RPs that can satisfy those requirements Not root RPs. Non-shar

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On 06/12/2017 02:17 PM, Edward Leafe wrote: On Jun 12, 2017, at 10:20 AM, Jay Pipes > wrote: The RP uuid is part of the provider: the compute node's uuid, and (after https://review.openstack.org/#/c/469147/ merges) the PCI device's uuid. So in the code that passes th

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Jun 12, 2017, at 10:20 AM, Jay Pipes wrote: >> The RP uuid is part of the provider: the compute node's uuid, and (after >> https://review.openstack.org/#/c/469147/ merges) the PCI device's uuid. So >> in the code that passes the PCI device information to the scheduler, we >> could add that

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On 06/09/2017 06:31 PM, Ed Leafe wrote: On Jun 9, 2017, at 4:35 PM, Jay Pipes wrote: We can declare that allocating for shared disk is fairly deterministic if we assume that any given compute node is only associated with one shared disk provider. a) we can't assume that b) a compute node cou

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Fri, 9 Jun 2017, Dan Smith wrote: In other words, I would expect to be able to explain the purpose of the scheduler as "applies nova-specific logic to the generic resources that placement says are _valid_, with the goal of determining which one is _best_". This sounds great as an explanatio

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Fri, 9 Jun 2017, Jay Pipes wrote: Sorry, been in a three-hour meeting. Comments inline... Thanks for getting to this, it's very helpful to me. * Part of the reason for having nested resource providers is because it can allow affinity/anti-affinity below the compute node (e.g., workloa

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

>> b) a compute node could very well have both local disk and shared >> disk. how would the placement API know which one to pick? This is a >> sorting/weighing decision and thus is something the scheduler is >> responsible for. > I remember having this discussion, and we concluded that a > comp

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Jun 9, 2017, at 4:35 PM, Jay Pipes wrote: >> We can declare that allocating for shared disk is fairly deterministic >> if we assume that any given compute node is only associated with one >> shared disk provider. > > a) we can't assume that > b) a compute node could very well have both local

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

Sorry, been in a three-hour meeting. Comments inline... On 06/06/2017 10:56 AM, Chris Dent wrote: On Mon, 5 Jun 2017, Ed Leafe wrote: One proposal is to essentially use the same logic in placement that was used to include that host in those matching the requirements. In other words, when it tr

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

>> My current feeling is that we got ourselves into our existing mess >> of ugly, convoluted code when we tried to add these complex >> relationships into the resource tracker and the scheduler. We set >> out to create the placement engine to bring some sanity back to how >> we think about things

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On 06/05/2017 05:22 PM, Ed Leafe wrote: Another proposal involved a change to how placement responds to the scheduler. Instead of just returning the UUIDs of the compute nodes that satisfy the required resources, it would include a whole bunch of additional information in a structured response. A

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

Sorry for the top-post, but it seems that nobody has responded to this, and there are a lot of important questions that need answers. So I’m simply re-posting this so that we don’t get too ahead of ourselves, by planning implementations before we fully understand the problem and the implications

Re: [openstack-dev] [Nova][Scheduler]

On 6/8/2017 3:36 AM, Narendra Pal Singh wrote: Does Ocata bits support adding custom resource monitor say network bandwidth? I don't believe so in the upstream code. There is only a CPU bandwidth monitor in-tree today, but only supported by the libvirt driver and untested anywhere in our inte

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Jun 7, 2017, at 1:44 PM, Mooney, Sean K mailto:sean.k.moo...@intel.com>> wrote: > [Mooney, Sean K] neutron will need to use nested resource providers to track > Network backend specific consumable resources in the future also. One example > is > is hardware offloaded virtual(e.g. vitio/vhost-u

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Jun 7, 2017, at 1:44 PM, Mooney, Sean K mailto:sean.k.moo...@intel.com>> wrote: > [Mooney, Sean K] neutron will need to use nested resource providers to track > Network backend specific consumable resources in the future also. One example > is > is hardware offloaded virtual(e.g. vitio/vhost-u

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

> -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Wednesday, June 7, 2017 6:47 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova][scheduler][placement] Allocating > Complex Resources > > On 06/07/2017 01:0

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On 06/07/2017 01:00 PM, Edward Leafe wrote: On Jun 6, 2017, at 9:56 AM, Chris Dent mailto:cdent...@anticdent.org>> wrote: For clarity and completeness in the discussion some questions for which we have explicit answers would be useful. Some of these may appear ignorant or obtuse and are mostly

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Jun 6, 2017, at 9:56 AM, Chris Dent wrote: > > For clarity and completeness in the discussion some questions for > which we have explicit answers would be useful. Some of these may > appear ignorant or obtuse and are mostly things we've been over > before. The goal is to draw out some clear st

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Mon, 5 Jun 2017, Ed Leafe wrote: One proposal is to essentially use the same logic in placement that was used to include that host in those matching the requirements. In other words, when it tries to allocate the amount of disk, it would determine that that host is in a shared storage aggrega

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

Le 06/06/2017 15:03, Edward Leafe a écrit : > On Jun 6, 2017, at 4:14 AM, Sylvain Bauza > wrote: >> >> The Plan A option you mention hides the complexity of the >> shared/non-shared logic but to the price that it would make scheduling >> decisions on those criteries imp

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

On Jun 6, 2017, at 4:14 AM, Sylvain Bauza wrote: > > The Plan A option you mention hides the complexity of the > shared/non-shared logic but to the price that it would make scheduling > decisions on those criteries impossible unless you put > filtering/weighting logic into Placement, which AFAIK

Re: [openstack-dev] [nova][scheduler][placement] Allocating Complex Resources

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 05/06/2017 23:22, Ed Leafe a écrit : > We had a very lively discussion this morning during the Scheduler > subteam meeting, which was continued in a Google hangout. The > subject was how to handle claiming resources when the Resource > Provider

Re: [openstack-dev] [Nova] [Scheduler]

On 05/31/2017 09:49 AM, Narendra Pal Singh wrote: Hello, lets say i have multiple compute nodes, Pool-A has 5 nodes and Pool-B has 4 nodes categorized based on some property. Now there is request for new instance, i always want this instance to be placed on any compute in Pool-A. What would b

Re: [openstack-dev] [nova][scheduler] Anyone relying on the host_subset_size config option?

Beside eliminate race conditions, we use host_subnet_size in the special cases, we have different capacity hardware in a deployment, imagine a simple case, two compute hosts(RAM 48G vs 16G free), only enable the RAM weighter for nova-scheduler, if we launch 10 instances(RAM 1G flavor) one by one, a

Re: [openstack-dev] [nova][scheduler] Anyone relying on the host_subset_size config option?

On 05/26/2017 12:17 PM, Edward Leafe wrote: [resending to include the operators list] The host_subset_size configuration option was added to the scheduler to help eliminate race conditions when two requests for a similar VM would be processed close together, since the scheduler’s algorithm w

Re: [openstack-dev] [nova][scheduler] Anyone relying on the host_subset_size config option?

On 05/26/2017 01:14 PM, Edward Leafe wrote: The host_subset_size configuration option was added to the scheduler to help eliminate race conditions when two requests for a similar VM would be processed close together, since the scheduler’s algorithm would select the same host in both cases, lea

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

On 05/04/2017 04:59 AM, Giuseppe Di Lena wrote: Hi Chris, I'm pretty sure a regular user can create a server group and specify the anti-affinity filter. yes, but we want that the user specifies just the Robustness; the way in which we assign the instances to the compute nodes should be a bl

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

Hi Chris, > I'm pretty sure a regular user can create a server group and specify the > anti-affinity filter. yes, but we want that the user specifies just the Robustness; the way in which we assign the instances to the compute nodes should be a black box for the regular user(and also for the

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

On 05/03/2017 03:08 AM, Giuseppe Di Lena wrote: Thank you a lot for the help! I think that the problem can be solved using the anti-affinity filter, but we want a regular user can choose an instance and set the property(image, flavour, network, etc.) and a parameter Robustness >= 1(that is the

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

Thank you a lot for the help! I think that the problem can be solved using the anti-affinity filter, but we want a regular user can choose an instance and set the property(image, flavour, network, etc.) and a parameter Robustness >= 1(that is the number of copies of this particular instance).

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

On 5/2/2017 2:15 PM, Chris Friesen wrote: It sounds to me that the problem could be solved by specifying --min-count and --max-count to specify the number of copies, and using server groups with the anti-affinity filter to ensure that they end up on different compute nodes. This is exactly what

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

On 05/02/2017 10:59 AM, Jay Pipes wrote: On 05/02/2017 12:33 PM, Giuseppe Di Lena wrote: Thank you a lot! :-). Actually, we are also working in parallel to implement the algorithm with tacker, but for this project we will only use the basic modules in OpenStack and Heat. If the scheduler hints

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

> -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Tuesday, May 2, 2017 5:59 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova-scheduler] Get scheduler hint > > On 05/02/2017 12:33 PM, Giuseppe Di Lena wrote

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

On 05/02/2017 12:33 PM, Giuseppe Di Lena wrote: Thank you a lot! :-). Actually, we are also working in parallel to implement the algorithm with tacker, but for this project we will only use the basic modules in OpenStack and Heat. If the scheduler hints are no longer supported, what is the cor

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

Thank you a lot! :-). Actually, we are also working in parallel to implement the algorithm with tacker, but for this project we will only use the basic modules in OpenStack and Heat. If the scheduler hints are no longer supported, what is the correct way to give the scheduler personalized input

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

On 05/02/2017 09:58 AM, Giuseppe Di Lena wrote: Thank you for your answer :-) I'm pretty new in OpenStack and open source in general(I started two months ago, and I don't have any experience in developing big project). What we are trying to do is to implement our algorithm for Robust NFV chain;

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

Thank you for your answer :-) I'm pretty new in OpenStack and open source in general(I started two months ago, and I don't have any experience in developing big project). What we are trying to do is to implement our algorithm for Robust NFV chain; to do it we need to create multiple copies of th

Re: [openstack-dev] [nova-scheduler] Get scheduler hint

On 05/02/2017 05:14 AM, Giuseppe Di Lena wrote: Hello all, I’m modifying nova-scheduler, implementing my own scheduler; there is a way to get all the list of the scheduler hints(for example when I lunch a new Instance, add a custom Hint MY_HINT, with value 100)? I tried with def select_destin

Re: [openstack-dev] [nova][scheduler] ResourceProvider design issues

> On Oct 17, 2016, at 8:45 PM, Jay Pipes wrote: > > On 10/17/2016 11:14 PM, Ed Leafe wrote: >> Now that we’re starting to model some more complex resources, it seems that >> some of the original design decisions may have been mistaken. One approach >> to work around this is to create multiple

Re: [openstack-dev] [nova][scheduler] ResourceProvider design issues

On 10/17/2016 11:14 PM, Ed Leafe wrote: Now that we’re starting to model some more complex resources, it seems that some of the original design decisions may have been mistaken. One approach to work around this is to create multiple levels of resource providers. While that works, it is unneces

Re: [openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?

On Mon, 8 Aug 2016, Ed Leafe wrote: Me too. I think that this is one case where thinking in SQL messes you up. Sure, you can probably make it work by hacking in the concept of infinity into the code, but there will still be a conceptual disconnect. And later, when we inevitably need to enhance r

Re: [openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?

On Aug 8, 2016, at 9:42 AM, Jay Pipes wrote: >> When some ssd-ness is consumed, all of it (infinity) is still left >> over. >> >> For me it is easier: a resource provider has just one way of >> describing what it can do: classes of inventory (that provide >> gigabytes of disk that are ssd). When

Re: [openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?

On 08/08/2016 06:14 AM, Chris Dent wrote: On Mon, 8 Aug 2016, Alex Xu wrote: Chris, thanks for the blog to explain your idea! It helps me understand your idea better. Thanks for reading it. As I think I've mentioned a few times I'm not really trying to sell the idea, just make sure it is clea

Re: [openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?

On Mon, 8 Aug 2016, Alex Xu wrote: Chris, thanks for the blog to explain your idea! It helps me understand your idea better. Thanks for reading it. As I think I've mentioned a few times I'm not really trying to sell the idea, just make sure it is clear enough to be evaluated. I agree the goa

Re: [openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?

Chris, thanks for the blog to explain your idea! It helps me understand your idea better. I agree the goal for API interface design in your blog. But one point I guess you also agree, that is "The interface is easy to understand for API user". So look at the example of API request flow with gabbi,

Re: [openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?

2016-08-05 21:16 GMT+08:00 Chris Dent : > On Tue, 2 Aug 2016, Alex Xu wrote: > > Chris have a thought about using ResourceClass to describe Capabilities >> with an infinite inventory. In the beginning we brain storming the idea of >> Tags, Tan Lin have same thought, but we say no very quickly, due

Re: [openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?

On Tue, 2 Aug 2016, Alex Xu wrote: Chris have a thought about using ResourceClass to describe Capabilities with an infinite inventory. In the beginning we brain storming the idea of Tags, Tan Lin have same thought, but we say no very quickly, due to the ResourceClass is really about Quantitative

Re: [openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?

2016-08-03 2:12 GMT+08:00 Jay Pipes : > On 08/02/2016 08:19 AM, Alex Xu wrote: > >> Chris have a thought about using ResourceClass to describe Capabilities >> with an infinite inventory. In the beginning we brain storming the idea >> of Tags, Tan Lin have same thought, but we say no very quickly,

Re: [openstack-dev] [nova] [scheduler] Use ResourceProviderTags instead of ResourceClass?

On 08/02/2016 08:19 AM, Alex Xu wrote: Chris have a thought about using ResourceClass to describe Capabilities with an infinite inventory. In the beginning we brain storming the idea of Tags, Tan Lin have same thought, but we say no very quickly, due to the ResourceClass is really about Quantitat

Re: [openstack-dev] [nova][scheduler] A simple solution for better scheduler performance

Hi John, Thanks for the reply. There’re two rounds of experiments: Experiment A [3] is deployed by devstack. There’re 1000 compute services with fake virt driver. The DB driver is the devstack default PyMySQL. And the scheduler driver is the default filter scheduler. Experiment B [4] is the rea

Re: [openstack-dev] [nova][scheduler] A simple solution for better scheduler performance

On 15 July 2016 at 09:26, Cheng, Yingxin wrote: > It is easy to understand that scheduling in nova-scheduler service consists > of 2 major phases: > A. Cache refresh, in code [1]. > B. Filtering and weighing, in code [2]. > > Couple of previous experiments [3] [4] shows that “cache-refresh” is th

Re: [openstack-dev] [nova][scheduler] bug in handling of ISOLATE thread policy

On 06/07/2016 11:36 AM, Chris Friesen wrote: Hi, The full details are available at https://bugs.launchpad.net/nova/+bug/1590091 but the short version is this: 1) I'm running stable/mitaka in devstack. I've got a small system with 2 pCPUs, both marked as available for pinning. They're two core

Re: [openstack-dev] [nova][scheduler] bug in handling of ISOLATE thread policy

On 08 Jun 10:11, Finucane, Stephen wrote: > On 07 Jun 11:36, Chris Friesen wrote: > > Hi, > > > > The full details are available at > > https://bugs.launchpad.net/nova/+bug/1590091 but the short version > > is this: > > > > 1) I'm running stable/mitaka in devstack. I've got a small system > > wi

Re: [openstack-dev] [nova][scheduler] bug in handling of ISOLATE thread policy

On 07 Jun 11:36, Chris Friesen wrote: > Hi, > > The full details are available at > https://bugs.launchpad.net/nova/+bug/1590091 but the short version > is this: > > 1) I'm running stable/mitaka in devstack. I've got a small system > with 2 pCPUs, both marked as available for pinning. They're t

Re: [openstack-dev] [nova] [scheduler] New filter: AggregateInstanceAffinityFilter

> -Original Message- > From: Alonso Hernandez, Rodolfo > [mailto:rodolfo.alonso.hernan...@intel.com] > Sent: Thursday, June 2, 2016 6:00 PM > To: OpenStack Development Mailing List (not for usage questions) > > Subject: [openstack-dev] [nova] [scheduler] New filter: > AggregateInstanceAf

Re: [openstack-dev] Nova scheduler startup when database is not available

Excerpts from Jay Pipes's message of 2015-12-28 09:45:39 -0800: > On 12/24/2015 02:30 PM, Clint Byrum wrote: > > This is entirely philosophical, but we should think about when it is > > appropriate to adopt which mode of operation. > > > > There are basically two ways being discussed: > > > > 1) Fa

Re: [openstack-dev] Nova scheduler startup when database is not available

rg Subject: Re: [openstack-dev] Nova scheduler startup when database is not available On 12/24/2015 02:30 PM, Clint Byrum wrote: > This is entirely philosophical, but we should think about when it is > appropriate to adopt which mode of operation. > > There are basically two ways

Re: [openstack-dev] Nova scheduler startup when database is not available

On 12/24/2015 02:30 PM, Clint Byrum wrote: This is entirely philosophical, but we should think about when it is appropriate to adopt which mode of operation. There are basically two ways being discussed: 1) Fail fast. 2) Retry forever. Fail fast pros- Immediate feedback for problems, no zombie

Re: [openstack-dev] Nova scheduler startup when database is not available

On 12/23/2015 08:35 PM, Morgan Fainberg wrote: On Wed, Dec 23, 2015 at 10:32 AM, Jay Pipes mailto:jaypi...@gmail.com>> wrote: On 12/23/2015 12:27 PM, Lars Kellogg-Stedman wrote: I've been looking into the startup constraints involved when launching Nova services with

Re: [openstack-dev] Nova scheduler startup when database is not available

Excerpts from Jay Pipes's message of 2015-12-23 10:32:27 -0800: > On 12/23/2015 12:27 PM, Lars Kellogg-Stedman wrote: > > I've been looking into the startup constraints involved when launching > > Nova services with systemd using Type=notify (which causes systemd to > > wait for an explicit notific

Re: [openstack-dev] Nova scheduler startup when database is not available

Le 24/12/2015 02:35, Morgan Fainberg a écrit : On Wed, Dec 23, 2015 at 10:32 AM, Jay Pipes > wrote: On 12/23/2015 12:27 PM, Lars Kellogg-Stedman wrote: I've been looking into the startup constraints involved when launching Nova service

Re: [openstack-dev] Nova scheduler startup when database is not available

On Wed, Dec 23, 2015 at 10:32 AM, Jay Pipes wrote: > On 12/23/2015 12:27 PM, Lars Kellogg-Stedman wrote: > >> I've been looking into the startup constraints involved when launching >> Nova services with systemd using Type=notify (which causes systemd to >> wait for an explicit notification from t

Re: [openstack-dev] Nova scheduler startup when database is not available

On 12/23/2015 01:32 PM, Jay Pipes wrote: > On 12/23/2015 12:27 PM, Lars Kellogg-Stedman wrote: >> I've been looking into the startup constraints involved when launching >> Nova services with systemd using Type=notify (which causes systemd to >> wait for an explicit notification from the service b

Re: [openstack-dev] Nova scheduler startup when database is not available

On 12/23/2015 12:27 PM, Lars Kellogg-Stedman wrote: I've been looking into the startup constraints involved when launching Nova services with systemd using Type=notify (which causes systemd to wait for an explicit notification from the service before considering it to be "started". Some services

Re: [openstack-dev] [nova-scheduler] Scheduler sub-group meeting - Agenda 11/30

Le 30/11/2015 15:17, Dugger, Donald D a écrit : Sorry guys, I can't get onto IRC so, if any of you can connect you'll just have to muddle through without me :-) Hopefully freenode will be back up next week. We had a discussion on the channel, and the agreement was to cancel the meeting fo

Re: [openstack-dev] [nova-scheduler] Scheduler sub-group meeting - Agenda 11/30

Sorry guys, I can't get onto IRC so, if any of you can connect you'll just have to muddle through without me :-) Hopefully freenode will be back up next week. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 -Original Message- From: Dugger, Donald D Se

Re: [openstack-dev] [nova][scheduler] New Scheduler Meeting Time

What Ed said. I've proposed a change to the infra tree that should percolate this time change up through the system but, starting next Mon, 4/6, we'll be talking scheduler at the new time & place. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 -Original M

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

Good summary, Ed! Ed Leafe said on Wed, Jun 03, 2015 at 07:53:02AM -0500: > > I totally agree the scheduler doesn't have to know anything about > > flavors though. We should push them out to request validation in the > > Nova API. This can be considered part of cleaning up the scheduler API. > > T

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

Le 03/06/2015 16:02, Nikola Đipanov a écrit : On 06/03/2015 02:13 PM, John Garbutt wrote: On 3 June 2015 at 13:53, Ed Leafe wrote: On Jun 2, 2015, at 5:58 AM, Alexis Lee wrote: If you allocate all the memory of a box to high-mem instances, you may not be billing for all the CPU and disk w

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

On 06/03/2015 02:13 PM, John Garbutt wrote: > On 3 June 2015 at 13:53, Ed Leafe wrote: >> On Jun 2, 2015, at 5:58 AM, Alexis Lee wrote: >> >>> If you allocate all the memory of a box to high-mem instances, you may >>> not be billing for all the CPU and disk which are now unusable. That's >>> why

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

On 3 June 2015 at 13:53, Ed Leafe wrote: > On Jun 2, 2015, at 5:58 AM, Alexis Lee wrote: > >> If you allocate all the memory of a box to high-mem instances, you may >> not be billing for all the CPU and disk which are now unusable. That's >> why flavors were introduced, afaik, and it's still a va

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

On Jun 2, 2015, at 5:58 AM, Alexis Lee wrote: > If you allocate all the memory of a box to high-mem instances, you may > not be billing for all the CPU and disk which are now unusable. That's > why flavors were introduced, afaik, and it's still a valid need. So we had a very good discussion at t

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

Ed Leafe said on Mon, Jun 01, 2015 at 07:40:17AM -0500: > We need to update our concept of a resource internally in Nova, both > in the DB and in code, and stop thinking that every request should > have a flavor. If you allocate all the memory of a box to high-mem instances, you may not be billing

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

On Jun 1, 2015, at 7:49 AM, Sylvain Bauza wrote: > Long story short : > https://blueprints.launchpad.net/nova/+spec/resource-objects > > Until we get this, it's difficult to discuss on different resources within > Nova. Let's work by small steps and provide a versioned resource system > before

Re: [openstack-dev] [nova][scheduler] Updating Our Concept of Resources

Le 01/06/2015 14:40, Ed Leafe a écrit : Several of the discussions at Vancouver got me thinking about what seems to me to be a fundamental mis-match in Nova: the way we think about resources, and how we handle requesting/claiming them. I wrote down my initial thoughts (http://blog.leafe.com/

Re: [openstack-dev] [nova-scheduler] Scheduler sub-group (gantt} meeting 5/26 - cancel

- Mail original - > De: "Donald D Dugger" > À: "OpenStack Development Mailing List (not for usage questions)" > > Envoyé: Lundi 25 Mai 2015 20:51:43 > Objet: [openstack-dev] [nova-scheduler] Scheduler sub-group (gantt} meeting > 5/26 - cancel > I would suggest we cancel the IRC meeting

Re: [openstack-dev] [nova-scheduler] Cross-project requirements for an independant (gantt) scheduler at Vancouver

uot;Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 -Original Message- From: John Garbutt [mailto:j...@johngarbutt.com] Sent: Thursday, May 14, 2015 3:35 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova-scheduler

Re: [openstack-dev] [nova-scheduler] Cross-project requirements for an independant (gantt) scheduler at Vancouver

On 13 May 2015 at 16:48, Dugger, Donald D wrote: > I’d like to get together to talk about what kind of APIs/requirements > different projects would need from a common scheduler. To that end room 221 > is available on Tues. at 3:40PM. If you’re at all interested in a common > scheduler come on by

Re: [openstack-dev] [nova-scheduler] Scheduler sub-group (gantt) meeting 5/5

Le 04/05/2015 20:15, Dugger, Donald D a écrit : I will not be able to make the meeting tomorrow but the IRC channel will be available for anyone who wants to get together. For an agenda I would suggest: 1) Liberty specs (tracking page - https://wiki.openstack.org/wiki/Gantt/liberty

Re: [openstack-dev] [nova] [scheduler] [gantt] Please stop using "Gantt" for discussing about Nova scheduler

86 > >-Original Message- >From: Ed Leafe [mailto:e...@leafe.com] >Sent: Friday, April 3, 2015 10:59 AM >To: openstack-dev@lists.openstack.org >Subject: Re: [openstack-dev] [nova] [scheduler] [gantt] Please stop using >"Gantt" for discussing about Nova scheduler > &

  1   2   3   >