| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-24 | |||
| 14:00:33 | larsks | Right. That is typically how things are configured, and most distros have facilities for managing /etc/resolv.conf as interfaces come up and down. | |
| 14:00:36 | sdague | larsks: if you can figure out a way to get neutron to build that information that way, it's probably possible to make corresponding nova changes to expose this | |
| 14:00:45 | danpawlik | mriedem, efried, kashyap: I fixed all what you comment in my PS: https://review.openstack.org/#/c/459753 | |
| 14:00:51 | mriedem | johnthetubaguy: got a policy question for you on https://github.com/openstack/nova/blob/master/nova/policies/quota_class_sets.py#L25 | |
| 14:00:51 | sdague | but nova doesn't own that datastructure | |
| 14:00:59 | kashyap | danpawlik: Yep, will look in a bit; in the middle of something | |
| 14:01:08 | mriedem | johnthetubaguy: the quota_class is the id in the GET call, | |
| 14:01:18 | mriedem | so effectively it means: 'is_admin:True or quota_class:default' | |
| 14:01:32 | larsks | sdague: all right, I'll poke around neutron. Does network_data.json come directly from neutron (e.g., nova is just proxying the information)? | |
| 14:01:33 | mriedem | johnthetubaguy: does that mean you could just configure policy per quota class? | |
| 14:01:38 | mriedem | even though we only have one | |
| 14:01:44 | artom | dansmith, yeah, they end up being global for the system, but what I think larsks has in mind is to add them to the global pool based on what interface is up/down | |
| 14:02:09 | dansmith | artom: sure, but not like added and removed as they become dynamically reachable, just assumed reachable because the interface is up | |
| 14:02:25 | dansmith | artom: which is what I thought you meant | |
| 14:02:44 | artom | dansmith, right, the "reachable" part is meaning we humans assign | |
| 14:02:57 | artom | For the machine it's just nic up -> add nameserver | |
| 14:02:59 | larsks | dansmith: artom: networkmanager and the legacy network scripts will manage entries in resolv.conf as interfaces come up/down. Which is what I think we would want. | |
| 14:03:11 | dansmith | yah | |
| 14:03:39 | mriedem | alex_xu: gmann: i've updated the bug - we'll need a spec to work the microversion fix, any volunteers? | |
| 14:03:49 | dansmith | larsks: yeah, I understand.. adding a nic to an instance should end up with all that network's info merged in, just like configuring a nic in a distro | |
| 14:04:15 | dansmith | larsks: sdague: don't we construct network.json from the pieces we get from neutron? | |
| 14:04:19 | larsks | dansmith: right. But it sounds like this is actually a neutron issue. Yeah. | |
| 14:04:22 | sdague | dansmith: we do | |
| 14:04:28 | sdague | https://github.com/openstack/nova/blob/c2c6960e374351b3ce1b43a564b57e14b54c4877/nova/virt/netutils.py#L166-L222 | |
| 14:04:32 | alex_xu | mriedem: i can done that, gmann already take another task for deprecated hide-address policy | |
| 14:04:42 | sdague | that's where the structure is built from our network_info block | |
| 14:04:43 | mriedem | ok | |
| 14:05:16 | dansmith | sdague: right, so I'm not sure why those are't already merged if multiple networks have dns info | |
| 14:05:25 | dansmith | L210 there | |
| 14:05:52 | sdague | yeh | |
| 14:06:02 | dansmith | larsks: ^ | |
| 14:07:26 | larsks | dansmith: I'm not sure I followed you there. | |
| 14:07:58 | larsks | I mean, they might be "merged in", but the issue is that they are provided globablly rather than interface-scoped so we can't put the information in the right place. | |
| 14:08:43 | dansmith | larsks: oh I see you want to be able to configure the distro interface files so that if they ifdown an interface, it removes those dns servers from the merged resolv.conf? | |
| 14:08:54 | sdague | larsks: do you want them at the link or networks side? | |
| 14:09:13 | dansmith | in that case, this is a nova-side change, although it's a change to our metadata which is something not to be taken lightly | |
| 14:09:20 | larsks | sdague: I *think* on the networks side. | |
| 14:09:39 | larsks | dansmith: understood! | |
| 14:09:48 | sdague | larsks: you could probably change things so that they *also* are at the networks side, but they are going to have to also stay global for systems that can't understand that change | |
| 14:09:51 | larsks | dansmith: also, yes, in response to your ealier question. | |
| 14:09:59 | larsks | sdague: that makes the most sense, I think. | |
| 14:10:09 | dansmith | larsks: sdague yeah, adding them in both places is the only thing you could do without breaking people | |
| 14:10:18 | sdague | larsks: that's at least the place to play around with things | |
| 14:12:59 | mriedem | btw, | |
| 14:13:13 | mriedem | i heard that one of the outcomes of a forum session on apis was that we don't have config drive documented anywhere | |
| 14:13:34 | mriedem | there is this https://docs.openstack.org/user-guide/cli-config-drive.html | |
| 14:13:56 | openstackgerrit | Daniel Pawlik proposed openstack/nova master: Add `hide_hypervisor_id` image property https://review.openstack.org/459753 | |
| 14:13:59 | mriedem | i'm assuming it's more a question of what the contents are | |
| 14:14:09 | mriedem | maybe per version, like what we have in the rest api version history | |
| 14:14:51 | sdague | yep, it's definitely in the state of something that you need to read code to understand | |
| 14:16:33 | dansmith | well, that goes for metadata too | |
| 14:16:34 | mriedem | there was a spec that mgagne recently updated for the network data json blob | |
| 14:16:46 | mriedem | dansmith: right, that's what i was thinking with versions | |
| 14:17:00 | mriedem | e.g. in newton you get a new version with device tags | |
| 14:17:45 | dansmith | yeah | |
| 14:18:38 | mriedem | this one https://review.openstack.org/#/c/337819/ | |
| 14:19:18 | mriedem | let me see if i can find the forum notes and start something in the ML to ask what people are looking for | |
| 14:19:45 | mriedem | i've also been thinking about starting an in-tree doc with a dump of all known flavor extra specs | |
| 14:22:11 | mgagne | I feel like this review is losing momentum, is there a way to highlight it somewhere to get more attention? https://review.openstack.org/#/c/454322/ | |
| 14:22:23 | mgagne | (Add ability to signal and perform online volume size change) | |
| 14:22:55 | mriedem | mgagne: it's on my list | |
| 14:23:04 | mriedem | mgagne: i've been going through some of the random smaller bp changes this week | |
| 14:23:10 | mgagne | thanks =) | |
| 14:41:11 | mriedem | http://lists.openstack.org/pipermail/openstack-dev/2017-May/117401.html | |
| 14:41:17 | mriedem | mgagne: ^ you might have input also | |
| 14:46:26 | mriedem | sdague: from http://lists.openstack.org/pipermail/openstack-dev/2017-May/117374.html - http://enos.irisa.fr/html/seqdiag/v1/trace-boot-and-delete.yaml.html | |
| 14:46:43 | mriedem | i remember someone from ibm research a few years ago wrote some tooling to do tracing like this too, using osprofiler i think | |
| 14:46:53 | mriedem | reminded me of the nova onboarding session | |
| 14:47:48 | sdague | yeh | |
| 14:48:01 | sdague | it would be nice if the output wasn't an eye chart with a soda straw | |
| 14:48:51 | mriedem | yeah it's hard to navigate | |
| 14:49:05 | sdague | and non searchable | |
| 14:49:22 | sdague | the svg thing looks all sexy, until you try to do things with it | |
| 15:09:15 | savvas | Hi guys, I've been hopping from channel to channel trying to isolate the cause of a problem I've been having | |
| 15:09:24 | savvas | when I try to boot an instance as following: nova boot newInstance --flavor testpack --security-groups default --nic net-id=7a2a1e61-1d86-4551-b578-dedf7f8443ea --block-device source=image,id=de61646b-8c48-43ac-a8b1-8f8348757d66,dest=volume,size=10,shutdown=remove,bootindex=0 --availability-zone hv01-zone | |
| 15:10:25 | savvas | nova seems to ignore the availability-zone for cinder, it tries to use the default "nova" zone for creating the volume, instead of the AZ defined in the boot command. Am I missing something in my configuration perhaps that tells nova to look in diff volume AZ? | |
| 15:12:17 | savvas | I should add that if I create a volume manually in the right AZ and then boot an instance from that volume, it works just fine. However, combining those actions into a nova boot / server create command fails | |
| 15:13:38 | mriedem | cfriesen: you might be interested in this thread http://lists.openstack.org/pipermail/openstack-dev/2017-May/116595.html | |
| 15:14:10 | mriedem | savvas: which release? | |
| 15:14:17 | savvas | ocata | |
| 15:14:20 | mriedem | and what's the value of [cinder]cross_az_attach in nvoa.conf? | |
| 15:14:21 | mriedem | *nova.conf | |
| 15:14:31 | mriedem | or is it not set? | |
| 15:14:41 | savvas | that's left to default, I found comments on that but I didn't think it was relevant in my case | |
| 15:14:44 | savvas | not set | |
| 15:15:41 | savvas | I figured based on the AZ I define when creating an instance that it would look for the available AZ as defined by the cinder-volume service | |
| 15:15:59 | mriedem | nova doesn't list AZs from cinder | |
| 15:16:44 | mriedem | have you looked at https://github.com/openstack/nova/blob/81bdbd0b50aeac9a677a0cef9001081008a2c407/nova/virt/block_device.py#L55 ? | |
| 15:17:12 | mriedem | cross_az_attach defaults to True, so that method is going to return None | |
| 15:17:38 | mriedem | which means when nova creates the volume, it's not going to pass an az to cinder, | |
| 15:17:43 | mriedem | so cinder uses it's default az, which is 'nova' | |
| 15:17:51 | mriedem | because that makes total sense right?! | |
| 15:18:05 | savvas | right lol | |
| 15:18:16 | mriedem | if you want nova to specify the same az for the volume as the vm, you have to set cross_az_attach=False | |
| 15:18:19 | sdague | yay for inherited defaults | |
| 15:19:19 | mriedem | there are apparently at least 3 cinder config options for the default az | |
| 15:19:35 | mriedem | one global one, which if not set defaults to another global one, which defaults to nova, but can be overridden on a per-backend basis | |
| 15:19:38 | mriedem | using yet another option | |
| 15:20:17 | mriedem | savvas: anyway, does that answer your question? | |
| 15:20:37 | savvas | trying it as we speak :) | |