| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-24 | |||
| 10:20:21 | bauwser | without having user-visible impacy | |
| 10:20:39 | bauwser | you mean "disable me this service in 1 hour" ? | |
| 10:20:54 | tojuvone | yes | |
| 10:21:03 | tojuvone | and what you can do in that windwo | |
| 10:21:19 | bauwser | say you have a planned maintenance in one hour | |
| 10:21:28 | bauwser | what do you want to have on the nova side? | |
| 10:21:40 | bauwser | ie. what do you want to do with the scheduler and your instances ? | |
| 10:21:50 | bauwser | not speaking of the proposed implementation | |
| 10:21:50 | tojuvone | and to have the rolling thing with that window | |
| 10:22:08 | bauwser | rather about what you wanna do as an operator during that period *before* the maintenance | |
| 10:22:28 | tojuvone | yes, for now we can forget what is proposed currently as implementation | |
| 10:22:40 | bauwser | for example | |
| 10:22:53 | bauwser | let's speak ITIL for a spec | |
| 10:22:55 | bauwser | sec | |
| 10:23:17 | tojuvone | as a user, application, you want to do something | |
| 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 | |