Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-11
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
16:07:17 mriedem and resource provider traits
16:07:18 jaypipes mriedem: :) how could I forget about them? :)
16:07:19 DuncanT jaypipes: I don't think the best fix for historical lack of definition is to slap something new on the edge though
16:07:57 jaypipes mriedem: one of the reasons we didn't call traits "tags" for resource providers was specifically because it is the system/admin that sets traits on a resource provider, not a user.
16:08:03 DuncanT I think we've only got volume.metadata, volume.admin_metadata, snapshot.metadata and backup.metadata, though I haven't checked carefully
16:08:49 jaypipes DuncanT: like I said, I didn't want to get in a conversation with you about how you're wrong. :P
16:09:13 jaypipes DuncanT: in case it's not clear, you're not wrong at all...
16:09:32 DuncanT jaypipes: You actually had me worried for a moment :-)
16:09:46 sdague mordred: with your user hat on, you want to check on this one - https://review.openstack.org/#/c/400883/
16:10:15 jaypipes DuncanT: the concept of a simple string tag is actually pretty universal in the web. The fact that OpenStack inherited the AWS EC2 concept of metadata key/value pairs is really just a vestigiality of the early Nova API more than anything else.
16:10:37 mriedem heh, i can even apply tags to VSIs in softlayer for gods sake
16:10:43 mriedem and they have the worst api
16:11:21 jaypipes mriedem: sshh, don't tell.
16:11:39 mriedem they know
16:13:14 mordred sdague: we do not seem to use that informaiton in glean at all
16:13:32 sdague mordred: ok, great
16:13:59 sdague I just wanted to make sure with a consumer before cutting that off
16:14:26 clarkb sdague: mordred you sure that won't affect the udev rules for glean?

Earlier   Later