| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-24 | |||
| 10:23:19 | bauwser | your change manager gave you a change window that will happen in 1 hour because you need to upgrade the kernel | |
| 10:23:26 | johnthetubaguy | bauwser: I think we just need to focus on the use cases in the spec | |
| 10:23:27 | bauwser | on a specific host | |
| 10:23:39 | johnthetubaguy | I am current adding a patch on top of tojuvone's spec to see if I understand them correctly | |
| 10:23:48 | johnthetubaguy | I think we should stay out of implementation detail right now | |
| 10:23:54 | bauwser | johnthetubaguy: those usecases are way too-high level for me | |
| 10:24:03 | bauwser | johnthetubaguy: I agree | |
| 10:24:13 | bauwser | johnthetubaguy: I want to understand the crux of the problem | |
| 10:24:16 | bauwser | without speaking code | |
| 10:24:37 | bauwser | ie. I want to discuss about what is a "planned maintenance" and what actions are needed to be done | |
| 10:24:43 | johnthetubaguy | yeah, I am trying to write that out now, to see if I understand what I think tojuvone is trying to say | |
| 10:24:52 | bauwser | for example | |
| 10:24:57 | johnthetubaguy | (this is based on how I know we wanted this to work for public cloud) | |
| 10:25:15 | bauwser | "* As an admin I want to have an external tool to handle hosts and their maintenance:" is mentioned in that spec, but waaaaays too much than just nova | |
| 10:25:15 | johnthetubaguy | well, we built this system using server metadata | |
| 10:25:36 | tojuvone | yes, that is used before ;) | |
| 10:25:58 | johnthetubaguy | it will be many, many different tools doing lots of this different operations, the key bit is the Nova interactions they all have in common, I am trying to write those down right now | |
| 10:26:14 | bauwser | okay, tojuvone could you please explain me what is a "planned maintenance" ? | |
| 10:26:16 | mdbooth | johnthetubaguy: https://review.openstack.org/#/c/439520/ | |
| 10:26:29 | mdbooth | I don't understand your comment about the rebase. What's the context there? | |
| 10:26:41 | openstackgerrit | John Garbutt proposed openstack/nova master: compute: Move detach logic from manager into driver BDM https://review.openstack.org/439520 | |
| 10:27:00 | johnthetubaguy | mdbooth: so I expected rebase to fail once that patch I linked to lands on master | |
| 10:27:16 | johnthetubaguy | mdbooth: 437665 I think it was | |
| 10:27:21 | mdbooth | johnthetubaguy: IIRC there was no conflict between the 2 | |
| 10:27:36 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Read Neutron port 'binding_profile' during boot https://review.openstack.org/449257 | |
| 10:27:41 | johnthetubaguy | mdbooth: so there was on my system, which is kinda freaky | |
| 10:27:52 | johnthetubaguy | mdbooth: I must have fat fingered something | |
| 10:27:55 | mdbooth | Ok, probably means there was, then :) | |
| 10:28:06 | tojuvone | I have used "planned maitenance", to high light it does not happen because sudden fault | |
| 10:28:16 | johnthetubaguy | so its on master, and it just rebased cleanly, so maybe we are OK | |
| 10:28:16 | mdbooth | But when lyarwood separated them he didn't lose review votes | |
| 10:28:24 | mdbooth | Suggesting there was no difference | |
| 10:28:29 | johnthetubaguy | mdbooth: ah, good point, that usually means no difference | |
| 10:28:52 | johnthetubaguy | I may have tried to cherry pick ontop of an old version of its-self or something dumb | |
| 10:29:02 | johnthetubaguy | oh, well, seems fine now | |
| 10:29:08 | mdbooth | Meh, if the other one's already in the gate it's no problem | |
| 10:29:08 | bauwser | tojuvone: I'm just commenting your spec | |
| 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 :) | |