Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-03
16:31:43 efried The fate of the series starting at https://review.openstack.org/#/c/558044/
16:31:54 efried jaypipes: which is the subject of said ML post.
16:34:50 jaypipes efried: ok, I apologize, I haven't gotten to that yet. need to do the mirroring aggregates spec first.
16:49:37 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Allow to specify granular CPU feature flags https://review.openstack.org/534384
16:50:22 kashyap dansmith: johnthetubaguy: When you get a sec, addresesed what you requested.
17:17:41 openstackgerrit Nguyen Hai proposed openstack/nova-specs master: Enhance nova-specs webpage and clean up repo https://review.openstack.org/551802
17:39:47 openstackgerrit Jay Pipes proposed openstack/nova-specs master: mirror nova host aggregates to placement API https://review.openstack.org/545057
17:39:48 jaypipes dansmith: ^^
17:40:01 jaypipes bauzas: ^^
17:45:37 openstackgerrit Arvind Nadendla proposed openstack/nova master: Update ImageMetaProp object to expose traits https://review.openstack.org/557795
18:06:59 openstackgerrit Eric Fried proposed openstack/nova master: WIP: placement: Granular GET /allocation_candidates https://review.openstack.org/517757
18:31:16 efried jaypipes: I would like to rebase series https://review.openstack.org/#/c/554529/ on master, so I can start hacking granular on top. That okay with you, or do you have local changes?
18:33:32 cdent efried: do I recall correctly that https://review.openstack.org/#/q/topic:bp/placement-api-error-handling was driving some cleanups you were hoping to do? Or was there an even more pressing concern?
18:34:26 efried cdent: The former, I believe. I can't think of anything super urgent.
18:35:10 efried cdent: e.g. https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L633
18:35:18 cdent would be nice to get it through, so it is in there waiting when we want it
18:35:35 cdent actually I can think of a thing where we will want it:
18:35:35 efried foshizzle
18:35:53 cdent we want to know when an allocation fails because of generation versus out of space
18:36:09 cdent (when consumer generations come on the scene)
18:36:35 cdent Basically the same issue as with inventories, but on the flip side
18:37:41 efried As in, "help me decide whether this conflict is because of a generation mismatch or because a resource you're requesting via the allocation is not available"?
18:39:35 cdent_ efried: yes to [t qqJ] (I got disconnectioned)
18:39:35 purplerbot <efried> As in, "help me decide whether this conflict is because of a generation mismatch or because a resource you're requesting via the allocation is not available"? [2018-04-03 18:37:41.872921] [n qqJ]
18:40:13 efried We should have some spec cores give that the ol' +A. Seems pretty straightforward to me. dansmith jaypipes care to have a swag?
18:40:37 efried Maybe they were waiting on edleafe's +1
18:54:01 jaypipes efried: go for it.
18:55:03 efried jaypipes: Staring at it some, I'm not sure I can do it until I see how you're wiring in from AllocationCandidates.get_by_requests
18:55:08 edleafe efried: was on a call. What am I supposed to be +1ing?
18:55:31 efried edleafe: The error codes from placement API spec: https://review.openstack.org/#/c/546177/
18:55:58 efried edleafe: Sorry, the spec is here: https://review.openstack.org/#/c/418393/
18:56:43 efried jaypipes: my bad, I was looking at the code when I asked you to approve the spec, which you did a week ago. Carry on.
18:56:45 edleafe efried: ack. Have another meeting, but will look ASAP
18:57:19 efried edleafe: Looks like you +1ed two patch sets ago, so should be an easy one.
19:04:53 openstackgerrit Jackie Truong proposed openstack/nova master: Implement certificate_utils https://review.openstack.org/479949
19:04:54 openstackgerrit Jackie Truong proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
19:32:17 efried ?
19:34:22 cdent you watch many horror movies efried ?
19:34:46 efried clearly not
19:35:13 efried Is it, like, when you're being watched by the guy with the bad acne and the striped shirt?
19:36:40 cdent a chill fills the room when the monster transforms, perhaps?
19:41:17 efried Hah!
19:56:18 andrewbogott I've just upgrade my nova from liberty to mitaka (that's the release that added the api_db). I've done my nova-manage api_db sync but now any nova api calls return 404
19:56:29 andrewbogott I can see the api handling these calls, it just doesn't know anything.
19:56:45 andrewbogott Has anyone thought about that migration recently enough to have suggestions for what I should be looking for?
19:57:21 andrewbogott (I wonder if e.g. every project is now under some default domain or zone or something that I need to be specifying in my API call)
20:05:41 cdent jaypipes, efried: can we pretty please get forbidden traits merged before https://review.openstack.org/#/c/554529 ?
20:06:11 efried heh
20:06:52 efried cdent: I was actually just working up granular and thinking much the same thing. Would force jaypipes to make nested work for granular, rather than me having to do the reverse :P
20:07:04 cdent 'xactly
20:09:20 cfriesen andrewbogott: see subject line for the channel. that said, did you add the [api_database]/connection information to nova.conf?
20:09:43 andrewbogott cfriesen: Yep! But, I'll try over there.
20:16:28 andrewbogott cfriesen: is there a doc you can link me to that explains what that new database actually does? Is it just a cache?
20:24:26 cdent edleafe, jaypipes: i'm pretty sure the data model in https://review.openstack.org/#/c/557958/ (consumer generation) is wrong. even if I'm wrong about being wrong, then we need to make it clear in the commit why we're doing it weirdly.
20:27:59 cdent are we trying to log generation on the allocation as a sort of historical reference? that won't work because we delete all allocations for a cosumer when they change
20:28:16 cdent efried_schoolrun: you'll also be interested in ^
20:38:56 cfriesen andrewbogott: it's related to the cellsv2 work. the nova DB became per-cell, and the nova-api DB spans the cells and has higher-level stuff
20:39:21 andrewbogott ah, that makes sense, and might be a clue. thanks.
21:16:01 jaypipes cdent: you're absolutely right. no idea why I hadn't seen that. :(
21:16:48 cdent ETOOMUCHNUMA
21:18:17 cdent I think I'll use that as my cue to retire
21:18:19 cdent night all
21:31:45 openstackgerrit Merged openstack/nova master: Fix N332 api_version decorator hacking check https://review.openstack.org/557743
21:33:07 arvindn051 jaypipes: https://review.openstack.org/#/c/557795/ wanted to discuss comments on the review...good time?
21:34:54 jaypipes arvindn051: I need to re-review that one...
21:36:02 arvindn051 k
21:36:48 arvindn051 no rush...i am able to make progress on future patches...but wanted to get feedback on using a list of strings vs dict
21:45:24 openstackgerrit Michael Still proposed openstack/nova master: Move configurable mkfs to privsep. https://review.openstack.org/551921
21:45:24 openstackgerrit Michael Still proposed openstack/nova master: Move xenapi xenstore_read's to privsep. https://review.openstack.org/552241
21:45:25 openstackgerrit Michael Still proposed openstack/nova master: Move xenapi disk resizing to privsep. https://review.openstack.org/552242
21:45:25 openstackgerrit Michael Still proposed openstack/nova master: Sync xenapi and libvirt on what flags to pass e2fsck. https://review.openstack.org/554078
21:45:26 openstackgerrit Michael Still proposed openstack/nova master: Move xenapi partition copies to privsep. https://review.openstack.org/553605
21:45:26 openstackgerrit Michael Still proposed openstack/nova master: Move image conversion to privsep. https://review.openstack.org/554437
21:45:27 openstackgerrit Michael Still proposed openstack/nova master: We don't need utils.trycmd any more. https://review.openstack.org/554439
21:45:27 openstackgerrit Michael Still proposed openstack/nova master: We no longer need rootwrap. https://review.openstack.org/554438
21:58:32 arvindn051 jaypipes: thx for comments....i can revert the prefix
21:59:11 arvindn051 how do you propose we handle preferred traits, numbered traits etc in future?
21:59:26 arvindn051 seperate fields for each of them?
22:01:52 jaypipes arvindn051: well, preferred traits will have a value of "prefer" not "require", right?
22:02:35 arvindn051 but we changed the image meta prop to be a list of strings in the object
22:02:50 arvindn051 so no way to introduce prefer for the value...
22:03:08 jaypipes arvindn051: that's just the outward production of the stuff stored in the image_properties table in glance, though...
22:03:09 arvindn051 i am talking about the ojbect definition...not the image property key value
22:03:33 jaypipes arvindn051: the object definition is entirely temporal... it never saves to a DB.
22:05:25 arvindn051 yup...it just parses the properties into usable object format...i got that.
22:06:04 arvindn051 if we had to introduce preferred traits to this model, we would first add trait:foo=preffered in the image property
22:06:38 arvindn051 when we parse it into the object, we would need to introduce antoher field preferred_traits with these values right?
22:07:15 jaypipes arvindn051: yes, precisely.
22:07:36 arvindn051 how about if we do numbered traits like trait:CUSTOM_foo, trait1:foo etc...how would we model this here?
22:08:16 jaypipes arvindn051: don't worry about that.
22:08:45 arvindn051 my intial thought was to just parse the image properties as a dict into the object and have the consumer figure out which keys/values makes sense to him
22:08:50 jaypipes arvindn051: for now, all we need to do is produce the non-granular required traits as a list of trait strings.
22:10:04 arvindn051 is there a possiblity to support the need for granular traits in the future? if so, how would we handle is what i am thinking about
22:10:37 arvindn051 if you think there is no possiblity of this, then we can ignore and go ahead with having specific fields
22:10:55 jaypipes arvindn051: like I said, don't worry about it. :)
22:11:47 jaypipes arvindn051: there's nothing about the proposed solution here that prohibits granular traits being parsed from strings like "trait1:HW_CPU_X86_AVX2" in the future.
22:13:21 arvindn051 ok :) i guess we could introduce a granular_traits dict of strings fields in the future if needed...
22:13:35 arvindn051 thanks...will make the updates in a couple of mins
22:23:05 openstackgerrit Arvind Nadendla proposed openstack/nova master: Update ImageMetaProp object to expose traits https://review.openstack.org/557795
22:24:51 arvindn051 jaypipes: made the changes...should be good now

Earlier   Later