| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-29 | |||
| 18:02:16 | cfriesen | mriedem: cool, will ping them | |
| 18:02:23 | edmondsw | cfriesen not sure I understood the question | |
| 18:03:04 | cfriesen | edmondsw: there's an issue (https://bugs.launchpad.net/openstack-ansible/+bug/1639940) where with ceph-backed instances/images nova tries to make a new image and then update the location later | |
| 18:03:05 | openstack | Launchpad bug 1639940 in openstack-ansible "Snapshots of instances launched from images fails with Ceph as storage." [Medium,Incomplete] - Assigned to Logan V (loganv) | |
| 18:03:25 | cfriesen | edmondsw: this used to work with glance v1, but with v2 it fails because glance doesn't allow updating the image location | |
| 18:03:52 | cfriesen | edmondsw: we were wondering whether we could use service tokens to allow glance to determine that the request is coming from another openstack service rather than a "normal" user | |
| 18:04:12 | edmondsw | ah, I see | |
| 18:04:37 | edmondsw | today, service tokens are only used re: expirations | |
| 18:04:59 | edmondsw | i.e., if the user token has expired, it'll still allow the operation if the service token isn't expired | |
| 18:05:56 | edmondsw | we have talked about going beyond that, and actually checking policy/RBAC based on service token instead of user token, but that has not been implemented | |
| 18:07:34 | cfriesen | do the APIs exist to allow glance to extract/validate the user token separately? or is that something that would need to be added in keystone? | |
| 18:07:46 | cfriesen | bah, service token, not user token | |
| 18:08:14 | edmondsw | cfriesen looking | |
| 18:08:18 | melwitt | cfriesen: it still fails after setting 'show_multiple_locations = True' as mentioned in comment 7? | |
| 18:08:40 | cfriesen | melwitt: presumably it works, but there are big security warnings about not setting that to True | |
| 18:09:10 | mriedem | cfriesen: this sounds very similar to a bug we have with glance v2 and shelve where the shelved snapshot image has a different set of project_id/user_id than the admin token that tries to get the image when unshelving, | |
| 18:09:17 | mriedem | and i thought we could use the member stuff with glancev2 | |
| 18:09:33 | cfriesen | melwitt: the current recommendation from the glance people was to have a whole separate glance node with a different config file just for nova to talk to it. | |
| 18:09:41 | mriedem | https://bugs.launchpad.net/nova/+bug/1675791 | |
| 18:09:43 | openstack | Launchpad bug 1675791 in OpenStack Compute (nova) "Instance created by demo user(non-admin), shelved by admin and unshelved by demo user --> ends up in error state " [Medium,Triaged] - Assigned to Damini Chopra (damini) | |
| 18:09:44 | melwitt | cfriesen: yeah. from what I understand, the fast clone has the caveat of the security issues | |
| 18:11:12 | melwitt | that is, you have to be in an environment where exposure of the image location urls isn't a problematic in order to use COW clone | |
| 18:11:23 | mriedem | err in the case of shelve, the elevated admin context creates the snapshot, and when the user goes to unshelve the instance, it fails b/c the non-admin user doesn't have access to the image created for them | |
| 18:12:55 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Check for leaked server resource allocations in post_test_hook https://review.openstack.org/538510 | |
| 18:12:56 | mriedem | gibi: cdent: ^ hark back to an old conversation about testing for allocation cleanups | |
| 18:15:33 | mriedem | dansmith: ^ we talked about that in denver i think | |
| 18:18:07 | dansmith | I believe you | |
| 18:18:54 | edmondsw | cfriesen looks like the context object should have info about the service_token if one was used | |
| 18:19:41 | edmondsw | though I think you're probably treading on thin ice trying to use those in a way that they were not really intended to be used | |
| 18:19:54 | edmondsw | better run what you are thinking by lbragstad | |
| 18:27:47 | efried | edleafe Be careful what you ask for. See -dev ML. | |
| 18:31:54 | lbragstad | cfriesen: edmondsw summed it up pretty well, the service token work is kind of a long road.. it sounds like you want to use service tokens to validation/determine more than just a "yes, this token is valid" or "no, it isn't"? | |
| 18:35:34 | edleafe | efried: thanks for that. So if I'm understanding things correctly, the "res.pool" is the root RP that placement would return | |
| 18:35:59 | efried | edleafe: Depends which model we're going with. | |
| 18:36:47 | efried | edleafe: That would be model (C) | |
| 18:39:15 | edleafe | efried: (C) makes the most sense to me, based on my limited familiarity | |
| 18:39:41 | efried | edleafe: But it suffers from at least two drawbacks. | |
| 18:39:43 | edleafe | efried: we don't want to fall into the trap of making everything fit the Nova model | |
| 18:40:32 | efried | edleafe: What do you mean? This *is* nova. | |
| 18:40:47 | efried | edleafe: You mean the libvirt model? | |
| 18:41:35 | edleafe | efried: yeah, like we tried to do with ironic | |
| 18:42:40 | edleafe | efried: from a placement POV, all we care about are the things that the consumer wants us to track. For generic libvirt nova, that would be compute nodes. For vmware nova, it would be resource pools | |
| 18:44:11 | efried | Dig. So we should look toward closing those gaps. In general, we should be working to make nova + placement + <virt> work smoothly, for all values of <virt>. | |
| 18:44:30 | edleafe | yeah | |
| 18:45:00 | edleafe | Placement should always be returning the thing that the consumer needs to proceed with a request | |
| 18:46:15 | efried | I need to close the time box on this. I'm going to make sure the PTG etherpad has an entry for this, and then get back to my regularly-scheduled programming. | |
| 18:46:33 | edleafe | efried: cool. Thanks for writing up that email | |
| 18:46:39 | efried | yahyoubetcha | |
| 19:00:29 | mriedem | jaypipes: melwitt: i'm going to undo the exception code handline refactor in https://review.openstack.org/#/c/538961/ - didn't mean to include that in this patch and it muddies the backpot | |
| 19:00:31 | mriedem | *backport | |
| 19:01:03 | melwitt | ack | |
| 19:04:17 | openstackgerrit | Sen Yang proposed openstack/python-novaclient master: Implement hypervisor hostname exact pattern match https://review.openstack.org/520187 | |
| 19:07:18 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Rollback instance.image_ref on failed rebuild https://review.openstack.org/538961 | |
| 19:07:19 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Collapse duplicate error handling in rebuild_instance https://review.openstack.org/539001 | |
| 19:11:53 | jaypipes | mriedem: +Wallaby'd | |
| 19:12:04 | mriedem | thanks | |
| 19:14:50 | efried | jaypipes: Can we continue the discussion as to whether or not we should in fact be requiring update_provider_tree to return True/False? | |
| 19:18:26 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Rollback instance.image_ref on failed rebuild https://review.openstack.org/539003 | |
| 19:18:29 | cfriesen | lbragstad: just back from lunch. yes, there's a scenario where we would like to answer the question "did this request come from another openstack service, not a 'normal' user". was hoping to use service tokens for this. | |
| 19:20:40 | jaypipes | efried: sure | |
| 19:21:58 | efried | jaypipes: So first off, it's trivial and inexpensive for report client to figure it out, so there's no real *need* for virt to tell us. | |
| 19:22:35 | efried | jaypipes: And after talking through a couple of potential impls from VMWare, it became clear that there's certainly the possibility that it would be awkward for the virt driver to figure it out. | |
| 19:23:11 | efried | jaypipes: For example, one viable implementation is to say, "I don't care what you gave me, I'm going to delete everything and build the ProviderTree as I know it from scratch" | |
| 19:23:34 | lbragstad | cfriesen: that kinda sounds like federation? | |
| 19:23:36 | openstackgerrit | melanie witt proposed openstack/nova stable/pike: Stop globally caching host states in scheduler HostManager https://review.openstack.org/539005 | |
| 19:24:39 | efried | jaypipes: Softer than that, it's IMO a source of extra unnecessary bugs to ask the virt driver to make sure they get that bool return correct. | |
| 19:25:10 | cfriesen | lbragstad: not sure federation applies since it's all within the same cloud. We just want glance to be able to special-case a request to change an image location if it comes from nova, but not if it comes from a regular user. | |
| 19:25:31 | ameeda | gibi: now its okay, can you please merge the bug ? or it need something else ? | |
| 19:25:52 | efried | jaypipes: Put another way: why have two chunks of code doing the same thing when one will do? | |
| 19:26:31 | jaypipes | efried: ok | |
| 19:27:04 | jaypipes | efried: I just thought it would make the RT's life easier if it could say "ok, no changes from virt driver... just move on" | |
| 19:27:12 | lbragstad | cfriesen: oh - sorry, for some reason i was thinking of different services | |
| 19:27:31 | efried | jaypipes: Definitely could have worked out that way. | |
| 19:29:26 | lbragstad | cfriesen: that sounds like new territory for service tokens, the first thing we started working on with them was the whole long running operation issue.. it'd be good to sync with jamielennox though | |
| 19:30:10 | lbragstad | cfriesen: he was one of the original people driving the effort, so i wouldn't be surprised if he's ventured down a couple different paths similar to what you're describing | |
| 19:31:53 | cfriesen | lbragstad: move it over to the keystone channel? | |
| 19:31:58 | lbragstad | cfriesen: sure | |
| 19:36:38 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Rollback instance.image_ref on failed rebuild https://review.openstack.org/539008 | |
| 19:51:41 | ameeda | is this error caused by me ? "http://logs.openstack.org/00/526900/26/check/openstack-tox-functional/c777a93/testr_results.html.gz" | |
| 19:51:47 | ameeda | from this gerrit "https://review.openstack.org/#/c/526900/" | |
| 19:51:57 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove redundant call to add_instance_fault_from_exc in rebuild_instance https://review.openstack.org/539011 | |
| 19:52:19 | ameeda | jaypipes: please check this for me when you available https://review.openstack.org/#/c/526900/ | |
| 19:56:55 | mriedem1 | ameeda: instance_system_metadata is a table where one row is a key/value pair for a single instance, and we can have a lot of sysmeta per instance, and a ton of instances, | |
| 19:57:09 | mriedem1 | in what world do we have a system metadata value that needs to be length TEXT? | |
| 19:58:56 | ameeda | mriedem: so I did something wrong ? | |
| 19:59:56 | mriedem | no, it's just, this is potentially a very large change in storage for that talbe | |
| 19:59:57 | mriedem | *Table | |
| 20:00:08 | mriedem | i see you're trying to match the nova table to glance https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/models.py#L159 | |
| 20:00:12 | mriedem | correct ^ ? | |
| 20:02:35 | mriedem | an alternative solution would be to add an image_props column to the instance_extra table and just store the serialized image properties in there, rather than the instance_system_metadata table | |
| 20:02:55 | mriedem | but then we could have n * TEXT entries in that json blob | |
| 20:03:39 | mriedem | jaypipes: TEXT is not preallocated right? | |
| 20:04:40 | ameeda | mriedem: I am new on openstack , I just follow the bug to fix it, I need to merge this bug. I worked on it a lot as you see :( | |
| 20:04:54 | jaypipes | mriedem: correct. | |
| 20:05:24 | mriedem | ameeda: do you have a customer hitting htis? | |
| 20:05:25 | mriedem | *this | |
| 20:06:54 | jaypipes | ameeda: reviewed. | |
| 20:07:37 | ameeda | I am working at local company here, and the customer ask us to fix bugs in openstack. so I have to get points | |
| 20:07:48 | ameeda | jaypipes: Thank you | |
| 20:08:42 | mriedem | ameeda: hmm, well, there are probably less controversial bugs to fix :) | |