| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-31 | |||
| 17:50:39 | dansmith | diablo_rojo: if you're asking because of ticket sales, | |
| 17:50:43 | diablo_rojo | Just looking for an approximation. More or less than last time etc. | |
| 17:50:49 | dansmith | diablo_rojo: we _just_ got approval for the first round of people last week, so.. | |
| 17:50:54 | diablo_rojo | dansmith, not for ticket sales. For room allocation. | |
| 17:51:05 | diablo_rojo | I can always put nova in a closet ;) | |
| 17:51:37 | jmlowe | cdent: I thought I remembered something about moving the add and remove of instance nics out of neutron and into nova, could have been imagining that | |
| 17:51:48 | diablo_rojo | dansmith, I know estimates are rough for everyone, but a general idea of how many would be a huge help. | |
| 17:52:28 | jaypipes | diablo_rojo: 25-35 would be my guess. | |
| 17:52:56 | cfriesen_ | question about resource tracking...why do we need the "reserved_host_cpus" config option when we already have "vcpu_pin_set"? | |
| 17:53:06 | cdent | jaypipes: does the confirm resize have access to the flavor/requestspec/whatever against which it could compare the values of a retrieve allocation against? | |
| 17:53:11 | diablo_rojo | jaypipes, that works. Thanks :) | |
| 17:53:26 | jaypipes | cdent: yes. | |
| 17:54:47 | cdent | jaypipes: actually, why compare, just write the allocation that is the result of the spec, it will cleanup the shared doubling there and then, no math required? | |
| 17:55:23 | dansmith | cdent: the allocation that is the result of the old flavor is non-trivial to determine.. size, yes, but RP, not so much | |
| 17:55:40 | cdent | we don't care about the old flavor | |
| 17:55:45 | cdent | we're going to clobber the old flavor | |
| 17:55:51 | cdent | the allocations that resulted from the old flavor | |
| 17:55:55 | jaypipes | cdent: because unfortunately the source host is what runs confirm_resize() and doesn't know the UUID of the dest host so the only way to do it is to look for the source host's UUID in the allocation list and delete those, leaving the others | |
| 17:56:07 | dansmith | cdent: well, if you meant subtract the old one to get the new net, but I don't think we know enough to generate a full new one | |
| 17:56:09 | cdent | argh! | |
| 17:56:10 | dansmith | because yeah, that& | |
| 17:56:31 | jaypipes | though I suppose the source host *could* look up the uUID of the dest host by looking at the Migration object | |
| 17:56:45 | cdent | I know understand why there was so much table flipping last week | |
| 17:56:47 | dansmith | please no | |
| 17:56:48 | cdent | now | |
| 17:57:01 | jaypipes | dansmith: yeah, I don't want to do that either. | |
| 17:57:36 | jaypipes | cdent: ok, so do you have all the answers and ideas you need to work on that bug? | |
| 17:57:51 | cdent | jaypipes: apparently not | |
| 17:57:58 | cdent | as we keep dismissing solutions | |
| 17:58:52 | dansmith | is it time for our daily hangout? | |
| 17:58:55 | jaypipes | cdent: well, all of these patches I pretty much consider just "hey, here's one solution to this problem, can you all check it out". | |
| 17:58:58 | cdent | or should I just go ahead and do the the VCPU introspection | |
| 17:59:04 | jaypipes | dansmith: I'm game | |
| 17:59:15 | cdent | i've got a different hangout now :( | |
| 17:59:21 | jaypipes | cdent: no, I think we're recommending trying the "just sum it" approach. | |
| 17:59:30 | jaypipes | from Mr. dansmith | |
| 17:59:35 | cdent | but we said we can't clean up the sum it approach? | |
| 18:00:23 | dansmith | if we're the only RP in the allocations, | |
| 18:00:25 | jaypipes | cdent: for shared providers, we will heal that on the *destination host* but after the move operation is entirely ended.. | |
| 18:00:36 | dansmith | jaypipes: we will? | |
| 18:00:39 | dansmith | I don't think we will | |
| 18:01:08 | jaypipes | dansmith: yeah, because _update_usage_from_instance() will overwrite the allocations to match a single amount of the flavor. | |
| 18:01:23 | dansmith | it can't | |
| 18:01:26 | dansmith | until after confirm | |
| 18:01:37 | jaypipes | right, which is what I said above, no? | |
| 18:01:38 | dansmith | and the destination doesn't know about confirm | |
| 18:01:57 | jaypipes | dansmith: "but after the move operation is entirely ended.." | |
| 18:02:22 | dansmith | oh | |
| 18:02:28 | dansmith | yeah, and you can't | |
| 18:02:36 | dansmith | the destination host does not know when the move has ended | |
| 18:02:57 | dansmith | jaypipes: https://hangouts.google.com/call/2phok3vj6nhipcx6gp62zvaly4u | |
| 18:23:59 | cdent | dansmith, jaypipes still hanging out? | |
| 18:24:05 | dansmith | cdent: yes | |
| 18:24:14 | dansmith | cdent: just getting to the "wtf now?" phase | |
| 18:30:53 | dansmith | mriedem: are you aware of a patch up that adds uuid for migration objects? | |
| 18:47:28 | openstackgerrit | Merged openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/488283 | |
| 18:50:29 | chohoor | I have a question, driver.deallocate_networks_on_reschedule(instance) will return True or False when nova do reschedulter(/nova/compute/manager.py:1822), why only ironic driver return True but other drivers return False? | |
| 19:31:06 | mriedem | dansmith: nope | |
| 19:34:23 | mriedem | sorry, been catching up on internal things that i put off all last week | |
| 19:37:02 | cdent | dansmith, jaypipes: did you fix everything and make the world safe for moves? | |
| 19:37:19 | dansmith | cdent: no, but we identified that suicide is the easiest path out | |
| 19:37:33 | cdent | but it brings on many changes | |
| 19:42:32 | cdent | dansmith, jaypipes: I have a horrible idea: proxy_id = consumer_uuid.replace(‘-‘, ‘+’) | |
| 19:42:50 | cdent | because it’s the doubling id | |
| 19:47:18 | jaypipes | cdent: that doesn't solve the problem we're currently stuck on though, w.r.t. old Ocata computes migrating instances to newer Pike computes | |
| 19:49:31 | openstackgerrit | Sean Dague proposed openstack/nova master: always show urls in list_cells https://review.openstack.org/487860 | |
| 19:49:37 | sdague | mriedem: I added the cacert test case | |
| 19:49:49 | sdague | but the rest of the suggested url adds are all actually invalid urls | |
| 19:50:06 | sdague | I was looking at https://tools.ietf.org/html/rfc3986 to figure out why they were parsing weird | |
| 19:54:32 | openstackgerrit | Eric Fried proposed openstack/nova master: nova.utils.get_endpoint_data() https://review.openstack.org/488137 | |
| 19:55:47 | cdent | jaypipes: that’s a less negative reaction than I was expecting | |
| 19:56:35 | openstackgerrit | Sean Dague proposed openstack/nova master: always show urls in list_cells https://review.openstack.org/487860 | |
| 19:56:38 | sdague | efried: also, the typo | |
| 19:59:12 | sdague | efried: and, any chance you can get powervm to run this patch to figure out what the hostname mismatch problem is - https://review.openstack.org/#/c/488381/ ? | |
| 20:02:32 | efried | esberglu ^^ | |
| 20:03:01 | efried | sdague - esberglu ran our CI against that patch (with our new CI changes) and it's all good. | |
| 20:03:32 | esberglu | efried: sdague: Yep. Everything looked fine, it was an issue on our end that's resolved now | |
| 20:04:22 | efried | sdague Possibly TMI, but the deal is: We have to do some hacking to set up our internal API to run remotely (i.e. not localhost). Before, we were waiting until after stack.sh finished, doing that hacking, and restarting the compute service. We were just accepting that it would fail to start up during stack itself. | |
| 20:04:43 | efried | sdague Now we've figured out how to hack it before stack.sh, so the compute service should come alive during stack. | |
| 20:09:27 | sdague | efried: ok, good stuff | |
| 20:09:39 | sdague | so, I think that just leaves the ironic ordering problem | |
| 20:09:49 | sdague | which I can special case | |
| 20:12:01 | efried | sdague Is there a reason you removed the ? from the regex? | |
| 20:12:36 | efried | sdague This will now do the wrong thing if there's an @ further along in the URL (e.g. in the querystring (which may be the only place it's legal without being escaped)) | |
| 20:12:49 | sdague | efried: no, it's matching on nethost | |
| 20:13:08 | sdague | the query string is out of bounds for that replacement | |
| 20:13:22 | efried | ahhhh, cool. | |
| 20:20:43 | dansmith | cdent: jaypipes: so the bottom patch in that series, | |
| 20:20:55 | dansmith | to fix the allocations thing by removing the where clause.. | |
| 20:20:59 | dansmith | doesn't seem to work for me | |
| 20:21:15 | dansmith | gibi's test on top of that still ends up with allocations for both computes after the confirm | |
| 20:22:18 | cdent | the way gibi_ changed it originally was less instrusive: it simply changed the existing and clause to one condition (the consumer uuid) | |
| 20:23:10 | cdent | which ought to be the same thing | |
| 20:23:33 | dansmith | isn't that way jay did? | |
| 20:24:19 | cdent | i’m looking up the discussion, one sec | |
| 20:24:30 | openstackgerrit | Jay Pipes proposed openstack/nova master: remove source provider allocs in confirm_resize() https://review.openstack.org/488510 | |
| 20:24:40 | jaypipes | dansmith: have a gander ^ | |
| 20:24:54 | jaypipes | dansmith: still needs tests but I want to get your early feedback. | |
| 20:25:25 | cdent | http://p.anticdent.org/4oEf | |
| 20:25:25 | dansmith | jaypipes: okay but see my question above? | |