Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-11
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
16:49:48 cdent huh, I think they're the least noisy way to answer the question: is the service getting the hits I expect
16:50:08 cdent but it's not really an issue, that info is a variety of places
16:52:08 sdague yeh, and with the journal, that should be a better way to see it. The logging standards are that those things should be in the INFO block, which should be easy to query.
16:52:55 melwitt has anyone seen a docs job failure like this? "WARNING: no "man_pages" config value found; no manual pages will be written"
16:53:11 dansmith melwitt: my docs job is failing too
16:56:34 openstackgerrit Balazs Gibizer proposed openstack/nova master: fix null_safe_int when called with 0 https://review.openstack.org/455778
16:59:36 jaypipes bauzas: have you checked out https://etherpad.openstack.org/p/new-instance-reservation ?
17:00:17 sdague jaypipes / bauzas / cdent - https://bugs.launchpad.net/nova/+bug/1681658
17:00:17 openstack sdague: Error: Could not gather data from Launchpad for bug #1681658 (https://launchpad.net/bugs/1681658). The error has been logged
17:00:29 sdague oh... thank you openstack bot :P
17:01:21 cdent sdague: that's correct behavior: max_unit means you can't have more than max_unit
17:01:30 cdent it's doesn't depend on allocation_ratio
17:01:54 cdent total capacity does
17:02:10 sdague cdent: ok, cool, can you update the bug with why it's a Won't Fix then?
17:02:13 cdent sdague: you wanna get that or shall I?
17:02:17 cdent jinxish
17:02:21 cdent yeah, will do
17:03:56 sfinucan dansmith, melwitt: It's a broken gate. There was a bot message on infra or docs a while back
17:04:08 dansmith sfinucan: that was for the py3 thing
17:04:13 dansmith which was supposedly already fixed
17:04:29 sfinucan Oh, wait - different issue
17:05:26 sfinucan the no man_pages thing can be fixed by removing same from Sphinx's conf.py or setting 'builders = html' in '[build_sphinx]' of 'setup.cfg'
17:06:03 sfinucan blame pbr being too clever for its own good :(
17:06:31 sfinucan https://github.com/openstack-dev/pbr/blob/master/pbr/builddoc.py#L66
17:07:08 dansmith sfinucan: are you saying that something has changed in some package such that we're dead until we start doing that?

Earlier   Later