| abhishekk | #startmeeting glance | 14:00 |
|---|---|---|
| opendevmeet | Meeting started Thu Apr 21 14:00:53 2022 UTC and is due to finish in 60 minutes. The chair is abhishekk. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'glance' | 14:00 |
| abhishekk | #topic roll call | 14:01 |
| abhishekk | #link https://etherpad.openstack.org/p/glance-team-meeting-agenda | 14:01 |
| dansmith | p/ (yay DST) | 14:01 |
| abhishekk | o/ | 14:01 |
| rosmaita | o/ | 14:01 |
| mrjoshi | o/ | 14:01 |
| abhishekk | pranali and cyril are not around | 14:01 |
| abhishekk | just wait couple of minutes more before we start | 14:01 |
| jokke_ | o/ | 14:02 |
| pslestang | o/ | 14:02 |
| alistarle | o/ | 14:02 |
| abhishekk | lets start | 14:02 |
| abhishekk | #topic release/periodic jobs update | 14:02 |
| abhishekk | Milestone 1 is 4 weeks away | 14:02 |
| abhishekk | most of the specs are up for review | 14:02 |
| abhishekk | we will walk through them in next section | 14:03 |
| abhishekk | Periodic job, all is green except newly added fips job which has failed | 14:03 |
| dansmith | I thought it was working? | 14:03 |
| abhishekk | it is failing intermittently | 14:04 |
| abhishekk | current execution failed while the previous one has passed | 14:04 |
| dansmith | okay, do you have a link handy to a failed run? | 14:04 |
| dansmith | if not I'll go dig it up | 14:04 |
| abhishekk | https://zuul.opendev.org/t/openstack/build/88b4b25744234bc2ad89cb97525970a7 | 14:05 |
| dansmith | thanks | 14:05 |
| abhishekk | np | 14:05 |
| abhishekk | moving ahead | 14:05 |
| dansmith | more volume fails ugh | 14:05 |
| abhishekk | yes | 14:05 |
| abhishekk | #topic Specs for review | 14:05 |
| abhishekk | I have added 1st draft for API for Instant caching of an Image | 14:05 |
| abhishekk | #link https://review.opendev.org/c/openstack/glance-specs/+/838642 | 14:06 |
| abhishekk | Expanding store details - https://review.opendev.org/c/openstack/glance-specs/+/835606 | 14:06 |
| abhishekk | Delete API for metadef resource types - https://review.opendev.org/c/openstack/glance-specs/+/818192 | 14:06 |
| abhishekk | spec-lite: ability to purge all rows by glance-manage - https://review.opendev.org/c/openstack/glance-specs/+/819622 (one +2) | 14:06 |
| dansmith | ah cool I need to look at that | 14:06 |
| abhishekk | Last one is we agreed on last PTG but it is moved to this cycle | 14:07 |
| abhishekk | So all members, kindly review the spec and give your suggestions | 14:07 |
| abhishekk | moving to next topic | 14:07 |
| abhishekk | #topic Secure RBAC | 14:07 |
| abhishekk | We are yet to get updates from Policy Popup team about our queries | 14:08 |
| abhishekk | meanwhile taking reference of rosmaita's work, pranali has prepared a glance policy matrix for us | 14:08 |
| abhishekk | #link https://review.opendev.org/c/openstack/glance/+/838857 | 14:08 |
| abhishekk | Kindly go through it and verify whether we are mapping it correctly or not | 14:09 |
| rosmaita | nice | 14:09 |
| abhishekk | moving forward; | 14:09 |
| abhishekk | slowly we are learning from you :D | 14:10 |
| abhishekk | #topic glance-download import method | 14:10 |
| abhishekk | #link https://review.opendev.org/c/openstack/glance-specs/+/836132 | 14:10 |
| abhishekk | pslestang, alistarle There are bunch of suggestions on the spec | 14:10 |
| dansmith | I was not aware we were re-discussing this at this meeting or I would have re-reviewed the spec earlier | 14:11 |
| rosmaita | yeah, i have not looked at it yet either | 14:11 |
| alistarle | Yeah we answer couple of the comment | 14:11 |
| pslestang | abhishekk: yes we read them | 14:11 |
| alistarle | thanks for the review btw | 14:11 |
| abhishekk | sorry for that, this was decided last meeting but dansmith you were not around | 14:11 |
| dansmith | ah, okay yeah sorry | 14:12 |
| abhishekk | and I failed to update it this week | 14:12 |
| abhishekk | alistarle, pslestang summary is only copying data from another glance is not useful | 14:13 |
| abhishekk | So if you guys think we can have a virtual discussion for this topic, sometime next week | 14:14 |
| alistarle | So you all agreed that copying metadata is a minimal requirement for the spec right ? | 14:14 |
| dansmith | as I said before, I'm also happy to put my money where my mouth is and help with getting the metadata bits right, although I think alistarle's comment made it sound like he was pretty on top of it | 14:15 |
| dansmith | alistarle: it is, IMHO.. at least hw_* and os_* things | 14:15 |
| abhishekk | os_* but not os_glance_*, right? | 14:15 |
| dansmith | it was good to get feedback from sean because he does a lot of nova stuff with required traits and numa instances and things that are likely to have those bits set and not work without them | 14:16 |
| abhishekk | ++ | 14:16 |
| dansmith | abhishekk: yeah, the os_ things that control stuff in nova like whether or not it's a windows image, which requires other things to be turned on in the hypervisor, etc | 14:16 |
| abhishekk | ack | 14:16 |
| dansmith | alistarle: pslestang: there's not code posted for this yet right? | 14:17 |
| pslestang | not right now | 14:17 |
| dansmith | okay | 14:17 |
| abhishekk | sean has also pointed out some swift example | 14:17 |
| pslestang | but we have some code that works that I can push as a WIP | 14:17 |
| abhishekk | that will be good to see | 14:17 |
| dansmith | abhishekk: the swift temporary url thing, yeah, that's exactly that I was proposing for being able to do this without federation | 14:18 |
| pslestang | abhishekk: acked | 14:18 |
| pslestang | I think it will overlap jokke_ stuff | 14:18 |
| abhishekk | dansmith, yeah, will have a look at it and we can see how feasible it is for us | 14:18 |
| pslestang | about import/export | 14:18 |
| alistarle | dansmith: yeah we talk a bit about it in the spec, but I think it is far more complicated to achieve | 14:18 |
| dansmith | abhishekk: I'm not saying we need to hang up the glance-download stuff on export/temp-url, to be clear | 14:19 |
| abhishekk | yep, me neither | 14:19 |
| dansmith | alistarle: export you mean? yeah, I'm not saying we hold this up for that | 14:19 |
| dansmith | alistarle: but with that sort of temp-url export, all the work you do here will be applicable in that case too, just via a dedicated url instead.. the image show and download will work the same, just no token required | 14:20 |
| jokke_ | Like I've mentioned before ... the export would really have been useful addition ot this work. Definitely not the other way around | 14:20 |
| alistarle | Oh yeah I see, yes we totally agree, but like plestang said it is more a topic related to export work we talk with jokke_ | 14:20 |
| alistarle | But we'll rely on it when it will be ready for sure | 14:21 |
| dansmith | there's also a little bit of terminology confusion here: | 14:21 |
| jokke_ | yeah. Also the swift use case was in the initial Interoperable Image Import spec, never implemented as no-one saw real push/value for that | 14:21 |
| abhishekk | really? | 14:22 |
| dansmith | the temp-url thing I was referring to was more like "take-out" which provides a way to have a non-trusted user access a single image without a user account.. | 14:22 |
| dansmith | "export" being more what jokke_ was talking about where we bundle image and metadata in one file | 14:22 |
| jokke_ | yeah, that was basically Rackspace and once they moved away from active development, no-one else stepped up saying it would be useful | 14:22 |
| dansmith | export can be used by a regular user or via the take-out, | 14:22 |
| dansmith | and glance-download could use export if not authenticated via federation | 14:22 |
| abhishekk | ack | 14:23 |
| dansmith | sorry | 14:23 |
| dansmith | glance-download could use take-out if not federated | 14:23 |
| alistarle | Hmm yeah agree, it is 3 different topic indeed, but who can be interconnected | 14:23 |
| dansmith | man, I need to write it down somewhere :P | 14:23 |
| pslestang | dansmith: ok agree with that and thanks for your clarification | 14:23 |
| abhishekk | definitely | 14:23 |
| dansmith | alistarle: I can write up a summary of the three not on the spot in irc if you want, | 14:24 |
| dansmith | and we can refer to that when we get confused again, if it would help | 14:24 |
| dansmith | just as a sort of potential road map | 14:24 |
| abhishekk | ++ | 14:24 |
| alistarle | Yep, especially if we want to implement them in following cycle | 14:24 |
| abhishekk | Also I think we can have one follow up virtual session to finalize the work items | 14:25 |
| dansmith | yeah, if nothing else, just a "if we're going to do this, we should do it this way" sort of thing | 14:25 |
| dansmith | like jokke_'s draft export spec that isn't planned to be done right away | 14:25 |
| abhishekk | makes sense | 14:26 |
| alistarle | Great, so what is the status for this glance-download spec then ? | 14:26 |
| jokke_ | I think abhishekk had plan to get it worked on once the spec is good to go (so yeah in that light within this group, not in next few cycles) | 14:26 |
| dansmith | I think there's a lot of comments in there to address, put in more detail about the namspaces we're going to copy, behavior of if the format is a mismatch, | 14:27 |
| dansmith | and I think it would be good to document what the client behavior is going to be, as sean brought up confusion there | 14:27 |
| dansmith | alistarle: ^ | 14:27 |
| abhishekk | jokke_, I will be happy to work on it, if the approach is finalized before Milestone 2 | 14:28 |
| alistarle | Ok so let's talk about this metadata, because it was not clear in the PTG, and we needed to talk about it here | 14:28 |
| abhishekk | go ahead | 14:28 |
| jokke_ | yeah, I think there is lots of mixup happening in the spec comments due to that too | 14:29 |
| alistarle | last status during the PTG was to not include the metadata at all, to keep it simple as a first step | 14:30 |
| jokke_ | ++ | 14:30 |
| alistarle | And in the spec it seems we need to include them, so the question are: | 14:31 |
| dansmith | that's not how we left it when I was there... | 14:31 |
| abhishekk | alistarle, that was not the decision, I said I will decide whether we should include hw_ properties or not in later week after PTG | 14:31 |
| alistarle | abhishekk: yes you're right | 14:32 |
| abhishekk | yeah, and looking at comments from nova team, just copying the data is not enough and not a good user experience | 14:33 |
| dansmith | since we had that discussion I've done some more (but not a comprehensive) survey of the critical properties, and hw_ os_ and probably trait: are pretty critical to copy I think | 14:33 |
| alistarle | If we need to include the hw_ properties, do you think we need to include it inside the glance-download plugin ? make it configurable in the json ? or enforce which metadata we copy in the glance configuration ? | 14:33 |
| dansmith | I think always copying those namespaces is fine, no config or option in the request is fine and the simplest to implement | 14:34 |
| jokke_ | I think the comments on the spec tell quite clear story how confusing the metadata part makes this whole feature. And also it being extended on every round of discussion making it even more mess in everyone's heads | 14:34 |
| dansmith | as noted I would *like* to also take a list of other namespaces to copy, but not critical like hw_ os_ etc | 14:34 |
| alistarle | dansmith: we also need to update the container_format and disk_format to match the source image right ? | 14:35 |
| jokke_ | and no, it definitely should not be done by the internal plugin that does the data transfer | 14:36 |
| dansmith | there's a lot of back and forth in the spec, but I don't think I see any arguing or confusion over the metadata like hw_* being important to copy | 14:36 |
| dansmith | alistarle: update or reject, I'm not sure I have a strong opinion either way | 14:36 |
| abhishekk | I think update should be the right approach | 14:36 |
| alistarle | dansmith: we already do it in the image conversion plugin, so I think update is OK, and we can even re-update if needed later in the image conversion plugin | 14:37 |
| dansmith | alistarle: sounded like you preferred update, which is fine with me.. definitely easier for the user | 14:37 |
| dansmith | alistarle: it also means the client can just create the image with any value for those, and let the plugin override them so they're correct, which is much nicer for the user | 14:37 |
| dansmith | like, bare/raw and let it be updated to match | 14:37 |
| alistarle | Yep, that looks good to me | 14:38 |
| dansmith | cool | 14:38 |
| pslestang | and do we add an option to let the customer add his own metadata? | 14:38 |
| dansmith | pslestang: add his own keys or his own namespaces? | 14:39 |
| alistarle | it can be a regex of keys | 14:39 |
| alistarle | so it match keys and namespaces | 14:39 |
| jokke_ | pslestang: no | 14:39 |
| dansmith | alistarle: sure that works... | 14:40 |
| abhishekk | why no, any specific reason? | 14:40 |
| pslestang | jokke_: I defnitely think that we should rely on your export spec, but for the first version of glance-download we need to have a solution that is ok for everyone | 14:42 |
| jokke_ | I think we should either consistently let the user to take care of their metadata or import all we can. Expecting user to write regexp as input to client is turning this same mess the old tasks api was already where we expected json as input from user and that got abandoned as whole due to that | 14:43 |
| alistarle | Ok so let's hardcode the namespace and that's it, right ? | 14:43 |
| dansmith | we're not expecting a user to write a regex, | 14:44 |
| dansmith | we're allowing them to if they have other keys to copy, other than the ones we know need to be copied | 14:44 |
| jokke_ | pslestang: remember that this is stable API we're talking about. We do it one way now, we're stuck with it. We don't break the api consistently and excuse that to microversions | 14:44 |
| pslestang | jokke_: yeah understood | 14:45 |
| alistarle | jokke: I agree we you, we need to take care of the API, so if we are not sure of the solution, let's not touch it | 14:46 |
| alistarle | And as we agree the definitive solution will be related to export stuff or other patch, I propose to hardcode it, so it is easier to move in future patch | 14:46 |
| dansmith | alistarle: I think there's a majority of people here who agree on most of the elements of a direction, so I'd say revise the spec to get us closer to that, address/resolve all the existing comments and we can go from there | 14:47 |
| abhishekk | +1 | 14:48 |
| dansmith | it'll be easier to iterate and discuss a concrete thing than a thing plus a diff of a bunch of comments and discussion | 14:48 |
| abhishekk | and also if you think you are stuck in some part feel free to ping us | 14:48 |
| alistarle | great, clear for me | 14:49 |
| abhishekk | cool | 14:49 |
| abhishekk | moving to open discussion | 14:49 |
| abhishekk | #topic Open discussion | 14:50 |
| abhishekk | #link https://review.opendev.org/c/openstack/glance/+/838822 | 14:50 |
| abhishekk | Update migration constant | 14:50 |
| abhishekk | Kindly review the patch, easy one and important one | 14:50 |
| abhishekk | Also I think pranali has forget to include export draft in review list | 14:51 |
| abhishekk | #link https://review.opendev.org/c/openstack/glance-specs/+/837127 | 14:51 |
| jokke_ | abhishekk: is that ^^ the alembic thingie we need to do every cycle? | 14:51 |
| abhishekk | jokke_, yep | 14:51 |
| jokke_ | gating | 14:52 |
| abhishekk | cool, thank you | 14:52 |
| abhishekk | dansmith, I am also not aware but looks like alembic migration depends on that | 14:53 |
| dansmith | abhishekk: I don't think the other projects have to do this sort of thing | 14:53 |
| jokke_ | it's part of how the migration scripts gets picked up iirc | 14:53 |
| abhishekk | they might have implemented the script execution differently | 14:53 |
| abhishekk | Something in our glance-db-manage needs to be fixed | 14:54 |
| dansmith | abhishekk: clearly they did, I'm just saying it seems like maybe something we could resolve | 14:54 |
| jokke_ | I think glance was the first one that got implemented and some of the inconveniences were quite quickly picked up and done differently elsewhere | 14:54 |
| abhishekk | ++ | 14:54 |
| abhishekk | dansmith, agree | 14:54 |
| abhishekk | Nothing else form me | 14:55 |
| abhishekk | last 5 minutes | 14:55 |
| jokke_ | I think it's one of the things that 10min of work every year has not yet warranted anyone dig deep enough into it to change the beaviour :P | 14:55 |
| dansmith | right :) | 14:56 |
| abhishekk | :D, lets change it this cycle | 14:56 |
| abhishekk | anything else guys? | 14:57 |
| jokke_ | I'm pretty sure you could tie it to pbr somehow | 14:57 |
| jokke_ | not from me | 14:57 |
| abhishekk | cool, lets wrap up | 14:58 |
| abhishekk | thank you all! | 14:58 |
| abhishekk | have a nice weekend o/ | 14:58 |
| abhishekk | #endmeeting | 14:58 |
| opendevmeet | Meeting ended Thu Apr 21 14:58:34 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:58 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/glance/2022/glance.2022-04-21-14.00.html | 14:58 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/glance/2022/glance.2022-04-21-14.00.txt | 14:58 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/glance/2022/glance.2022-04-21-14.00.log.html | 14:58 |
| *** dasm is now known as dasm|off | 23:57 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!