| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-29 | |||
| 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 | |
| 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 | |