Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-11
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?
16:14:45 clarkb I guess udev doesn't rely on metadata only what is actualy exposed by kernel
16:14:48 mordred clarkb: I don't see us doing anything with link type in glean at all
16:15:08 clarkb mordred: well glean does things with the link type in udev, but thats provided by linux kernel not metadata
16:15:14 mordred right
16:15:24 mordred I mean doesn't do anything with the link type from config-drive
16:17:31 jaypipes mriedem, sdague, johnthetubaguy, dansmith, bauzas: https://review.openstack.org/#/c/376200/ ready for your eyeballs if you have some time today.
16:19:44 sdague jaypipes / cdent what's the status on api-ref for placement?
16:20:25 cdent sdague: https://review.openstack.org/#/q/topic:cd/placement-api-ref
16:21:30 cdent sdague: avolkov is working on getting the publishing jobs linked up right. the html drafts are created but not linking into the test results yet
16:21:46 sdague cdent: is the publishing job up for review anywhere?
16:22:19 mriedem markus_z: https://bugs.launchpad.net/nova/+bug/1680363
16:22:19 openstack Launchpad bug 1680363 in OpenStack Compute (nova) "Raise Unexpected API Error when get console log from stopped instance" [Undecided,In progress] - Assigned to Zhenyu Zheng (zhengzhenyu)
16:22:33 mriedem markus_z: UnboundLocalError on https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2801
16:22:43 sdague traits seems big enough I don't want us to be digging too giant of a hole on the docs side, as we know how long it takes to dig out from the past nova experience
16:23:07 cdent sdague: the initial ones have merged, last I talked to avolkov there's more that's WIP, but I don't currently have the details
16:24:02 cdent https://review.openstack.org/#/q/project:openstack-infra/project-config+owner:avolkov%2540mirantis.com+status:merged
16:25:40 sdague cdent: yeh, doesn't seem like any open patches
16:25:59 cdent yeah, I think in this case WIP means "on his disk"
16:26:29 sdague ok
16:28:17 cdent sdague: since we're in the same place at the same time, did you see that I left some notes on the uwsgi etherpad, just some playing around with options https://etherpad.openstack.org/p/devstack-uwsgi ?
16:28:28 sdague cdent: sure
16:28:39 openstackgerrit melanie witt proposed openstack/nova-specs master: Amend spec for placement project/user association https://review.openstack.org/454352
16:29:07 sdague so the line 85 bit
16:29:12 cdent it's opened some question on what we're actually trying to accomplish with uwsgi, logs, etc. because, as ever, there are options...
16:29:28 sdague can you do that without ports
16:30:29 sdague what I'd really like to do is find a way to not have the custom ports used anywhere
16:30:59 openstackgerrit Balazs Gibizer proposed openstack/nova master: Make all timestamps formats equal https://review.openstack.org/421981
16:31:49 sdague which I think means, 1 http server with a lot of /paths, talking to a bunch of uwsgi processes over the local app socket
16:32:02 cdent line 85 can do that
16:32:31 sdague cdent: that I think gets us the most win
16:33:12 cdent is the port issue to make sure that nothing connects to the port (even over localhost) because the first example binds to localhost only, so isn't externally exposed.
16:33:48 markus_z mriedem: OK, will review it tomorrow. Thanks for the notice
16:35:01 mordred sdague: btw - if you get rid of the custom ports, I will buy you a unicornpony
16:35:03 mriedem markus_z: nvm it's latent anyway
16:35:09 mriedem markus_z: easy fix, it's not a regression
16:36:01 sdague cdent: I want nothing to connect to it, because we still have collisions if we require them anywhere

Earlier   Later