| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-24 | |||
| 22:28:11 | mriedem | enabling the filters just to say, 'don't do this b/c we're going to stop caring about them for the filter scheduler' is very weird | |
| 22:28:51 | bauzas | mriedem: I agree, that doesn't sound a great plan | |
| 22:29:26 | dansmith | bauzas: yeah, I know.. I'm not sure what root=0 has to do with this discussion at all | |
| 22:30:03 | bauzas | dansmith: https://review.openstack.org/#/c/417961/22/nova/scheduler/filter_scheduler.py@164 | |
| 22:30:43 | mriedem | bauzas: those are different issues, | |
| 22:32:41 | openstackgerrit | Steven Webster proposed openstack/nova: Release PCI devices on drop_move_claim() https://review.openstack.org/370374 | |
| 22:34:45 | mriedem | bauzas: given the retarded dance we'd have to come up with just to say this stuff is changing, i think i'd prefer to just always request VCPU/RAM/DISK_GB as outlined in the spec and make it clear in the release notes that if you didn't have those filters enabled before, you need to adjust for that with allocation ratios now before upgrading to ocata | |
| 22:34:54 | mriedem | bauzas: and as dansmith said, we could also work that into the nova-status upgrade check | |
| 22:36:14 | bauzas | mriedem: okay, I then need to hurry up to change a few more things | |
| 22:36:36 | bauzas | and hope nobody won't complain too much | |
| 22:37:11 | mriedem | bauzas: and then reply to the ML thread signing away your consent | |
| 22:37:49 | bauzas | mriedem: tbc, I won't have the bandwidth for the nova-status check | |
| 22:38:00 | bauzas | mriedem: neither me notifying the operators they have to move on | |
| 22:38:32 | mriedem | bauzas: i can do nova-status | |
| 22:38:34 | bauzas | for what I see, I only have 1.5 day left for changing at least a couple of tests | |
| 22:38:48 | bauzas | at least some of the functional tests | |
| 22:38:59 | bauzas | mriedem: you're on vacation, remember :) | |
| 22:39:16 | bauzas | mriedem: well, I don't have a RV for that | |
| 22:43:00 | mriedem | jaypipes: how are things looking for this last patch in the resource classes series? https://review.openstack.org/#/c/404472/ | |
| 22:43:34 | bauzas | sooooo, the grenade change didn't help the scheduler change | |
| 22:43:41 | bauzas | I'm depressed | |
| 22:44:33 | mriedem | jaypipes: er i guess it's no longer the last change in the series | |
| 22:46:31 | bauzas | let's be clear, given the grenade problem, I'm not feeling we could merge https://review.openstack.org/#/c/417961 by Ocata | |
| 22:46:35 | bauzas | anyway | |
| 22:46:53 | bauzas | I'll need to bail out for the night or I'm doomed | |
| 22:47:29 | bauzas | so in case folks have a bit of interest about https://review.openstack.org/#/c/417961 and are knowing grenade, feel free to help | |
| 22:54:10 | andreykurilin | stevemar: please, put W-1 at https://review.openstack.org/#/c/424847/1 . It breaks novaclient's gates | |
| 22:54:15 | andreykurilin | :( | |
| 22:54:49 | andreykurilin | it looks like we need to bump openstacksdk and openstackclient versions together | |
| 22:55:25 | mriedem | andreykurilin: reminder on https://review.openstack.org/#/c/418190/ in case you have to use it | |
| 22:55:40 | stevemar | andreykurilin: that'll blow the requirements teams minds | |
| 22:55:45 | mriedem | only thing on ^ is we'd have to cleanup the commit message | |
| 22:56:23 | stevemar | mriedem: fi-lgtm | |
| 22:57:02 | stevemar | andreykurilin: i rebased it, should be bumped out of the gate (don't think it even got that far) | |
| 22:57:26 | dansmith | bauzas: it's not starting the placement api, looks like | |
| 22:57:35 | dansmith | bauzas: I see no placement-api log | |
| 22:57:38 | stevemar | andreykurilin: how would bumping OSC min solve the issue? | |
| 22:58:00 | andreykurilin | mriedem: but why we have multiple networks with latest openstacksdk and do not have them with old version? | |
| 22:59:38 | mriedem | andreykurilin: because the sdk broke the filtering on available networks :) | |
| 22:59:47 | andreykurilin | mriedem: oh | |
| 23:00:00 | mriedem | at least i think that's what kevinbenton found when he looked at that issue before | |
| 23:00:18 | mriedem | his notes are in that patch | |
| 23:00:20 | stevemar | andreykurilin: mriedem can we just get the nova functional tests working with the newer version? | |
| 23:00:31 | andreykurilin | mriedem: can you update commit message? | |
| 23:00:40 | stevemar | i guess that's what https://review.openstack.org/#/c/418190/ does | |
| 23:00:45 | mriedem | stevemar: well shouldn't that be a major version bump on the sdk? | |
| 23:01:06 | stevemar | mriedem: they have a stance that since they are pre 1.0 they are allowed to break compatibility | |
| 23:02:09 | stevemar | mriedem: like how gmail was in beta for a decade | |
| 23:02:32 | mriedem | stevemar: jesus h c | |
| 23:02:38 | stevemar | osc and senlinclient *need* the latest version | |
| 23:02:39 | bauzas | dansmith: roger, I'll try to investigate tomorrow morning but I'm just exhausted | |
| 23:02:40 | andreykurilin | stevemar: I'm ok to merge mriedem fix for our gates and then look at the process of merging g-r update. I do not want to see g-r update at first, since we need to merge one patch before cutting new release | |
| 23:02:40 | mriedem | well they should shit or get off that pot | |
| 23:02:50 | andreykurilin | heh | |
| 23:02:57 | stevemar | mriedem: soon (tm) | |
| 23:03:04 | stevemar | andreykurilin: i would looove that | |
| 23:03:45 | stevemar | andreykurilin: rally is good right? | |
| 23:04:06 | andreykurilin | stevemar: yes. setting quotas works. thanks | |
| 23:04:18 | Kevin_Zheng | mriedem: https://bugs.launchpad.net/nova/+bug/1658571 | |
| 23:04:18 | openstack | Launchpad bug 1658571 in OpenStack Compute (nova) "Microversion 2.37 break 2.32 usage" [High,In progress] - Assigned to Artom Lifshitz (notartom) | |
| 23:05:25 | andreykurilin | stevemar: PS: I wonder why are so dependent on pre 1.0 library which can do whatever they want(as you said) .. | |
| 23:05:36 | andreykurilin | *why we are | |
| 23:05:46 | mriedem | andreykurilin: yeah good question | |
| 23:06:09 | mriedem | stevemar: so is OSC going to have a thing in it's release notes saying, oh btw, when you create private tenant networks in this release things are doing to be different? | |
| 23:06:10 | stevemar | andreykurilin: theres some history there | |
| 23:06:25 | mriedem | Kevin_Zheng: hi | |
| 23:06:34 | mriedem | Kevin_Zheng: did you see the ML thread? | |
| 23:07:22 | andreykurilin | stevemar: if they want to play with us in the same sandbox, they should follow the same rules | |
| 23:07:50 | Kevin_Zheng | mriedem: not yet, left early yesterday | |
| 23:08:01 | stevemar | mriedem: we can add that to the release notes, but i think we rename the column/info properly | |
| 23:09:12 | bauzas | mriedem: what kind of important note should we write for telling to ops "folks, you need to change your cloud before upgrading to Ocata"? | |
| 23:09:24 | bauzas | mriedem: given the upgrade section is already huuuuuge | |
| 23:09:49 | bauzas | possibly in the prelude I guess | |
| 23:10:00 | dansmith | bauzas: made changes.. start_placement() isn't getting called which means no a2ensite, restart, etc | |
| 23:10:08 | mriedem | bauzas: yeah and probably in the placement devref | |
| 23:10:26 | bauzas | dansmith: kewl thanks ! | |
| 23:10:34 | mriedem | bauzas: we'll have something in the prelude section for placement and cells v2 for sure | |
| 23:10:47 | mriedem | i'd also like docs reflected in the devref which we have for placement and cells v2 | |
| 23:10:49 | mriedem | for stuff like this | |
| 23:10:54 | bauzas | dansmith:jam+1 | |
| 23:11:05 | dansmith | heh | |
| 23:11:13 | stevemar | mriedem: plus, everyone uses neutron anyway :P | |
| 23:13:15 | Kevin_Zheng | mriedem: just read, so a new microversion? | |
| 23:13:26 | mriedem | Kevin_Zheng: yes | |
| 23:13:35 | mriedem | Kevin_Zheng: but i think we can handle that as a bug fix after the feature freeze | |
| 23:13:41 | mriedem | so we're not rushing toward thursday | |
| 23:13:55 | Kevin_Zheng | Cool | |
| 23:14:11 | bauzas | dansmith: wrt grenade, how can we make sure that we don't run a placement API in the compute-only for the multinode job ? | |
| 23:14:14 | mriedem | stevemar: this is like earth-shattering issue #4 today so i've lost my sense of humor about it :) | |
| 23:14:21 | Kevin_Zheng | But Chinese New Year comes this week | |
| 23:14:30 | stevemar | mriedem: samesies | |
| 23:14:32 | dansmith | bauzas: by not starting one in the subnode? | |
| 23:14:38 | mriedem | Kevin_Zheng: i think artom is planning to work on it | |
| 23:14:44 | Kevin_Zheng | Ok | |
| 23:14:57 | dansmith | bauzas: the subnode only has ENABLED_SERVICES='n-cpu' or something | |
| 23:15:08 | bauzas | dansmith: yeah, but since I'm updating from-newton, am I sure it's not for the subnode? | |
| 23:15:18 | dansmith | yes | |
| 23:15:41 | bauzas | dansmith: okay, but I'd still want to have the subnode running placement_compute_only | |
| 23:15:49 | dansmith | bauzas: if that was a problem, all the db creation stuff above your code would run on the subnode too | |
| 23:16:51 | andreykurilin | bauzas mriedem: can you look at https://review.openstack.org/#/c/424256/ ? neutron job stuck, but all others passed. | |