Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-11
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?
17:07:58 sfinucan dansmith: Depends on what project the issue is happening in. This isn't nova, is it?
17:08:11 dansmith sfinucan: it's neutron, we're just talking about it in the nova channel
17:08:17 dansmith sfinucan: kidding, yes nova :P
17:08:46 dansmith actually, melwitt, mine seems to still be the py3 thing
17:09:09 sdague yeh, the known broken thing was python3 going on by default
17:09:15 melwitt hmm
17:09:20 dansmith one of my changes is working though so maybe the puppet didn't propagate fully yet
17:09:57 jaypipes sdague: done.
17:10:28 sfinucan dansmith: Yeah, it shouldn't happen for nova. All 'source/conf.py's (doc, api-ref, api-guide) have 'man_page' removed or set to something
17:10:42 sfinucan Hence "this isn't nova" :)
17:15:13 melwitt sfinucan: my failure is happening in nova-specs
17:16:21 melwitt I see 'man_pages = []' under doc/source/conf.py
17:16:42 melwitt so it seems like it shouldn't be failing
17:16:51 melwitt it's not failing locally, only in the gate
17:17:01 melwitt and I rebased it already
17:18:08 melwitt ¯\_(ツ)_/¯
17:18:27 jaypipes melwitt: yeah, I had the same reaction looking at your spec amendment's docs failure :(
17:24:18 openstackgerrit Mario Villaplana proposed openstack/nova master: virt/ironic: Implement rescue and unrescue https://review.openstack.org/416487
17:38:48 cdent sdague: hiccup on mod_proxy_uwsgi: we need this version https://uwsgi-docs.readthedocs.io/en/latest/Changelog-2.0.13.html to get unix socket support, xenial is 2.0.12
17:39:12 cdent do we have a usual solution to such issues?
17:41:44 clarkb cdent: you can ask ubuntu to backport, but generally if its not a bug I don't think they do. The other option is to get it into cloud archive (and then use cloud archive). Or maybe just use tcp?
17:42:17 cdent clarkb: not using tcp is a design goal
17:42:28 cdent clarkb: https://etherpad.openstack.org/p/devstack-uwsgi
17:42:51 openstackgerrit Andy McCrae proposed openstack/nova master: Allow CONTENT_LENGTH to be present but empty https://review.openstack.org/455710
17:43:08 clarkb cdent: to avoid the port allcoation madness?
17:43:15 cdent in part yeah
17:43:34 clarkb another option may be to use not apache if another tls terminator has better uwsgi support?
17:44:26 cdent clarkb: yeah, nginx was the original plan, but we're doing discovery on apache options to see about limit the surface of the change
17:55:25 sdague cdent: we have a certain amount of flexibility in making it a reasonable dev environment, even if it means more change. I'm totally find with the nginx cut over at the same time
17:58:07 clarkb can I selfishly ask that https://bugs.launchpad.net/nova/+bug/1676363 and its associated changes get reviews/input/etc? This is the sort of issue in the pike release that will break us (us being infra) when the noav change that precipitated this hits clouds
17:58:07 openstack Launchpad bug 1676363 in OpenStack Compute (nova) "The network metadata should be more useful" [Medium,In progress] - Assigned to Dr. Jens Rosenboom (j-rosenboom-j)
18:05:56 jaypipes clarkb: looking now.
18:16:13 cdent sdague: added some notes on the hackarounds I did to get mox_proxy_uwsgi working, going to switch to some other things for a while: https://etherpad.openstack.org/p/devstack-uwsgi
18:18:28 openstackgerrit Gábor Antal proposed openstack/nova master: Transform instance.volume_attach.error notification https://review.openstack.org/455801
18:29:04 prabhuraj Hi all, Warm Greetings, someone could review my code https://review.openstack.org/#/c/397471/
18:29:14 prabhuraj https://review.openstack.org/#/c/397459/
18:29:34 mriedem prabhuraj: wrong channel?
18:29:36 mriedem those are fuel patches
18:29:37 mriedem this is nova
18:34:18 clarkb jaypipes: tldr on glean was cloud init couldn't configure rax interfaces and monty went off and made a thing that could. But also cloud init has historically made some very bad choices for us so I think mordred was just looking for an excuse at that point. (distro specific users, mounting volumes in places where we did not wnat them mounted are the two big ones that I recall)
18:34:56 jaypipes clarkb: hey, cool by me. I wasn't complaining about NIH or anything. was genuinely learning about a new thing :)
18:35:08 clarkb ya, just thought I'd explain after seeing your comment :)
18:35:54 clarkb jaypipes: there are days I am grumpy about it (especially when something breaks due to sillyness in glean) but then there are times when we don't break due to something cloud init would have done when I am happy
18:35:56 clarkb :)
18:36:17 jaypipes no worries clarkb :)
18:36:33 clarkb but its become quite common with ironic uses I guess because it groks vlans and stuff
18:36:57 jaypipes clarkb: doesn't cloud-init grok vlans as well? I think it does...
18:37:21 clarkb I think it didn't for a long time?
18:38:01 jaypipes clarkb: ok, done with reviews on that series.
18:38:15 jaypipes clarkb: only thing I'd like to see is prefixlen be an int not a string.
18:38:16 clarkb this is mostly second hand I don't actually do ironic things. VLANs and link aggregation were the two big features they like
18:38:22 jaypipes clarkb: otherwise, looks fine to me.
18:38:27 clarkb jaypipes: awesome thank you for taking a look
18:38:30 jaypipes any time.
18:39:39 jaypipes clarkb: link agg: https://git.launchpad.net/cloud-init/tree/cloudinit/sources/helpers/openstack.py#n590 and vlans: https://git.launchpad.net/cloud-init/tree/cloudinit/sources/helpers/openstack.py#n614 :)
18:44:40 mordred jaypipes: yah -so - when we started in on glean, cloud-init was on a very explicit freeze not accepting new things becaue they were working on a v2
18:44:53 mordred jaypipes: which meant adding support for the network_info.json stuff was a no-go
18:45:03 mordred they have since unfrozen, which is great for everyone
18:45:09 jaypipes cool beans.
18:45:54 mordred so at this point the main difference is size - glean assumes the only thing you want it to do is get networking set up and inject ssh keys - and that you NEVER want to talk to non-config-drive metadata service
18:46:12 mordred cloud-init is much more flexible and lets you inject arbitrary scripts
18:46:20 mordred which some people think is cool
18:47:05 mordred and I support them in that - I, for myself, _never_ want to run scripts via cloud-init because I can run scripts over ssh much more easily and more debuggably :)
18:47:07 dansmith mordred: orly, glean is configdrive-only?
18:47:15 mordred dansmith: yup

Earlier   Later