Earlier  
Posted Nick Remark
#openstack-nova - 2017-02-24
15:45:04 sdague EmilienM: right, you've said now nova devs are responsible to report issues back
15:45:30 EmilienM sdague: in which room are you?
15:45:38 sdague I'm generally against all that kind of project linkage, we spent so much time decomposing that
15:46:22 EmilienM sdague: let's talk about this thing face to face so we can find a solution
15:46:28 sdague EmilienM: the nova room. But you either get to have me actually figure out this keystone issue, or spend time not convincing me to agree to this
15:46:31 sdague so pick
15:49:55 jroll mriedem: y'all doing priorities/deadlines today?
15:51:40 mriedem jroll: maybe this afternoon
15:51:48 mriedem we're not even close to being done with topics
15:51:56 jroll word, put ironic at the top for me. kthx.
15:52:23 jroll I won't be here this afternoon, so will check the output, thank you :)
15:52:36 mriedem jroll: ironic at the top of the nova priority list?
15:52:45 jroll mriedem: yep
15:52:47 mriedem ok done
15:52:52 jroll \o/
15:54:21 mriedem kevinbenton: do you have a link to the etherpad for the nova/neutron/os-vif xp session that happened on tuesday?
16:01:25 nicodemus_ hello
16:02:07 nicodemus_ is it possible to create two AZs, one that points to the rotational disks of the computes and another that points to the SSD disks on the same compute nodes?
16:02:39 nicodemus_ Or should I have half the computes with SSD in one AZ, and the other half with spinning disks in another AZ?
16:07:01 bauzas nicodemus_: one host can be in two aggregates, but it can be exposed as only one AZ
16:08:53 nicodemus_ bauzas, ok... so I should separate the disks among compute nodes, in order to have a single type ok disk per compute
16:08:56 nicodemus_ right?
16:09:16 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Reserve NUMA nodes with PCI devices attached https://review.openstack.org/364468
16:20:46 mriedem dansmith: jaypipes: we're going to start moving again on misc stuff
16:25:34 mriedem jroll: we're tlaking about virt and metal in the same region
16:26:17 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach/detach Cinder flow https://review.openstack.org/330285
16:26:18 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Remove check_attach https://review.openstack.org/335358
16:27:35 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach/detach Cinder flow https://review.openstack.org/330285
16:27:36 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Remove check_attach https://review.openstack.org/335358
16:29:39 kevinbenton mriedem: it's not clear to me there was one
16:29:49 kevinbenton mriedem: i came into the room an ianw was already talking about specs
16:30:02 mriedem yeah i couldn't find anything
16:30:07 kevinbenton mriedem: so i'm not sure if someone was capturing things in etherpads
16:30:20 mriedem and by ianw you don't mean ianw
16:30:28 mriedem you mean ian wells :)
16:30:40 kevinbenton whoops
16:30:43 kevinbenton ijw: ^^
16:38:27 miss_hypothermia mriedem: I have a dumb question to the reno for remove check_attach
16:39:29 mriedem shoot
16:39:34 miss_hypothermia mriedem: into which section(s) should I put the notes on AZ config for unshelve and blocking the volume until deleting the instance in case of failure?
16:40:23 mriedem i'm thinking 'other'
16:42:15 miss_hypothermia mriedem: ok, thanks
16:56:34 ijw kevinbenton, mriedem: what have I done now?
16:58:38 mriedem ijw: were there notes from the nova/neutron os-vif xp session on tuesday?
16:58:42 mriedem did you have an etherpad?
17:01:24 efried What would be the appropriate channel on which to discuss the current devstack borkage affecting CI?
17:03:26 mriedem efried: probably #openstack-qa
17:03:51 efried mriedem Thanks.
17:07:23 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Implement new attach/detach Cinder flow https://review.openstack.org/330285
17:07:24 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Remove check_attach https://review.openstack.org/335358
17:10:16 sdague EmilienM: as best I can decypher the endpoint for identity looks wrong
17:10:28 sdague I've left a bunch of debugging comments inside the bug
17:15:25 EmilienM sdague: ok, looking. Thanks
17:17:03 EmilienM sdague: you're right, endpoints points to v2.0
17:18:23 EmilienM sdague: while I'm going to update tripleo to use v3 endpoint in our catalog, we need to acknoledge that your patch broke all deployments with keystone v2.0 endpooint and maybe consider a patch in Nova to accept v2 endpoint.
17:37:34 openstackgerrit Anusha Unnam proposed openstack/nova master: fix admin context scenarios for cinderclient https://review.openstack.org/384799
17:43:10 openstackgerrit Takashi NATSUME proposed openstack/nova master: Fix doc generation warnings https://review.openstack.org/425549
17:58:30 openstackgerrit Dan Smith proposed openstack/nova master: Make compute/api instance get set target cell on context https://review.openstack.org/437355
17:58:31 openstackgerrit Dan Smith proposed openstack/nova master: Target cell in conductor cold migrate https://review.openstack.org/438022
17:58:32 openstackgerrit Dan Smith proposed openstack/nova master: WIP: HACK up the mq targeting to only honor what is in the context https://review.openstack.org/438023
17:58:32 openstackgerrit Dan Smith proposed openstack/nova master: Add cell field to Destination object https://review.openstack.org/438024
17:58:32 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025
18:02:55 johnthetubaguy miss_hypothermia I guess its not just our room that is a bit cold today
18:03:59 miss_hypothermia johnthetubaguy: I was suffering yesterday too, but today is worse
18:04:58 miss_hypothermia johnthetubaguy: I'm using people's hot cup of coffee as hand warmer... :)
18:05:33 johnthetubaguy miss_hypothermia: good call this coffee is helping a touch
18:09:23 melwitt dansmith: those changes look clean, pleasantly surprising
18:21:10 miss_hypothermia johnthetubaguy: :)
18:30:17 openstackgerrit Jay Pipes proposed openstack/nova master: placement: ironic inventory reporting https://review.openstack.org/437602
18:32:42 EmilienM sdague: I think you didn't see my irc message here but while I'm going to update tripleo to use v3 endpoint in our catalog, we need to acknoledge that your patch broke all deployments with keystone v2.0 endpooint and maybe consider a patch in Nova to accept v2 endpoint
18:50:28 ijw mriedem: You talk like I had anything to do with it - I was just trying to get a few things by before the Nova peeps turned up
18:50:52 ijw mriedem: but I'll see if Kevin knows anything and write up the details. It amounted to 'we'll do os-vif first'
18:52:54 mriedem EmilienM: that came up in the review and the assertion was keystone v2 has been deprecated since mitaka so by pike people should be running keystone v3 at least, if not both
18:53:07 EmilienM mriedem: and I agree
18:53:16 EmilienM mriedem: but nothing says v2 is prohibited
18:54:34 EmilienM I don't see any release note in Nova that says "do not install nova with keystone v2 endpoints", or I missed it
18:55:01 mriedem https://review.openstack.org/#/c/435010/13/nova/api/openstack/identity.py@40 doesn't mean you can't have v2
18:55:03 mriedem it means you need v3
18:55:22 mriedem but i also don't know why whatever error is in ^ is not handled by that try/except
18:55:54 mriedem "# something is wrong, like there isn't a keystone v3 endpoint,"
18:56:04 mriedem so tripleo has a v3 endpoint but it's wrong?
18:56:11 mriedem i don't know the latest on what the actual break is
18:56:44 EmilienM mriedem: tripleo undercloud has keystone endpoints pointing to v2.0, I'm fixing it now
18:56:49 EmilienM mriedem: to be versionless
19:03:01 oomichi dansmith: can you take a look at https://review.openstack.org/#/c/425958 ? I could not +2 before you
19:04:48 openstackgerrit Sean Dague proposed openstack/nova master: Generate log error message if keystone looks funny https://review.openstack.org/438049
19:05:05 sdague EmilienM: I do agree that we should be nicer to the operator to explain things
19:05:12 sdague that's the patch above
19:05:23 EmilienM I have been testing tripleo with v3 endpoint and it seems to work
19:05:31 EmilienM our overcloud runs v3 by default
19:05:37 EmilienM so our case might be fixed by tonight
19:05:49 sdague But pointing identity endpoint to /v2.0 actually means that no other clients besides keystoneclient can work with v3
19:05:55 EmilienM but I'm wondering if other operators hit it
19:06:12 sdague EmilienM: right, I just added and upgrade release note about that
19:07:08 EmilienM sdague: ok. thx
19:07:29 openstackgerrit Balazs Gibizer proposed openstack/nova master: handle uninited fields in notification payload https://review.openstack.org/415857
19:07:33 satyar Hi everyone
19:07:41 satyar i am running the trunk
19:08:06 satyar it seems when VM goes to error the VCPU is not cleaning up after deletion of VM
19:08:26 satyar anyone aware of this issue?

Earlier   Later