| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-29 | |||
| 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 | |
| 20:15:23 | bauzas | clear | |
| 20:15:30 | bauzas | I'm not talking at all about Nova providing that | |
| 20:15:47 | bauzas | and I'm -2 on that idea too if you prefer | |
| 20:15:47 | jaypipes | bauzas: the inability of another tenant using that "slot" of resources makes the reservation exactly equal in cost to the use of something. | |
| 20:16:42 | openstackgerrit | Anusha Unnam proposed openstack/nova master: Add description to policies in servers_migrations.py https://review.openstack.org/451487 | |
| 20:16:56 | bauzas | jaypipes: I'm trying to explain that without a whiteboard, hold on | |
| 20:17:26 | bauzas | jaypipes: there are situations where, as a tenant, I want to make sure I will have the capacity in 2 hours | |
| 20:17:37 | bauzas | for a certain duration | |
| 20:17:43 | bauzas | unrelated to my quotas | |
| 20:18:40 | bauzas | jaypipes: the fact that another tenant could use all the resources *before* or *after* my period doesn't really hurt me | |
| 20:19:18 | mriedem | jaypipes: thanks for looking at https://review.openstack.org/#/c/441692/ again | |
| 20:20:07 | bauzas | jaypipes: what people want is some way to say "I'm gonna lock some resources not for now, but when my period will start" | |
| 20:20:40 | bauzas | dansmith: rebuild doesn't guarantee you it will success by the time you do it | |
| 20:20:54 | dansmith | bauzas: eh? | |
| 20:20:57 | mriedem | neither does reserving and saying you're going to create a server in 2 hours | |
| 20:21:12 | mriedem | if ceph crashes | |
| 20:21:20 | bauzas | dansmith: you're asking the scheduler for rebuild | |
| 20:21:56 | mriedem | maybe this is the thing where people have asked in the past for a way to create a server in stopped state immediately | |
| 20:22:01 | mriedem | as a workaround for a lack of reservations | |
| 20:22:05 | bauzas | mriedem: agreed, all of that supposes a fully functional cloud | |
| 20:22:23 | bauzas | mriedem: yup, shelved instances was the hack | |
| 20:22:35 | bauzas | shelved *offloaded* | |
| 20:22:41 | mriedem | rather than just create and then stop in separate calls | |
| 20:22:58 | bauzas | but by the time the instance unshelves, you have no guarantee that it will succeed | |
| 20:23:15 | dansmith | bauzas: rebuild doesn't ask anything of the scheduler right? | |
| 20:23:32 | bauzas | dansmith: lemme verify, my guts say the contrary | |
| 20:23:51 | dansmith | only for evacuate, IIRC | |
| 20:24:25 | mriedem | the scheduler has to take into account image properties in the new image | |
| 20:24:26 | mriedem | for rebuild | |
| 20:24:50 | mriedem | i think we actually have a bug for that, | |
| 20:24:54 | mriedem | because we don't do that today | |
| 20:25:08 | dansmith | bauzas: host=instance.hosdt | |
| 20:25:34 | mriedem | that's the bug | |
| 20:25:49 | mriedem | the new image could have properties that don't fit the instance's existing host | |
| 20:25:57 | bauzas | dansmith: yeah you're right, just verified | |
| 20:26:06 | bauzas | dansmith: and I think it's a miss | |
| 20:26:06 | dansmith | mriedem: right, but rebuild is supposed to be in place | |
| 20:26:23 | openstack | Launchpad bug 1667667 in OpenStack Compute (nova) "Rebuilding instance ignores image's property hw_disk_bus" [Low,Confirmed] | |
| 20:26:23 | mriedem | https://bugs.launchpad.net/nova/+bug/1667667 | |
| 20:26:25 | bauzas | mriedem: resize != rebuild | |
| 20:26:31 | mriedem | bauzas: i know | |
| 20:26:46 | bauzas | mriedem: yeah I know you know, but it's not taking a new flavor, right? | |
| 20:26:55 | bauzas | oh, the image props | |
| 20:26:59 | dansmith | image | |