| openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22) https://review.openstack.org/576712 | 00:03 |
|---|---|---|
| openstackgerrit | melanie witt proposed openstack/nova master: Update api-guide and api-ref to be clear about forced-down https://review.openstack.org/492533 | 00:04 |
| openstackgerrit | melanie witt proposed openstack/nova master: Update contributor process doc for stein https://review.openstack.org/592766 | 00:13 |
| openstackgerrit | melanie witt proposed openstack/nova master: Update contributor docs for stein https://review.openstack.org/592766 | 00:29 |
| *** nicolasbock has quit IRC | 00:36 | |
| openstackgerrit | fupingxie proposed openstack/nova master: Support list for alias in pci section in nova.conf https://review.openstack.org/592243 | 01:31 |
| openstackgerrit | melanie witt proposed openstack/nova master: Update api-guide and api-ref to be clear about forced-down https://review.openstack.org/492533 | 01:42 |
| *** tetsuro has joined #openstack-placement | 01:44 | |
| *** tetsuro has quit IRC | 01:44 | |
| openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Add support specify volume type when boot instance https://review.openstack.org/579520 | 01:47 |
| openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Support deleting data volume when destroy instance https://review.openstack.org/580336 | 01:50 |
| openstackgerrit | Matt Riedemann proposed openstack/nova master: Add zvm admin intro and hypervisor information https://review.openstack.org/533125 | 02:05 |
| openstackgerrit | Tao Li proposed openstack/nova master: Rollback instance vm_state to original where instance claims failed https://review.openstack.org/592252 | 02:08 |
| openstackgerrit | Matt Riedemann proposed openstack/nova master: Add zvm CI information https://review.openstack.org/533512 | 02:09 |
| openstackgerrit | Merged openstack/nova master: Add zvm admin intro and hypervisor information https://review.openstack.org/533125 | 02:28 |
| *** Nel1x has joined #openstack-placement | 02:49 | |
| openstackgerrit | Matt Riedemann proposed openstack/nova master: Add zvm CI information https://review.openstack.org/533512 | 02:58 |
| openstackgerrit | Takashi NATSUME proposed openstack/nova master: Update contributor guide for Stein https://review.openstack.org/591258 | 03:10 |
| *** Nel1x has quit IRC | 03:11 | |
| openstackgerrit | Merged openstack/nova master: Add zvm CI information https://review.openstack.org/533512 | 03:21 |
| *** e0ne has joined #openstack-placement | 05:20 | |
| *** takashin has left #openstack-placement | 05:31 | |
| openstackgerrit | Tao Li proposed openstack/nova master: Rollback instance vm_state to original where instance claims failed https://review.openstack.org/592252 | 05:54 |
| *** e0ne has quit IRC | 06:44 | |
| *** gibi is now known as giblet | 07:03 | |
| *** tssurya has joined #openstack-placement | 07:07 | |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Remove the deprecated API extensions policies https://review.openstack.org/586872 | 07:11 |
| openstackgerrit | Merged openstack/nova master: Update api-guide and api-ref to be clear about forced-down https://review.openstack.org/492533 | 07:58 |
| *** e0ne has joined #openstack-placement | 07:59 | |
| openstackgerrit | Surya Seetharaman proposed openstack/nova master: Merge extended_status extension response into server view builder https://review.openstack.org/592092 | 08:26 |
| *** e0ne has quit IRC | 08:37 | |
| openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add get_by_cell_and_project() method to InstanceMappingList https://review.openstack.org/591656 | 08:40 |
| openstackgerrit | Surya Seetharaman proposed openstack/nova master: API microversion bump for handling-down-cell https://review.openstack.org/591657 | 08:40 |
| openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova list when a cell is down https://review.openstack.org/567785 | 08:41 |
| openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova show when a cell is down https://review.openstack.org/591658 | 08:41 |
| openstackgerrit | Surya Seetharaman proposed openstack/nova master: Return a minimal construct for nova service-list when a cell is down https://review.openstack.org/584829 | 08:41 |
| openstackgerrit | Tao Li proposed openstack/nova master: Rollback instance vm_state to original where instance claims failed https://review.openstack.org/592252 | 08:50 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: any traits in allocation_candidate query https://review.openstack.org/565730 | 09:04 |
| openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: support mixing required traits with any traits https://review.openstack.org/565741 | 09:25 |
| *** e0ne has joined #openstack-placement | 10:09 | |
| sean-k-mooney | o/ anyone around at the moment? | 10:15 |
| sean-k-mooney | dumb question but how would people feel about haveing an addtional user_traits field in a resouce provider so we can unabigusly distinguish between tratis that are discovered by openstack services and traits that have been set by an operator? | 10:17 |
| *** cdent has joined #openstack-placement | 10:23 | |
| *** nicolasbock has joined #openstack-placement | 10:35 | |
| cdent | giblet: check my thinking here please. If we go ahead and expect that generation conflicts are not going to happen with current use cases, that means that there's very little work that we did in Rocky, related to placement, that has immediate visible impact to users? | 10:40 |
| cdent | That's not a horrible thing, I'm just trying to think in terms of what to tell people about "what we did". | 10:41 |
| sean-k-mooney | cdent: o/ are you free to answer a potentailly dumb question | 10:44 |
| cdent | I'm available to listen, but I can't promise to be able to answer | 10:45 |
| sean-k-mooney | there is some work around adding tracking of passthough devices to placement proposed for next cycle. | 10:45 |
| sean-k-mooney | i think you have seen it already | 10:45 |
| * cdent nods | 10:46 | |
| sean-k-mooney | one of the things that has come up again is operators providing traits for devices and how that interacts with deiscovered traits that a virt-driver might detect | 10:46 |
| cdent | yeah, I remember some pretty complicated discussions about that in dublin (I think it was dublin) | 10:47 |
| cdent | And there seemed to be some magical thinking about the virt driver being able to "own" some traits | 10:47 |
| cdent | it would only change those it owned | 10:48 |
| sean-k-mooney | so the dumb question is. how would you feel about adding a "user-traits" or "declared-tratis" field to the Resouce proveder object so that we can unabigiusly seperate discovered traits (the current tratis field) and user provided/ declared traits (the new field) | 10:48 |
| sean-k-mooney | then in the db you would jsut union the two sets of traits when calulating the allocation candiates ectra | 10:49 |
| cdent | I'd feel pretty bad about that | 10:49 |
| cdent | I think that's something the clients should worry about | 10:49 |
| sean-k-mooney | cdent: ya that is certenly an option | 10:49 |
| cdent | i wouldn't want placement have to distinguish between "types" of traits | 10:49 |
| sean-k-mooney | cdent: efried was sugestting namespacing some tratis that are owned by the virt-driver. but i think that lessense the usefullness of standard traits | 10:50 |
| cdent | I think the the idea of a virt driver (or whatever) being able to say "I own these traits" (which mahy or may not be configurable) is a better and more flexible option | 10:50 |
| cdent | i agree. I wouldn't want to see namespacing. I think the "owner" thing is better | 10:51 |
| cdent | if we get namespacing then we have a huge profligation of traits that are almost but not quite the same thing | 10:51 |
| sean-k-mooney | cdent: that implyes that a virt-driver and operator cant both own the same trait which begs the question who owns standard tratis. | 10:52 |
| sean-k-mooney | ya i agree that duplicating traits per driver is an anti pattern. | 10:52 |
| sean-k-mooney | anyway we dont need to solve this now but just trying to think if there were any less invaisve way to do this | 10:53 |
| sean-k-mooney | cdent: your perference would be to handel this client side not server(placemnt) side thouhg in general | 10:54 |
| cdent | yeah, that co-ownership issue was a point I raised in dublin and at that time it seemed to be the consensus that "don't do that" was the way to go. which seems rather limited to me. Which is why I think the operator should be able to configure the virt-driver to limit/define which traits it owns | 10:54 |
| cdent | yes, in general, that's my thought about most things to do with placement. changing the server, at this stage, should be the choice of last resort. We already have a very complicated but failrly complete set of generic concepts and resources. | 10:55 |
| cdent | a while back jaypipes had a proposal for a way for a virtdriver to configure itself with regard to providers and inventory. a yaml file. that yaml file could say "I care about these traits" or something like that | 10:55 |
| sean-k-mooney | ya a nova config option would be a vaild way to do this but i would prefer that option to be enforced above the virt dirver either in the compute manager or cloud wide | 10:56 |
| cdent | well presumably if you are in a hetereogenous environment, different racks (and potentialy different hypervisors) will have different requirements | 10:56 |
| cdent | having the compute declare itself seems most flexible to me | 10:57 |
| cdent | (even if that means inheriting from some kind of global choice) | 10:57 |
| sean-k-mooney | cdent: yes that is true hence why i initiall said compute manager | 10:58 |
| cdent | this is probably a topic we'll want to revisit at the ptg, you wanna put something on the etherpad (if it isn't already there) | 10:59 |
| sean-k-mooney | if we were talking about neutron i could see this being cloud wide at the ml2 driver level but, nova may be more hetorgnious in its compute node config | 10:59 |
| cdent | we (openstack at large) seem to have an ongoing conflict in design-sense between individual pieces being able to declare themselves and some global thing doing imperative control | 11:00 |
| sean-k-mooney | cdent: well its coming up in https://etherpad.openstack.org/p/device-placement-passthrough-2 as part of a proposal to move pci devices into placement with a yaml based invetory. so i would expect this to be disccused in the ptg in that context in anycase but perhaps this should be a topic by itself | 11:00 |
| cdent | makes for imepedence mismatches | 11:00 |
| cdent | is there a link to that etherpad on the ptg etherpad? and making reference to this conversation might be useful for context | 11:01 |
| sean-k-mooney | proably not currently. | 11:02 |
| *** cdent_ has joined #openstack-placement | 11:07 | |
| *** cdent has quit IRC | 11:07 | |
| *** cdent_ is now known as cdent | 11:07 | |
| *** cdent has quit IRC | 11:51 | |
| jaypipes | sean-k-mooney: https://review.openstack.org/#/c/550244/ | 11:58 |
| sean-k-mooney | jaypipes: this is the yaml file proposal? | 12:04 |
| jaypipes | sean-k-mooney: yes | 12:04 |
| sean-k-mooney | jaypipes: have you seen https://review.openstack.org/#/c/591037/ | 12:05 |
| sean-k-mooney | jaypipes: just quickly looking at your abanodned spec and my prototype propsal here https://etherpad.openstack.org/p/generic-device-schema they seam kindof similar | 12:07 |
| sean-k-mooney | although different in several ways alos | 12:08 |
| sean-k-mooney | your propsal actully has the inventoies declared in the file | 12:08 |
| sean-k-mooney | mine was assuming i was jsut declaring what devices the virt driver can invetory an then grouping them | 12:09 |
| jaypipes | sean-k-mooney: that's been in my list of things to get to... haven't gotten to it yet unfortunately. :( | 12:09 |
| sean-k-mooney | no worries. you dont have to do everything | 12:10 |
| sean-k-mooney | there are several different proposals for things in this area that we will liekly want to discuss in more detail at the PTG | 12:11 |
| jaypipes | sean-k-mooney: I hate the vendor_id/device_id device pools functionality currently in the pci management module. | 12:11 |
| sean-k-mooney | jaypipes: well i was thinking of replacing that entire moduel so good to know | 12:11 |
| jaypipes | sean-k-mooney: I'm leaving on PTO until wednesday starting in about 30 minutes so won't really be able to comment | 12:12 |
| sean-k-mooney | jaypipes: vendor_id/device_id is something we need to care about but would proably use resouce classes to handel that | 12:12 |
| sean-k-mooney | vendor_id/device_id is not something placement should have to care about however | 12:12 |
| sean-k-mooney | jaypipes: also enjoy. PTO is important even though i never take it | 12:14 |
| sean-k-mooney | my plans to take august off kindo of got changed when i changed jobs | 12:14 |
| jaypipes | :) | 12:15 |
| jaypipes | alright, ciao folks... | 12:16 |
| *** jaypipes has quit IRC | 12:16 | |
| *** efried has quit IRC | 12:28 | |
| *** efried has joined #openstack-placement | 12:29 | |
| openstackgerrit | Jose Castro Leon proposed openstack/nova master: Fix get_device_path from network mounted volume https://review.openstack.org/590188 | 12:48 |
| *** edleafe has joined #openstack-placement | 12:57 | |
| *** cdent has joined #openstack-placement | 13:09 | |
| cdent | edleafe: dtroyer reminded me of the location of https://github.com/openstack/oslo.tools/blob/master/filter_git_history.sh and it looks like it could be useful, given it is fed with the right list of files | 13:12 |
| *** efried is now known as fried_rice | 13:12 | |
| edleafe | cdent: thanks, will look into it | 13:12 |
| fried_rice | cdent, sean-k-mooney: Is the suggestion that the config file would somehow contain the comprehensive list of traits that the driver owns? | 13:25 |
| cdent | fried_rice: I hadn't really got that far in my thinking. It could either be that, or the other way round: the traits it chooses to not own | 13:26 |
| cdent | but yes, something, somewhere, needs to be an explicit statement of ownership | 13:26 |
| fried_rice | cdent: But there's an infinite number of traits. | 13:27 |
| fried_rice | And I have to be able to recognize a trait I "own" even if it's *not set*. | 13:27 |
| cdent | thus the list of "I own" is the better choice | 13:28 |
| cdent | in fact it is probalby necessary to have both | 13:28 |
| cdent | I., the driver, own these | 13:28 |
| cdent | I, the op, have chosen to make the driver not own these (even though it normally would) | 13:28 |
| openstackgerrit | Matthew Edmonds proposed openstack/nova master: comment correction for libvirt multiattach https://review.openstack.org/593050 | 13:29 |
| fried_rice | cdent: My point is that the driver may generate traits, and the possible pool of these can be infinite. So I can't have an inclusive/exhaustive list. I have to use some kind of pattern aka namespace. | 13:31 |
| cdent | well that sounds pretty broken then | 13:32 |
| cdent | why have infinite traits? | 13:32 |
| cdent | also, presumably anything that is generating traits is creating CUSTOM_ ones and thus it _must_ be the owner of them | 13:33 |
| cdent | if other things are going to _manipulate_ (rather than just be aware of) that trait, it shouldn't be custom | 13:33 |
| cdent | but if some complex system wanted to share a bunch of custom traits that they all manipulate, I contend that that sharing of knowledge is not placement's job | 13:34 |
| fried_rice | cdent: I'm talking about thinks like CUSTOM_VENDOR_ID_XXXX | 13:34 |
| cdent | that's the conplex system's job | 13:34 |
| fried_rice | s/k/g/ | 13:34 |
| fried_rice | or even CUSTOM_PCI_ADDRESS_DD_BB_DD_FF | 13:34 |
| cdent | why would more than one thing need to set or delete that (instead of just read it)? | 13:35 |
| fried_rice | or CUSTOM_NETWORK_FOO | 13:35 |
| fried_rice | cdent: It wouldn't, and shouldn't, which is exactly the point. | 13:35 |
| cdent | then if nothing does, then you're okay, right? you know who owns that | 13:36 |
| cdent | you declare that, somehow | 13:36 |
| fried_rice | no, that's the use case that's hard. | 13:36 |
| fried_rice | Taking the vendor ID example: the driver is set up to generate a VENDOR_ID_XXXX trait. If it loads up the provider and sees a VENDOR_ID_YYYY trait on it, it needs to know to remove that trait, because it's wrong. | 13:38 |
| cdent | I think I'm either missing some critical detail, or I have an expectation of the client doing more work than you have | 13:38 |
| fried_rice | If my CPU has AVX but not AVX2, somebody needs to notice when the AVX2 trait is set, and remove it. Because we don't want the operator setting the trait and thereby pretending the CPU can do something it can't. | 13:39 |
| cdent | in that case the driver needs to know "I am do XXXX not YYYY" | 13:39 |
| fried_rice | Meaning YYYY needs to be on a list | 13:39 |
| fried_rice | of things I "own", a subset of which I can detect should be set, and the remainder of which I can authoritatively unset. | 13:40 |
| fried_rice | Which is fine for CPU traits; that's a constrained list. | 13:40 |
| cdent | and in that second case, the virt driver knows "my hardware is onkyl AVX2 and these provider somehow are wrong. I am a virt driver, I'm authoritative about HW_CPU_X86" | 13:40 |
| fried_rice | Yes, fine for CPU traits; that's a constrained list. | 13:40 |
| fried_rice | But it is not fine for e.g. vendor IDs because there's a theoretically infinite number of them (okay, 2^32). | 13:41 |
| fried_rice | Or capabilities. Some new card with a new capability is published. It sure would be nice to be able to support that card and that capability without having to merge a patch to extend that list of owned traits. | 13:41 |
| cdent | fried_rice: and how do you want that to happen?> | 13:42 |
| fried_rice | the only solution I had come up with thus far was namespacing. | 13:42 |
| fried_rice | CUSTOM__THE_VIRT_DRIVER_OWNS_THIS_TRAIT_DONT_F_WITH_IT__CAPABILITY_YYYY | 13:43 |
| cdent | would CUSTOK_VENDOR_ID_NS_YYYY get similar results in a more narrow way? | 13:44 |
| openstackgerrit | Matthew Edmonds proposed openstack/nova master: Doc: PowerVM does support shelve https://review.openstack.org/593052 | 13:44 |
| fried_rice | cdent: Not sure what distinction you're making, explain please? | 13:44 |
| cdent | fried_rice: i'm putting the namespace towards the more specific end of the trait hierarchy, sort of assuming that virt drivers wil want to wild card traits that they "own" | 13:46 |
| cdent | (prefix-based wildcard) | 13:46 |
| edleafe | I always thought that things like VENDOR_ID_XXXX is not a trait. It's not a capability | 13:48 |
| fried_rice | I'm not stuck on a particular pattern necessarily, I've just been discussing the concept in general, which folks seem to object to initially. | 13:48 |
| fried_rice | edleafe: Yes, I agree. But taking that discussion to its logical conclusion (which has happened several times) leads to statements like, "And it's the responsibility of the device vendor to define the comprehensive list of capabilities in a place where we can get at it." | 13:49 |
| fried_rice | Which is a pipe(s) dream. | 13:49 |
| edleafe | fried_rice: my point is that if they create traits that aren't traits, it's not placement's job to clean up that mess | 13:50 |
| fried_rice | So traiting product/vendor IDs is a simple way to achieve the same result; it requires the operator to understand what capabilities correspond to what vendors. | 13:50 |
| fried_rice | edleafe: If we want to put that stake in the ground, I can get behind it. | 13:51 |
| cdent | from one standpoint, placement doesn't care if someone choose to namespace. but I suspect nova does. | 13:51 |
| edleafe | I was under the impression that that stake has been there since the beginning | 13:51 |
| cdent | yes | 13:51 |
| edleafe | cdent: if nova wants to namespace, then that is up to nova to manage that | 13:52 |
| cdent | right | 13:52 |
| edleafe | same with any other service that uses placement | 13:52 |
| fried_rice | uh, the beginning of what? It was Thursday in Dublin before we even brought up the concept of traits being mergeable. | 13:52 |
| cdent | but I'm guessing that the parts of nova not currently in this conversation would not be best pleased | 13:52 |
| edleafe | That's why extraction is important: to stop having placement doing nova stuff | 13:52 |
| edleafe | fried_rice: since the concept of traits has been defined | 13:53 |
| openstackgerrit | Chen proposed openstack/nova master: Fix evacuate logging https://review.openstack.org/593055 | 13:53 |
| edleafe | They have been capabilities. Not state. Not metadata | 13:53 |
| fried_rice | This really has nothing to do with placement doing nova stuff. We're talking about nova (and others) using placement-isms. | 13:53 |
| edleafe | fried_rice: more like nova and others misunderstanding placement-isms | 13:54 |
| cdent | fried_rice: right, and I'm trying (but failing because I've never been very good at it) to represent some of the concerns I've heard various nova folk mention | 13:54 |
| fried_rice | edleafe: Semantics. Is CUSTOM_PHYSNET_A a capability? No, it's metadata. But we're sure going to use that. | 13:54 |
| fried_rice | "capable of communicating on physnet A" <== semantics. | 13:55 |
| cdent | it's definitely the case that various nova and neutron things (and blazar) are talking about using traits as both metadata and state | 13:55 |
| cdent | and that's fine | 13:55 |
| fried_rice | "capable of doing things that a device with product ID XXXX can do" <== ditto. | 13:55 |
| edleafe | fried_rice: disagree. I see it as a shorthand for CUSTOM_CAN_COMMUNICATE_ON_PHYSNET_A | 13:55 |
| edleafe | jinxish | 13:55 |
| cdent | but _they_ are responsible for managing that mess, not placement. earlier sean-k-mooney made a proposal that placement do so, which I hope made clear I didn't think was a good idea | 13:55 |
| fried_rice | you mean like adding an "owner" metadata field on a trait? Yeah, ixnay at-they. | 13:56 |
| edleafe | exactly. If you want to adopt a shorthand, then you have to be responsible for managing how that is used | 13:56 |
| fried_rice | Yeah, none of that is at issue (at least in my mind). We're not talking about asking placement to change anything about what it's doing or how it's doing it. We're talking about how nova (and others) will need to (ab)use the existing API to make traiting work sanely for operators. | 13:57 |
| *** dansmith is now known as steelydan | 13:58 | |
| *** steelydan is now known as SteelyDan | 13:58 | |
| edleafe | fried_rice: ah, then that seems like it should be discussed in -nova, no? | 13:58 |
| fried_rice | that was happening too. | 13:59 |
| *** cdent has quit IRC | 14:05 | |
| *** giblet is now known as gibi_off | 14:11 | |
| *** cdent has joined #openstack-placement | 15:05 | |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP Add regression for bug 1787606 https://review.openstack.org/593073 | 15:14 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP scheduler: Only skip the selected host when finding alternates https://review.openstack.org/593074 | 15:14 |
| openstack | bug 1787606 in OpenStack Compute (nova) "Multi instance creation rescheduling fails due to a lack of alternates" [Undecided,New] https://launchpad.net/bugs/1787606 | 15:14 |
| cdent | edleafe: that ^ may be of interest to you | 15:15 |
| openstackgerrit | melanie witt proposed openstack/nova stable/rocky: add zvm into support matrix https://review.openstack.org/593079 | 15:28 |
| openstackgerrit | melanie witt proposed openstack/nova stable/rocky: Add zvm admin intro and hypervisor information https://review.openstack.org/593080 | 15:28 |
| openstackgerrit | melanie witt proposed openstack/nova stable/rocky: Add zvm CI information https://review.openstack.org/593081 | 15:28 |
| *** e0ne has quit IRC | 15:59 | |
| cdent | fried_rice: it will take a while to get a reasonable base line on some of those perf things, because as gibi_off rightly helped point out somewhere in the discussion, the difference between providers and general node health is very relevant | 16:05 |
| fried_rice | ack | 16:06 |
| cdent | and you're right: going from 750 (or likely many more) rps with aggregates to all them would presumably make no difference | 16:08 |
| cdent | fried_rice: what's your read on the status of reshaper? Is it basically a question of reviews at this point or is there more to it? | 16:20 |
| fried_rice | cdent: Jay has -1s on several patches, so I'll need to respin to address those. | 16:22 |
| fried_rice | I think I'm taking the afternoon off to rewire my home internet and build a goat milking stand, so it'll likely be next week before I get to it. | 16:23 |
| cdent | does the goat go in the stand | 16:23 |
| fried_rice | on/in | 16:25 |
| fried_rice | I think I'm going to do a dry run with the lumber I have lying around, then decide whether to go PVC after that. | 16:27 |
| *** fried_rice is now known as efried_pto | 16:29 | |
| cdent | I clearly need to adjust my priorities | 16:33 |
| *** tssurya has quit IRC | 16:38 | |
| *** e0ne has joined #openstack-placement | 17:56 | |
| openstackgerrit | Dan Smith proposed openstack/nova master: Batch results per cell when doing cross-cell listing https://review.openstack.org/592698 | 18:32 |
| openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Make instance_list perform per-cell batching https://review.openstack.org/593131 | 18:32 |
| openstackgerrit | Dan Smith proposed openstack/nova master: Batch results per cell when doing cross-cell listing https://review.openstack.org/592698 | 19:06 |
| openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Make instance_list perform per-cell batching https://review.openstack.org/593131 | 19:06 |
| *** cdent has quit IRC | 19:13 | |
| *** nicolasbock has quit IRC | 19:50 | |
| *** nicolasbock has joined #openstack-placement | 19:55 | |
| openstackgerrit | Joshua Harlow proposed openstack/nova master: Add exact match aggregate image properties matcher/filter https://review.openstack.org/593167 | 20:17 |
| openstackgerrit | Joshua Harlow proposed openstack/nova master: Add exact match aggregate image properties matcher/filter https://review.openstack.org/593167 | 20:18 |
| openstackgerrit | Joshua Harlow proposed openstack/nova master: Add exact match aggregate image properties matcher/filter https://review.openstack.org/593167 | 20:18 |
| openstackgerrit | Joshua Harlow proposed openstack/nova master: Add exact match aggregate image properties matcher/filter https://review.openstack.org/593167 | 20:27 |
| *** e0ne has quit IRC | 20:35 | |
| openstackgerrit | Joshua Harlow proposed openstack/nova master: Add exact match aggregate image properties matcher/filter https://review.openstack.org/593167 | 20:57 |
| openstackgerrit | Dmitry Sutyagin proposed openstack/nova-specs master: Allow disabling KSM / mem-merge via extra spec https://review.openstack.org/593197 | 21:25 |
| *** nicolasbock has quit IRC | 21:59 | |
| openstackgerrit | Merged openstack/nova master: comment correction for libvirt multiattach https://review.openstack.org/593050 | 23:59 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!