| jakeyip | thanks ricolin I will test | 07:18 |
|---|---|---|
| jakeyip | hi anyone around today? | 08:54 |
| travisholton | yep, hi jakeyip | 08:56 |
| jakeyip | hi travisholton. let's wait to see if there are more. | 08:57 |
| jakeyip | travisholton: looks like possibly just us. let's just have chat then, instead of a meeting | 09:03 |
| travisholton | sounds good | 09:03 |
| jakeyip | anything on your mind? | 09:03 |
| travisholton | curious how you got on with getting capi to run in devstack | 09:04 |
| jakeyip | it was really good. worked out of the box for me AFAICT | 09:04 |
| travisholton | good to hear! | 09:05 |
| jakeyip | good work there :) | 09:05 |
| jakeyip | I'm working my way up the chain for review. there are a few questions I have as of now | 09:06 |
| travisholton | well the stackhpc folks did all that. We're looking forward to getting things merged | 09:06 |
| travisholton | it does seem to work pretty smoothly | 09:07 |
| jakeyip | yeah was hoping stackhpc people be here | 09:07 |
| travisholton | I think we'll try and ping them again to see if we can arrange some chat time | 09:09 |
| travisholton | i've done some additional work to get flatcar working as well as k8s-keystone-auth that i'm keen to integrate with it | 09:10 |
| jakeyip | from my (limited) testing, it works, and it didn't break current CTs. I'm pretty happy to merge that based on this, and do improvements in future commits. | 09:11 |
| jakeyip | I think that will be sensible and get us over this hump | 09:11 |
| jakeyip | I have a question though - is there a way we can feature gate this, so operators _must_ explicitly enable it? | 09:13 |
| travisholton | that sounds promising | 09:13 |
| jakeyip | any ideas? how are you rolling it out? | 09:14 |
| dalees | the config item `[drivers]/disabled_drivers` may allow that if we want to explicitly disable it by default. | 09:15 |
| travisholton | we're just about to try rolling it out in our preprod environment | 09:15 |
| travisholton | driver selection would also be implicit based on os-distro as well. Right now the cluster_api driver only works with images having os_distro=ubunut | 09:17 |
| travisholton | ubuntu | 09:17 |
| jakeyip | dalees: I was looking at that. we could add that to default, but if a cloud has set that, then it'll be enabled? | 09:17 |
| jakeyip | travisholton: a user can create image os_distro=ubuntu and create a CT based on that | 09:17 |
| travisholton | it works that way currently | 09:20 |
| dalees | jakeyip: yeah if a cloud has defined that config item, a newly introduced driver would be enabled. | 09:21 |
| dalees | we're planning on rolling it out alongside the Heat driver for some amount of time, to allow plenty of transition time to newer templates that will be CAPI based and not creating newer CT using Heat drivers. | 09:24 |
| dalees | where the transition will be new cluster builds, of course. | 09:24 |
| jakeyip | I think we can do it with a new config, maybe I'll have a play | 09:24 |
| dalees | yeah, I'd be okay with `[drivers]/capi_enabled` or the like defaulting to false, then true at a later date. | 09:25 |
| jakeyip | yeah | 09:26 |
| jakeyip | or maybe something generic like CONF.drivers.enable_beta_drivers | 09:27 |
| dalees | it seems like the surest way to gate it, and make sure operators know they'll use it. The backing cinder image does need to be fairly specific, though, for the CAPI driver to handle the Cluster Template. | 09:27 |
| jakeyip | I'll have a play | 09:28 |
| dalees | cool | 09:28 |
| jakeyip | another thiing along the same line is os=ubuntu. this seems to box us into ubuntu os, although right now openstack image-builder only has ubuntu if I'm correct? | 09:29 |
| travisholton | it also has flatcar. that's what we've been testing with | 09:29 |
| travisholton | that'll be what we use for our managed service once everything is ready | 09:30 |
| jakeyip | hm do you have a link for flatcar image building for capi? | 09:31 |
| jakeyip | oh nvm found it, sorry | 09:32 |
| travisholton | it works with the image_builder but the Makefile they provide only generates the image as a file that must be uploaded. | 09:33 |
| jakeyip | OK, I'll have to take a more detailed look later | 09:34 |
| travisholton | I've been using some customised packer to build it directly in openstack | 09:34 |
| jakeyip | so how are you handling them? os_distro=ubuntu? ? | 09:34 |
| travisholton | os_distro=flatcar | 09:34 |
| jakeyip | that must be the patch you are talking about in the beginning? | 09:35 |
| jakeyip | https://review.opendev.org/c/openstack/magnum/+/887545 ? | 09:36 |
| travisholton | ah yep that's it | 09:37 |
| jakeyip | ah ok. I was originally thinking of os_distro=capi and all capi images be using that. but it looks like flatcar may need a bunch more stuff? | 09:39 |
| travisholton | it needs some changes to the helm charts that stackhpc created originally to add support for "ignition based OS" | 09:41 |
| travisholton | that's what you don't see in that patch..and brings up the point about where helm charts should live in the future | 09:41 |
| travisholton | we're hosting it locally from our oci registry at the moment | 09:42 |
| jakeyip | yeah. any ideas on that? I was trying to find out if there are projects hosting helm charts | 09:45 |
| jakeyip | like openstack-helm? :D | 09:45 |
| travisholton | I'm not sure what options are available either. Our local oci-registry has been working well and since its primary function is hosting the images we use for k8s it's easy to support | 09:51 |
| jakeyip | travisholton: do you mind sharing a link to your helm charts that work with flatcar? | 09:52 |
| travisholton | sec | 09:52 |
| dalees | the magnum project would need a git repo for the helm charts, and then some distribution mechanism - OCI or tar are the supported? | 09:52 |
| dalees | travisholton: looks like this is your PR - https://github.com/stackhpc/capi-helm-charts/pull/53 | 09:54 |
| travisholton | ah yep | 09:54 |
| jakeyip | lol https://github.com/stackhpc/capi-helm-charts/pull/53/commits/0a4cc48c4c8b2fde21fead9a52518cf371760706#diff-51d17971d66a02544b44f9430110767ac95d1202322f9bd10cdd791f1de4b51cR58 | 09:55 |
| dalees | haha | 09:56 |
| travisholton | oops yeah there's still some catalystcloud stuff in there | 09:56 |
| travisholton | i think i still need to push a more recent version to that | 09:57 |
| jakeyip | travisholton: so if I understand your patch, one of the change will be `"ignitionBasedOS": ignition_based_os` which gets passed down as a value to helm upgrade ? | 10:04 |
| travisholton | exactly...and that tells the helm chart to add in some ignition specific configuration | 10:06 |
| jakeyip | I wonder if we should get extra `values` configurable in a CT. possibly as a label | 10:06 |
| jakeyip | motivation is to do away with os detection in magnum code, make it as dumb as possible | 10:07 |
| travisholton | one thing we're keen on avoiding is allowing customers to override helm values via labels | 10:09 |
| jakeyip | why¿? | 10:10 |
| jakeyip | oops didn't mean to do that ^ | 10:11 |
| * dalees needs to sleep, been a long day today. | 10:18 | |
| jakeyip | yeap, we can continue next week | 10:19 |
| jakeyip | thanks for coming | 10:19 |
| travisholton | hopefully we get to chat with some of the others next week as well | 10:19 |
| dalees | thanks jakeyip - trav and i will discuss further the os detection in magnum code before next week, so we can pick up there too. | 10:20 |
| travisholton | jakeyip: I have a patch I need to push up to the capi-helm-chart PR that I forgot about (but have been using locally for a while) | 10:20 |
| jakeyip | travisholton: ok will watch | 10:20 |
| travisholton | cool..i'll try and ping you when I do | 10:21 |
| jakeyip | see you next week dalees travisholton | 10:22 |
| travisholton | o/ | 10:22 |
| mnasiadka | hello, just got back from vacation if any reviews are waiting - just point me to them :) | 17:52 |
| travisholton | jakeyip: I made that update. If you do give that a go please let me know how it works for you. | 18:23 |
| -opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline briefly for a minor upgrade at 21:00 utc, approximately an hour from now | 20:02 | |
| -opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline briefly for a minor upgrade, but should return shortly | 21:01 | |
| jakeyip | hi mnasiadka hope you had a good holiday :) | 23:02 |
| jakeyip | hi, I have this nagging issue, wonder if anyone has a solution. when a pv is created in k8s, then the cluster is deleted w/o deleting the pv first, a cinder vol is left behind | 23:08 |
| jakeyip | I have a bunch of cinder vol but I can't correlate this to a cluster | 23:09 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!