Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-24
13:57:31 artom larsks, isn't that a limitation of networking in general though? I mean, nameservers are for the whole system, I don'tknow of a way to limit nameservers to an interface, with Nova or without
13:58:02 larsks artom: not at all. I mean, you may have interface that are only reachable via specific interfaces. If everything is up, that's fine, but if you bring down the corresponding interface you want those nameservers to go away.
13:58:09 openstackgerrit Daniel Pawlik proposed openstack/nova master: Add `hide_hypervisor_id` image property https://review.openstack.org/459753
13:58:53 sdague larsks: yeh, this is basically just the /etc/resolv.conf handled case, nothing fancier
13:59:06 sdague it's going to be processed by cloud-init
13:59:20 larsks sdague: well, the problem here is that since Nova doesn't provide interface-scoped DNS servers, cloud-init...or anything else...can't actually configure the system correctly.
13:59:35 larsks E.g., DNS information should be added to interface config files (like /etc/sysconfig/network-scripts/ifcfg-eth0).
13:59:47 larsks But we can't, since the servers are only listed globally.
14:00:02 artom larsks, ah, so you want DNS servers being dynamically added/removed based on if they'd be reachable or not
14:00:31 Guest36154 artom: no, you can put all the dns servers in resolv.conf and it'll use the right route to get to each server
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,

Earlier   Later