Earlier  
Posted Nick Remark
#openstack-nova - 2017-03-24
14:11:11 bauwser superdan: ah correct then
14:11:19 sdague the midwest water table being 1' below the surface and everything flat is quite a thing
14:11:23 superdan yeah
14:12:01 bauwser do you collect that into pipes, or do you spill the water in your garden ?
14:12:31 openstackgerrit Dan Smith proposed openstack/nova master: Remove legacy regeneration of RequestSpec in MigrationTask https://review.openstack.org/449640
14:12:36 superdan bauwser: mine goes into the storm drain
14:12:36 mriedem in my neighborhood, you wash it down the hill to the suckers at the bottom,
14:12:37 leakypipes bauwser: spill. :)
14:12:43 mriedem which unfortunately is me and another guy after me
14:12:46 bauwser interesting
14:13:08 bauwser because yet another regulation here is to defend us spillinh
14:13:16 mriedem supposed to be graded to drain into catch baskets that pump it into a pond further down the way
14:13:29 bauwser but rather collecting all the rain into pipes that are transfered to a specific collecting tank
14:13:36 bauwser that's a rain network
14:13:45 superdan bauwser: == storm drain
14:14:08 mriedem sometimes i hear you get a drunken frenchman drown in one of those and then he clogs up the pipes
14:14:15 superdan hah
14:14:28 mriedem stories to scare your kids,
14:14:33 mriedem like ringing doorbells
14:14:51 bauwser hah
14:17:40 bauwser superdan: what will be the name of your branch for cleaning up the migration task ? I'd ideally put it on the same gerrit topic
14:17:53 superdan bauwser: the bug? see above ^
14:18:08 bauwser superdan: cool
14:22:21 mdbooth mriedem: Thanks for sorting out the connect/disconnect thing
14:22:32 mdbooth ABCs don't do what we want though, unfortunately
14:22:52 mdbooth All an ABC does is ensure that subclasses implement abstract methods
14:23:02 mdbooth It doesn't actually do any checking of the signatures of those methods
14:23:09 mdbooth So... not all that useful tbh
14:23:14 mriedem mdbooth: why not? if you change the signature on an abstractmethod, and fail to adjust any classes that inherit from the ABC, they will blow up
14:23:31 mriedem mdbooth: i'm saying make the actual connect/disconnect_volume methods abstractmethods
14:23:38 mdbooth Case in point: RemoteFilesystemDriver is an ABC, and none of its subclasses have the correct signature for copy_file
14:24:00 mdbooth mriedem: Yeah, that's fine. But that will only assert that subclasses implement them
14:24:06 mdbooth There's no signature checking
14:24:12 mdbooth So it wouldn't catch this error
14:24:57 mdbooth Anyway, I agree that a test for this would be good, and probably useful in a few different places
14:25:15 mdbooth My first thought was to look for an existing tool, and I gave pylint a go
14:25:35 mdbooth However, pylint would be wildly impractical unfortunately.
14:25:51 mdbooth Getting a clean pylint job would be more work than getting python3 working, I think.
14:26:31 mdbooth So, I was considering writing some kind of introspection test for superclasses with abstract interfaces
14:26:38 mdbooth So you'd do something like:
14:27:13 mdbooth FSTest = SubclassCheckTest(SuperClassToTest)
14:27:22 mdbooth And it would generate you a test class
14:27:28 mriedem can't you scope pylint?
14:27:31 mriedem or whitelist?
14:27:40 mdbooth It all over the place
14:28:12 mdbooth I disabled almost everything, and I still had 95% false positives
14:30:41 mdbooth It did find RemoteFilesystemDriver.copy_file for me
14:31:00 mdbooth Although in this case, somebody has clearly updated all the implementations and forgotten to update the superclass
14:31:26 nkorabli Need to know your opinions, to start fixing it! :) Thanks in advance!
14:31:26 openstack Launchpad bug 1675791 in OpenStack Compute (nova) "Instance created by demo user(non-admin), shelved by admin and unshelved by demo user --> ends up in error state " [Undecided,New]
14:31:26 nkorabli Hi there! I noticed a multitenancy issue, here is a bug report: https://bugs.launchpad.net/nova/+bug/1675791
14:31:29 mriedem ok i see what you mean about abstractmethod not checking the signature
14:31:30 mriedem that sucks
14:31:33 mriedem i just tested locally
14:31:57 mdbooth mriedem: Anyway, how about the testclass generator?
14:32:01 mdbooth Overkill?
14:32:03 mriedem nkorabli: we already talked about this the other day
14:32:09 leakypipes np
14:32:15 mdbooth I think we could use it in a few places
14:32:16 nkorabli mriedem: Hi there!
14:32:29 mriedem nkorabli: the error during unshelve wasn't due to the tenant
14:32:38 mriedem it was most likely due to a failure to spawn the instance during unshelve
14:32:42 mriedem which put the instance into ERROR state
14:33:26 nkorabli mriedem: right, we did I just tested it with pure openstack (stable/newton) in devstack environment - and I see this error as well.
14:33:44 mriedem nkorabli: i've invalidated the bug,
14:33:51 mriedem nkorabli: have you checked the logs for errors during unshelve?
14:34:00 mriedem because there has to be an error in the logs if the instance is in error state
14:35:37 nkorabli I actually haven't found anything useful in the logs, but let my check one more time.
14:49:28 bauwser superdan: mriedem: quick question
14:49:39 bauwser superdan: mriedem: I'm about to clean up a bit of useless code in the conductor
14:50:25 bauwser superdan: mriedem: and I just notice that we do verify at every move operation if the affinity filters are present on the conductor side
14:51:03 bauwser superdan: mriedem: from my perspective, this is violating our policy to separate what's scheduler and what's conductor
14:51:38 bauwser if the operator disabled the affinity filters but had an instance that was previously booted by using an InstanceGroup, should we fail the move operation ?
14:51:45 bauwser my guts say no
14:51:59 bauwser johnthetubaguy: too ^
14:52:39 johnthetubaguy maybe we shouldn't allow those filters to be disabled?
14:52:55 johnthetubaguy its not 100% clear to me
14:53:05 bauwser well
14:53:13 bauwser disabling a filter is an operator thing
14:53:33 bauwser in case they use instance groups, then why they should disable that ?
14:53:45 bauwser it's terrible for users
14:53:53 johnthetubaguy now you might want to disable instance groups, but that seems like it should be discoverable
14:54:06 bauwser because for example, say Bob created an instance and asked for this group A
14:54:23 bauwser then Max (operator) disabled the filters without asking Bob
14:54:24 johnthetubaguy as you can see, I am just a bit confused by the question really
14:54:46 bauwser then, the current situation is that if Bob wants to migrate its instance, it will be getting an exception
14:54:53 bauwser gibi: p
14:55:10 johnthetubaguy bob by default can't migrate his instance, so its a bit of an odd one for me
14:55:32 johnthetubaguy we should really just respect the filters, given the preferences
14:55:50 bauwser johnthetubaguy: https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L162-L163
14:55:58 johnthetubaguy but seems like certain filters you shouldn't kill
14:56:11 openstackgerrit Vasyl Saienko proposed openstack/nova master: Implement interface attach/detach in ironic virt driver https://review.openstack.org/419975
14:56:23 bauwser johnthetubaguy: https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L311-L315
14:56:23 johnthetubaguy bauwser: thats just refreshing the list of instances in the group, at least I thought that was the intent there
14:56:41 bauwser johnthetubaguy: nope, not the instances
14:56:51 johnthetubaguy oh, I see
14:56:53 johnthetubaguy thats odd
14:57:05 bauwser johnthetubaguy: the InstanceGroup.hosts is set by the nodes having instances in there
14:57:11 johnthetubaguy do we fail to boot with the same things I guess?
14:57:16 bauwser johnthetubaguy: but it's a lazy-loadable field

Earlier   Later