| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-10 | |||
| 13:41:01 | bauzas | sdague: anyway, my question still remains wrt grenade | |
| 13:41:13 | bauzas | sdague: do we need to s// something when we upgrade the node ? | |
| 13:41:23 | sdague | bauzas: grenade should be fine as long as those things didn't get deleted | |
| 13:41:25 | bauzas | in terms of nova.conf -ism | |
| 13:41:36 | sdague | it will use the ocata config in pike | |
| 13:41:46 | bauzas | yeah, my thoughts | |
| 13:41:48 | bauzas | not super then | |
| 13:42:13 | bauzas | we don't remove those filters because CachingScheduler still requires them | |
| 13:42:28 | bauzas | but in theory, you don't need to run those filters since Ocata | |
| 13:42:40 | sdague | right as long as there is normal deprecation cycles you don't need to do anything in grenade | |
| 13:42:51 | bauzas | that's just we wanted to be gentle in Ocata and not ask operators to change their conf when upgrading from Newton | |
| 13:42:59 | sdague | as long as you remove the deprecated setting of things in devstack in the release where you deprecate them | |
| 13:43:08 | bauzas | okay, I think it's reasonable then | |
| 13:43:10 | sdague | it just naturally rolls through it all | |
| 13:43:17 | bauzas | k | |
| 13:44:33 | bauzas | mriedem: looping over https://etherpad.openstack.org/p/nova-pike-release-candidate-todo | |
| 13:44:48 | sdague | mriedem: I think putting the entire recovery path inside the API ref for forced-down is not idea - https://review.openstack.org/#/c/492533/1/api-ref/source/os-services.inc | |
| 13:45:02 | bauzas | mriedem: AFAICT, the top prio for reviewing is then https://review.openstack.org/#/c/491012/ ? | |
| 13:45:06 | sdague | there probably needs to be a specific HA recovery document for the whole thing | |
| 13:45:15 | sdague | this is just "don't use this unless you really are sure" | |
| 13:45:34 | bauzas | :p | |
| 13:45:34 | bauzas | it's a force thing | |
| 13:45:51 | bauzas | 'force' is meaningful in Linux terminology :) | |
| 13:46:08 | mriedem | bauzas: yes | |
| 13:46:15 | bauzas | don't expect good things to happen magically if you use a force flag | |
| 13:46:33 | mriedem | sdague: i didn't say to put the entire recovery path in there... | |
| 13:46:41 | mriedem | just 'never come back' is not really correct, | |
| 13:46:50 | mriedem | i think maybe you mean 'never come back in it's current state' | |
| 13:46:51 | mriedem | or something | |
| 13:47:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Resource tracker compatibility with Ocata and Pike https://review.openstack.org/491012 | |
| 13:47:35 | mriedem | cdent: jaypipes: ^ fixed the functional test failure | |
| 13:47:38 | bauzas | you can "force enable" back | |
| 13:47:53 | cdent | mriedem: roger | |
| 13:47:59 | bauzas | but honestly, that forced-down thing is just a hack because of our SG API | |
| 13:48:15 | bauzas | I'm not sure we should be explicit here | |
| 13:51:15 | openstackgerrit | Ed Leafe proposed openstack/nova master: Handle addition of new nodes/instances in ironic flavor migration https://review.openstack.org/487954 | |
| 13:53:31 | openstackgerrit | Sean Dague proposed openstack/nova master: Update api-guide and api-ref to be clear about forced-down https://review.openstack.org/492533 | |
| 13:59:18 | mriedem | nova meeting in 1 minute | |
| 13:59:21 | bauzas | sdague: tried to help with defining why we have a force-down flag https://review.openstack.org/#/c/492533/2 | |
| 13:59:35 | bauzas | seeing that being used by operators scares me | |
| 13:59:42 | bauzas | it was never the intent | |
| 14:00:04 | bauzas | and like the bug report mentions, we have the disabling thing | |
| 14:00:10 | ioggstream | hi@all | |
| 14:00:14 | sdague | bauzas: right, so I think we have to be careful about putting too much into api-ref because it's supposed to be a reference | |
| 14:00:25 | sdague | we probably need an HA guide here that explains the whole thing | |
| 14:00:42 | ioggstream | about OS:: Nova::ServerGroup policy, how will anti-affinity (default) policy work if I have more vms than compute nodes? | |
| 14:00:52 | bauzas | sdague: well the problem is that our API can be consumed by both end-users and automation tools | |
| 14:01:13 | sdague | bauzas: I'll be honest, I'm not going to spend all day redrafting this docs patch. I think what I have up there is an improvement, if folks want to take it over and write it instead, I'm good with that | |
| 14:01:13 | mriedem | bauzas: the api-ref could link to a more detailed guide | |
| 14:01:14 | bauzas | sdague: to be frank, I do wonder if we should just cut that flag from the nova CLI | |
| 14:01:20 | mriedem | sdague: there is, or was, a maintenance guide | |
| 14:01:23 | bauzas | sdague: okay, I'll push a rev then | |
| 14:01:25 | mriedem | planned and unplanned | |
| 14:01:29 | sdague | mriedem: sure | |
| 14:01:40 | mriedem | i'd put it in there, but it might have been in the now defunct ops guide | |
| 14:01:46 | bauzas | mriedem: sdague: what are you thinking of just removing that method from our nova CLI ? | |
| 14:01:46 | mriedem | would have to dig | |
| 14:01:56 | bauzas | since only scripts should call it | |
| 14:02:00 | mriedem | meeting time | |
| 14:02:13 | sdague | bauzas: people might have manually downed their nodes as well | |
| 14:02:21 | sdague | bauzas: I think it's fine to be in the nova cli | |
| 14:02:30 | sdague | that's an admin tool | |
| 14:02:38 | sdague | they just need to realize what they are doing | |
| 14:02:43 | bauzas | agreed | |
| 14:02:58 | bauzas | sdague: I'll try a new rev | |
| 14:03:54 | sdague | bauzas: I think your assumption that no one should ever call this manually is wrong | |
| 14:03:58 | jianghuaw | jianghua | |
| 14:04:02 | sdague | the important point is they met preconditions | |
| 14:04:06 | sdague | the service is fenced | |
| 14:04:12 | sdague | we don't care how they met those | |
| 14:04:19 | sdague | but they are expressing to nova that they did | |
| 14:04:24 | bauzas | sdague: we have a service group API for that | |
| 14:04:29 | sdague | it might have been a tool | |
| 14:05:01 | bauzas | sdague: the only usecase I heard of was that the SG API was lacking of functionality and either lagging or totally missing the host being down | |
| 14:05:21 | bauzas | sdague: so, eventually, the SG API would meet those preconds | |
| 14:05:49 | bauzas | that's just because Nova isn't intented to be a Nagios system, we allow other tools to fence the host for us | |
| 14:05:50 | sdague | bauzas: that's not good enough if I need it now | |
| 14:06:03 | bauzas | from our behalf, I mean | |
| 14:06:24 | dtantsur | edleafe: hi! my last attempt to use resource classes in the CI ended up with RamFilter removing the nodes | |
| 14:06:58 | dtantsur | I wonder if I'm missing something.. I thought I disabled requesting RAM/disk/CPU | |
| 14:07:50 | bauzas | dtantsur: Nova by default was still running those filters until yesterday | |
| 14:08:03 | dtantsur | oh | |
| 14:08:18 | edleafe | dtantsur: probably the request was for 1 of the resource class, along with the disk/ram/cpu in the flavor | |
| 14:08:36 | dtantsur | edleafe: I assume I'm removing the request for disk/ram/cpu from flavor | |
| 14:08:39 | dtantsur | lemme get a link | |
| 14:09:06 | dtantsur | edleafe: https://review.openstack.org/#/c/476968/13/devstack/lib/ironic@1889 | |
| 14:09:41 | dtantsur | bauzas: this one, right? https://github.com/openstack/nova/commit/2fe96819c24eff5a9493a6559f3e8d5b4624a8c9 | |
| 14:09:42 | edleafe | dtantsur: ok, then that should work | |
| 14:09:58 | bauzas | dtantsur: correct | |
| 14:10:10 | dtantsur | thanks, I'll see how it looks nowadays | |
| 14:10:10 | edleafe | dtantsur: do you have the call to placement anywhere in logs? | |
| 14:10:14 | bauzas | dtantsur: oh wait | |
| 14:10:23 | bauzas | dtantsur: Ironic is special-case IIRC | |
| 14:10:32 | bauzas | dtantsur: you folks have your own czay filters list :) | |
| 14:10:36 | bauzas | crazy | |
| 14:10:43 | bauzas | in nova | |
| 14:10:47 | dtantsur | yeah, we did change something around it.. lemme check | |
| 14:11:11 | dtantsur | https://review.openstack.org/#/c/490459/ | |
| 14:12:07 | dtantsur | this is why I'm seeing the RamFilter, not the ExactRamFilter | |
| 14:12:20 | dtantsur | oh, and by the way. should we kill Exact filters with fire | |