| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-24 | |||
| 09:54:28 | johnthetubaguy | frickler: its a question that keeps coming up, I keep meaning to ask gmann and alex_xu about this one, we really need the metadata service (and config drive) documenting in our api-ref | |
| 09:54:53 | frickler | the closest thing I can find is this, but it doesn't look up to date https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/metadata-service-network-info.html | |
| 09:55:26 | johnthetubaguy | it has change some over time, I am just looking to see what we have in the code | |
| 09:55:32 | johnthetubaguy | ironic have done some recent tweaks | |
| 09:55:37 | frickler | johnthetubaguy: in particular it would be good to settle whether ipv6_dhcp can also mean ipv6_slaac or whether that should be distinguishable | |
| 09:56:01 | tojuvone | johnthetubaguy, I will take a look. Surely these are otherwise "traditional" Telco requirements. | |
| 09:56:21 | johnthetubaguy | tojuvone: not questioning that, just wanting to make sure we get wide feedback | |
| 09:56:52 | openstackgerrit | Zhou Jianming proposed openstack/nova master: 'uplug' word spelling mistake https://review.openstack.org/449543 | |
| 09:58:37 | tojuvone | johnthetubaguy, yes, understand that :) | |
| 09:59:01 | johnthetubaguy | tojuvone: I think there are some folks at intel curious about this one too, I need to get them to have a look | |
| 10:01:05 | tojuvone | johnthetubaguy, great | |
| 10:02:32 | bauwser | tojuvone: johnthetubaguy: what's puzzling me is that I don't get the last piece of the puzzle for automatic redeployment | |
| 10:02:55 | bauwser | tojuvone: johnthetubaguy: so, Vitrage is defining alarms. ala CloudWatch, right? | |
| 10:03:08 | johnthetubaguy | frickler: this may not help, but this is the bit of code that is interesting: https://github.com/openstack/nova/blob/a4ee3ea563ccf6ad92e081e8fdd537c7d411142a/nova/virt/netutils.py#L166 | |
| 10:03:18 | bauwser | tojuvone: johnthetubaguy: so my question is, which project is triggering those alarms ? | |
| 10:03:27 | johnthetubaguy | frickler: we are currently talking with neutron how to get them to own this interface | |
| 10:03:36 | bauwser | tojuvone: hence my point, I was thinking it was Watcher | |
| 10:03:51 | johnthetubaguy | frickler: get the network experts doing the network stuff seems more... sound | |
| 10:04:02 | bauwser | tojuvone: actually, Watcher already subcribes to the notification bus so possibly there wouldn't be a need for Vitrage | |
| 10:04:22 | gmann | johnthetubaguy: frickler yea we lack that documentation. this tempest tests fetch and check device tag in case that help - https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_device_tagging.py | |
| 10:04:50 | johnthetubaguy | gmann: can you get that onto the agenda for the next API meeting, we should fix that before we finish off that concept guide | |
| 10:05:06 | tojuvone | bauwser, Vitrage is used to monitor cloud, make RCA of events and raise alarms | |
| 10:05:23 | johnthetubaguy | gmann: generating some api samples would be awesome, I suspect that may be the way to start | |
| 10:05:38 | bauwser | tojuvone: what is the differenciator with AODH and Ceilometer ? | |
| 10:05:58 | tojuvone | bauwser, It uses AODH | |
| 10:06:16 | bauwser | mmmmm okay | |
| 10:06:20 | gmann | johnthetubaguy: yea, i can check on this but may not be not soon... | |
| 10:06:39 | bauwser | tojuvone: I guess I need to look at the Vitrage wiki then to understand their needs | |
| 10:06:59 | johnthetubaguy | gmann: understood | |
| 10:07:05 | tojuvone | bauwser, So we actually use it NFV | |
| 10:07:13 | johnthetubaguy | gmann: probably just need to get that on our list for this cycle | |
| 10:07:14 | bauwser | because I don't see the need of an abstraction over another abstraction :) | |
| 10:07:26 | bauwser | tojuvone: that, I got it | |
| 10:07:31 | mdbooth | johnthetubaguy: Whoa | |
| 10:08:39 | mdbooth | johnthetubaguy: Well, there's only 1 thing for it: better merge the next patch quick :) | |
| 10:09:04 | gmann | johnthetubaguy: sure. | |
| 10:09:24 | johnthetubaguy | mdbooth: thats one way to do it, you want to line those back up, and we can take another look quickly | |
| 10:09:28 | tojuvone | Vitrage need to differentiate host fault from planned maintenance, to have proper alarms | |
| 10:09:47 | mdbooth | johnthetubaguy: I'm joking, if we need to revert lets do it. | |
| 10:09:57 | mdbooth | However, I really would like to get that merged | |
| 10:09:59 | johnthetubaguy | mdbooth: I think they did the revert already | |
| 10:10:03 | mdbooth | Ok, cool | |
| 10:10:29 | johnthetubaguy | yeah, I think the emergency bit is done already | |
| 10:10:56 | mdbooth | We don't run the NFS job by default, which is probably how that slipped through | |
| 10:11:13 | bauwser | tojuvone: so, to understand correctly the NFV usecase, Vitrage emits alarms, right? | |
| 10:11:20 | mdbooth | And, as you say, I only did the more thorough manual testing on the next patch in the series. | |
| 10:11:37 | bauwser | tojuvone: for each "node" that is impacted by some notification | |
| 10:11:48 | mdbooth | I'll line that up today | |
| 10:12:21 | bauwser | tojuvone: now, once those deduced alarms are raised, which tool will trigger actions on those ? | |
| 10:12:29 | tojuvone | bauwser, Its RCA raising alarms on each level where needed to | |
| 10:12:40 | bauwser | tojuvone: that I got it too | |
| 10:12:48 | bauwser | the output is basically a set of alarms | |
| 10:12:58 | bauwser | with linkages between thoses | |
| 10:12:59 | tojuvone | bauwser, so here planned mainteancne instead | |
| 10:13:33 | tojuvone | bauwser, at least in fault situation it could force down host or what else would be configured | |
| 10:13:48 | tojuvone | bauwser, but it is not intended to make workflows to migrate | |
| 10:13:56 | bauwser | *what* would do that ? | |
| 10:14:02 | bauwser | Vitrage? | |
| 10:14:24 | bauwser | ie. what executes the action plan ? | |
| 10:14:30 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-novaclient master: Imported Translations from Zanata https://review.openstack.org/449041 | |
| 10:14:48 | bauwser | tojuvone: is this something which is already present today | |
| 10:14:49 | bauwser | ? | |
| 10:15:03 | bauwser | tojuvone: because my main concern on Nova is that we need to understand the missing gaps | |
| 10:15:30 | bauwser | tojuvone: ie. what is specifically lacking on our side so that a specific usecase could be fulfilled | |
| 10:15:40 | tojuvone | bauwser, I was planning to make poc with Craton upon planned mainteancne | |
| 10:16:09 | bauwser | tojuvone: the main problem I have with your spec is that I don't see yet a clear picture on the overall workflow, and what's missing in that workflow on the nova side | |
| 10:16:36 | tojuvone | bauwser, I am not sure somebody doing this in fully open source | |
| 10:16:55 | bauwser | well, I'm not exactly concerned by that | |
| 10:17:13 | bauwser | but I need to understand why we can't just disable services or force hosts down | |
| 10:17:27 | bauwser | because I don't have the clear workflow picture in my mind | |
| 10:17:40 | bauwser | for example, say the forced_down series you implemented | |
| 10:18:18 | tojuvone | bauwser, In Nova it is much to me to see it in servers API | |
| 10:18:21 | bauwser | it was clear to me that there was an usecase where 3rd-party tools (opensource or not) could be identifying before our SG API that a host is down and could accelerate the logic by having a specific bit to call | |
| 10:19:03 | tojuvone | that is fault management | |
| 10:19:18 | tojuvone | here you have planned maintenance | |
| 10:19:23 | bauwser | correct, I'm not saying your spec is that | |
| 10:19:45 | bauwser | sure, but what's missing in nova for that ? | |
| 10:19:54 | bauwser | you can disable a service | |
| 10:20:10 | bauwser | you can migrate all the existing instances of that host out | |
| 10:20:20 | tojuvone | the planned window is missing | |
| 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 | tojuvone | and to have the rolling thing with that window | |
| 10:21:50 | bauwser | not speaking of the proposed implementation | |
| 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 | |