| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-29 | |||
| 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 | |
| 18:38:50 | edleafe | they solve all your problems | |
| 18:39:30 | mriedem | that makes sense, i have a legacy enterprise backyard | |
| 18:39:46 | jaypipes | lmao | |
| 18:43:13 | openstackgerrit | Sujitha proposed openstack/nova master: Change tags to default field in Instance object. https://review.openstack.org/415298 | |
| 19:01:07 | openstackgerrit | dane-fichter proposed openstack/nova master: Use cursive for signature verification https://review.openstack.org/351232 | |
| 19:25:16 | oomichi | edleafe: thanks for your feedback on https://review.openstack.org/#/c/376200 I also feel tags guidelline is wrong. The tags guideline patch was huge and we just missed the point I think | |
| 19:25:52 | bauzas | mriedem: thanks for leaving comments on the claims | |
| 19:26:03 | bauzas | mriedem: I'll review those soon | |
| 19:26:07 | mriedem | bauzas: np, cool | |
| 19:26:27 | mriedem | bauzas: i'd like to go into the forum with a good idea of the plan for pike | |
| 19:26:33 | bauzas | agreed | |
| 19:26:52 | edleafe | oomichi: just proposed a fix: https://review.openstack.org/451536 | |
| 19:26:52 | mriedem | i think the goal is get as much prep work done in pike, and then cutover early in queens and drop the caching scheduler | |
| 19:27:15 | bauzas | mriedem: yup, hence why I provided this spec | |
| 19:27:41 | bauzas | mriedem: I prefered to leave us discussing about the possibilites before I could implement that by Queens | |
| 19:27:59 | bauzas | mriedem: also, unrelated, I saw https://review.openstack.org/#/c/389216/ | |
| 19:28:16 | bauzas | mriedem: I do wonder if we should be discussing about reservations with the Blazar team | |
| 19:28:50 | bauzas | for the moment, Blazar is using aggregates for reserving computes, but I'd prefer they could discuss with us about using the placement API too | |
| 19:29:11 | bauzas | mriedem: FWIW, I was a Blazar core 3 years ago | |
| 19:31:59 | mriedem | isn't blazar dead? | |
| 19:32:59 | bauzas | mriedem: not really | |
| 19:33:08 | bauzas | mriedem: it resurrected 6 months ago | |
| 19:33:21 | bauzas | mriedem: because of something having 3 letters :p | |
| 19:33:45 | bauzas | Nouvelle Formule Verifiée | |
| 19:33:56 | jaypipes | Neverending Feature Velocity. | |
| 19:34:31 | jaypipes | mriedem: Blazar is now in OPNFV. | |
| 19:34:59 | bauzas | not really, but yeah | |
| 19:35:24 | bauzas | OPNFV folks looked at some reservation possibilities, and they saw Blazar | |
| 19:36:12 | bauzas | honestly, I'm good with the APIs, but I think we could be somehow use placement for their backends | |
| 19:36:35 | bauzas | it's about saying "I want this compute in 3 hours for 2 mins" | |
| 19:38:03 | bauzas | jaypipes: do you agree with me possibly asking Blazar and those folks https://review.openstack.org/#/c/389216/ discussing about how to create reservations using placement as a backend for Blazar? | |
| 19:38:31 | bauzas | jaypipes: tbc, I don't think placement should think about leases or other time stuff | |
| 19:38:52 | bauzas | jaypipes: I just think they could be creating allocations using specific RPs | |
| 19:39:02 | mriedem | rub some placement on it | |
| 19:39:04 | mriedem | problem solved | |
| 19:39:27 | jaypipes | bauzas: placement wouldn't even be involved until the claim was actually made, though... | |
| 19:39:36 | bauzas | jaypipes: I know | |
| 19:39:50 | bauzas | the discussion wouldn't be for something Pike and I doubt Queens | |
| 19:40:15 | bauzas | but having folks around discussing about reservations would also help folks like https://review.openstack.org/#/c/389216/ | |
| 19:40:33 | bauzas | because lots of operators use server groups for that | |
| 19:40:51 | bauzas | and we know how the server group API can be difficult to be used :) | |
| 19:41:12 | jaypipes | bauzas: I need to read that spec. sorry, haven't had a chance yet :( | |
| 19:41:35 | bauzas | jaypipes: tl,dr: it's about saying "I want to reserve this space into the servergroup" | |
| 19:43:02 | jaypipes | bauzas: how does AWS/EC2 approach a use case like that? Can I tell EC2 "hey, can you please just reserve a rack of machines for me to be guaranteed access and use of some time in the future and don't charge me for anything. kthxbai" | |
| 19:44:22 | bauzas | jaypipes: well, AWS doesn't propose that, they rather propose an invoice API called 'spot-instances' and 'reserved computes' :p | |
| 19:44:46 | bauzas | I'm betting that invoice API translates into something real about capacity management tho | |
| 19:45:43 | jaypipes | bauzas: spot instances are totally different. those are instances that can be slotted into "available" resource nodes but terminated if a higher priority workload needs the space. | |
| 19:46:02 | bauzas | jaypipes: correct | |
| 19:46:12 | bauzas | jaypipes: but that's an invoice SLA | |
| 19:46:45 | jaypipes | bauzas: lemme finish the traits reviews and then I'll read that spec. | |
| 19:46:53 | bauzas | jaypipes: heh, no rush at all | |
| 19:47:35 | bauzas | I was just considering the interest of proposing a Forum session about that, that's it | |
| 19:47:55 | bauzas | given the deadline (Apr 2nd) | |
| 19:48:13 | bauzas | either way, it's a priority for my duty work :) | |
| 19:48:24 | bauzas | I just take that as a personal interest in it | |
| 19:48:37 | bauzas | it's *not* a priority, dang. | |
| 20:04:12 | openstackgerrit | Sujitha proposed openstack/nova master: Adding auto_disk_config field to InstancePayload https://review.openstack.org/419185 | |
| 20:04:58 | openstackgerrit | Sujitha proposed openstack/nova master: Reduce calls to load_tags() to 0 https://review.openstack.org/435146 | |
| 20:12:44 | jaypipes | bauzas: -2 on that affinity group spec. see my review... | |
| 20:14:23 | bauzas | jaypipes: well, there are usecases where people want to define a lease, and start paying for that lease when it starts | |
| 20:14:46 | bauzas | here, booting instances in advance is suboptimal for an OPEX PoV | |
| 20:14:57 | dansmith | why? | |
| 20:14:57 | jaypipes | bauzas: see my review. there's no difference between reserving and using a resource in Nova. | |
| 20:15:10 | dansmith | boot it now, rebuild it if you need a different image later | |
| 20:15:12 | bauzas | jaypipes: in Nova, I totally agree | |
| 20:15:20 | bauzas | lemme make it cleat | |