| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-24 | |||
| 07:17:16 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Fix api-ref for adminPass behavior https://review.openstack.org/449450 | |
| 07:17:43 | nkorabli | Hi there, I've got a question related to multitenancy, I believe. I already asked it once, but have some new details.. | |
| 07:18:33 | nkorabli | login as demo user and try to unshelve the instance shelved by admin user | |
| 07:18:33 | nkorabli | login as a admin user navigate to admin panel and shelve the instance (as admin user is able shelve any instance) | |
| 07:18:33 | nkorabli | login as demo user and create an instance . | |
| 07:18:35 | nkorabli | expected : instance should be unshelved | |
| 07:18:37 | nkorabli | Actual : instance is not shelved but is went to error state. There are two conditions here 1.If this scenarios is not valid admin user should not have an option to shelve the instance , this option should be removed . | |
| 07:18:39 | nkorabli | 2.If this is a valid flow , instance should be unsheleved by the demo user. During the shelve process a snap shot will be created in the instance panel and it will be removed automatically when instance is unshelved. But when admin user is trying to shelve instance a snapshot is created under admin projects instead of demo project . This may be the reason for unshelve failure | |
| 07:19:02 | nkorabli | So, basically what is a valid workflow for this scenario? | |
| 07:34:24 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add description to policies in lock_server.py https://review.openstack.org/448468 | |
| 07:34:32 | openstackgerrit | Tomi Juvonen proposed openstack/nova-specs master: Planned host maintenance https://review.openstack.org/310510 | |
| 07:43:26 | tojuvone | johnthetubaguy, updated the spec: https://review.openstack.org/310510 | |
| 07:44:30 | openstackgerrit | Sivasathurappan Radhakrishnan proposed openstack/nova master: Use mask_dict_password from oslo.utils https://review.openstack.org/388345 | |
| 07:45:42 | openstackgerrit | jichenjc proposed openstack/nova master: refactory some code on get_password https://review.openstack.org/449458 | |
| 07:46:20 | openstackgerrit | jichenjc proposed openstack/nova master: check hw:mem_page_size when change extra_spec https://review.openstack.org/408610 | |
| 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 | johnthetubaguy | tojuvone: hi, thanks for the update, just reading through that, lots of great context in there now | |
| 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: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 ? | |