Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-24
10:29:14 bauwser tojuvone: I think I get a better picture
10:29:26 tojuvone bauwser, ok :)
10:29:44 bauwser tojuvone: #1 you wanna signal some hosts for a maintenance and prevent instances booting on them
10:29:57 bauwser #2 you wanna test those hosts during that maintenance
10:30:16 bauwser #3 you wanna only schedule instances to maintened hosts
10:30:27 bauwser that's BIG
10:30:42 johnthetubaguy funny, thats whats in my patch I am writing
10:31:21 tojuvone bauwser, There is a lot since I have collected also operator input and put obvious possibilities this gives
10:31:51 bauwser tojuvone: I just think you're boiling the ocean with your spec
10:32:10 bauwser I'm not saying it's not valid concerns
10:32:47 tojuvone bauwser, It has not been a easy year since started to bring this to light :D
10:33:37 johnthetubaguy I kept meaning to write this us for Rackspace for the last few years, it just seems a bit different to what I expected
10:34:01 johnthetubaguy we have 80% of this already in tree
10:34:07 tojuvone bauwser, My own NFV requirement stared just the fact I need to know in application side
10:47:31 bauwser tojuvone: johnthetubaguy: FWIW, I just commented the above discussion in https://review.openstack.org/#/c/310510/19
10:47:45 bauwser just one short comment, hope tojuvone would accept that
10:48:41 bauwser tojuvone: basically, I want to explain to you that you need to scope more your spec, and identify what you want to achieve by that spec - you could possibly mention other usecases or problems, but please be explicit that those are not intended to be resolved by the spec
10:48:50 BobBall_ johnthetubaguy: Any chance you could re-review https://review.openstack.org/#/c/353862/ at some point?
10:49:28 bauwser tojuvone: the idea of preventing instances to be scheduled on hosts that aren't maintained yet is an idea I already saw
10:49:37 johnthetubaguy BobBall_: opened it in a tab, hope to get back to that
10:49:42 bauwser tojuvone: I just think the abstraction model isn't rich enough
10:49:45 BobBall_ +1 thanks :)
10:49:57 bauwser tojuvone: ie. you wanna schedule instances on hosts that are >= some siognal
10:50:19 bauwser ie. having some "capability" or "trait" :p
10:50:52 bauwser like, I could want to schedule instances on hosts that ship latest libvirt
10:51:12 tojuvone bauwser, Thanks, patch 19 was to catch everything and did exactly that for the cases
10:51:24 bauwser yeah, I understand
10:51:41 tojuvone totally agree, separate specs otherwsie
10:51:47 bauwser that looks like more you trying to log all the possible usecases, so I'd rather say a backlog spec would fit that
10:52:07 bauwser it looks like an epic to me
10:52:25 bauwser either way, I need to move on :)
10:52:39 tojuvone bauwser, thanks :)
10:53:44 tojuvone so I felt really need to have each corner to tell where it might lead. While not to do the whole implementation in same
10:53:56 mdbooth http://stackoverflow.com/questions/25183424/can-a-python-abstract-base-class-enforce-function-signatures
10:54:07 mdbooth Abstractmethods will not save us :(
10:54:37 mdbooth A compiler would be awesome
10:54:38 bauwser tojuvone: hence me thinking a backlog spec could describe the end goal
10:54:58 bauwser tojuvone: and you iterating over a couple of specs for that
10:55:32 cdent mdbooth's epitath: "A compiler would be awesome"
10:56:07 tojuvone bauwser, Is there a good example of this kind of specs
10:56:21 mdbooth I recalled from a previous investigation that abstractmethods are pretty useless
11:06:58 nkorabli Hi everyone! I’ve got a multitenancy related question:
11:06:58 nkorabli if you create a instance as demo user, shelve it as admin and then try to unshelve it as demo again - you won’t see any errors or warnings, but instance will end up with an ERROR state.
11:06:58 nkorabli So, what should be the right way for this scenario? What do you think?
11:08:36 nkorabli Just reproduced it with stable/newton in a devstack environment
11:25:30 kashyap mdbooth: This is ready for merge, no? -- https://review.openstack.org/#/c/383859/ ("libvirt: Fix races with nfs volume mount/umount ")
11:26:12 kashyap Needs another core reviewer to take a look at it
11:26:33 mdbooth kashyap: No, there was a bug in the parent commit
11:27:38 mdbooth kashyap: It was reverted :)
11:28:03 kashyap mdbooth: Mind throwing the URL? Gerrit's interface trips me up always
11:28:32 mdbooth Revert was change If1ee6d6e4004750f80424ec54d7dabc564ec9e06
11:29:42 kashyap Ah, thanks.
11:48:18 openstackgerrit Stephen Finucane proposed openstack/nova master: doc: Start using oslo.sphinxext https://review.openstack.org/449584
11:48:37 sfinucan johnthetubaguy, macsz: I think you'll like that one ^
11:52:09 cdent sfinucan: I assume this meaning is something others can only grasp if they too go on the same journey and thus you cannot pass it on?
11:52:50 nkorabli Could you please comment my question - then I will create a bug
11:53:01 nkorabli if you create an instance as a demo user, shelve it as admin and then try to unshelve it as demo user again - you won’t see any errors or warnings, but instance will end up with an ERROR state.
11:53:01 nkorabli So, what should be the right way for this scenario? What do you think?
11:53:43 cdent nkorabli: I'd comment except for the fact that I don't know.
11:54:17 sfinucan cdent: I'm afraid so
11:54:19 sfinucan I intend to blog about some of it but if reading dhellman's musings [1] alone couldn't help me attain enlightenment, what hope has a mere mortal like myself of helping others? [1] https://doughellmann.com/blog/2010/05/09/defining-custom-roles-in-sphinx/
11:57:30 openstackgerrit Lucas Alvares Gomes proposed openstack/nova master: [Ironic] Do not hard fail when Ironic is not available https://review.openstack.org/449587
11:57:34 nkorabli cdent: thanks, fair enough :)
11:59:54 sfinucan nkorabli: I'd say just open a bug with your findings and let others come to their own conclusions about how to resolve it
12:01:09 sdague johnthetubaguy: you about?
12:01:18 johnthetubaguy I am
12:01:26 sdague I was just going through the policy spec, and I'm with mriedem, it's super confusing
12:01:36 sdague even though I know where you are trying to go with it, I think
12:01:58 sdague I left some thoughts on how to rewrite bits for clarity
12:03:17 johnthetubaguy sdague: thats cool, it is confusing
12:03:31 johnthetubaguy I tried a few different rewords, I might be stuck in the middle of a few of them right now
12:03:37 mdbooth Bless it's cotton socks, pylint does try hard in the face of overwhelming adversity
12:03:38 openstackgerrit John Garbutt proposed openstack/nova-specs master: Alternative for warning users about maintenance https://review.openstack.org/449593
12:04:07 johnthetubaguy tojuvone: (and bauwser) I typed up some ideas I had in there ^
12:04:11 johnthetubaguy sdague: is that both of them, btw?
12:04:15 jroll lucasagomes: nice find, thanks for that
12:04:33 sdague johnthetubaguy: I just went through the bottom one
12:05:25 mdbooth sdague: Actually, this sounds like something you might have tried. I'm looking for a test which checks function arguments and before writing something custom I thought I'd checkout pylint. Do you know if anybody's ever looked at a pylint job for Nova?
12:05:44 johnthetubaguy sdague: OK, thats the one I hoped was better to read, is it worth a quick hangout?
12:07:00 johnthetubaguy sdague: actually, I think I get your comment, let me try fix that
12:09:36 sdague johnthetubaguy: I can do a quick hangout in a few minutes if you like
12:10:05 johnthetubaguy sdague: maybe I try a quick rev of that first section, and see how we look later on?
12:10:17 sdague sure
12:12:32 lucasagomes jroll, o/ np thanks for the review
12:14:11 nkorabli sfinucan: thanks, I just thought if I would get a response, I could fix it now..
12:18:43 openstackgerrit fengzhr proposed openstack/nova master: Make network:attach_external_network policy check outside nova-api https://review.openstack.org/449598
12:22:12 openstackgerrit Andrey Volkov proposed openstack/nova master: Structure for simply managing placement-api-ref https://review.openstack.org/409340
12:22:13 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] add api-ref for GET /resource_providers https://review.openstack.org/418503
12:28:20 sdague sfinucan: you reading the email on the ipv6 issue infra hit
12:29:01 sfinucan sdague: I am not. Link?
12:29:25 sfinucan Is this 'Config drive claims ipv6_dhcp, neutron api says slaac'
12:33:18 sdague yeh
12:37:44 sfinucan Hmm, I've never even heard of slaac. It would appear I've not so much broken something as exposed existing broken behaviour. This is going to be fun to debug
12:39:01 leakypipes alex_xu: well, I've been trying to get those traits in to os-traits here: https://review.openstack.org/#/c/448283/
12:39:32 leakypipes alex_xu: but cdent and sean-k-mooney don't seem to care for the patch before it that splits out traits into different modules.
12:40:12 leakypipes alex_xu: I originally had the NIC traits added as a single patch but sean-k-mooney requested some refactoring before expanding the single const.py further.
12:40:46 cdent leakypipes: that's a bit strong, it's more like it's not what it says on the tin. what's in the tin is good enough if the label is changed. However the label does sound pretty nice.
12:40:52 sean-k-mooney leakypipes: im always causing trouble :)
12:40:59 alex_xu leakypipes: yea, i see, just thought we can begin to use those NIC traits in https://review.openstack.org/435954
12:41:38 leakypipes alex_xu: you mean replace "tso" with "HW_NIC_OFFLOAD_TSO" in the spec?

Earlier   Later