| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-24 | |||
| 15:27:38 | openstackgerrit | Ryan Rossiter proposed openstack/nova master: Remove run_tests.sh https://review.openstack.org/437947 | |
| 15:30:15 | EmilienM | sdague: ok thanks | |
| 15:30:49 | EmilienM | mriedem, sdague: could we revisit https://review.openstack.org/#/c/428424/ please? | |
| 15:30:55 | sdague | EmilienM: there is also no user identity being logged in the logs for API calls, so it's hard to figure out what is happening | |
| 15:30:59 | EmilienM | I think tripleo jobs bring good feedback | |
| 15:32:54 | rcarrillocruz | johnthetubaguy: oh, that for linking, that makes sense | |
| 15:36:53 | sdague | EmilienM: I'm definitely -1 on per commit runs of that | |
| 15:40:58 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Reserve NUMA nodes with PCI devices attached https://review.openstack.org/364468 | |
| 15:42:45 | EmilienM | sdague: did you read the commit message, | |
| 15:42:47 | EmilienM | ? | |
| 15:42:53 | EmilienM | "The theory here is that Nova devs are going to dig through these," | |
| 15:43:04 | EmilienM | you're wrong, if you read the commit message, I said the opposite | |
| 15:43:19 | EmilienM | " The | |
| 15:43:21 | EmilienM | job would be non-voting for now, please don't ignore it and report | |
| 15:43:23 | EmilienM | failures on #tripleo or ping EmilienM on #openstack-nova. If nobody | |
| 15:43:25 | EmilienM | replies shortly or don't give feedback on the failure, you can ignore | |
| 15:43:27 | EmilienM | it and move forward in your review process. Though we hope it can be | |
| 15:43:29 | EmilienM | useful to track some bugs." | |
| 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 | |