Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-11
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
16:36:13 sdague cdent: I'm starting a new bit at the top about behaviors of the system
16:36:33 cdent sdague: cool, I'll build the example of the l85 version tonight or tomorrow morning, and dump its implications when I do. should be simple-ish
16:39:00 sdague cdent: yeh, before you run off, look at my list of behaviors at the top of that etherpad
16:39:08 sdague and make sure they make sense
16:39:52 cdent they do make sense, thanks for that, will leave some comments
16:41:57 cdent sdague: one question about logs: coming from a webby background I think in terms of an access log and and error log, as showin in one of the examples lower in the doc. uwsgi can have specific request logs if configured to do so but I'm not sure if those logs can go to systemd in the same was as the error log, does that matter
16:43:03 openstackgerrit Balazs Gibizer proposed openstack/nova master: fix null_safe_int when called with 0 https://review.openstack.org/455778
16:43:05 sdague cdent: we're going to be hooking the journal directly in the oslo.log setup I think
16:43:41 sdague i.e. I think we're going to straight bypass that ... but we'll see
16:44:13 cdent okay, but what about request logs (of the access_log vareity). do they matter?
16:44:51 cdent for me they've always been at least as important as the log messages generated by LOG.*('some message')
16:45:03 openstackgerrit melanie witt proposed openstack/nova-specs master: Amend spec for placement project/user association https://review.openstack.org/454352
16:49:02 sdague cdent: honestly, I don't think the access logs are all that useful one way or another, because they are lacking all the identifiable information about request-id / project-id / user-id that let you dig any deeper about what was going on
16:49:17 sdague mostly only really for high level statistics I think
16:49:33 bauzas p!spy
16:49:44 sdague at least that's how I react when I look at something like this - http://logs.openstack.org/31/450431/3/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/38bb8c6/logs/apache/tls-proxy_access.txt.gz

Earlier   Later