| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-12 | |||
| 19:35:30 | sean-k-mooney | dansmith: yes but the we have too trees for the same phyical server and we dont currently have a way to model that they are the same server | |
| 19:35:37 | sean-k-mooney | i guess maybe with an aggregate | |
| 19:35:47 | dansmith | sean-k-mooney: they're not the same server, | |
| 19:36:02 | sean-k-mooney | dansmith: why not? | |
| 19:36:10 | efried | dansmith, jaypipes: Please confirm: you want two separate methods, with *traits args | |
| 19:36:10 | dansmith | sean-k-mooney: they represent services that happen to be on the same box.. if we need to model that they're on the same box (i.e. below a parent provider) then that's a thing | |
| 19:36:17 | dansmith | efried: that's fine | |
| 19:36:18 | jaypipes | efried: yes please | |
| 19:36:26 | efried | ight | |
| 19:36:34 | jaypipes | add_traits() and remove_traits() would be my preference. | |
| 19:36:43 | jaypipes | efried: ^ | |
| 19:36:45 | dansmith | efried: btw, excellent job not having your head explode here. kudos :) | |
| 19:37:19 | efried | jaypipes: Cool, swhere I was gonna go. dansmith: ack, thx; head may yet explode over aggregates thing, but so far so good. | |
| 19:37:21 | dansmith | efried: on friday of PTG, I thought maybe your eyeballs were about to shoot from your head at lethal velocity, which scared me when they were pointed at me | |
| 19:37:43 | sean-k-mooney | dansmith: ok anyway thats a little off topic. i do think we may want to have a parent of the compute node RP at some point then but let cross that bridge only when we need too | |
| 19:38:11 | dansmith | sean-k-mooney: we may and that would solve the problem of this ownership of the tree for deletes problem, that's what I'm saying :) | |
| 19:38:32 | dansmith | until that point, if you create a provider underneath someone else's provider, I think you need to know that you're at the other's mercy | |
| 19:38:35 | efried | dansmith: It ain't my eyeballs that should worry you :P FWIW, I'm still uncomfortable with this, but I don't see a better alternative. | |
| 19:38:46 | dansmith | um. | |
| 19:39:46 | dansmith | oof | |
| 19:40:48 | sean-k-mooney | dansmith: oh yes it would solve that issue. it would raise the question of which tree i shoudl create the resouce other for thinks like bandwith. anyway i better run before the stores close at 8 | |
| 19:41:14 | dansmith | yeah | |
| 19:52:19 | mnaser | hm, does anyone have any idea behind the historical reason why ComputeCapabilitiesFilter is hard-coded to use instancetypes (not taking image properties into consideration?) | |
| 19:52:50 | mnaser | context: customer *needs* instances with a specific cpu flag, i'd like to minimize the number of flavors so i was hoping i can have a image flag requesting that cpu flag | |
| 19:53:00 | mnaser | vs having to create a new instance type for this use case specifically | |
| 19:53:48 | efried | jaypipes: Considering removing ProviderTree.set_traits/set_aggregates entirely. | |
| 20:00:18 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Allow for merging traits and aggregates https://review.openstack.org/552122 | |
| 20:00:32 | efried | dansmith, jaypipes, cdent, edleafe: ^ with changes as requested, plus for aggregates | |
| 20:03:16 | cdent | ✔ | |
| 20:16:00 | jaypipes | efried: +2 from me. thx | |
| 20:16:09 | efried | thx | |
| 20:21:54 | edleafe | efried: a little late, but added my +1 for good measure :) | |
| 20:22:03 | efried | thx | |
| 20:23:02 | dansmith | efried: consider me suitably thrown under the bus for my method naming | |
| 20:24:57 | efried | dansmith: You're not held accountable for sample code in pastebin. Else I would have griped at you about having the + case first and the - case the default. | |
| 20:25:56 | dansmith | else should have raised | |
| 20:26:37 | mriedem | efried: with ^ how can i integrate that with https://review.openstack.org/#/c/538498/ where i'm not in a virt driver with a provider tree - or will that RT code eventually have the provider tree object so i can call add_traits there? | |
| 20:28:05 | mriedem | alternatively, if the RT isn't the place to do that and the virt driver is, i could add a generic method in the base ComputeDriver class that handles adding traits from the capabilities dict | |
| 20:28:29 | dansmith | mriedem: virt driver can do that from u_p_t he's describing here | |
| 20:28:45 | mriedem | right, but i don't want to copy the same thing in all virt drivers | |
| 20:28:49 | dansmith | but better for compute to do it right where it's calling into the virt driver | |
| 20:28:51 | mriedem | so RT or base class, i'm ok with either | |
| 20:28:52 | dansmith | call the capabilities compute-owned | |
| 20:29:03 | efried | mriedem: I'm glad you asked. I believe you should get the traits from placement and add in those you got from _get_traits (which is the union of those from virt & capabilities). | |
| 20:29:06 | mriedem | the compute isn't calling this, the RT is | |
| 20:29:10 | dansmith | yeah, wherever we call that in the virt driver from | |
| 20:29:22 | mriedem | i don't know what the RT will have the UPT | |
| 20:29:25 | dansmith | efried: eh? | |
| 20:29:29 | mriedem | maybe it will and i'm just behind | |
| 20:29:49 | mriedem | efried: i'm not sure why i need to call placement, | |
| 20:29:53 | dansmith | efried: we get them from the virt driver structure, we can just generate the traits that go with them and tack them onto the provider tree for the compute node RP | |
| 20:29:56 | mriedem | i want to *always* report these capabilities | |
| 20:29:58 | dansmith | mriedem: you wouldn't | |
| 20:29:59 | dansmith | right | |
| 20:30:09 | dansmith | these are compute-asserted traits, IMHO | |
| 20:30:56 | mriedem | telling me, "go look at the UPT series of changes and figure it out" is acceptable also | |
| 20:31:42 | efried | mriedem: If we can slot your change into the UPT series, that would make things easier to reason about. Having to decide what it would look like in all three possible permutations is harder. | |
| 20:32:04 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: Network interface attach/detach https://review.openstack.org/546813 | |
| 20:32:10 | dansmith | mriedem: https://review.openstack.org/#/c/520246/52/nova/compute/resource_tracker.py L884 there I think | |
| 20:32:43 | dansmith | logically it's compute, but mechanically it's RT because that's what owns the compute node RP | |
| 20:32:52 | mriedem | ok that works for me, i can rebase on top of that | |
| 20:32:55 | efried | mriedem: If we do your change *after* https://review.openstack.org/#/c/520246/ then you can use the prov_tree to merge in the capability traits and then call update_from_provider_tree. | |
| 20:33:49 | mriedem | yeah i'll plan on that, | |
| 20:33:50 | mriedem | no rush | |
| 20:35:51 | efried | mriedem: I'm about to do some ka-shuffle-fu. Want me to fold that in? | |
| 20:36:26 | mriedem | no leave it to me | |
| 20:36:28 | mriedem | please | |
| 20:37:04 | mriedem | that also leaves you on the hook for reviewing it when i do it | |
| 20:38:21 | mikal | Deleted nova-net yet? | |
| 20:48:18 | mriedem | no | |
| 20:48:23 | mriedem | working on it | |
| 20:48:46 | mriedem | need to get https://review.openstack.org/#/c/549789/ going | |
| 20:49:02 | mriedem | but i have to go through the test failures there and figure out what (and how) to blacklist | |
| 20:49:12 | mriedem | mikal: ^ | |
| 20:49:38 | mriedem | the failures are mostly just due to stuff like not supporting security groups in the cells v1 api | |
| 20:50:16 | mriedem | https://review.openstack.org/#/c/225199/ would have handled that nicely but it got bogged down in committee | |
| 21:06:27 | edmondsw | does tagged_attach require the metadata service? Because cloud-init would only be an option during boot, not after, right? | |
| 21:10:05 | ameeda | Hi, I try to call heat template by rest api, when I try to do GET http:// |
|
| 21:10:28 | edmondsw | and by cloud-init I should have said config drive... | |
| 21:21:35 | mriedem | edmondsw: tagged attach does not require the metadata service, the tagged devices will show up in the metadata blob in the config drive | |
| 21:21:52 | mriedem | the config drive will only have the create-time tagged devices, correct | |
| 21:22:07 | edmondsw | mriedem config drive is available beyond the first boot? | |
| 21:22:07 | mriedem | if you need on-the-fly changes to tagged devices then you'd need the metadata service | |
| 21:22:15 | mriedem | no it's not | |
| 21:22:25 | edmondsw | ok, that's what I was thinking | |
| 21:23:29 | edmondsw | boo... but tx for confirming | |
| 21:23:57 | mriedem | now if you're using configuration strategy, | |
| 21:23:59 | mriedem | who knows | |
| 21:24:00 | mriedem | :) | |
| 21:24:35 | edmondsw | "configuration strategy"? | |
| 21:27:48 | mriedem | https://www.ibm.com/developerworks/community/forums/html/topic?id=1918efbc-ae12-44a3-8075-a6023831d334&ps=100 | |
| 21:28:49 | mriedem | https://www.ibm.com/support/knowledgecenter/en/SST55W_4.2.0/liaca/liacaimportingstrategy.html is better | |
| 21:29:43 | mriedem | i.e. config-drive for ibm i and aix images right? | |
| 21:30:41 | mriedem | boot me an ibm i guest with 500 volumes attached in a single call please | |
| 21:39:29 | openstackgerrit | Merged openstack/nova-specs master: Report CPU features to placement service by traits API https://review.openstack.org/497733 | |
| 21:41:42 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: Snapshot https://review.openstack.org/543023 | |
| 22:03:13 | openstackgerrit | Merged openstack/nova-specs master: Express forbidden traits in placement API https://review.openstack.org/548915 | |
| 22:12:39 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Fix spec name for "report CPU features to as traits" https://review.openstack.org/552159 | |
| 22:12:58 | tasker | trying to instruct tox to run "nova.tests.unit.compute.test_compute_api" and it fails, complaining about being unable to import "nova.tests.unit.network.test_neutronv2", "nova.tests.unit.virt.test_block_device", and "nova.tests.unit.virt.test_imagecache". any quick thoughts on what I've done wrong? | |
| 22:13:00 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Fix spec name for "report CPU features as traits" https://review.openstack.org/552159 | |