| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-24 | |||
| 07:47:48 | openstackgerrit | jichenjc proposed openstack/nova master: remove keypair server extension https://review.openstack.org/396611 | |
| 07:48:53 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: Use mask_dict_password from oslo.utils https://review.openstack.org/388345 | |
| 07:49:50 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: Use mask_dict_password from oslo.utils https://review.openstack.org/388345 | |
| 07:50:31 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add description to policies in keypairs.py https://review.openstack.org/448461 | |
| 08:17:43 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add description to policies in pause_server.py https://review.openstack.org/449478 | |
| 08:22:03 | openstackgerrit | Markus Zoeller (markus_z) proposed openstack/nova master: live-migration test hook for serial console https://review.openstack.org/347471 | |
| 08:25:58 | openstackgerrit | lan proposed openstack/os-vif master: Remove log translations https://review.openstack.org/447865 | |
| 08:35:26 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add description to policies in server_groups.py https://review.openstack.org/449486 | |
| 09:17:20 | openstackgerrit | 龚肖 proposed openstack/nova master: Replaces uuid.uuid4 with uuidutils.generate_uuid() https://review.openstack.org/449515 | |
| 09:21:21 | openstackgerrit | Jordan Pittier proposed openstack/nova master: Remove the Libvirt Scality volume driver https://review.openstack.org/449517 | |
| 09:31:36 | alex_xu | jaypipes: are we ready to use standard traits that defined in os-traits when create neutron port https://review.openstack.org/#/c/435954/11/specs/pike/approved/enable-sriov-nic-features.rst@122 ? | |
| 09:38:17 | sfinucan | cfriesen: You were looking for me? | |
| 09:39:07 | johnthetubaguy | mdbooth: sfinucan: sounds like we missed a bit in this one (really worries about our testing now): https://review.openstack.org/#/c/438970/ | |
| 09:42:35 | openstackgerrit | Huan Xie proposed openstack/nova master: Fix race condition when neutron is using minimized poll https://review.openstack.org/444230 | |
| 09:42:35 | johnthetubaguy | tojuvone: hi, thanks for the update, just reading through that, lots of great context in there now | |
| 09:43:24 | johnthetubaguy | tojuvone: got a question, it says "in NFV there are automated action on host failure", what tool is that? | |
| 09:44:59 | bauwser | johnthetubaguy: yeah I was on the spec too :) | |
| 09:45:00 | tojuvone | johnthetubaguy, NFV wouldn't think yet opensource, but one could soon make this in places like craton, or currently by utilizing mistral | |
| 09:45:25 | bauwser | tojuvone: I thought it was Watcher ? | |
| 09:46:22 | johnthetubaguy | tojuvone: OK, just wondering if there is a specific opensource community we should be talking to about this spec, I was assuming the OpenNFV folks might have something cooking for this | |
| 09:46:49 | johnthetubaguy | just if those folks exist, I would love their feedback on this one, I just don't know who to reach out to | |
| 09:47:09 | openstackgerrit | 龚肖 proposed openstack/nova master: Replaces uuid.uuid4 with uuidutils.generate_uuid() https://review.openstack.org/449537 | |
| 09:47:49 | tojuvone | bauwser, I need to look watcher better. I know its optimizing resources | |
| 09:49:11 | tojuvone | johnthetubaguy, I know there is some MANO projects, but haven't been dealing with those myself | |
| 09:50:01 | johnthetubaguy | tojuvone: is there any chance you could reach out to those folks, or someone who knows them, to ask if they are interested in reviewing your spec? | |
| 09:53:12 | frickler | is the format of network_data.json documented somewhere? my Google foo seems weak this morning | |
| 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 | |