Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-04
14:52:30 jaypipes dansmith: ah, sorry, I missed that. :)
14:52:39 bauzas cdent: jaypipes: dansmithwhat needs to move ?
14:52:56 bauzas I'm fine with leaving ORM code as it is
14:53:09 bauzas if that's the point
14:58:04 jaypipes bauzas: the discussion is not around the ORM code but rather there is a discussion about how long the code comment with SQL is on that function.
14:58:20 bauzas well
14:58:22 bauzas okay
14:58:29 bauzas not sure it's a problme
14:58:54 bauzas when I wrote the long docstring, I also fixed the comment when I changed the calls
14:59:19 bauzas that's why I'd like to at least pdb your change for verifying the SQL query
14:59:39 mriedem won't we want the big ass sql comment for the complicated orm code?
14:59:51 mriedem as dansmith said earlier in the week, this is all fine but i won't be debugging it :)
14:59:52 bauzas it's just part of a reviewer duty /me shrugs
15:00:00 dansmith there is no question about ORM stuff AT ALL
15:00:12 dansmith it's about where to put these comments about the sql
15:00:22 bauzas tbc, I'm fine with the current situation
15:00:34 bauzas having large docstrings is good wit hme
15:00:47 bauzas anyway, /me needs to take my daughter \o
15:05:46 nammo jaypipes: dansmith Hi guys! Can you please help me with removing a filter?
15:05:54 peter-hamilton mriedem: just wanted to put this on your radar - https://review.openstack.org/#/c/357202/
15:06:07 nammo I removed it from enabled_filters, restarted n-sch but still it exists
15:06:11 jaypipes nammo: give us 15-25 minutes. we're currently on a call.
15:06:21 nammo Oh ok sorry.
15:06:26 jaypipes no worries :)
15:06:45 peter-hamilton mriedem: danefichter and i want more nova eyes on it before we go any further
15:10:02 mtreinish johnthetubaguy: what were you looking for on: https://review.openstack.org/#/c/459470 ? The comments are a bit vague on what's missing (its more of a discussion)
15:10:47 johnthetubaguy mtreinish: good question, I have a feeling I got distracted and moved to a different review
15:14:52 johnthetubaguy mtreinish: you know, the only nit was that config that I think we can just remove, but I have a feeling mriedem wasn't 100% sure about the remove, lets worry about that in a follow up patch
15:18:18 mtreinish johnthetubaguy: yeah, that's why I added the additional information to the help instead of deleting it
15:28:17 openstackgerrit Matthew Treinish proposed openstack/python-novaclient master: Remove the deprecated certs interfaces https://review.openstack.org/462598
15:28:23 mtreinish mriedem: ^^^
15:28:31 mtreinish I'll work on the cloudpipe client deprecation later
15:35:54 jaypipes nammo: so, which filter did you try removing?
15:41:12 openstackgerrit Roman Podoliaka proposed openstack/nova master: service: use restart_method='mutate' for all services https://review.openstack.org/462600
15:49:00 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Add Neutron port capabilities to devspec in request https://review.openstack.org/451777
15:49:00 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257
15:52:44 dansmith edleafe: think you could address some of the feedback that has been sitting on these patches for a few days? https://review.openstack.org/#/c/460177
15:52:44 mriedem peter-hamilton: it's going to be hard today, lots of meetings
15:52:53 mriedem mtreinish: you can't remove the nova cert CLI stuff until queens
15:53:07 mriedem mtreinish: we need to deprecate the cloudpipe API bindings and CLIs in novaclient like i did for the os-hosts stuff though
15:53:28 mriedem johnthetubaguy: oh the vpn_ip?
15:53:29 dansmith edleafe: I haven't seen any replies from bauzas so I assume he's busy with other stuff
15:53:30 mriedem yeah i wasn't sure
15:54:18 johnthetubaguy mriedem: yeah, I figured mtreinish updated the description, we can always rip it out later if that turns out to be the right call.
15:55:10 edleafe dansmith: I know he was on holiday earlier this week
15:55:16 dansmith edleafe: yeah
15:55:28 edleafe bauzas: still around?
15:56:15 mriedem he's picking up his daugher from school i think
15:56:20 edleafe dansmith: I mean, I'd be happy to work on this, but didn't want to step on bauzas's toes
15:56:32 edleafe mriedem: what, are they walking? :)
15:56:52 dansmith edleafe: yeah, it's been days though so I figured he's just busy, but cool to check
15:56:54 mriedem edleafe: probably an old fashioned bike would be my guess
15:57:03 mriedem with cigs and croissants
15:57:13 dansmith but if you're willing I would think some of it could be shared at least
15:57:43 edleafe dansmith: that's fine with me
15:58:15 edleafe dansmith: I'll start on it after the api-wg meeting, unless bauzas speaks up first
15:58:38 nammo jaypipes: RetryFilter
15:58:43 dansmith edleafe: cool, thanks
15:59:01 jaypipes nammo: that cannot be removed, AFAIK.
15:59:21 edleafe nammo: why would you want to remove that?
15:59:31 melwitt it used to be able to be removed
15:59:55 nammo jaypipes: edleafe Any consecutive request to boot are failing due to RetryFilter
16:00:52 edleafe nammo: RetryFilter only comes into play when a request to build on a host has already failed
16:01:14 jaypipes melwitt: really? TIL...
16:01:24 nammo edleafe: I deleted that VM and tried to boot again
16:01:56 melwitt we had removed it because of the integration with other systems we had done, vast majority of failures were deterministic and retrying a different compute wasn't going to help and would waste time, so we didn't have RetryFilter in our list and set scheduler_max_attempts = 1
16:02:47 nammo melwitt: Is it intended for me?
16:03:49 melwitt nammo: no. just trivia on one reason someone would remove it
16:04:09 dansmith yay for more reasons to not do scheduler retries
16:04:40 nammo melwitt: scheduler_max_attempts This should be under default section?
16:05:35 mtreinish mriedem: oh I thought the deprecation timer started long enough ago. Well I'll just wip it to block the merge until after the release
16:06:25 melwitt nammo: these days it's [scheduler]/max_attempts. but the fact that you see "Previously tried hosts" in your log still means the RetryFilter is still there, which doesn't make sense if you removed it from enabled_filters and restarted n-sch
16:07:08 nammo melwitt: So is there any other solution to launch VM on the same host?
16:07:30 nammo melwitt: host is up and available
16:08:34 melwitt nammo: what are you trying to do? the RetryFilter just retries on a different host if the selected host fails. you're trying to get multiple VMs to land on the same host?
16:09:26 nammo melwitt: I just have one node that satifies my VM spec
16:10:03 nammo melwitt: I will see the sched logs to see why RetryFilter failed
16:10:10 melwitt that's usually what you want with a vanilla nova deployment, is to have retries. because if the host the scheduler selected fails to spawn the instance, it's usually best to try a different host next
16:10:16 mriedem mtreinish: it's going to be sitting quite awhile if you do that, butok
16:10:30 nammo melwitt: Agree
16:10:48 nammo But for me it just one host that my VM can launch on
16:11:10 melwitt nammo: I see. you should check the sched logs to determine why the first attempt failed. usually means not enough resources or extra_specs didn't match or something like that. if you turn on debug log level for n-sch you will see all the detail of which filters it tried and which one failed
16:21:52 nammo melwitt: http://paste.openstack.org/show/608889/
16:25:26 nammo melwitt: I see no error here
16:25:37 nammo melwitt: Can you please help?
16:26:10 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Debug race in delete-while-booting test https://review.openstack.org/461513
16:26:44 dansmith nammo: please see topic, this channel is for development
16:27:41 openstackgerrit Dan Smith proposed openstack/nova master: Move to proper target_cell calling convention https://review.openstack.org/458634
16:27:41 openstackgerrit Dan Smith proposed openstack/nova master: WIP: De-complicate some of the instance delete path https://review.openstack.org/458636
16:27:42 openstackgerrit Dan Smith proposed openstack/nova master: DNM: Canary test against multi-cell devstack https://review.openstack.org/458537
16:27:42 openstackgerrit Dan Smith proposed openstack/nova master: Make target_cell() yield a new context https://review.openstack.org/458635
16:28:25 nammo dansmith: I see. Thanks
16:28:44 dansmith jaypipes: is the reason that first test worked because of the trait?
16:29:20 melwitt nammo: to close the loop on this, agree there's no problem in n-sch and you need to check your n-cpu logs for why it failed to spawn the instance on the selected host
16:29:34 mriedem dansmith: your access has been...granted
16:29:38 dansmith mriedem: thanks
16:30:13 nammo melwitt: Thanks :)
16:42:22 mriedem bauzas: jaypipes: edleafe: you guys will likely want to see this https://review.openstack.org/#/c/394857/ since it has to do with overhead calculation and overrides in the RT and virt drivers
16:43:25 edleafe mriedem: just reading the commit message on that seems like it's a misunderstanding
16:44:35 mriedem i'm -1ing now

Earlier   Later