| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-29 | |||
| 16:56:34 | openstackgerrit | Dan Smith proposed openstack/nova master: Teach HostAPI about cells https://review.openstack.org/442162 | |
| 16:56:35 | openstackgerrit | Dan Smith proposed openstack/nova master: Make scheduler target cells to get compute node instance info https://review.openstack.org/439891 | |
| 16:56:36 | openstackgerrit | Dan Smith proposed openstack/nova master: Sort CellMappingList.get_all() for safety https://review.openstack.org/443174 | |
| 16:56:37 | openstackgerrit | Dan Smith proposed openstack/nova master: Add get_by_instance_uuids() to InstanceMappingList https://review.openstack.org/443292 | |
| 16:56:37 | openstackgerrit | Dan Smith proposed openstack/nova master: Clean up ClientRouter debt https://review.openstack.org/444487 | |
| 16:56:38 | openstackgerrit | Dan Smith proposed openstack/nova master: Make server_groups determine deleted-ness from InstanceMappingList https://review.openstack.org/443293 | |
| 16:56:39 | openstackgerrit | Dan Smith proposed openstack/nova master: Remove Mitaka-era service version check https://review.openstack.org/442861 | |
| 16:56:41 | openstackgerrit | Dan Smith proposed openstack/nova master: Add workaround to disable group policy check upcall https://review.openstack.org/442736 | |
| 16:56:42 | mriedem | clarkb: it's not clear to me if we have a way to hook testing packages in our CI? | |
| 16:56:45 | clarkb | mriedem: yes but that bug isn't a problem | |
| 16:56:54 | clarkb | mriedem: we have 3 other libvirt bugs that are actually major issues | |
| 16:57:09 | clarkb | mriedem: and I mentioned it would be simple to modify devstack to use a ppa or just wget and dpkg -i | |
| 16:57:45 | mriedem | ok, and we don't have fixes identified to backport for 1.3.3 in xenial LTS for testing yet | |
| 16:58:03 | jamespage | clarkb: can I get context please on those three bugs | |
| 16:58:14 | jamespage | refs would be ok for now | |
| 16:58:28 | jamespage | guessing one is bug 1643911 | |
| 16:58:28 | openstack | bug 1643911 in OpenStack Compute (nova) "libvirt randomly crashes on xenial nodes with "*** Error in `/usr/sbin/libvirtd': malloc(): memory corruption:"" [Medium,Confirmed] https://launchpad.net/bugs/1643911 | |
| 16:58:28 | mriedem | jamespage: https://bugs.launchpad.net/nova/+bug/1643911/ | |
| 16:58:45 | clarkb | jamespage: its the three elastic recheck links I gave you above | |
| 16:58:49 | clarkb | jamespage: they have links to launchpad | |
| 16:58:54 | jamespage | clarkb: ta | |
| 16:59:18 | mriedem | jamespage: some info in http://lists.openstack.org/pipermail/openstack-dev/2017-March/114648.html too | |
| 16:59:31 | mdbooth | dansmith: https://review.openstack.org/#/c/443292/ https://review.openstack.org/#/c/445139/ :) | |
| 17:01:32 | openstackgerrit | Anusha Unnam proposed openstack/nova master: Add description to policies in servers_migrations.py https://review.openstack.org/451487 | |
| 17:02:39 | mdbooth | Absolutely nothing! To be expected, I guess as it's pretty much boilerplate, but it's funny they're character identical. My test is a bit longer. | |
| 17:03:05 | mriedem | mdbooth: it's not the size of the patch, but the motion on the ocean | |
| 17:03:14 | mriedem | that matters that is | |
| 17:06:15 | mdbooth | mriedem: I've just been back through that refactor, btw. | |
| 17:06:41 | mdbooth | I had also glossed over the poll thing, having previously seen it when johnthetubaguy spotted it :) | |
| 17:37:33 | mriedem | sfinucan: you probably have to take this over https://review.openstack.org/#/c/396289/ | |
| 17:41:53 | openstackgerrit | Gergely Csatari proposed openstack/nova master: api-ref: adminPass is optional in Create Server https://review.openstack.org/451497 | |
| 18:01:38 | mriedem | dumb question: what config option defines if the scheduler is packing or spreading? | |
| 18:02:39 | mriedem | ram_weight_multiplier ? | |
| 18:03:08 | mriedem | dansmith: melwitt: didn't we just talk about something with the default options being weird? | |
| 18:03:16 | melwitt | the subset_size right | |
| 18:03:39 | melwitt | host_subset_size | |
| 18:03:57 | melwitt | if that's 1, it will pack | |
| 18:04:07 | mriedem | or host_subset_size ? | |
| 18:04:08 | mriedem | yeah | |
| 18:04:20 | mriedem | ok and 1 is the default | |
| 18:04:29 | melwitt | right | |
| 18:07:29 | mriedem | were we really thinking about creating a new claims resource in placement for claims in the scheduler? or just re-use allocations? | |
| 18:07:44 | mriedem | creating a new claims resource and ticket system really sounds like the old style quota system to me, with the reservations table | |
| 18:07:49 | mriedem | i would think we want to avoid redoing that | |
| 18:07:50 | mriedem | https://review.openstack.org/#/c/437424/ | |
| 18:07:57 | mriedem | jaypipes: ^ would you agree? | |
| 18:17:16 | edleafe | mriedem: the sticking point is how to keep track of groups of allocations as a unit | |
| 18:17:58 | edleafe | I don't believe that that's necessary | |
| 18:18:25 | edleafe | Just allocating when a host is selected, and de-allocating if the build fails | |
| 18:20:28 | mriedem | hmm yeah i didn't think about the grouping | |
| 18:20:53 | mriedem | couldn't you use the consumer_id field to group them? | |
| 18:21:12 | mriedem | essentially your 'claim ticket' is a uuid generated during the build process in conductor, | |
| 18:21:19 | mriedem | and that's used for the claims | |
| 18:21:40 | mriedem | if you successfully build the instance on the compute host, then update the consumer_id with the instance.uuid in the allocatoins | |
| 18:21:42 | mriedem | *allocatoins | |
| 18:21:43 | edleafe | Consumer_id is one way, yeah | |
| 18:21:57 | mriedem | i love fixing my misspell with the same misspell | |
| 18:22:12 | mriedem | but we'd still need to keep track of the 'claim ticket' uuid somehow | |
| 18:22:12 | edleafe | at least you're consistent :) | |
| 18:22:19 | mriedem | maybe req spec? | |
| 18:22:42 | mriedem | i'd say build request, but that's deleted once we pick a cell | |
| 18:23:15 | mriedem | once we pick a cell, we create the instance in that cell, and that instance has a uuid, so why not just use the instance uuid? | |
| 18:23:19 | edleafe | yeah, there has to be something that is persistent from scheduling through build | |
| 18:23:41 | edleafe | But I don't think a separate table and new resource URLs are the way to go | |
| 18:24:12 | mriedem | so conductor asks scheduler for the list of hosts (or a single host), we get the cell that the host is in, and create the instance in that cell and delete the build request, | |
| 18:24:22 | mriedem | so that's a chicken/egg, | |
| 18:24:23 | mriedem | however, | |
| 18:24:28 | mriedem | the build request uuid is the instance uuid | |
| 18:24:36 | mriedem | so we could pass the build request uuid to the scheduler to make the allocation 'claim' | |
| 18:24:51 | mriedem | and that will be the same uuid we use to update the allocation in the RT in the compute after a successful build | |
| 18:25:02 | mriedem | or to rollback and delete the allocation on NoValidHost if that happens | |
| 18:25:48 | edleafe | mriedem: wait - if we use the instance UUID to make the claim, what's to update if the build succeeds? | |
| 18:26:11 | edleafe | The resources are already allocated to the correct consumer, no? | |
| 18:26:39 | mriedem | good point | |
| 18:26:49 | mriedem | i think i'm mixing the update part from the spec | |
| 18:27:08 | mriedem | but yeah that's even better if we just claim with the instance uuid via allocations in the scheduler | |
| 18:27:21 | edleafe | The only real change is handling rollback when a build fails. | |
| 18:27:36 | mriedem | if all is good, we're done. if something fails and we need to pick another host, drop the allocations on the first RP and make the allocations on the 2nd RP | |
| 18:27:59 | edleafe | but we can use the failed instance UUID to remove those allocations | |
| 18:28:22 | mriedem | right | |
| 18:28:28 | mriedem | there has to be a catch | |
| 18:29:21 | edleafe | I think we might have been stuck in the older, more complicated way of claiming via the RT | |
| 18:29:37 | edleafe | Placement is *supposed* to make things simpler | |
| 18:30:02 | mriedem | outrageous | |
| 18:30:21 | edleafe | Yeah, I know, job security and all | |
| 18:30:35 | mriedem | btw forum session proposed for claims in the scheduler http://forumtopics.openstack.org/cfp/details/63 - jaypipes bauzas johnthetubaguy dansmith | |
| 18:30:36 | edleafe | but since I don't have that at the moment... :) | |
| 18:30:54 | dansmith | cool | |
| 18:31:01 | jaypipes | mriedem: danke | |
| 18:31:41 | jaypipes | mriedem: and no, I am not a fan of creating another resource/ticketing endpoint in the REST API. | |
| 18:32:39 | jaypipes | mriedem: sorry folks for my absence today. we have a plumber replacing the backflow prevention system and it's turned into a $2K disaster needing an electrical upgrade, a leak in the city water meter fixed, and a new water heater. :( | |
| 18:33:05 | edleafe | jaypipes: should be Friday | |
| 18:33:50 | jaypipes | edleafe: yeah :( | |
| 18:34:07 | edleafe | you could really live up to your alt-nick | |
| 18:35:18 | jaypipes | edleafe: indeed. :) | |
| 18:37:59 | mriedem | jaypipes: i'm spending at least $1300 on a new primary sump pump and backup system next week, so i feel you. oh and a bunch of rain washed out some of our landscaping so i'm also going to have to pay for fixing that, plus probably installing a new drain tile system in part of the yard. | |
| 18:38:00 | mriedem | yay! | |
| 18:38:17 | mriedem | gd water | |
| 18:38:19 | jaypipes | mriedem: :( boo. I feel ya. | |
| 18:38:45 | edleafe | you guys need to use containers | |