| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-24 | |||
| 20:06:54 | dansmith | $TOP_DIR/files | |
| 20:08:16 | cdent | bauzas: see upgrade-tempest for an example | |
| 20:08:45 | cdent | bauzas: and/or projects/30_swift/upgrade.sh | |
| 20:08:52 | bauzas | cdent: roger | |
| 20:09:18 | cdent | looks like those use $TARGET_DEVSTACK_DIR/files | |
| 20:11:12 | bauzas | dansmith: I guess I can deploy grenade on my local devstack for testing ? | |
| 20:11:28 | dansmith | if you're really really lucky :) | |
| 20:11:29 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova: Updated from global requirements https://review.openstack.org/424828 | |
| 20:12:25 | bauzas | dansmith: you mean it's difficult? | |
| 20:13:10 | dansmith | bauzas: I mean I often have issues | |
| 20:14:02 | cdent | bauzas: I agree with dansmith: I often have issues, and in addition it takes forever to reach those issues, at which point you throw your hands up in the air | |
| 20:14:18 | dansmith | yeah | |
| 20:14:34 | bauzas | okay, so let's hit the gate... | |
| 20:37:40 | amrith | andreykurilin, the patch to requirements repo has come down to trove via the req bot. I've dep'ed your change on that. Hope that's what you intended. | |
| 20:42:15 | andreykurilin | amrith: everything should work now in trove | |
| 20:42:19 | andreykurilin | without my patch | |
| 20:45:15 | openstackgerrit | Andrey Kurilin proposed openstack/python-novaclient: [CLI] Fix token auth type https://review.openstack.org/424256 | |
| 20:45:56 | amrith | andreykurilin, cool. in that case I'm going to announce my retirement and move to a beach somewhere where it is warm. | |
| 20:46:09 | amrith | :) | |
| 20:46:09 | andreykurilin | heh | |
| 20:46:21 | amrith | thanks andreykurilin I very much appreciate your help with this set of changes. | |
| 20:47:20 | andreykurilin | amrith: I'll return to them with new novaclient 7.1.0 :) but I'll try to do it before breaking gates | |
| 20:47:42 | amrith | OK, and I'll propose some of the tests that I mentioned this morning against head of nova | |
| 20:48:16 | andreykurilin | amrith: it will be cool, thanks | |
| 20:51:24 | openstackgerrit | STEW TY proposed openstack/nova: Transform instance.resize_revert notification https://review.openstack.org/396811 | |
| 21:01:33 | openstackgerrit | Dan Smith proposed openstack/nova: WIP: Collected release notes for Ocata CellsV2 https://review.openstack.org/424737 | |
| 21:01:33 | openstackgerrit | Dan Smith proposed openstack/nova: Move instance creation to conductor https://review.openstack.org/319379 | |
| 21:12:41 | mriedem | i hope my insurance covers a bad case of sand crack | |
| 21:15:18 | cdent | get some talcum powder on that ass | |
| 21:19:22 | openstackgerrit | Andrey Kurilin proposed openstack/python-novaclient: DO NOT MERGE: check OSC https://review.openstack.org/420941 | |
| 21:23:54 | mriedem | vladikr: so i was thinking about vlan vifs and tempest testing, we probably don't have any jobs that use vlan tags on ports do we? | |
| 21:29:44 | cdent | bauzas: your grenade run has just finished | |
| 21:29:56 | bauzas | cdent: yup, was following | |
| 21:30:06 | cdent | on the old side it looks like placement auth isn't in place: http://logs.openstack.org/30/424730/2/check/gate-grenade-dsvm-neutron-ubuntu-xenial/6ccea97/logs/old/screen-n-cpu.txt.gz#_2017-01-24_20_36_57_937 | |
| 21:30:47 | bauzas | cdent: that's for the full grenade job right? | |
| 21:31:02 | bauzas | cdent: if so, I think it's not a problem | |
| 21:31:13 | cdent | Oh, is it just changed for one of the jobs not all? | |
| 21:31:32 | bauzas | cdent: I was rather looking at the multinode job | |
| 21:31:51 | bauzas | cdent: I provided a from-newton script | |
| 21:32:04 | bauzas | cdent: so it's not changing the old side AFAICU | |
| 21:32:24 | cdent | ah, I follow now | |
| 21:33:03 | bauzas | cdent: that said, I'd like to see the old compute calling the new scheduler by grenade | |
| 21:33:13 | bauzas | cdent: so IIUC it's the multinode job | |
| 21:33:36 | bauzas | but maybe dansmith can insight? | |
| 21:34:11 | bauzas | I think I'm also starting the placement engine for any node, including a specific compute only | |
| 21:34:38 | cdent | bauzas: I've got to call it a night, but if there's something I can do to help out tomorrow morning leave me a note somewhere (email or here is fine) | |
| 21:34:52 | bauzas | cdent: I'm just rechecking the scheduler change | |
| 21:35:00 | bauzas | cdent: for seeing if it's now happy | |
| 21:35:03 | bauzas | cdent: sure | |
| 21:37:37 | dansmith | bauzas: from-$release only runs on the main node AFAK | |
| 21:38:28 | bauzas | dansmith: I replied to you on the ML thread about optional resources | |
| 21:38:38 | bauzas | dansmith: have you seen my other emails ? | |
| 21:38:45 | dansmith | yeah | |
| 21:39:01 | bauzas | and why I think it's understandable, I think asking that for Ocata seems difficult to me | |
| 21:39:17 | bauzas | the gate itself is even not running DiskFilter... | |
| 21:39:22 | bauzas | oops | |
| 21:39:26 | bauzas | CoreFilter I meant | |
| 21:39:57 | bauzas | and we also have an assertion that says amount can't be 0 - but we have a lot of flavors having root_gb=0 | |
| 21:40:51 | bauzas | so what should I ask for if a flavor is set to root_gb=0 for example ? | |
| 21:41:13 | bauzas | I mean, I totally understand jaypipes's opinion about why it's a wrong direction | |
| 21:41:24 | bauzas | I just think it's not something we should stop by Ocata | |
| 21:42:52 | cburgess | dansmith: If I have an instance object (returned from novaclient) is there an easy way to refresh the status and task_status from the DB? Or do I have to do a full server.get() again? | |
| 21:43:33 | dansmith | cburgess: you don't get instance objects back from novaclient, you get a dict.. so yeah, you have to .get() again | |
| 21:43:35 | cburgess | OK well not from the DB since clearly it has to make an API call since I'm using novaclient. I mean do you just get it again or is there some swanky built-in to refresh it? | |
| 21:43:40 | cburgess | Oh ok.. | |
| 21:44:18 | bauzas | dansmith: saw my points above ? | |
| 21:44:29 | cburgess | Hmm weird.. its got methods defined on it, but I get your point. I'll re-fetch it. | |
| 21:44:52 | dansmith | bauzas: yes, I've read your emails and the points above, I'm not sure what to say and I'm frantically trying to get other work done | |
| 21:44:55 | dansmith | bauzas: it's just MHO | |
| 21:45:23 | bauzas | dansmith: okay again, I don't disagree with both of you | |
| 21:45:30 | bauzas | dansmith: I'm just trying to be pragmatic | |
| 21:49:58 | vladikr | mriedem, sorry I was away.. Yes, I didn't find any jobs that uses vlans | |
| 21:50:59 | vladikr | mriedem, also, in order to test it, we need something that will set the {binding:{details:{vlan: X}}} | |
| 21:51:42 | vladikr | mriedem, which is not available for all vnic types | |
| 21:51:44 | mriedem | vladikr: right that's what got me thinking about it | |
| 21:51:53 | mriedem | if we don't have a job that sets the vlan tag on the port details, | |
| 21:52:04 | mriedem | then any tempest test for checking it probably isn't going to do anything | |
| 21:53:09 | vladikr | mriedem, I'm still looking for how to do it.. artom is helping as well (took a break to pickup the kids though) - but I don't know if it's all possible | |
| 21:54:11 | mriedem | vladikr: if the vif details don't have a vlan tag, do we not put anything into the metadata json response? if we always have something in there for vlan tags, even if it's just None or [], we could check for that | |
| 21:55:20 | vladikr | mriedem, if we don't have anything in the binding we just skip the device (unless it has tags) | |
| 21:58:50 | mriedem | bauzas: replied to your thread with a question/clarification | |
| 22:03:13 | bauzas | mriedem: I think your clarification works with me | |
| 22:03:28 | bauzas | mriedem: I'm not only worried by CDs like TripleO | |
| 22:03:59 | bauzas | mriedem: I'm more worried of people trying to change their cloud because we decided so without a warning cycle | |
| 22:04:33 | bauzas | in general, we try to first notice them for a cycle and do the cut on the next one | |
| 22:05:05 | bauzas | here, if you're not changing your cloud before upgrading, you won't get any failure but the scheduler won't work like you set it previosuly | |
| 22:05:24 | bauzas | so I'm pretty sure lots of folks will be confused then | |
| 22:05:56 | bauzas | that said, I'm still having 2 concerns | |
| 22:06:11 | mriedem | bauzas: well you should be reading the release notes before upgrading | |
| 22:06:22 | bauzas | mriedem: I know | |
| 22:06:31 | bauzas | mriedem: and I'm all in favor of that | |
| 22:06:45 | bauzas | but for example, take the flavor root_gb=0 | |
| 22:07:02 | bauzas | people do that for avoiding having issues with shared volumes, right? | |
| 22:07:18 | bauzas | I know we're going to help them with the aggregates BP | |
| 22:07:32 | bauzas | but for the moment, they still have flavors set with that zero size | |
| 22:07:46 | mriedem | we account for that in the RT don't we? | |
| 22:08:01 | mriedem | *scheduler report client | |
| 22:08:04 | mriedem | for disk inventory | |
| 22:08:05 | bauzas | mriedem: but what should we ask to the PlacementAPI if the flavor is 0 ? | |
| 22:08:42 | bauzas | mriedem: eg. https://review.openstack.org/#/c/417961/22/nova/scheduler/filter_scheduler.py@164 | |