Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-02-11
17:56:08 dansmith or log.warn instead of EXPLODE
17:58:15 lyarwood dansmith: https://github.com/openstack/nova/blob/fec44e5d38baa0232bf41367303b82dc332eb512/nova/compute/manager.py#L7778-L7790 looks like we try to log at DEBUG in that case but didn't in this instance
17:58:43 lyarwood oh because it's looking at the exception and not checking if the instance is around still
18:00:46 dansmith yeah, so it probably does that right if we triggered the NotFound as a result of pulling up info on the instance,
18:01:04 dansmith but if we failed because its been nuked, we should refresh our world view before we decide who to wake up
18:01:50 dansmith although it's logging a trace, but I don't see it passing the exc_info there
18:03:48 lyarwood need to run and help put a baby to bed, I'll try and finish writing this up before I call it for the day
18:11:55 openstackgerrit Merged openstack/python-novaclient master: Uncap PrettyTable https://review.opendev.org/c/openstack/python-novaclient/+/775143
18:12:05 openstackgerrit Merged openstack/python-novaclient master: requirements: Remove simplejson https://review.opendev.org/c/openstack/python-novaclient/+/775144
20:34:30 sean-k-mooney lyarwood: can you take a look at https://review.opendev.org/c/openstack/nova/+/759522 and https://review.opendev.org/c/openstack/nova/+/759151
20:35:09 sean-k-mooney elod: if you could take a look too that would be great that has to go back to train
20:35:48 sean-k-mooney victoria is merged so ussuri is up next
20:36:19 sean-k-mooney there are a few people askinf for this on the bug https://bugs.launchpad.net/nova/+bug/1888395
20:36:22 openstack Launchpad bug 1888395 in OpenStack Compute (nova) ussuri "live migration of a vm using the single port binding work flow is broken in train as a result of the introduction of sriov live migration" [High,In progress] - Assigned to Billy Olsen (billy-olsen)
20:55:26 openstackgerrit Merged openstack/nova master: db: Compact Stein database migrations https://review.opendev.org/c/openstack/nova/+/759090
20:58:28 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: Fix l-c job and move to latest hacking 4.0.0 https://review.opendev.org/c/openstack/placement/+/775214
20:58:37 elod sean-k-mooney: sure, added to my TODOs, will look into it tomorrow
23:01:40 openstackgerrit Dan Smith proposed openstack/nova master: Make a couple test jobs run async devstack https://review.opendev.org/c/openstack/nova/+/775293
23:22:30 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: Fix l-c job and move to latest hacking 4.0.0 https://review.opendev.org/c/openstack/placement/+/775214
#openstack-nova - 2021-02-12
01:03:48 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: DNM: testing https://review.opendev.org/c/openstack/placement/+/775303
01:24:55 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: DNM: testing https://review.opendev.org/c/openstack/placement/+/775303
01:37:32 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: Fix l-c job and move to latest hacking 4.0.0 https://review.opendev.org/c/openstack/placement/+/775214
02:34:41 openstackgerrit melanie witt proposed openstack/nova master: Add regression test for bug 1914777 https://review.opendev.org/c/openstack/nova/+/775307
02:34:42 openstack bug 1914777 in OpenStack Compute (nova) "Possible race condition between n-cpu and n-api when deleting a building instance" [High,In progress] https://launchpad.net/bugs/1914777 - Assigned to melanie witt (melwitt)
02:34:42 openstackgerrit melanie witt proposed openstack/nova master: Handle instance = None in _local_delete_cleanup https://review.opendev.org/c/openstack/nova/+/775308
02:34:42 openstackgerrit melanie witt proposed openstack/nova master: WIP Differentiate between InstanceNotFound and ConstraintNotMet https://review.opendev.org/c/openstack/nova/+/775309
02:52:19 gmann dansmith: lyarwood elod gibi placement stable/victoria is green now, added releasenote also for backporting the pep8 changes- https://review.opendev.org/c/openstack/placement/+/775214
02:52:56 openstackgerrit Ghanshyam proposed openstack/placement stable/victoria: Update TOX_CONSTRAINTS_FILE for stable/victoria https://review.opendev.org/c/openstack/placement/+/754671
10:52:06 bauzas gibi: stephenfin: while I'm on things I call unnecessary but asked, I tho wonder how to say "it's an UUID parameter" and not just "it's a string" ?
10:52:31 bauzas context : https://review.opendev.org/c/openstack/nova/+/773976/5/nova/network/neutron.py@3491 for the neutron_id
10:54:13 gibi bauzas: network_id is a uuid printed to as string. If it would be an instance of uuid.UUID from the standard lib then you can say network_id: uuid.UUID
10:54:48 gibi bauzas: think about it as C++ type. if there you have a string that contains a uuid you still use the type string for it
10:54:51 bauzas meh
10:55:30 gibi bauzas: it is nova's decision to pass around string instead of uuid.UUID objects internallyt
10:55:43 bauzas I love python for some stuff, and the fact that we wouldn't need to tell 'heh, it's a string'
10:56:30 bauzas https://realpython.com/lessons/duck-typing/
10:57:12 bauzas if it looks like a UUID, and if you use it for a UUID, then it's a UUID
10:58:14 gibi what we pass around is a string representation of an UUID . If some code would threat it as uuid.UUID and call .fields on it, the code will fail with AttributeError
10:58:43 gibi python still enforce types :)
10:59:48 bauzas that's the reason why we have code reviews and docstrings... but the ship sailed eitherway
11:00:31 bauzas I'm just a bit sad we hadn't discussed it in a PTG session
11:00:32 gibi and we still have code review and doc string in the future, mypy just help with that review by automating some part of it
11:00:44 bauzas before telling to use mypy
11:00:49 gibi bauzas: we discussed it in some point and was no consensus
11:01:02 gibi so as a nova project we don't tell you that you have to use mypy
11:01:11 gibi it is stephenfin who asks it
11:01:14 bauzas well, here I'm asked to do it :)
11:01:50 gibi can I forbid stephenfin to ask such thing? No I don't think so
11:02:12 gibi what I can say that it is not mandatory to add mypy type hint to your patch
11:02:22 gibi as we never decided to make it mandatory
11:02:23 bauzas do we also want to use type hints for private methods ?
11:03:59 gibi in my eyes the benefit of mypy (if any) applies equally on private and public too
11:04:09 stephenfin bauzas: You're misstating what I asked. I suggested adding type hints, but I was very clear that they weren't mandatory
11:04:28 bauzas anyway, I'm adding them
11:04:37 stephenfin Please don't say I'm forcing you into anything wrt mypy because it's not true
11:04:57 bauzas ack
11:05:35 stephenfin "Code itself is fine, but I do question the wisdom of throwing these into the utils modules and I don't like reinventing the wheel and doing something neutronclient appears to support. The -1 is for the latter. I'd also like to see type hints and have provided them for you, but I can't force than on you of course 😄"
11:05:45 stephenfin from https://review.opendev.org/c/openstack/nova/+/773976/5
11:06:30 bauzas oki, then I'm trying to use the neutron client method
11:06:32 stephenfin And we did discuss this at a PTG and as gibi said, there was no consensus. We said we could add them if we wanted but they weren't mandatory
11:06:47 bauzas which is a good call
11:06:53 stephenfin given the value had yet to be proven
11:06:58 stephenfin I can find the notes if you'd like
11:07:17 stephenfin but tbc, it's also not true to say this wasn't discussed. It absolutely was
11:08:38 stephenfin wrt changing things from manual calls to using the neutronclient, this patch might be helpful https://review.opendev.org/c/openstack/nova/+/706295
11:08:53 stephenfin as a blueprint, I mean
11:09:08 stephenfin though I suspect your changes won't need to be as big since it's not baked in yet :)
11:11:10 bauzas I already used the client method for getting subnets, so it's indeed quick
11:34:06 stephenfin gibi, bauzas: Could you take a look at this requirements patch today? https://review.opendev.org/c/openstack/nova/+/775142
11:34:26 bauzas I can try
11:34:36 stephenfin We're trying to uncap a dependency (PrettyTable) and need to do that across multiple projects
11:36:48 bauzas gibi: stephenfin, others: I just spotted the fact that most of our prefilters don't raise exceptions but one
11:37:13 bauzas do we have kind of a consensus about a prefilter error behaviour ?
11:37:38 bauzas if so, I should catch the exceptions I raise in the subsequent modules
11:37:59 stephenfin hmm, I've no idea. Depends on what happens with those exceptions. Do we capture them or would it result in a HTTP 5xx?
11:38:02 bauzas or raising them nested into a RequestFilter exc
11:38:17 bauzas the caller is a prefiler, so that's async
11:38:22 bauzas prefilter*
11:38:48 bauzas the scheduling phase should set an ERROR state, that's it
11:38:58 bauzas exactly like a NoValidHosts
11:39:09 bauzas hence the questionj
11:39:33 bauzas I'm OK with nesting any exception within a RequestFilter exception so we make consistent behaviour
11:39:42 gibi bauzas: that sounds like a good behavior. Set the instance to ERROR and let the create instance action store the exception
11:40:04 stephenfin Ah yes, I see what you mean
11:40:06 bauzas ok then stephenfin's point about better exception handling is legit
11:40:19 stephenfin the other filters just log and return False
11:41:08 bauzas right but there is the require_tenant_aggregate() prefilter which does this too
11:41:15 bauzas hence my question
11:41:26 bauzas looks like we hadn't thought about this
11:41:35 bauzas not saying the other filters don't raise exceptions
11:41:57 bauzas their own calls could fail too, that's just they don't handle them straight
11:42:07 gibi explicit failure is better than simply skipping the prefilter behavior and move forward with the scheduliung
11:42:36 stephenfin Yeah, we don't seem to do anything with the return values
11:42:39 stephenfin outside of tests
11:42:59 stephenfin process_reqspec simply calls the filter - it doesn't do anything with the return value
11:43:14 stephenfin so raising does seem like a sensible thing to do, if it's something we can't recover from
11:43:28 stephenfin and we should probably do the same for the other filters
11:44:46 bauzas gibi: a filter generally can fail without blocking
11:45:04 bauzas we don't hard stop on a scheduler filter failure iirc
11:45:35 bauzas honestly, I don't know what to say

Earlier   Later