Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-31
01:49:55 openstackgerrit Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 discover_hosts https://review.openstack.org/421442
01:49:55 openstackgerrit Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 list_cells https://review.openstack.org/421458
01:49:56 openstackgerrit Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 create_cell https://review.openstack.org/421444
01:53:04 diana_clarke Now I need to switch to a GitHub workflow. I've grown to really like Gerrit.
01:55:33 artom diana_clarke, gerrithub?
01:56:09 diana_clarke artom: is that a thing... off to google it
01:59:17 melwitt mriedem: I just looked at the cells v1 job "Failed to get metadata for IP 10.1.3.255: no metadata" in n-api logs and I think it's normal in that, the error means it couldn't lookup a FixedIP by address. and in cells v1 fixed_ips are populated only in the child cell database, so any reads from the api cell will yield not found
02:06:06 mriedem melwitt: should that be an ERROR though?
02:06:15 mriedem plus, has that changed recently?
02:06:18 mriedem i don't remember seeing that before
02:06:24 melwitt for non cells v1, yes
02:06:44 melwitt and agreed I don't remember seeing it repeatedly. I thought it used to only show it once. so I'm not sure what changed
02:10:02 openstackgerrit ChangBo Guo(gcb) proposed openstack/nova: rbd: Remove unnecessary 'encode' calls https://review.openstack.org/412356
03:06:55 mriedem so, bauzas' scheduler change has failed in the gate twice in the cells v1 job on the volume swap test...
03:07:25 mriedem and https://review.openstack.org/#/c/399735/ merged today
03:08:17 mriedem and we don't run the cells v1 job on the check queue for devstack, which re-enabled the test
03:08:36 mriedem https://review.openstack.org/#/c/374373/
03:08:44 mriedem but i'm pretty sure that just introduced some kind of weird race failure
03:08:46 mriedem lyarwood: ^
03:11:24 mriedem mdbooth: ^
03:12:50 mriedem looks like it's also killing the ceph job
03:16:15 mriedem i'm assuming this is probably just something to do with cells v1 not supporting the swap volume API
03:17:34 mriedem https://bugs.launchpad.net/nova/+bug/1660511/
03:17:35 openstack Launchpad bug 1660511 in OpenStack Compute (nova) "TestVolumeSwap.test_volume_swap fails in cells v1 job waiting for first volume to detach" [High,Confirmed]
03:18:39 mriedem melwitt: if cells v1 doesn't support the swap volume API, shouldn't it fail in some kind of spectacular way?
03:19:28 melwitt mriedem: cells v1 non support usually fails in subtle crappy ways, in my experience
03:20:27 mriedem yeah that seems to be the case here
03:20:45 mriedem i was looking at the requests in a failed job earlier and at some point it looked like something just didn't happen,
03:20:49 mriedem like one of the requests just stopped
03:20:52 melwitt is this a new test, i.e. something that needs to be added to the blacklist?
03:21:01 mriedem it's a newly enabled test as of today
03:21:03 mriedem based on tempest config
03:21:04 melwitt ah
03:21:08 mriedem so i'm going to disable it for cells v1 in devstack
03:21:18 mriedem we could also blacklist it in nova,
03:21:30 mriedem which would probably actually make this go faster since we can fast approve it and not wait for devstack cores
03:21:33 mriedem mtreinish: are you around?
03:21:40 melwitt oh, disable the tempest conf option if cells v1 in devstack
03:22:26 mriedem yeah
03:22:28 mriedem i'm doing that now
03:24:32 mriedem https://review.openstack.org/427009
03:26:10 mriedem if i don't get a quick ack from the cores i've pinged, i'll push up a blacklist patch in nova and just move forward that way
03:27:06 melwitt okay
03:30:19 openstackgerrit Matt Riedemann proposed openstack/nova: Blacklist test_volume_swap from cells v1 testing https://review.openstack.org/427013
04:48:39 abhishekk is there any provision in nova to restrict users from addind certain metadata to server?
04:49:55 mriedem here is the not-so-subtle error http://logs.openstack.org/06/425806/8/check/gate-tempest-dsvm-cells-ubuntu-xenial/ab0bba2/logs/screen-n-cell-child.txt.gz?level=TRACE#_2017-01-31_01_25_10_115
06:59:17 openstackgerrit Dinesh Bhor proposed openstack/nova: Remove unused exceptions from nova.exception https://review.openstack.org/427041
08:06:18 openstackgerrit Balazs Gibizer proposed openstack/nova: reno for notification-transformation-ocata https://review.openstack.org/426810
08:54:12 openstackgerrit Takashi NATSUME proposed openstack/nova-specs: List/show all server migration types https://review.openstack.org/407237
08:56:37 tdurakov pkoniszewski:hi, left several comments on liv-mig claim patch, could discuss them on irc if you want
09:08:51 openstackgerrit Takashi NATSUME proposed openstack/nova-specs: Fix formatting errors and warnings https://review.openstack.org/407364
09:10:34 openstackgerrit sahid proposed openstack/nova-specs: Libvirt driver emulator threads placement policy https://review.openstack.org/427066
09:26:09 openstackgerrit Takashi NATSUME proposed openstack/nova: Avoid forcing translation on logging calls https://review.openstack.org/413876
09:42:15 openstackgerrit Jordan Pittier proposed openstack/nova: Fix unspecified bahavior on GET /servers/detail?tenant_id=X as admin https://review.openstack.org/426259
09:45:19 abhishekk hi all, is there any provision in nova to restrict users from adding certain metadata to server?
09:59:01 openstackgerrit Takashi NATSUME proposed openstack/nova: Refactor a test method including 3 test cases https://review.openstack.org/394738
10:01:48 openstackgerrit John Garbutt proposed openstack/nova: DNM: hack ironic with resource providers https://review.openstack.org/426296
10:13:57 johnthetubaguy bauzas: are you around by any chance, and do you have the context around the ironic changes?
10:21:59 bauzas johnthetubaguy: I'm here yup
10:22:33 johnthetubaguy bauzas: I wondered if you could check my comments on this patch: https://review.openstack.org/#/c/404472
10:22:41 johnthetubaguy not sure if I am talking nonsense or sense
10:23:49 andymccr morning all - im having a few issues with the placement service, was hoping for a bit of guidance. The first is that it seems you can't define which endpoint interface compute connects to placement on. (I put a PR in for that which worked for me but I may be way off the mark: https://review.openstack.org/#/c/426163/ )
10:23:50 openstackgerrit Alex Szarka proposed openstack/nova: Transform instance.add_fixed_ip notification https://review.openstack.org/332876
10:25:09 andymccr secondly, i get a 409 on the first PUT from the compute host, 200 on all GETs but then 400's on subsequent PUTs. The errors are vague though - I'm not too sure what steps I can take to debug that further.
10:29:44 johnthetubaguy andymccr: hmm, interesting
10:29:53 johnthetubaguy andymccr: the endpoint is picked using the keystone service catalog
10:30:02 johnthetubaguy (or should be)
10:30:34 johnthetubaguy andymccr: oh, the interface
10:30:34 andymccr johnthetubaguy: yeah it is, but it forces "public" afaict because the keystoneauth endpoint_filter doesnt include an interface option when passed by nova
10:30:46 johnthetubaguy should we really default to private?
10:31:05 andymccr my pr defaults it to public - so in essence, no change if you don't set it
10:31:33 andymccr internal works for my usecase, but not sure it'd work for everybody - so figured its best to not change things like that midway :) rather make them changeable.
10:32:04 andymccr i imagine in things like role gates/devstack it makes no difference since the endpoints are probably all the same regardless of internal/public
10:32:21 johnthetubaguy its an admin only API (at least by design) so its probably a mute point
10:33:01 andymccr if its admin only perhaps it should default to admin instead?
10:33:32 andymccr from my pov, i need it to not be public or else i have to do some munging when i create endpoints to ensure the public endpoint is created differently to all other public endpoints and uses the internal ip
10:34:24 johnthetubaguy oh, possibly, yeah, default to admin makes more snese
10:35:47 johnthetubaguy in theory non admin users would just get 403 errors I think, but its good to message that better
10:36:23 johnthetubaguy bauzas: cdent: do you have better context on the intended deployment stuff, for our OSA friends?
10:37:09 bauzas johnthetubaguy: sorry, I had an internal problem
10:37:29 bauzas and I'm very busy, so could you please explain me the issue ?
10:37:55 johnthetubaguy bauzas: service catalog, we default to accessing the "public" URL for placement
10:38:05 johnthetubaguy that seems odd, given its an admin only API
10:38:10 andymccr (and you can't override it afaict)
10:38:25 bauzas lemme verify something
10:38:47 bauzas I think nova just doesn't use the public field
10:39:00 johnthetubaguy it seems to, because of how keystone auth works
10:39:19 johnthetubaguy infact it only uses the public field, if I am remembering correctly
10:39:37 bauzas :/
10:41:31 toabctl mriedem, hey. anything I can do to push https://review.openstack.org/#/c/402318/ ?
10:41:33 bauzas johnthetubaguy: AFAIK, we don't have yet policies
10:42:43 johnthetubaguy bauzas: I was wondering about that... uh, oh
10:47:13 johnthetubaguy I think we are OK for policy, looking at this: https://github.com/openstack/nova/blob/a0100d61a9531a3e32f2c72eab54157c32114f5b/nova/api/openstack/placement/handler.py#L175
10:48:28 bauzas agreed
10:50:05 gmann johnthetubaguy: can you look into release notes patch of sort/filter things - https://review.openstack.org/#/c/421760/
10:50:18 gmann johnthetubaguy: i have removed the all_tenant policy bits from there
10:50:22 bauzas johnthetubaguy: when I wrote the PlacementFixture, I saw that it was returning 401s if I wasn't auth'd
10:50:27 johnthetubaguy gmann: ah, we trimmed it down, cool
10:50:29 bauzas now I remember that
10:50:40 gmann yea

Earlier   Later