Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-24
11:13:25 openstackgerrit Claudiu Belu proposed openstack/nova master: POC: tests: autospecs all the mock.patch usages https://review.openstack.org/447505
11:29:47 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for GET resource provider https://review.openstack.org/467541
11:29:48 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for DELETE resource provider https://review.openstack.org/467543
11:29:48 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for PUT resource provider https://review.openstack.org/467542
11:29:49 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for resource classes https://review.openstack.org/467596
11:29:49 openstackgerrit Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for POST resource provider https://review.openstack.org/456176
12:23:20 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Send out notifications when instance tags changed https://review.openstack.org/459923
12:25:05 peter-hamilton hi all, hoping to get some reviews on cert validation patches: https://review.openstack.org/#/c/457711/, https://review.openstack.org/#/c/357202/, and https://review.openstack.org/#/c/457678/
12:25:15 peter-hamilton any and all reviews welcome :)
12:45:05 alex_xu nova api meeting is in 15 mins at #openstack-meeting-4
12:46:24 sfinucan alex_xu: Where would I find the agenda for that meeting?
12:47:36 alex_xu sfinucan: here is https://wiki.openstack.org/wiki/Meetings/NovaAPI
12:47:55 sfinucan alex_xu: ++
13:00:23 alex_xu nova api meeting is running now
13:26:40 openstackgerrit Jay Pipes proposed openstack/nova master: integrate trait cache with TraitList and Trait https://review.openstack.org/462770
13:26:41 openstackgerrit Jay Pipes proposed openstack/nova master: add cache which keeps DB and os_traits in sync https://review.openstack.org/462769
13:27:58 openstackgerrit Jay Pipes proposed openstack/nova master: add cache which keeps DB and os_traits in sync https://review.openstack.org/462769
13:27:58 openstackgerrit Jay Pipes proposed openstack/nova master: integrate trait cache with TraitList and Trait https://review.openstack.org/462770
13:34:08 openstackgerrit Hong Hui Xiao proposed openstack/nova master: VMware: Check if network is ready on cluster host https://review.openstack.org/467589
13:43:43 openstackgerrit Eric Berglund proposed openstack/nova master: Add strict option to discover_hosts https://review.openstack.org/467218
13:48:54 openstackgerrit Eric Berglund proposed openstack/nova master: Add strict option to discover_hosts https://review.openstack.org/467218
13:54:35 larsks The network_data.json provided by nova provides nameserver information globally in the "services" key, rather than scoping it per-interface. This would seem to mean that it's not possible to associate different sets of DNS servers with different interfaces.
13:54:44 larsks Am I reading the situation correctly?
13:57:18 sdague larsks: that sounds right
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 sdague but nova doesn't own that datastructure
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: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

Earlier   Later