Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-03-24
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?
12:41:50 alex_xu leakypipes: yea
12:42:16 leakypipes alex_xu: well, that's fine of course :) but I won't hold up the spec for that. we can always enforce that in the code.
12:43:03 sean-k-mooney alex_xu: we could definetly do that and assuming the network traits land before pike release we chan change the impentation to use them once they are merged
12:43:50 alex_xu leakypipes: yea, I also did ask the doc work to replace tso to 'HW_NIC_OFFLOAD_TSO', just thought when we put those NIC traits in the code, those should be standard trait. otherwise, we will let user transfer to the standard trait in the future
12:44:28 sean-k-mooney leakypipes: i dont thnik we nesicalliy have all the feature flag we would need in your initall patch but we can extend in follow up patches
12:44:34 alex_xu s/did ask/didn't ask/
12:44:36 alex_xu oops
12:45:15 alex_xu sean-k-mooney: yea, in the internal implement that is totally ok.
12:47:16 leakypipes sean-k-mooney: sure, agreed.
12:48:17 alex_xu sean-k-mooney: +1
12:48:27 openstackgerrit Silvan Kaiser proposed openstack/nova master: Switch Nova Quobyte volume driver to mount via systemd-run https://review.openstack.org/432344
12:49:32 sean-k-mooney alex_xu: so do you want us to update the spec to reflect or just enforce it via the code review of the implentation of the feature?
12:50:26 alex_xu sean-k-mooney: i think we only update this line https://review.openstack.org/#/c/435954/11/specs/pike/approved/enable-sriov-nic-features.rst@222
12:59:03 ralonsoh alex_xu: hi
12:59:09 ralonsoh alex_xu: just for confirmation

Earlier   Later