| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-25 | |||
| 18:35:02 | mriedem | i'm having a hard time parsing that | |
| 18:35:04 | mriedem | failing in the gate? | |
| 18:35:21 | mriedem | and exclude rule on a job in project-config? | |
| 18:35:32 | smcginnis | sdague: I had made changes there, but that was a few weeks back now. | |
| 18:35:53 | smcginnis | sdague: AFAIK, all grenade jobs should have been blocked on stable/newton. | |
| 18:36:16 | sdague | smcginnis: I have no idea the last time someone tried to get grenade changes on stable/newton through, it's not very often | |
| 18:36:33 | sdague | mriedem: yes, it's running a job it definitely should not be | |
| 18:36:42 | smcginnis | sdague: Now that mitaka is EOL, it shouldn't ever be done. | |
| 18:37:11 | sdague | smcginnis: agreed | |
| 18:37:45 | sdague | mriedem: anyway, the backport fixes for the cell naming change jobs aren't going to work until the jobs are cleaned up on the gate | |
| 18:38:24 | mriedem | sigh, ok | |
| 18:38:29 | mriedem | let me coffee up first | |
| 18:39:04 | sdague | mriedem: https://www.youtube.com/watch?v=yysnM407rjE - power up | |
| 18:39:39 | savvas | mriedem: your suggested host space reservation doesn't do much for me. If I enable that, instance creation fails if I select boot from image in new volume. If I set my root disk size to 0 to bypass that, the whole point is gone as heat for example deploys a simple instance with block device again and ignores the reserved host space | |
| 18:39:56 | savvas | any other thoughts? | |
| 18:44:08 | mriedem | savvas: no immediate thoughts, you could try the #openstack-operators channel to see if others are dealing with this, | |
| 18:44:27 | mriedem | or ask med_, cburgess or mgagne, our resident nova channel friendly ops, about their opinions | |
| 18:44:50 | cburgess | Do what now? | |
| 18:44:57 | mriedem | help someone | |
| 18:44:58 | mriedem | c'mon chet | |
| 18:45:14 | cburgess | Oh OK.. I gues I can try... | |
| 18:45:21 | savvas | :--) | |
| 18:45:34 | cburgess | Whats the question/issue/suggestion? | |
| 18:45:39 | savvas | Right | |
| 18:45:50 | savvas | well I am trying to avoid instances being created on local storage | |
| 18:46:11 | cburgess | Oh that one... | |
| 18:46:15 | savvas | our nodes have a 20G root partition and that should be utilized for system processes only. So apart from the fact that nova doesn't seem to recognize cinder storage as usable space | |
| 18:46:25 | savvas | it also simply refuses not to try and make local block devices | |
| 18:46:54 | cburgess | Define refuse? If you launch an instance with boot from volume you shouldn't see a local device. | |
| 18:49:16 | mriedem | cburgess: the problem is the same as usual, in that you can't force the user to do boot from volume | |
| 18:49:27 | mriedem | unless you automagic something in the api code to do that, as some have done | |
| 18:50:02 | cburgess | Correct | |
| 18:50:30 | cburgess | Hence the point of that whole sessions in bonston. I still need to write that spec... | |
| 18:50:34 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/468089 | |
| 18:50:37 | cburgess | You simply can't block an local instance launch in nova unless you write a custom patch. | |
| 18:51:00 | savvas | cburgess: for creating a new instance it works just fine via horizon but for example if I launch a simple stack it doesn't force me to select a boot volume or anything | |
| 18:51:03 | savvas | and it creates a local block device | |
| 18:52:15 | cburgess | savvas Yup.. its a limitation in openstack. Its something thats been of ongoing discussion for the past few cycles and we are working on a spec for.. queens (mriedem??) to try and address this limitation. | |
| 18:52:26 | mriedem | queens yes | |
| 18:52:58 | savvas | ye I read about that | |
| 18:53:08 | savvas | was hoping people may have found a workaround to deal with this problem though | |
| 18:53:44 | savvas | but seems like there aren't any (yet) | |
| 18:53:57 | mriedem | not outside of patching the api | |
| 18:54:01 | mriedem | which i'd advise against | |
| 18:54:25 | cburgess | Even I advise against patching the API now, even though I've been known to do it. | |
| 18:54:58 | cburgess | But yes... its a known issue and hopefully we can have a good discussion about it at the upcoming PTG and agree on a spec for the queens cycle to address this issue. | |
| 18:55:41 | mriedem | chet is in nova-patchers-anonymous | |
| 18:56:08 | cburgess | mriedem Meh.. I got tired of dansmith accusing me of doing awful things with his code. :P | |
| 18:56:21 | mriedem | i know i don't get tired of that | |
| 18:56:38 | dansmith | mriedem kinda likes the pain you know | |
| 18:56:47 | mriedem | i meant you hurting chet | |
| 18:56:47 | mriedem | not me | |
| 18:56:56 | dansmith | heh | |
| 19:02:03 | cfriesen | would there be value in having "nova-manage db online_data_migrations" return a value indicating whether or not it needs to be called again? (when specifying --max-count) | |
| 19:02:45 | cfriesen | seems like currently a calling script needs to parse the output | |
| 19:03:21 | melwitt | I thought it already returns 1 if there's more to do and 0 when there's no more to do. or are you saying it returns 0 when you use --max-count and there is still more to do? | |
| 19:05:01 | cfriesen | melwitt: it currently has "return ran and 1 or 0" and I think an exception in one of the migration routines will give a 0 | |
| 19:05:15 | cfriesen | I want success/partial-success/error return codes | |
| 19:05:17 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Handle conflict from neutron when addFloatingIP fails https://review.openstack.org/468136 | |
| 19:05:29 | mriedem | cfriesen: sounds like a bug | |
| 19:06:30 | cfriesen | mriedem: what should it return in the error case? 127 like we have if you specify a nonpositive integer for max-count? or something else | |
| 19:06:55 | mriedem | idk, sometimes we return 2 for things | |
| 19:07:00 | mriedem | it's not really defined | |
| 19:07:35 | sdague | cfriesen: so the problem with that is it means you have to turn off set -e in scripts | |
| 19:07:56 | mriedem | sdague: that's what we do in grenade for the nova-status upgrade check | |
| 19:08:06 | sdague | mriedem: yeh, which is a little suck | |
| 19:08:33 | mriedem | well maybe we don't https://github.com/openstack-dev/grenade/blob/master/projects/60_nova/upgrade.sh#L97 | |
| 19:08:38 | mriedem | i must be thinking of something in d-g | |
| 19:08:56 | mriedem | ah we use || | |
| 19:08:59 | sdague | yeh | |
| 19:09:04 | sdague | which is just mask the world | |
| 19:09:23 | cfriesen | sdague: you mean distinguishing between success-and-done vs success-and-need-to-call-again? | |
| 19:10:15 | sdague | yeh, but more importantly best practice for shell scripts is set -e, and things are only supposed to be non zero on failure | |
| 19:11:11 | cfriesen | sdague: so you're saying the caller must always parse the output to determine if it's actually done? | |
| 19:11:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Handle conflict from neutron when addFloatingIP fails https://review.openstack.org/468136 | |
| 19:11:19 | cfriesen | because that seems kind of lame | |
| 19:11:55 | sdague | cfriesen: you're just calling this in a loop from another program right? | |
| 19:12:32 | cfriesen | sdague: no guarantee it'll be in a loop...what if someone wanted to process X migrations each maintenance window | |
| 19:12:45 | sdague | ok | |
| 19:13:19 | mriedem | sdague: i think that grenade-dsvm-neutron-multinode-ubuntu-trusty failure in stable/newton wasn't what you thought it was | |
| 19:13:23 | mriedem | stable/mitaka isn't deleted yet | |
| 19:13:30 | mriedem | plus this job passed yesterday | |
| 19:13:33 | mriedem | it's an ssh issue with ansible | |
| 19:13:40 | mriedem | http://logs.openstack.org/50/420750/2/gate/gate-grenade-dsvm-neutron-multinode-ubuntu-trusty/7fd8a27/logs/devstack-gate-setup-host.txt | |
| 19:14:13 | sdague | mriedem: how is stable/mitaka still a thing? | |
| 19:14:24 | mriedem | sdague: rax laid off tonyb | |
| 19:14:38 | mriedem | if i had twitter, i'd tweet it, that if you want LTS in openstack, don't hire tonyb | |
| 19:14:52 | sdague | heh | |
| 19:19:57 | mriedem | huh, this is weird http://logs.openstack.org/74/467674/2/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/414bb96/logs/screen-n-api.txt.gz?level=TRACE#_May_25_02_46_02_139728 | |
| 19:20:09 | mriedem | if you run tempest with cinder.cross_az_attach=False, | |
| 19:20:15 | mriedem | 2 bfv tests fail, | |
| 19:20:25 | mriedem | but they are failing on some weird instance.host lazy load issue in the api | |
| 19:20:27 | mriedem | which i wouldn't expect | |
| 19:20:50 | mriedem | host wouldn't be set at this point | |
| 19:20:55 | mriedem | but i'd think it's None | |
| 19:22:47 | mriedem | hmm, or is it the BuildRequest object? | |
| 19:23:04 | mriedem | dansmith: ^ methinks that's what is blowing up | |
| 19:23:33 | mriedem | we create an Instance object w/o a host field set, and serialize that into the BuildRequest | |
| 19:23:50 | dansmith | well, no host at that point | |
| 19:23:55 | mriedem | right, | |