| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 15:22:58 | sdague | jaypipes: no, it's a microversion change | |
| 15:23:01 | johnthetubaguy | mordred: I was curious on your comment about server metadata getting out of sync, is that given the clouds you are using? They might not have the bug fix in them | |
| 15:23:03 | mordred | johnthetubaguy: speaking of kevinbenton ... I just realized that my ssh-hostkey spec should actually be a neutron feature not a nova feature, so I'm going to be bugging kevinbenton about it and not you | |
| 15:23:19 | rpodolyaka | mriedem: hey! you asked about https://review.openstack.org/#/c/381912/ yesterday. It's not on the top of my list, but yes, I was hoping either me or snikitin_ will take over it from pkholkin | |
| 15:23:32 | openstack | Launchpad bug 1642918 in neutron "floating-ip nova notification is broken" [High,Fix released] - Assigned to YAMAMOTO Takashi (yamamoto) | |
| 15:23:32 | mriedem | rpodolyaka: ok | |
| 15:23:34 | mordred | johnthetubaguy: it's entirely possible, yes - but we have since learned to not trust that data as it's proxy data and just go directly to the source | |
| 15:23:41 | mordred | johnthetubaguy: AWESOME | |
| 15:23:48 | sdague | jaypipes: the old version continues to work as well, this is just the new prefered way. The old one isn't going to get dropped any time soon. | |
| 15:23:50 | johnthetubaguy | mordred: yeah, that makes sense | |
| 15:23:55 | alex_xu | mordred: under 'neutron floatingip-create EXT_NET_ID VM_PORT_ID' is one API or multiple API? | |
| 15:23:56 | mordred | johnthetubaguy: that does, in fact, sound like the problem we saw :) | |
| 15:24:17 | mordred | alex_xu: well, I honestly don't know about the neutron command line client- but there is a single REST API for create-with-port | |
| 15:24:21 | mordred | one sec, lemme find it for you | |
| 15:24:26 | amotoki | alex_xu: it is a single API except name lookup | |
| 15:24:45 | alex_xu | mordred: amotoki, ah, that is cool | |
| 15:25:18 | mriedem | alex_xu: mordred: https://developer.openstack.org/api-ref/networking/v2/index.html?expanded=show-port-details-detail,create-floating-ip-detail#create-floating-ip | |
| 15:25:28 | mriedem | POST /v2.0/floatingips with a port_id in the body | |
| 15:25:30 | mordred | mriedem: yah | |
| 15:25:32 | mordred | that'sit | |
| 15:25:38 | mriedem | "To associate the floating IP with an internal port, specify the port ID attribute in the request body. If you do not specify a port ID in the request, you can issue a PUT request instead of a POST request." | |
| 15:26:14 | mordred | (this API is 100% of the reason I want port_ids on fixed ips reported in the nova server record, fwiw) | |
| 15:26:37 | alex_xu | amotoki: I remember we can't do that in single API in long time before? | |
| 15:28:10 | mordred | sdague, jaypipes: so - don't hate me - but I do actually think net_id and subnet_id are also useful alongside the port_id in the addresses dict - largely because if I only have port_id I'll still have to go do a GET on the port to find out what network it's from so I can match it to cached information I've figured out about which networks are public and which are private | |
| 15:28:12 | mordred | SO | |
| 15:28:51 | mordred | if it's possible to add it when you add port_id without any additional cost - it is very useful (and still isn't duplicating all the additinonal info) | |
| 15:29:13 | sdague | mordred: so... I think it's pushing it to put all of that in the server doc | |
| 15:29:29 | sdague | in the subresource, sure | |
| 15:29:59 | mordred | sdague: adding three ids adjacent to the ip is pushing it? | |
| 15:30:02 | jaypipes | sdague: yeah, that's what I was referring to... as in "we still will duplicate information for a time being" :) | |
| 15:30:10 | mordred | I mean, you already have the port_id in ram when you're building addresses and just delete it | |
| 15:30:39 | jaypipes | mordred: sure, I hear ya. it's more of an efficiency thing, as we discussed. | |
| 15:30:40 | sdague | mordred: it's mostly about the constant everyone wants everything they might ever need in the server document | |
| 15:31:08 | sdague | and we're trying to resist that a bit | |
| 15:31:17 | mordred | sure. but it's not everything they might ever need -it's the two foreign keys you need to know how to take action on the server from a networking perspective. | |
| 15:32:08 | sdague | mordred: so, I think it's just time to walk away on this one, because the whole thing got dropped from pike about 30 minutes ago when it overran mriedem's rage level | |
| 15:32:16 | mordred | ok | |
| 15:32:48 | mordred | I'd _love_ to dig in to find the right thing whenver it's the right time to do that - but I totally grok rage level on this topic | |
| 15:33:30 | mriedem | johnthetubaguy: alex_xu: so given the above discussion, maybe we do just merge the deprecation of add/removeFloatingIP with add/removeFixedIP (multinic), and also throw os-virtual-interfaces deprecation in there as well | |
| 15:33:53 | johnthetubaguy | mriedem: I am very tempted by that | |
| 15:34:12 | mriedem | johnthetubaguy: don't let me seduce you, you're married proper now | |
| 15:34:45 | mriedem | mordred: sdague: jaypipes: yeah i'm running as far away from fixing bdms and ports in the compute API as i can for pike | |
| 15:34:52 | mriedem | because both attempts crushed both balls | |
| 15:35:12 | jaypipes | mriedem: fine with me. | |
| 15:35:18 | jaypipes | mriedem: sorry for complaining. | |
| 15:35:38 | johnthetubaguy | mriedem: :) | |
| 15:35:41 | mriedem | oh btw https://review.openstack.org/#/c/453272/ | |
| 15:35:41 | mordred | mriedem: well, please let me know if/when the topic comes up again. I'm definitely both very interested, very opinionated and often very confused | |
| 15:36:03 | sdague | mordred: yeh, well the issue is not a lack of opinions for sure.... | |
| 15:36:14 | jaypipes | mriedem: apparently, Tommy *doesn't* Like. | |
| 15:37:22 | mordred | sdague: :) | |
| 15:40:36 | mriedem | jaypipes: since you championed server tags in the comptue api, you might want to chime in on this cinder thread to do similar for volume tags http://lists.openstack.org/pipermail/openstack-dev/2017-March/114618.html | |
| 15:40:49 | mriedem | because the reply right now is, 'use searchlight' | |
| 15:41:09 | jaypipes | mriedem: that would mean I want to tell DuncanT that he's wrong again. :) | |
| 15:42:21 | mordred | mriedem: are clouds using searchlight yet? | |
| 15:43:36 | mriedem | mordred: no idea | |
| 15:45:00 | mriedem | mordred: searchlight wasn't listed in the oct 2016 user survey report anyway | |
| 15:46:53 | mriedem | mordred: well let me introduce you to https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/list-instances-using-searchlight.html | |
| 15:47:10 | mriedem | mordred: you're going to end up wasting your entire gd day in this channel | |
| 15:48:17 | mordred | mriedem: luckily I like all of you people | |
| 15:48:59 | sdague | mriedem: after a couple of hours yesterday, I did figure out why my flake8 in buffer checking didn't like the order import extension. It's that it's out of the box behavior isn't what we use | |
| 15:49:33 | sdague | and that if the file being run on it is outside of the tox tree (and there are reasons tools do that) it then behaves differently | |
| 15:49:34 | mordred | mriedem: neat! | |
| 15:50:10 | sdague | anyway I have a work around, but as this is the second time that flake8-import-order caused an issue, I do kind of wonder if we really want to keep it, https://review.openstack.org/#/c/454853/ | |
| 15:51:04 | mriedem | sdague: i have no opinion on it, and haven't had issues with it | |
| 15:51:27 | sdague | mriedem: it broke the intel ci, again, because it does things by just being installed | |
| 15:51:46 | mriedem | because it's in nova? | |
| 15:52:10 | sdague | well, it used to be in test-requirements | |
| 15:52:17 | sdague | which means it impacted things system wide | |
| 15:53:26 | mriedem | it's not in test-requirements anymore though | |
| 15:53:29 | sdague | it's not | |
| 15:53:39 | sdague | now it's this other problem | |
| 15:53:42 | amotoki | alex_xu: sorry for late. IIRC we can do that from the beginning: 'neutron floatingip-create --port-id <port-id> <floating-ip-net> | |
| 15:55:14 | amotoki | alex_xu: neutron didn't change the floating IP API from Folsom, but I am not sure the neutron proxy in nova supports all of the API | |
| 15:56:04 | sdague | mriedem: at this point it's in the land of "we shouldn't make it any harder to develop than we have to" | |
| 15:56:46 | DuncanT | jaypipes: I've spent enough time telling you over the years that you're wrong, turn about is fair play. I'm often wrong, I just hope I'm right even more often :-) | |
| 15:57:07 | jaypipes | :) | |
| 15:58:53 | mriedem | sdague: i've had 0 problem with it | |
| 15:59:00 | mriedem | i don't use tramp over emacs or whatever you said | |
| 15:59:05 | mriedem | so i don't have an opinion | |
| 15:59:06 | sdague | mriedem: that's fine, I've lost a full day of development | |
| 15:59:20 | sdague | debugging why this does the wrong thing | |
| 15:59:42 | mriedem | sorry about that. i've lost a full day on abandoned specs. | |
| 15:59:44 | mriedem | it sucks | |
| 16:00:12 | mriedem | i'm not -1 on it | |
| 16:02:19 | DuncanT | jaypipes: Having caught up with what I said, it seems daft to have two apis (metadata and tags) for the same purpose... I guess if you /really/ want tags, we just make it a convenience API that updates one specific metadata key (tags), rather than having a whole new bunch of stuff in the db... not sure if that will make search prohibatively difficult | |
| 16:02:20 | DuncanT | though... SQL has in 'in' operator, right? | |
| 16:02:54 | jaypipes | DuncanT: that's not how the IN operator works in SQL. | |
| 16:03:18 | DuncanT | jaypipes: Step 1, fix SQL ;-) | |
| 16:04:10 | jaypipes | DuncanT: we (in Nova-land) tend to separately define tags as "user-defined simple strings" whereas the metadata key/values can (and often are) added by the system itself and have a particular encoding of information in them. | |
| 16:04:47 | jaypipes | DuncanT: so, tags on a server instance are just that... simple string tags ala the typical Web definition of the term. | |
| 16:05:00 | jaypipes | DuncanT: and the system never sets tags on anything. | |
| 16:05:04 | jaypipes | DuncanT: only the user. | |
| 16:05:29 | mriedem | the nova 'system' doesn't set anything on server.metadata | |
| 16:05:35 | mriedem | it uses server.system_metadata | |
| 16:05:44 | DuncanT | jaypipes: metadata in cinder should never be set by anything other than the user... we have admin-metadata for sematically significant things | |
| 16:05:58 | mriedem | the single-tenant NFV monolith might be the system that uses server.metadata, idk | |
| 16:06:26 | DuncanT | jaypipes: I think there's a historical lack of definition about what the 'metadata' fields are there for | |
| 16:06:28 | jaypipes | mriedem: well, yes, sorry I was referring to the entire concept of key/value metadata. there is server metadata, system metadata on the server, image metadata, "metadetails" on the aggregate, etc. | |
| 16:07:08 | mriedem | don't forget about flavor extra specs | |