| jakeyip | hi all, just checking to see who is around and interested for a meeting. please populate agenda here. | 08:28 |
|---|---|---|
| jakeyip | I have a (WIP) spec that captures some of the discussion over vPTG. needs some eyes https://review.opendev.org/c/openstack/magnum-specs/+/900410 | 08:29 |
| jakeyip | dalees: I saw your comment and will ack them later, thanks! | 08:30 |
| dalees | jakeyip: hello, I'm around today | 08:42 |
| jakeyip | dalees: let me know if you have anything, I'm driving atm, may be 10 mins late | 08:53 |
| travisholton | hello all | 08:58 |
| mnasiadka | I'm here if needed | 09:05 |
| jakeyip | I'm here too | 09:12 |
| jakeyip | ##startmeeting magnum | 09:12 |
| jakeyip | #startmeeting magnum | 09:12 |
| opendevmeet | Meeting started Wed Nov 15 09:12:53 2023 UTC and is due to finish in 60 minutes. The chair is jakeyip. Information about MeetBot at http://wiki.debian.org/MeetBot. | 09:12 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 09:12 |
| opendevmeet | The meeting name has been set to 'magnum' | 09:12 |
| jakeyip | Agenda: | 09:13 |
| jakeyip | #link https://etherpad.opendev.org/p/magnum-weekly-meeting | 09:13 |
| jakeyip | #topic Roll Call | 09:13 |
| jakeyip | o/ | 09:13 |
| travisholton | o/ | 09:13 |
| dalees | o/ | 09:14 |
| jakeyip | mnasiadka: ? | 09:14 |
| mnasiadka | o/ | 09:14 |
| jakeyip | thanks all | 09:15 |
| jakeyip | please put discussion items in etherpad | 09:15 |
| jakeyip | #topic improve-driver-discovery spec | 09:15 |
| jakeyip | I've wrote up something to capture the discussion. https://review.opendev.org/c/openstack/magnum-specs/+/900410 hopefully that gives us a good base | 09:16 |
| jakeyip | need help and eyes on it | 09:16 |
| dalees | thanks for writing that down jakeyip , much appreciated. | 09:16 |
| jakeyip | no worries, happy to move it on | 09:17 |
| jakeyip | so I've been hemming and hawwing because I am unsure which alternative was the best, given all the changes that are happening | 09:18 |
| jakeyip | I guess we just need to fix something, and make it work | 09:18 |
| dalees | I've given my feedback today, but it's fairly minor. We need the driver tiebreak and we can move on with the CAPI drivers | 09:19 |
| jakeyip | dalees: thanks for your feedback | 09:20 |
| jakeyip | there's no pressure to read that spec at this meeting, happy to have a week to input comments and a discussion about it next meeting | 09:20 |
| dalees | yeah - it'll require a little refactor in the driver loading system, but then the driver selection tiebreak can be done. Almost all the options do expose the Magnum user to the driver concept, but it seems unavoidable with multiple drivers for one tuple. | 09:20 |
| noonedeadpunk | o/ | 09:21 |
| jakeyip | my opinion is they need to know driver specific details already currently, like os_distro=fedora_coreos | 09:22 |
| jakeyip | which isn't actually an os_distro label | 09:22 |
| jakeyip | hi noonedeadpunk | 09:22 |
| mkjpryor | Using image properties to do it still ties an image to a driver, which mirrors the current situation | 09:22 |
| mkjpryor | And if the operator uploads the images and creates the templates, and blocks the creation of new templates, the user still doesn't need to know about drivers | 09:23 |
| mkjpryor | Even if they allow custom templates, the operator-uploaded images would select the correct driver | 09:23 |
| jakeyip | good point mkjpryor | 09:23 |
| mkjpryor | So I guess that is me saying that I quite like it | 09:24 |
| jakeyip | :) | 09:24 |
| mkjpryor | I don't like the idea so much of co-opting the os_distro label to do explicit driver selection in the tie-break case. It feels like we should have our own label to do that | 09:24 |
| mkjpryor | That way it also reduces to the current situation in the case where you have no clashes as well | 09:25 |
| mnasiadka | What about adding another cluster template property that ties to the driver, if unspecified then we fall back to what we have today? | 09:25 |
| mkjpryor | Yeah - that is jakes proposal one I think | 09:26 |
| mkjpryor | Ah - cluster template property | 09:26 |
| jakeyip | mkjpryor: the proposal calls for using another glance image property. ln 83-89 | 09:26 |
| jakeyip | mnasiadka: cluster template property will require client change. we can also use label | 09:27 |
| mnasiadka | glance image property ties that image to a specific driver, in a cloud where users can upload their own image and create their own cluster template - this is going to be a problem | 09:27 |
| dalees | mnasiadka: we we discussed that, it felt like it necessitates exposing an API to list enabled drivers. But on reflection maybe the image property does in a similar way. | 09:27 |
| mnasiadka | well, if the goal is that we try to make it with minimal effort and easy backporting - then sure, we don't want an API impact | 09:28 |
| jakeyip | mnasiadka: in the current implmentation, the user already has to find out driver specific information like os_distro=fedora_coreos for setting on their own image. I feel it isn't a big leap for another image property specifying the driver name | 09:29 |
| jakeyip | I noted in the spec that the 'correct' os_distro label should be 'fedora' . 'fedora-coreos' is a magnum thing | 09:30 |
| mnasiadka | os_distro is one of the ,,standard'' glance image properties | 09:30 |
| mnasiadka | #link https://docs.openstack.org/glance/latest/admin/useful-image-properties.html | 09:30 |
| mnasiadka | And people learned that over time | 09:30 |
| mnasiadka | But maybe it's enough | 09:30 |
| jakeyip | https://gitlab.com/libosinfo/osinfo-db/-/blob/v20231027/data/os/fedoraproject.org/coreos-stable.xml.in?ref_type=tags#L10 | 09:31 |
| jakeyip | anyway they can't put any image and expect it to work with CAPI driver. they have to build a CAPI image and select a CAPI driver | 09:31 |
| jakeyip | it's not like heat | 09:31 |
| mnasiadka | ok then, why not | 09:32 |
| mkjpryor | The difference for me is that if we use an _image_ property, then users only creating custom templates don't need to worry about drivers - they just specify the image that the operator uploaded with the correct properties | 09:32 |
| mnasiadka | In order to allow custom image properties, Glance must be configured with the glance-api.conf setting allow_additional_image_properties set to True. (This is the default setting.) | 09:32 |
| mnasiadka | hmm | 09:32 |
| mnasiadka | well, I guess nobody disables that today | 09:32 |
| mkjpryor | Is there a good reason to disable it? | 09:33 |
| mnasiadka | probably not | 09:33 |
| mkjpryor | So if we use an extra image property to break the tie-break, users don't need to know about drivers in order to create custom templates which is nice | 09:34 |
| mnasiadka | especially the operator would loose all custom image properties, eg the Nova ones as well | 09:34 |
| mnasiadka | (if they would disable it) | 09:35 |
| mkjpryor | If a user is uploading a custom image, especially for the CAPI drivers, I would argue that is an advanced enough use case that expecting them to know the driver names and set an extra property is not an unreasonable expectation | 09:35 |
| dalees | mkjpryor: yeah, agreed - the image property keeps it confined to one place the operator is likely to manage. it does lock one CAPI image into one driver, but the use case for having two CAPI drivers enabled is to transition, so it's less likely to want the same image for both (and you could just upload twice). | 09:35 |
| mkjpryor | dalees: It would be nice if Glance could recognise that the two images have the same checksum and not store them twice though :D | 09:36 |
| mkjpryor | But yeah - for transition I think it is fine | 09:37 |
| mnasiadka | well, ideally a user should be able to override the driver on each of those three levels (image, cluster template, cluster) - but maybe let's go with the image only (since it's for transition time) - and see if there are any corner cases users would report | 09:38 |
| jakeyip | cool | 09:40 |
| jakeyip | sorry was having a browse in glance source wondering if os_distro is a build in or extra property :D | 09:40 |
| jakeyip | a grep shows https://github.com/openstack/glance/blob/stable/2023.2/glance/async_/flows/api_image_import.py#L85-L92 | 09:41 |
| jakeyip | nothing concrete, don't worry about it too much | 09:41 |
| mkjpryor | I don't have a problem with also adding a template field to override the driver choice | 09:41 |
| mkjpryor | I actually don't think it should be customisable on the cluster level | 09:41 |
| jakeyip | mkjpryor: that needs API update, was hoping to avoid that | 09:42 |
| jakeyip | unless we use labels :) | 09:42 |
| mkjpryor | I think it can happen in a second patch if we decide we really want it after using the image property for a bit | 09:42 |
| jakeyip | yeap | 09:42 |
| jakeyip | I think mostly all fine? please leave review if you have concern, I'll tidy up and maybe we aim for a spec merge in 1 or 2 weeks | 09:43 |
| jakeyip | I'm also going to try find some time to do the POC and send up code for it | 09:44 |
| jakeyip | let's move on | 09:44 |
| jakeyip | #topic CI tests | 09:44 |
| jakeyip | mnasiadka: are you blocked on anything? | 09:45 |
| mnasiadka | I'm blocked on my time, I might have some on Friday to fix the failed deploy log collection | 09:45 |
| mnasiadka | because that's the only thing that is not working for now | 09:45 |
| jakeyip | mnasiadka: I think if the passing case is OK, you can submit it | 09:47 |
| mnasiadka | ok, I'll shape it up in current form and ask for final reviews | 09:48 |
| jakeyip | it's still useful, we can use it to test if deprecating the swarm driver and stuffs will get a -1 , | 09:48 |
| jakeyip | thanks | 09:48 |
| jakeyip | #topic spec resize master count | 09:48 |
| jakeyip | dalees: | 09:49 |
| dalees | just wanted to briefly mention this - I've tested and have this working in CAPI helm, masters can size between 1, 3 and 5. | 09:49 |
| dalees | I'd like to write a spec and implement this in the driver interface, so existing (heat) will not support resize, but CAPI can if it wanted to | 09:50 |
| dalees | s/masters/control plane/ | 09:50 |
| jakeyip | dalees: I think that will be very useful for people who started with 1... :D | 09:50 |
| jakeyip | qn: can it scale down? | 09:51 |
| dalees | yep, any odd number, both up and down. | 09:51 |
| jakeyip | ok | 09:52 |
| jakeyip | we are almost at time. dalees anything else for this topic? | 09:52 |
| dalees | no, just mentioning at this point. I will write the spec | 09:53 |
| jakeyip | #action dalees to write spec | 09:53 |
| jakeyip | #topic ClusterAPI | 09:53 |
| jakeyip | everyone's favorite :) | 09:53 |
| dalees | mkjpryor: thanks for the reviews; I was about to ask ;) | 09:54 |
| jakeyip | I have a question - we need to fork the Helm Chart hosted by Magnum | 09:54 |
| jakeyip | can someone help? | 09:54 |
| dalees | jakeyip: which helm chart? the stackhpc capi one? | 09:55 |
| jakeyip | dalees: yeah | 09:55 |
| jakeyip | I mean, this doesn't _need_ to happen until we merge StackHPC in tree. but I'm interested if someone already knows how to do this or is already doing this | 09:56 |
| jakeyip | dalees: I think you mentioned you were working on OCI version of helm chart? | 09:56 |
| dalees | I created a repo for it in opendev, but now I realise that to fork properly(and keep commits) the source git repo should be specified on creation. So we may need to delete and re-create when we're ready to merge the driver | 09:56 |
| jakeyip | can a fork in opendev work? I was under the impression it may require to build the site in Github pages? | 09:57 |
| dalees | jakeyip: helm charts can be uploaded to an OCI registry, so this can be too. The OCI support just needed to be in the capi helm driver (and it now is, thanks johnthetubaguy) | 09:57 |
| dalees | https://helm.sh/docs/topics/registries/ | 09:58 |
| mkjpryor | dalees: in the next couple of months I want to look at moving all our Helm charts to OCI, so it will probably happen by default for the CAPI Helm charts at some point | 09:58 |
| dalees | mkjpryor: cool - we host stackhpc charts in our OCI and the magnum-capi-helm driver works nicely with it. | 09:59 |
| noonedeadpunk | so, for ones with limited connectivity, would need either to source stackhpc repo or have a clone of whole OCI registry? | 09:59 |
| dalees | noonedeadpunk: yes, but that's true for loads of OCI images that are required to boot a k8s cluster. | 10:00 |
| mkjpryor | It becomes exactly like you would do for a Docker image - just mirror the repository into your own registry | 10:00 |
| noonedeadpunk | well, just source is a bit concenring as a requirement for in-tree driver | 10:01 |
| dalees | it ends up being a single asset in a OCI registry | 10:01 |
| mnasiadka | dalees: it's not going to work that way - we just need to push all the commits with history (the fork) | 10:01 |
| mnasiadka | well, not history even | 10:02 |
| noonedeadpunk | yeah, and indeed it needs repo to be dropped and re-created... | 10:02 |
| mnasiadka | one commit | 10:02 |
| noonedeadpunk | which is kinda sucks if it's already under governance... | 10:02 |
| noonedeadpunk | as then it indeed has quite some overhead | 10:02 |
| noonedeadpunk | but indeed would be nice if it is moved with whole history | 10:03 |
| jakeyip | dalees: can you drive this? since you have the most experience | 10:04 |
| mnasiadka | basically easiest would be to push the code in one commit, add Co-Authored-By for all authors | 10:04 |
| noonedeadpunk | another tip for moving to opendev - it can not contain any zuul config files | 10:04 |
| noonedeadpunk | (during forking) | 10:04 |
| dalees | jakeyip: i have experience in doing it wrong :) But yep I can figure out removing the empty repo, and we can fork the charts properly into governance with history once the driver merges. | 10:05 |
| noonedeadpunk | yeah, that would be another way around, depending how much we wanna preserve history | 10:05 |
| jakeyip | mnasiadka: if there is no requirement from OpenStack and StackHPC is fine with us doing this, that is good idea | 10:05 |
| dalees | repo link: https://opendev.org/openstack/magnum-capi-helm-charts | 10:06 |
| mnasiadka | I'll leave the ''StackHPC is fine with us doing this'' to mkjpryor | 10:06 |
| jakeyip | that will allow us to start with bare minimum, instead of forking and backing out some of the StackHPC addition like GPU | 10:07 |
| jakeyip | #action dalees to look into hosting helm chart | 10:07 |
| jakeyip | we are over time, let's call the meeting. leave something for next meeting | 10:07 |
| mkjpryor | The charts are released under the Apache 2.0 licence so whether we are fine with it or not isn't a deal breaker | 10:08 |
| mkjpryor | :D | 10:08 |
| jakeyip | mkjpryor: hahaha | 10:08 |
| jakeyip | well legally correct and morally wrong isn't a path Magnum Core Team should take ;) | 10:08 |
| mkjpryor | But I think the ambition was always that they would become a community resource that represents best practice for deploying CAPI clusters on OpenStack | 10:08 |
| jakeyip | #endmeeting | 10:09 |
| opendevmeet | Meeting ended Wed Nov 15 10:09:21 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 10:09 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/magnum/2023/magnum.2023-11-15-09.12.html | 10:09 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/magnum/2023/magnum.2023-11-15-09.12.txt | 10:09 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/magnum/2023/magnum.2023-11-15-09.12.log.html | 10:09 |
| mkjpryor | So I personally don't have a problem with it. I guess I would naturally become a maintainer on that project | 10:09 |
| jakeyip | Sorry I have to end meeting as I have someone waiting for me. please feel free to continue | 10:09 |
| mkjpryor | No worries | 10:09 |
| jakeyip | seeya next week | 10:09 |
| mkjpryor | We have our company all hands next week so there probably won't be any StackHPC folks attending | 10:10 |
| jakeyip | gotcha | 10:10 |
| dalees | ok, thanks for joining all. | 10:10 |
| dalees | noonedeadpunk: re "just source is a bit concenring" - I don't think Helm will function pointing at a git repo - it needs an artifact tar.gz or OCI blob. So we'll need to "publish" somewhere - does that help?. | 10:12 |
| noonedeadpunk | dalees: So, I think it was more about - how welcomed contributors from outside will be, will 4 opens be respected there and things like that | 10:13 |
| noonedeadpunk | which are kinda solved in opendev. and when it's true for the driver but not true for hard dependency - it's slightly meh. Though openstack have plenty of such dependencies, so dunno | 10:14 |
| noonedeadpunk | (as well as plenty of issues with them) | 10:14 |
| dalees | ah ok, I understand now. that hard dependency has the ambition of being part of opendev, so we'll aim for that. | 10:17 |
| noonedeadpunk | yeah, sound good then :) | 11:00 |
| mnasiadka | noonedeadpunk: kinda solved, unless the project is not maintained ;-) | 11:13 |
| noonedeadpunk | yeah, though it at least gives a chance to pick up maintenance without much hussle if anybody will be up for it | 12:10 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!