| opendevreview | Michal Nasiadka proposed openstack/magnum-tempest-plugin master: WIP: k8s driver CI tests https://review.opendev.org/c/openstack/magnum-tempest-plugin/+/893131 | 05:22 |
|---|---|---|
| opendevreview | Michal Nasiadka proposed openstack/magnum master: DNM: Test VexxHost driver in requirements.txt https://review.opendev.org/c/openstack/magnum/+/895872 | 05:45 |
| opendevreview | Michal Nasiadka proposed openstack/magnum master: DNM: Test VexxHost driver in requirements.txt https://review.opendev.org/c/openstack/magnum/+/895872 | 05:54 |
| opendevreview | Michal Nasiadka proposed openstack/magnum master: DNM: Test VexxHost driver in requirements.txt https://review.opendev.org/c/openstack/magnum/+/895872 | 07:19 |
| opendevreview | Michal Nasiadka proposed openstack/magnum-tempest-plugin master: WIP: k8s driver CI tests https://review.opendev.org/c/openstack/magnum-tempest-plugin/+/893131 | 07:32 |
| opendevreview | Michal Nasiadka proposed openstack/magnum-tempest-plugin master: WIP: k8s driver CI tests https://review.opendev.org/c/openstack/magnum-tempest-plugin/+/893131 | 07:42 |
| opendevreview | Michal Nasiadka proposed openstack/magnum-tempest-plugin master: WIP: k8s driver CI tests https://review.opendev.org/c/openstack/magnum-tempest-plugin/+/893131 | 08:23 |
| opendevreview | John Garbutt proposed openstack/magnum master: WIP: ClusterAPI: add initial driver implementation https://review.opendev.org/c/openstack/magnum/+/851076 | 08:32 |
| opendevreview | John Garbutt proposed openstack/magnum master: WIP: ClusterAPI: add initial driver implementation https://review.opendev.org/c/openstack/magnum/+/851076 | 08:41 |
| opendevreview | John Garbutt proposed openstack/magnum master: Add appcred and cacert inspired by vexxhost driver https://review.opendev.org/c/openstack/magnum/+/895828 | 08:47 |
| opendevreview | John Garbutt proposed openstack/magnum master: ClusterAPI: add simple k8s client https://review.opendev.org/c/openstack/magnum/+/881475 | 08:48 |
| opendevreview | John Garbutt proposed openstack/magnum master: WIP: ClusterAPI: add initial driver implementation https://review.opendev.org/c/openstack/magnum/+/851076 | 08:48 |
| jakeyip | hi all, meeting in 5 mins. pinging mnasiadka dalees :) | 08:56 |
| mnasiadka | jakeyip: ping ping? ;) | 09:02 |
| dalees | hi mkjpryor | 09:02 |
| mkjpryor | morning | 09:03 |
| jakeyip | let's start :) | 09:03 |
| travisholton | hi all | 09:03 |
| gbialas | hi all | 09:03 |
| johnthetubaguy | o/ | 09:03 |
| mnasiadka | #startmeeting magnum | 09:03 |
| opendevmeet | Meeting started Wed Sep 20 09:03:56 2023 UTC and is due to finish in 60 minutes. The chair is mnasiadka. Information about MeetBot at http://wiki.debian.org/MeetBot. | 09:03 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 09:03 |
| opendevmeet | The meeting name has been set to 'magnum' | 09:03 |
| mnasiadka | jakeyip: couldn't resist ;) | 09:04 |
| mnasiadka | #topic rollcall | 09:04 |
| mnasiadka | o/ | 09:04 |
| johnthetubaguy | o/ | 09:04 |
| bbezak | o\ | 09:04 |
| dalees | o/ | 09:04 |
| mkjpryor | o/ | 09:04 |
| gbialas | o/ | 09:04 |
| travisholton | o/ | 09:04 |
| jakeyip | o/ | 09:04 |
| jakeyip | what a crowd :) | 09:05 |
| mnasiadka | #topic agenda | 09:05 |
| mnasiadka | BU Mentorship | 09:05 |
| mnasiadka | ClusterAPI | 09:05 |
| mnasiadka | Open discussion | 09:05 |
| mnasiadka | #topic BU Mentorship | 09:05 |
| mnasiadka | So, it was linked last time in the etherpad | 09:06 |
| jakeyip | #link https://etherpad.opendev.org/p/magnum-weekly-meeting | 09:06 |
| dalees | etherpad link: https://etherpad.opendev.org/p/magnum-weekly-meeting | 09:06 |
| mnasiadka | I reached out to diablo_rojo - it seems there are no students that signed up, but it would be good if we could have a list of potential mentors from Magnum side | 09:06 |
| mnasiadka | #link https://etherpad.opendev.org/p/2023-BU-Magnum | 09:06 |
| mnasiadka | It would be nice if people interested would add their names on that etherpad to Mentors section | 09:07 |
| opendevreview | John Garbutt proposed openstack/magnum master: WIP: ClusterAPI: add initial driver implementation https://review.opendev.org/c/openstack/magnum/+/851076 | 09:07 |
| mnasiadka | #topic ClusterAPI | 09:07 |
| mnasiadka | jakeyip: giving the meeting back to you ;-) | 09:07 |
| opendevreview | John Garbutt proposed openstack/magnum master: WIP: ClusterAPI: add initial driver implementation https://review.opendev.org/c/openstack/magnum/+/851076 | 09:08 |
| jakeyip | oh man the difficult topic | 09:08 |
| jakeyip | johnthetubaguy are you around? (I guess you are online from ^) | 09:08 |
| johnthetubaguy | I can update from our side what we are doing? | 09:08 |
| jakeyip | yes thanks | 09:09 |
| johnthetubaguy | So given we didn't get merged this cycle, and we are testing this with a few customers, we have created this repo for now: https://github.com/stackhpc/magnum-capi-helm | 09:09 |
| johnthetubaguy | I have been rebaseing the upstream patches so they could be kept in sync with the above | 09:10 |
| johnthetubaguy | I certianly would still like a cluster api driver, that uses helm charts, in tree, if that is possible | 09:10 |
| johnthetubaguy | This is the tip of the updated patch set: https://review.opendev.org/c/openstack/magnum/+/851076 | 09:11 |
| dalees | thanks for creating that repo btw; it's much easier to install from a repo than carry a stack of gerrit patches to test against. | 09:11 |
| johnthetubaguy | in the process of retesting the devstack bits there, to see what I broke in all the refactoring (facepalm!) | 09:12 |
| jakeyip | thanks. for background and comparison, VEXXHOST driver is out of tree, I don't think there's inclination for them to contribute to in-tree. | 09:12 |
| johnthetubaguy | dalees: cool, glad that helps, certainly seemed easier going | 09:12 |
| johnthetubaguy | so we spoke about things at the last PTG right, and I think the core difference is we want to use helm charts that can be shared with k8s on OpenStack outside of magnum | 09:13 |
| johnthetubaguy | in particilar I would like ArgoCD directly as and option (alongside Azimuth that has been using these for 18 months or more) | 09:13 |
| johnthetubaguy | and really I would love for that to be a community effort, with a tested referece starting point people can use | 09:13 |
| johnthetubaguy | ... so I don't think that vision has changed form when we approved the spec, granted we only got our funding approved about two weeks ago, hence the re-annimation on our side | 09:14 |
| jakeyip | yeap I understand. both approaches have their pros and cons, but let's not get too deep into that now, in the interest of time as that can take a while | 09:14 |
| johnthetubaguy | So there is a new patch in the series | 09:15 |
| johnthetubaguy | https://review.opendev.org/c/openstack/magnum/+/895828 | 09:15 |
| jakeyip | so we paused the merge because we realised the patches in tree, as it stands, would conflict with VEXXHOST and existing implementations using that driver | 09:15 |
| johnthetubaguy | It sarts some common utils to share being the two drivers | 09:15 |
| johnthetubaguy | jakeyip: yes, I noticed that late last week in the comments, that is certainly bad | 09:15 |
| johnthetubaguy | for the moment I went for changing our use of os-distro | 09:15 |
| johnthetubaguy | "os": "capi-kubeadm-cloudinit" | 09:16 |
| johnthetubaguy | now that is pretty crazy, but it represents that the current chart defaults depend on the kubeadm cloudinit bootstrapper | 09:16 |
| johnthetubaguy | (we can add the flat car one, with the approriate values tweak too!) | 09:16 |
| johnthetubaguy | with my Nova hat os os_distro=ubuntu is technically mal formed and not useful to nova | 09:17 |
| dalees | I think, given both drivers require the same capi built images (ubuntu for now, flatcar soon), we need some other way of differentiating besides (vm, ubuntu, kubernetes) tuple. At the moment I prefer the idea of having the Magnum template define the driver preference (and it could default otherwise). | 09:17 |
| johnthetubaguy | from a more human sense, its a bit odd though, but it stops us conflicting for now | 09:17 |
| jakeyip | cool. glad we all agree we shouldn't break existing implementations. certainly it caught us (me) by surprise. It would have helped if we did had a VEXXHOST representative reviewing those patches. | 09:17 |
| johnthetubaguy | dalees: yeah, that would be ideal, of couse you could only enable one of the drivers via config | 09:18 |
| mnasiadka | jakeyip: I think they have hard time attending this meeting, due to time difference - but let's see if we can resolve it in long term :) | 09:18 |
| johnthetubaguy | jakeyip: 100% we shouldn't break that driver, I am glad that got spotted, I certainly didn't notice that till it was pointed out | 09:18 |
| jakeyip | mnasiadka: yeah we can put one of them as a core to review patches, offline from meeting TZ. | 09:19 |
| dalees | johnthetubaguy: yes, there are config flags to disable certain drivers - this solves one part. jakeyip brought up the point that if someone was migrating between drivers, they'd want both running at once for some duration. | 09:19 |
| johnthetubaguy | mnasiadka: +1 the overlap is hard | 09:19 |
| mnasiadka | Let's not get deep into technical stuff here, Gerrit is for code reviews (at least that's my opinion) - situation is that we have Bobcat RC1 right now, so if we merge any in-tree driver then it's going to be earliest Caracal | 09:19 |
| johnthetubaguy | dalees: jakeyip yeah, good point, you would want side by side | 09:19 |
| johnthetubaguy | FWIW, I kinda like the idea of the template speciying a driver more directly, and the driver validating the image its self | 09:20 |
| johnthetubaguy | we could look at writing up a spec for that? but general guidence on the best way to implement that is very welcome | 09:21 |
| johnthetubaguy | a label is tempting, but also nasty | 09:22 |
| jakeyip | in addition the config approach, the current config option is 'disabled_drivers'; a new one driver in a new cycle will be enabled by default, if operator hasn't update config | 09:22 |
| johnthetubaguy | top level template param to select the driver? if empty falls back to the legacy image based seletion? | 09:22 |
| johnthetubaguy | jakeyip: I have your beta driver change in my series to make sure its opt in till we are happy | 09:23 |
| dalees | yeah, top level template param seems suitable i think, with empty fallback to the tuple match (or *also* do the tuple match, as well as the driver selection?). | 09:23 |
| jakeyip | the problem really is the tuple design, it will hamstring us if we keep trying to work with it. plus if we introduce new tuples, we run the risk of it breaking an installation out there | 09:24 |
| johnthetubaguy | I was thinking a top level template param means we just ignore the tuple, and we call that legacy for when the top level param is empty? | 09:24 |
| johnthetubaguy | i.e. you opt into the new system, for new templates. | 09:25 |
| jakeyip | johnthetubaguy: yeap, that is sort of the design we came up with last week after our brainstorming session. | 09:25 |
| johnthetubaguy | and you just say, driver=k8s_capi_helm_v1 or whatever in the template. That does mean we need an API to list the avaliable drivers. | 09:26 |
| mnasiadka | yes, but that might be easier to do when we drop all other drivers | 09:26 |
| johnthetubaguy | seems cleaner, I honestly hate the tuple thing, I have spend hours debugging that with image permissions, etc. | 09:26 |
| dalees | true; there's a CLI tool for listing drivers, but not an API. | 09:27 |
| mnasiadka | seems like a nice priority for C cyle | 09:27 |
| johnthetubaguy | mnasiadka: well we can't drop the old approach without killing the API right, so I don't see why that needs to wait? this is all about someting for C release anyways? | 09:27 |
| mnasiadka | *cycle | 09:27 |
| johnthetubaguy | is there someone who wants to take this one and write up a spec I guess? | 09:28 |
| jakeyip | good point about API, the old discovery is useful in certain circumstances where a user creates a template, possibly off the information on magnum user docs | 09:28 |
| mnasiadka | johnthetubaguy: just saying all other drivers are already deprecated, and it might be just easier to get that implemented when we drop them for simplicity | 09:29 |
| johnthetubaguy | so the API would exclude disabled drivers, and include any out of tree things you happen to have installed, I presume. | 09:29 |
| jakeyip | I am not sure if that is a thing anymore when we are talking about out of tree drivers nowadays. how does the user know what os_distro to use if they didn't know about the driver(s) | 09:29 |
| johnthetubaguy | So personally, I think we should disable users from creating templates, by default, and leave that to the admin... but I might be on my own there. | 09:30 |
| johnthetubaguy | (but that is a whole other RBAC debate really) | 09:30 |
| jakeyip | what, more api changes?! :) | 09:30 |
| dalees | johnthetubaguy: +1, we create these for users. self-serve is a minefield of labels :) | 09:31 |
| johnthetubaguy | so many of our customers do that, as the users get them selvers in a mess when they create crazy templates, and they just don't have the time to help them with that | 09:31 |
| jakeyip | FWIW we create templates for user. Users do create their templates off ours if they want something special. | 09:31 |
| mnasiadka | I think let's not get into the policy battle for now | 09:31 |
| mnasiadka | people can change magnum policy today and I think that's fine | 09:31 |
| jakeyip | but let's shelve that, a whole other discussion | 09:31 |
| mnasiadka | instead of enforcing our thinking on users :) | 09:31 |
| johnthetubaguy | the problem is relevant to who is expected to create a template, and needing to know the avilable driver list right? but happy to ignore that for now | 09:32 |
| johnthetubaguy | this feels like a PTG like discusion to me | 09:32 |
| jakeyip | but I think what this leads to is that the API to discover drivers is not strictly necessary? | 09:32 |
| jakeyip | at least, not at the inital to support CAPI driver. It can come later, if someone wants to. | 09:33 |
| mnasiadka | I don't think it's strictly necessary for anything, it's nice to have - and given the size of the Magnum community, we might find better use for our time | 09:33 |
| johnthetubaguy | I don't personally see this as blocking the driver, it only blocks side by side having two cluster api drivers, assuming we have the same os_distro flag, which now we don't | 09:34 |
| johnthetubaguy | ... it does however seem useful and worth adding, either way | 09:34 |
| jakeyip | +1 I agree. we will accept patches if someone do the work. needs a spec. let's leave it as that | 09:34 |
| johnthetubaguy | does anyone want to implement that? | 09:34 |
| mnasiadka | Let's leave that question for PTG | 09:35 |
| johnthetubaguy | (I mean does anyone have time, really) | 09:35 |
| jakeyip | johnthetubaguy: if we continue on the new approach to use CT to define driver, it's not a blocker for two CAPI driver side by side | 09:35 |
| johnthetubaguy | Is magnum signed up to the PTG? | 09:35 |
| jrosser | from an operator pov you need a k8s running capi somewhere - is this completely independant/decoupled from the particular magnum capi driver in use? | 09:35 |
| jakeyip | jrosser: good point. there's a config option to point to the management option. I think we have to make sure config options don't clash | 09:36 |
| johnthetubaguy | note quite, as the CRDs the drive use might depend on specific operator versions, but in theory they should overlap a lot | 09:36 |
| jakeyip | at some point, Magnum still needs to assignment config sections to prevent conflicts | 09:36 |
| jakeyip | e.g. each driver will have their section named after driver name | 09:37 |
| johnthetubaguy | so the heat driver does that now, so I went for capi_helm in my current patch series | 09:37 |
| jakeyip | edit: there's a config option to point to the management cluster | 09:37 |
| johnthetubaguy | I think the two drivers are doing that today? | 09:38 |
| johnthetubaguy | as in they both have spearate config, or did you mean they should share? | 09:39 |
| jakeyip | johnthetubaguy: I don't really understand what you mean by 'heat driver does that now' ? | 09:39 |
| johnthetubaguy | jakeyip: I guess its not really true, I mean their is a [heat] config section that is specific to the heat driver, but I guess its not really that clean | 09:39 |
| jakeyip | johnthetubaguy: I mean, currently for both drivers, and also for future drivers, we sort of should have a standard for people implementing out of tree drivers to prevent conflicts | 09:39 |
| jrosser | imho there needs to be some good thought to operator experience, i foresee a large attraction in general of the capi driver approach is to relieve the operator from having extremely deep k8s expertise but still be able to run the magnum service | 09:40 |
| jakeyip | there are a few point of conflicts. (1) tuple (we solve by CT specifying driver) (2) config section (3) driver name | 09:42 |
| jakeyip | I think understanding this is enough so we can help advice future patches / reviews. | 09:42 |
| jakeyip | jrosser: can you elaborate? is there something we can do better? | 09:43 |
| jrosser | i am very interested in the new direction of travel for magnum, it looks great | 09:43 |
| jrosser | as an operator we have been unable to deploy the existing approach as it is too much burden | 09:44 |
| johnthetubaguy | +1 Cluster API is a strong base, regardless of all this, and I am excited by the further traction its getting inside and outside of OpenStack | 09:45 |
| jakeyip | ah I see, understand now. | 09:45 |
| jakeyip | ok to bring the driver discussion back, would like to poll the room on our approach and if there's anything we've missed | 09:46 |
| johnthetubaguy | jakeyip: my main question is what is needed to help get the capi_helm driver merged in the C cylce? And I suspect that is probably best discussed at the PTG if we can find a slot when lots of us can attend, including vexxhost driver representatives. I know I can't usually make this meeting time either. | 09:48 |
| jakeyip | johnthetubaguy: will you, or someone from StackHPC, be able to work with VEXXHOST to align both your drivers? | 09:50 |
| johnthetubaguy | Or maybe I should rephrase, that, to getting a clear yes we aim to merge (as we said in B) or we decide to not have any drivers in tree. | 09:50 |
| johnthetubaguy | jakeyip: we have wanted to do that from the start, but helm is the deal breaker from both sides, based on our previous discussions | 09:50 |
| johnthetubaguy | I have started some driver common utils where we have a bit of shared code already, it would be great to expand that, so the out of tree driver can consume that when it makes sense for it, or not, as it may choose. | 09:51 |
| jakeyip | johnthetubaguy: I think VEXXHOST mainly wants to continue on the ClusterClass route. | 09:52 |
| johnthetubaguy | I want to use clusterclass too, its on the roadmap, just spending our effort on magnum integration right now | 09:52 |
| johnthetubaguy | it wasn't working when we started the helm charts, so we didn't use it from the start | 09:53 |
| jakeyip | cool. definitely it can be a good collab. | 09:53 |
| johnthetubaguy | similar to the add ons, we have our own helm add on installer, to get around the life-cycle issues on the updates there | 09:53 |
| jakeyip | right now, our focus is more on how to get both drivers to work together. Once we figure that out, the way to getting your CAPI driver merged will be clear | 09:54 |
| johnthetubaguy | jakeyip: I would like to collab, but I am not seeing the opertunity right now, beond some share utils, which is a shame, my strong preference is for a single in tree solution we all support :'( | 09:54 |
| jakeyip | yeap I am keen for that. | 09:55 |
| dalees | I think Magnum needs to ensure both drivers can co-exist (discussed above), and then I'm keen to see one or both merge if there are maintainers for them. Staying out of tree is okay too. We're actively picking up the helm driver and using it now. | 09:56 |
| johnthetubaguy | I would be cool with both merging in tree too, that would be cool too right? | 09:57 |
| jakeyip | the single in tree solution doesn't have to be there from day one. as long as we allow for multiple drivers, we can iterate | 09:57 |
| johnthetubaguy | (much easier to share code and logic when we are both in tree) | 09:57 |
| johnthetubaguy | jakeyip: I believe the current patches actively allow for both drivers today? at least that was always the intention on my part, although it wasn't the reality due to the problems we found in review. | 09:58 |
| jakeyip | similar to how linux can work different FS. Allow multiple to exists, see which one wins out over time. | 09:58 |
| johnthetubaguy | maybe a different question, based on the current patches, where is the tention? | 09:59 |
| johnthetubaguy | s/tention/conflict/ | 09:59 |
| jakeyip | we need maintainers for any driver, which is the _hard_ problem. | 09:59 |
| johnthetubaguy | jakeyip: that is a good comparison here, we use different package managers... I mean add on providers | 09:59 |
| jakeyip | johnthetubaguy: I believed we have covered the conflicts so far? | 10:00 |
| johnthetubaguy | jakeyip: I mean, I think they are all addressed in the current patches, I would love comments on the patches highlighting any that are left please | 10:01 |
| dalees | johnthetubaguy: the actual image supported by both is identical. it's true they don't conflict now in the tuple, but only because of the changed `os_distro` (as well reasoned as it is, to differ from `ubuntu`) - there's no reason the vexxhost driver shouldn't launch using an identical image. | 10:01 |
| johnthetubaguy | dalees: agreed the same images should work with both | 10:03 |
| johnthetubaguy | but I don't know of a use case we are blocking that would actively want to support that | 10:03 |
| johnthetubaguy | I do like the driver selection in the template, it would be a good add, and avoid this problem | 10:04 |
| jakeyip | johnthetubaguy: I am not really sure of the question and basis you are asking from actually. may need clarification. | 10:05 |
| jakeyip | are you asking for conflicts, on the basis that (1) os_distro has been changed (2) CT appraoch is not implemetned ? | 10:05 |
| dalees | well that is a point; if I were moving drivers I'd not need both drivers to launch the same image; I'd use a new k8s version. | 10:05 |
| johnthetubaguy | jakeyip: I am meaning, now we use differnet os_distro flags, I think they for most people, don't conflict | 10:06 |
| johnthetubaguy | dalees: you wouldn't need to wait long to get a new release at least :) | 10:07 |
| jakeyip | johnthetubaguy: ok I understand. yes things don't conflict now, with the os_distro change, but there are more about using the os_distro that I need to clarify. | 10:07 |
| jakeyip | it is outside the scope of meeting though, if you would like to hang around a bit after? | 10:08 |
| jakeyip | I am just concious we are over time | 10:08 |
| mnasiadka | ok, do we need some summary? | 10:08 |
| jakeyip | OK I will summarise this topic | 10:08 |
| johnthetubaguy | afraid I really should run, I was meant to be with my customer at 9am, and its gone 11 now. | 10:08 |
| jakeyip | johnthetubaguy: sure I may put comments in your PS then. or we find a better time | 10:09 |
| jakeyip | #agreed we have stopped the CAPI driver in Bobcat due to conflict with VEXXHOST's driver. We will explore solutions that allow multiple drivers to exist in C cycle. | 10:10 |
| jakeyip | anyone wants to add on? | 10:11 |
| johnthetubaguy | jakeyip: yes to both, lets discuss in the patch | 10:11 |
| mnasiadka | yes, we need a timeframe for vPTG and some etherpad to add all those ideas in there :) | 10:11 |
| johnthetubaguy | So I don't really agree there is a conflict, but agree we need to work that out during the C cycle. | 10:12 |
| jakeyip | mnasiadka: OK, vPTG will be separate discussion. | 10:12 |
| jakeyip | let's close ClusterAPI | 10:12 |
| johnthetubaguy | (I should say, I still don't really understand the conflict right now, lets work that out ASAP) | 10:12 |
| jakeyip | #topic vPTG | 10:13 |
| jakeyip | I didn't register for a vPTG this cycle because for the previous cycle the timing doesn't suit us, and we had our own vPTG discussion at this timeslot on the vPTG week | 10:13 |
| jakeyip | I am not sure what's the best way to go, considering that it'll be valuable to have VEXXHOST attend too. | 10:14 |
| * dalees is willing to make some ungodly NZ hour, if it means more can attend. | 10:14 | |
| mnasiadka | I'm willing to make the same as dalees, but it will be 12 hours later for me ;) | 10:14 |
| jakeyip | (this is all new to me/us, happened after vPTG registration has closed) | 10:15 |
| mnasiadka | I think generally 19UTC is 7AM NZ time and 9PM CEST | 10:15 |
| dalees | 7am is quite acceptable, for both myself and travisholton | 10:16 |
| jakeyip | it is 5AM AEST but sure :) | 10:16 |
| dalees | hah, sorry jakeyip :) | 10:16 |
| mnasiadka | ah right | 10:16 |
| mnasiadka | lol | 10:16 |
| jakeyip | it's ok | 10:16 |
| johnthetubaguy | are there two different slots that would work, where many people can make both? (granted its all relative to massive jet lag) | 10:17 |
| travisholton | we have daylight savings from next week as well | 10:17 |
| johnthetubaguy | we have that soon too, that is a good point, is this where it gets worse again or better? I forget... | 10:18 |
| travisholton | https://shorturl.at/fuvAD | 10:18 |
| mnasiadka | travisholton: that might make things better, because our daylight savings time change is 29th Oct | 10:18 |
| jakeyip | mnasiadka, johnthetubaguy, dalees - given you all may have different vPTGs to attend to, how is Wed 25/10 1900 UTC ? | 10:18 |
| mnasiadka | it's ok for me | 10:19 |
| johnthetubaguy | sorry, checking | 10:19 |
| jakeyip | that is also a slot NOT on the vPTG https://ptg.opendev.org/ptg.html | 10:19 |
| johnthetubaguy | I think that can work (its half term here) | 10:20 |
| jakeyip | they may as well put 24 hour slots for the vPTG | 10:20 |
| dalees | 8am NZT, yes - I can make that work. | 10:21 |
| jakeyip | ptg-bot doesn't need toilet break | 10:21 |
| travisholton | me too | 10:21 |
| johnthetubaguy | sounds like its worth trying that time, and asking on the ML for folks that can't make that time | 10:22 |
| jakeyip | ok let's pencil that in for now. | 10:22 |
| opendevreview | Michal Nasiadka proposed openstack/magnum-tempest-plugin master: WIP: k8s driver CI tests https://review.opendev.org/c/openstack/magnum-tempest-plugin/+/893131 | 10:22 |
| jakeyip | johnthetubaguy: ok I will make a post on ML to notify others. I am still holding out for mnaser too | 10:23 |
| jakeyip | #topic Open Discussion | 10:24 |
| jakeyip | free for all to post | 10:24 |
| jakeyip | oops forgot for previous topic | 10:25 |
| jakeyip | #agreed vPTG on 25 Oct 1700 UTC | 10:26 |
| jakeyip | if there's nothing I would like to end the meeting. | 10:26 |
| jakeyip | thanks everyone for coming! | 10:26 |
| jakeyip | #endmeeting | 10:27 |
| opendevmeet | Meeting ended Wed Sep 20 10:27:23 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 10:27 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/magnum/2023/magnum.2023-09-20-09.03.html | 10:27 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/magnum/2023/magnum.2023-09-20-09.03.txt | 10:27 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/magnum/2023/magnum.2023-09-20-09.03.log.html | 10:27 |
| jakeyip | I'll be around for another half hour or so if anyone wants to chat | 10:27 |
| dalees | thanks all, good discussion. | 10:27 |
| jakeyip | thanks dalees :) | 10:27 |
| travisholton | +1 | 10:28 |
| johnthetubaguy | +1 thank you all, good to understand things a bit better | 10:28 |
| johnthetubaguy | Ah, 🤦 I miss-read that time at 7pm UTC, which would also work for me. | 10:29 |
| jakeyip | thanks johnthetubaguy, appreciate the work you and matt put in for CAPI. feels bad we couldn't get it merged in this cycle. | 10:29 |
| johnthetubaguy | no worries, keen to get something that works for everyone merged, that takes time | 10:29 |
| dalees | I'm pondering a patch to disable the upgrade API for Heat based drivers and return a 400/500 error - these upgrades are not reliable for a couple of reasons. Do we want this upstream, or leave as is and let CAPI driver take over and do upgrades properly? | 10:29 |
| mnasiadka | well, does it make any sense to merge it in C? | 10:30 |
| johnthetubaguy | dalees: FWIW, I am +1 that, including backporting that as far as the CI will let us, gut that is probably just me | 10:31 |
| jakeyip | dalees: we (Nectar) have disabled it in policy | 10:31 |
| * johnthetubaguy waves at everyone, and runs away | 10:32 | |
| dalees | cool - I will create a patch and it can be reviewed. | 10:32 |
| jakeyip | dalees: not sure what you mean though, we can both disable upgrade for heat AND leave it in place for CAPI ? | 10:33 |
| jakeyip | maybe code will help | 10:33 |
| dalees | jakeyip: yes; i'll explain in code ;) | 10:34 |
| jakeyip | cool :) | 10:34 |
| jakeyip | oh FYI, I won't be around for the next meeting as I am going to KubeCon Shanghai :) | 10:36 |
| * travisholton envious | 10:36 | |
| jakeyip | heehee thanks :) | 10:36 |
| jakeyip | anyone going, do ping me to catch up. | 10:37 |
| dalees | jakeyip: i hope there are some clusterapi talks you can attend. i hear it's the new thing to do | 10:38 |
| travisholton | +1 | 10:38 |
| dalees | enjoy; i won't be there unfortunately ;( | 10:39 |
| * travisholton waves before wandering off into NZ nighttime | 10:39 | |
| * dalees also. | 10:39 | |
| jakeyip | thanks, I will report back if there are cool things. | 10:39 |
| jakeyip | mnasiadka , dalees: I'll leave the decision to have the next meeting to you. don't have to if you don't want to. | 10:40 |
| jakeyip | johnthetubaguy: when you get a chance to reply, I would like to find out from you about coming up with your own names for `os_distro`. | 10:46 |
| jakeyip | AFAICT, from https://docs.openstack.org/glance/latest/user/common-image-properties.html and https://docs.openstack.org/python-glanceclient/latest/cli/property-keys.html , the image properties are meant to act as a guide for consumption by other services | 10:48 |
| jakeyip | I also didn't understand when you said > '09:17:20 <johnthetubaguy> with my Nova hat os os_distro=ubuntu is technically mal formed and not useful to nova' - is this referring to the capi image tagged with ubuntu? | 10:58 |
| jakeyip | just wondering how far we can go to (ab)use the os_distro tag for our benefits. https://docs.openstack.org/glance/latest/admin/useful-image-properties.html says 'Specify only a recognized value for this field'. I think this is only in context of if we want this image consumed by other services, we may be free to abuse it otherwise? | 11:04 |
| mnasiadka | we could think of moving to magnum_distro label, so it's less abused ;) | 11:25 |
| opendevreview | Jake Yip proposed openstack/magnum master: Update chart.metadata.version to reflect breaking change in helm v3.5.2 https://review.opendev.org/c/openstack/magnum/+/879157 | 11:27 |
| opendevreview | Jake Yip proposed openstack/magnum master: fix: update Helm version https://review.opendev.org/c/openstack/magnum/+/856854 | 11:28 |
| opendevreview | Jake Yip proposed openstack/magnum master: fix: update Helm version https://review.opendev.org/c/openstack/magnum/+/856854 | 11:28 |
| jakeyip | mnasiadka: the change you asked me about, looks good. also added mnaser's patch that bumped helm version | 11:31 |
| opendevreview | Michal Nasiadka proposed openstack/magnum-tempest-plugin master: WIP: k8s driver CI tests https://review.opendev.org/c/openstack/magnum-tempest-plugin/+/893131 | 12:28 |
| *** freyes_ is now known as freyes | 13:04 | |
| opendevreview | Dale Smith proposed openstack/magnum master: Remove support for in-place upgrades with the Heat driver. https://review.opendev.org/c/openstack/magnum/+/895983 | 21:32 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!