| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-09-28 | |||
| 22:24:37 | efried | cdent I think saying "can be satisfied by a parent" implies more than what's happening. | |
| 22:24:44 | cdent | jaypipes, efried : it’s the belonging thing that’s really botherin gme | |
| 22:25:07 | cdent | but again, I’m not sure it is relevant in the immediate sense | |
| 22:25:11 | cdent | (of the spec) | |
| 22:25:19 | efried | okay, so back to that. | |
| 22:26:28 | mikal | mriedem: does "Michael runs with this" mean you'd like me to propose the session? | |
| 22:27:10 | efried | I assume the target audience of this spec is 1) developers who will be a) implementing the /allocation_candidates API changes, and b) coding the modeling and registration of the RPs that it'll talk to; as well as 2) (eventually, as it gets "propagated" into docs) the operator who's gonna populate the flavor with the resource classes and traits. | |
| 22:27:18 | cdent | efried: If you want we can probably just revisit this later, as I’m +1. I’m conscious however that we will stumble on this stuff again later when trying to document stuff and consider implications. | |
| 22:29:41 | efried | 1a definitely needs to understand it for NRP to construct the query right. 1b needs to understand it for NRP to model the RPs right. And 2 needs to understand it because he's gonna look at the RPs as real things with meaningful traits and know that he can ask for HW_CPU_X86_SSE2. | |
| 22:30:40 | efried | cdent Okay, sure. I don't necessarily disagree that the propagation discussion could have happened in a different spec as well (like maybe the NRP spec). But I still can't see how it's misplaced here. | |
| 22:32:36 | efried | cdent Slightly less controversial (hopefully) response to your other comment inline :) | |
| 22:32:44 | cdent | I don’t think it is misplaced, if it were clear, but it isn’t it, and clarifying it it is too hard especially when not in the context of the nrp spec/code, so as it is stands is distracting | |
| 22:33:49 | mriedem | mikal: yes | |
| 22:34:52 | efried | cdent Gotcha. | |
| 22:38:47 | cdent | efried: yeah, I didn’t mention the resource3,required3 thing there because of wanting to keep the immediate scope narrow, but yes, both of those could also do the repeat treatment if we wanted. not necessary or anything | |
| 22:39:24 | efried | cdent But don't we already have an API that does resources= with commas? | |
| 22:39:43 | cdent | yes, but that doesn’t prevent also allowing repeats | |
| 22:39:52 | cdent | that’s what I was saying, we can do both if we like | |
| 22:39:58 | efried | Mm. | |
| 22:40:03 | efried | That's a big test matrix | |
| 22:40:25 | cdent | sure, but repeats is _normal_ for web-based query parameters, and we might like that | |
| 22:40:32 | efried | I mean, I dig the idea of using the repeats. But seems like that's something that should have been done from the start. | |
| 22:40:38 | cdent | oh sure | |
| 22:40:44 | efried | Yeah, normal for web-based query params ++ | |
| 22:40:45 | cdent | so should many things :) | |
| 22:41:14 | efried | But given that we did the comma thing, IMO the lesser evil is consistency and KISS. | |
| 22:42:44 | cdent | On 2) above, I’m less worried about people creating flavors than I am about inventory creating tooling getting the traits on the righ resource. Because in a flavor when you express a trait or quantity of resource, initially, it’s just that you require it, not the structure thereof | |
| 22:43:06 | cdent | the comma thing will remain the primary thing I expect | |
| 22:43:19 | mikal | mriedem: ok, I will do that thing | |
| 22:43:30 | cdent | and we may never do the repeat thing, unless the framework already supports it (which it may, which is why I mentioned it) | |
| 22:43:51 | mriedem | mikal: thanks | |
| 22:45:01 | cdent | is extra_specs a dict, or is it a string that looks vaguely like a dict? | |
| 22:48:23 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Use ksa adapter for cinder client (OPTION 1) https://review.openstack.org/508345 | |
| 22:53:05 | mriedem | johnthetubaguy: if you're going to be at the forum: http://forumtopics.openstack.org/cfp/details/12 | |
| 23:00:41 | mriedem | i've seen at least 3 forum topics on here about ETSI/NFV | |
| 23:00:45 | mriedem | all sound like duplicates | |
| 23:00:54 | mikal | You're welcome? | |
| 23:01:51 | mriedem | "HOT topic: Heat-ing up Telco VNFs in the ETSI way" | |
| 23:01:57 | mriedem | this guy knows how to get a talk accepted | |
| 23:02:36 | mikal | As a man who recently learned those acronymns, isn't that just a session on how to use heat to start instances? | |
| 23:05:01 | mriedem | ha | |
| 23:05:04 | mriedem | maybe? | |
| 23:05:10 | mriedem | but in the etsi way | |
| 23:06:37 | cdent | MANO your VIM with TOSCA | |
| 23:07:15 | jaypipes | dansmith: so after 4 hours fucking around with this, I remember why I made it parent_provider_uuid and root_provider_uuid instead of using internal integer fields. | |
| 23:07:28 | dansmith | jaypipes: lay it on e | |
| 23:07:49 | mikal | cdent: OMG, that sentence even parsed | |
| 23:07:57 | mikal | Why do these people love stupid acronyms so much? | |
| 23:08:27 | cdent | Don’t acronyms mean importance? I’m sure I read a white paper on that. | |
| 23:08:27 | jaypipes | dansmith: having to deal with all the friggin relationship stuff in the ORM results in a boatload of code and errors everywhere about lazy-loading and Sessions being inactive.. | |
| 23:09:23 | dansmith | jaypipes: that makes no sense to me | |
| 23:09:46 | dansmith | um, so do it? | |
| 23:10:12 | jaypipes | dansmith: the resource_provider.py module is a mess of mixed up ORM and non-ORM code. drives me nuts. | |
| 23:11:52 | dansmith | mriedem: smackin' the patch now | |
| 23:23:43 | dansmith | mriedem: I got bad news about your sysmeta patch | |
| 23:27:53 | cdent | Goodnight you princes of Maine, you kings of New England. | |
| 23:28:08 | dansmith | mriedem: it _only_ makes our API about 16% faster on average: https://imgur.com/a/ovFq2 | |
| 23:28:21 | mriedem | is that bad news? | |
| 23:28:36 | dansmith | terrible | |
| 23:28:42 | mriedem | do i, | |
| 23:28:45 | mriedem | or do i not, | |
| 23:28:48 | mriedem | need a special comb | |
| 23:30:32 | mriedem | crabs | |
| 23:30:34 | mriedem | it's a crabs joke | |
| 23:30:40 | mriedem | you know, bad news | |
| 23:30:42 | mriedem | you've got crabs | |
| 23:30:44 | dansmith | hah, okay | |
| 23:32:25 | gmann | mriedem: yea, tags(all type of query like tag_any, not_tag etc) are in query itself | |
| 23:32:51 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove system_metadata loading in Instance._load_flavor https://review.openstack.org/508357 | |
| 23:33:04 | gmann | mriedem: api extension policy removal spec is ready - https://review.openstack.org/#/c/508101/2 | |
| 23:33:32 | gmann | i listed 11 policies to remove | |
| 23:35:50 | mriedem | gmann: ok, i'm not going to be able to get to that tonight | |
| 23:36:01 | mriedem | we're going to do a spec review sprint early next week | |
| 23:36:17 | gmann | mriedem: sure, btw when is spec freeze date ? | |
| 23:36:38 | mriedem | oct 19 | |
| 23:37:57 | gmann | ok. thanks. | |
| 23:38:57 | dansmith | your patch will conflict with my cutover patch, btw | |
| 23:40:23 | mriedem | dansmith: i know, i'll wip | |
| 23:40:45 | dansmith | mriedem: don't have to, just pointing it out | |
| 23:41:19 | mriedem | was just about to go through 505418 and underneath it | |
| 23:41:34 | mriedem | laura is going to have my hide if she comes home at 7 and i don't have dinner started | |
| 23:42:03 | dansmith | I didn't change the cutover one, just put a patch underneath to save the tests | |
| 23:42:25 | dansmith | was going to do your refactoring in the top patch but I haven't yet | |
| 23:45:40 | mriedem | yeah noticed | |
| 23:45:43 | mriedem | the comment i mean | |
| 23:45:46 | openstackgerrit | Steve Noyes proposed openstack/nova master: update live migration to use v3 cinder api https://review.openstack.org/463987 | |
| 23:47:04 | dansmith | mriedem: so, I was wondering if maybe doing the cells in parallel would hide this benefit some and it does: https://imgur.com/a/YMxPQ | |
| 23:47:38 | dansmith | that doesn't mean the gain isn't there, it means there's two gains and we're bumping up against just cpu performance processing the results from the DB I think | |
| 23:47:41 | dansmith | which is good | |
| 23:47:41 | mriedem | the sysmeta benefit? | |
| 23:47:43 | dansmith | yeah | |
| 23:47:48 | mriedem | ah | |
| 23:47:56 | dansmith | that's the instance_list patch plus the sysmeta one vs. master | |
| 23:48:08 | mriedem | cool | |
| 23:49:39 | dansmith | I wish we could spawn a real thread instead of a greenthread to do the cells scatter | |
| 23:50:37 | mriedem | https://review.openstack.org/#/c/505418/12 | |
| 23:50:41 | dansmith | because we're just pegging one core when we're doing all this | |
| 23:50:55 | mriedem | you know who likes to talk threading? | |
| 23:50:58 | mriedem | that works on your team | |
| 23:51:14 | mriedem | me too | |