| *** xiangdong-huang has joined #openstack-containers | 01:16 | |
| *** spsurya has joined #openstack-containers | 01:17 | |
| *** xiangdong-huang has quit IRC | 01:22 | |
| *** altlogbot_3 has quit IRC | 01:37 | |
| *** altlogbot_0 has joined #openstack-containers | 01:38 | |
| *** ricolin has joined #openstack-containers | 02:16 | |
| *** hongbin has joined #openstack-containers | 02:49 | |
| *** yolanda has quit IRC | 03:21 | |
| *** yolanda has joined #openstack-containers | 03:22 | |
| *** ramishra has joined #openstack-containers | 03:34 | |
| openstackgerrit | zengjia proposed openstack/magnum master: Update "auth_url" port in install docs https://review.opendev.org/674724 | 03:58 |
|---|---|---|
| *** ykarel|away has joined #openstack-containers | 04:05 | |
| *** hongbin has quit IRC | 04:11 | |
| *** udesale has joined #openstack-containers | 04:38 | |
| *** jhesketh has joined #openstack-containers | 04:54 | |
| *** janki has joined #openstack-containers | 05:04 | |
| *** ramishra has quit IRC | 05:38 | |
| *** jchhatbar has joined #openstack-containers | 05:38 | |
| *** ykarel|away is now known as ykarel | 05:39 | |
| *** jchhatbar has quit IRC | 05:41 | |
| *** janki has quit IRC | 05:41 | |
| *** jchhatbar has joined #openstack-containers | 05:42 | |
| *** jchhatbar has quit IRC | 05:43 | |
| *** ramishra has joined #openstack-containers | 06:19 | |
| *** ykarel is now known as ykarel|lunch | 08:02 | |
| *** rcernin has quit IRC | 08:04 | |
| *** lpetrut has joined #openstack-containers | 08:10 | |
| openstackgerrit | Merged openstack/magnum master: Support auto_healing_controller https://review.opendev.org/666209 | 08:40 |
| *** mgoddard has quit IRC | 10:03 | |
| *** ykarel_ has joined #openstack-containers | 10:17 | |
| *** ykarel|lunch has quit IRC | 10:19 | |
| *** ykarel_ is now known as ykarel | 10:27 | |
| *** ykarel_ has joined #openstack-containers | 10:31 | |
| *** ykarel has quit IRC | 10:34 | |
| *** ykarel_ is now known as ykarel | 10:42 | |
| tbarron | jakeyip: yeah, that nautilus dependency is in the partner protocol node plugin rather than in manila-csi proper, i've used ceph luminous with nfs gateway and hence nfs csi node plugin | 10:48 |
| tbarron | jakeyip: manila itself needs at least luminous when backed by CephFS | 10:48 |
| *** ramishra has quit IRC | 11:00 | |
| *** ramishra has joined #openstack-containers | 11:02 | |
| *** mgoddard has joined #openstack-containers | 11:13 | |
| *** ivve has joined #openstack-containers | 11:22 | |
| *** ykarel is now known as ykarel|afk | 11:47 | |
| *** henriqueof has joined #openstack-containers | 12:10 | |
| *** ykarel|afk is now known as ykarel | 12:11 | |
| jakeyip | tbarron: do you mean need at least nautilus with CephFS? | 12:19 |
| tbarron | jakeyip: I mean luminous, but when you back manila with cephfs there are two options | 12:31 |
| tbarron | jakeyip: a) use cephfs native, expose the shares via CephFS protocol, mount them with ceph-fuse or kernel support for CephFS | 12:32 |
| *** udesale has quit IRC | 12:32 | |
| *** udesale has joined #openstack-containers | 12:32 | |
| tbarron | b) use an nfs-ganesha gateway and expose them via NFS protocol | 12:33 |
| tbarron | jakeyip: manila-csi can work with either of these, as well as with other backings for manila that expose shares via NFS | 12:33 |
| tbarron | jakeyip: option a requires nautilus because the mounting of the shares is done via the cephfs-csi node plugin and it requires nautilus | 12:34 |
| *** hongbin has joined #openstack-containers | 12:34 | |
| tbarron | jakeyip: option b only requires luminous, because mounting of shares is done va the nfs-csi node plugin (so no ceph requirement there) and | 12:35 |
| tbarron | the controller-provisioner part just depends on manila which in turn depends on ceph luminous when manila is backed by CephFS | 12:35 |
| *** ykarel_ has joined #openstack-containers | 12:42 | |
| *** ykarel has quit IRC | 12:44 | |
| *** ykarel_ is now known as ykarel | 12:54 | |
| *** ykarel_ has joined #openstack-containers | 13:16 | |
| *** ykarel has quit IRC | 13:18 | |
| *** ykarel_ is now known as ykarel|afk | 13:19 | |
| *** hongbin has quit IRC | 13:24 | |
| *** ykarel_ has joined #openstack-containers | 13:38 | |
| *** ykarel|afk has quit IRC | 13:40 | |
| *** dioguerra has quit IRC | 13:42 | |
| *** ykarel__ has joined #openstack-containers | 13:45 | |
| *** dioguerra has joined #openstack-containers | 13:46 | |
| *** ykarel_ has quit IRC | 13:47 | |
| *** ykarel__ is now known as ykarel | 13:48 | |
| *** ykarel has quit IRC | 14:11 | |
| *** dioguerra has quit IRC | 14:12 | |
| *** ykarel has joined #openstack-containers | 14:12 | |
| *** altlogbot_0 has quit IRC | 14:12 | |
| *** altlogbot_1 has joined #openstack-containers | 14:13 | |
| *** dioguerra has joined #openstack-containers | 14:14 | |
| *** ramishra has quit IRC | 14:23 | |
| *** KeithMnemonic has joined #openstack-containers | 14:36 | |
| brtknr | tbarron: looks like we've had an exchange before: https://github.com/ceph/ceph/pull/25407 | 15:07 |
| tbarron | brtknr: ah, that was you who drove those backports! Thanks! | 15:08 |
| brtknr | tbarron: :) i was just thinking that the mode needs to be 777 for enabling non root users to write to a manila pv | 15:10 |
| brtknr | we'd maybe get away with 0776 too | 15:11 |
| tbarron | brtknr: my experience was from OpenShift users with the pre-csi dynamic external provisioner. They reported 775 was sufficient for their case. | 15:11 |
| tbarron | brtknr: but maybe the problem was a little different | 15:11 |
| brtknr | for non-root users to be able to write? | 15:12 |
| brtknr | sounds like it | 15:12 |
| tbarron | brtknr: I think they only needed users in a certain group to be able to write and search but I guess in your case you need any user to | 15:13 |
| tbarron | brtknr: be able to do it from the top of the tree | 15:13 |
| brtknr | tbarron: thats right | 15:13 |
| tbarron | brtknr: and they may need 777 to be able to search in directories there | 15:13 |
| brtknr | :) we're back in full circle | 15:14 |
| tbarron | brtknr: sorry for assuming your use case was the same but the other one actually drove that ceph_volume patch | 15:14 |
| tbarron | brtknr: glad it handles your use case too :) | 15:15 |
| brtknr | tbarron: your use case is is probably the better approach as you are in control over what groups are allowed to write to a pv | 15:18 |
| *** ykarel is now known as ykarel|away | 15:19 | |
| *** nfakhir has quit IRC | 15:26 | |
| *** ivve has quit IRC | 15:46 | |
| *** ricolin has quit IRC | 16:20 | |
| *** hongbin has joined #openstack-containers | 16:24 | |
| *** hongbin has quit IRC | 16:29 | |
| *** udesale has quit IRC | 17:00 | |
| *** mgariepy has quit IRC | 17:25 | |
| *** lpetrut has quit IRC | 17:44 | |
| *** sapd1_x has joined #openstack-containers | 17:51 | |
| *** spsurya has quit IRC | 17:52 | |
| *** lpetrut has joined #openstack-containers | 18:03 | |
| *** sapd1_x has quit IRC | 18:28 | |
| *** ykarel|away has quit IRC | 18:31 | |
| *** henriqueof has quit IRC | 18:38 | |
| *** ivve has joined #openstack-containers | 19:32 | |
| *** lpetrut has quit IRC | 19:39 | |
| *** henriqueof has joined #openstack-containers | 19:42 | |
| *** lpetrut has joined #openstack-containers | 20:08 | |
| *** strigazi has joined #openstack-containers | 21:01 | |
| strigazi | #startmeeting containers | 21:01 |
| openstack | Meeting started Tue Aug 6 21:01:36 2019 UTC and is due to finish in 60 minutes. The chair is strigazi. Information about MeetBot at http://wiki.debian.org/MeetBot. | 21:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 21:01 |
| *** openstack changes topic to " (Meeting topic: containers)" | 21:01 | |
| openstack | The meeting name has been set to 'containers' | 21:01 |
| strigazi | #topic Roll Call | 21:01 |
| *** openstack changes topic to "Roll Call (Meeting topic: containers)" | 21:01 | |
| strigazi | o/ | 21:01 |
| jakeyip | o/ | 21:01 |
| strigazi | Hello jakeyip | 21:03 |
| strigazi | #topic Announcements | 21:03 |
| *** openstack changes topic to "Announcements (Meeting topic: containers)" | 21:03 | |
| jakeyip | hi strigazi. wondering if flwang is around? | 21:03 |
| strigazi | After discussion with flwang , we will clean up the review list abandoning all patches olders than 30 days. of course contributors can reopen the them | 21:04 |
| jakeyip | +1 | 21:04 |
| strigazi | jakeyip: flwang is attenging a conference and can not join | 21:04 |
| strigazi | Since we are the two of us, let's make this an open discussion | 21:05 |
| strigazi | #topic Open Discussion | 21:05 |
| *** openstack changes topic to "Open Discussion (Meeting topic: containers)" | 21:05 | |
| strigazi | Is there something specific you would like to discuss jakeyip ? | 21:06 |
| strigazi | Any patches or something you need to be fixed? Any issues with your deployment? | 21:06 |
| jakeyip | thanks for putting a note on the quota patch. https://review.opendev.org/#/c/673782/ . since you think it's ok I will go on updating tests and such | 21:08 |
| *** lpetrut has quit IRC | 21:08 | |
| jakeyip | I'm currently working on a few things a.t.m. am interested in ceph's deployment of manila + magnum | 21:09 |
| strigazi | would you like also to pick https://review.opendev.org/#/c/657435/ ? | 21:09 |
| strigazi | jakeyip: https://gitlab.cern.ch/strigazi/csi-plugins | 21:10 |
| jakeyip | strigazi: sure I'll have to read the etherpad later to get more context | 21:10 |
| strigazi | jakeyip: the above soon will be update to csi 1.0 and csi-manila, but these work | 21:10 |
| jakeyip | are you doing nfs / cephfs to users? | 21:10 |
| strigazi | not nfs, only cephfs | 21:11 |
| jakeyip | and your cluster is nautilus? | 21:12 |
| tbarron | strigazi: note that there is a diff between the manila-provisioner and the newer manila-csi provisioner | 21:12 |
| strigazi | tbarron: yeap, unfortunatelly I know :) | 21:12 |
| jakeyip | hi tbarron! | 21:12 |
| jakeyip | I see there's a cvmfs csi too. that might be interesting to our HPC guys | 21:13 |
| tbarron | hi, sorry to interrupt | 21:13 |
| strigazi | unfortunatelly because we will need to change a bit. But we are keen to deploy when ready | 21:14 |
| tbarron | ack | 21:15 |
| strigazi | jakeyip: only limitation to these two is that they work with up to k8s 1.13.x | 21:15 |
| strigazi | manila-csi will implement csi 1.0, right tbarron ? | 21:16 |
| tbarron | strigazi: up | 21:16 |
| tbarron | yes | 21:16 |
| strigazi | and cvmfs-csi will have to be adapted accordingly | 21:16 |
| jakeyip | I see. I was testing with 1.13.7 so it's ok. | 21:16 |
| tbarron | i've only tested with 1.15.0 but 1.13.0+ should be good | 21:17 |
| jakeyip | what are you running in prod strigazi tbarron ? | 21:17 |
| strigazi | we do | 21:17 |
| tbarron | and as jakeyip and I discussed manila-csi requires a partner protocol plugin so for cephfs native that is | 21:17 |
| strigazi | tbarron: any pointer to the manifests you used for manila-csi? | 21:18 |
| tbarron | the ceph-csi plugin (just for node ) | 21:18 |
| tbarron | to actually do the mounts | 21:18 |
| tbarron | and it needs nautilus | 21:18 |
| tbarron | strigazi: I'll share them in this channel later, they are right now on a private file server | 21:18 |
| tbarron | strigazi: i've been testing with the nfs gateway and nfs partner plugin for ceph b/c that's my employer's immediate interest | 21:19 |
| strigazi | tbarron: ok, thanks. ping me if it is not trouble | 21:19 |
| tbarron | jakeyip: i'm not in production, am doing r&d as it were | 21:19 |
| tbarron | strigazi: of course, will get them public and share | 21:20 |
| tbarron | strigazi: not a secret, just a convenience atm | 21:20 |
| jakeyip | ok. thanks for all your input! | 21:20 |
| strigazi | tbarron: no problem, got it | 21:21 |
| strigazi | jakeyip: Do you want to discuss anything else? Shall we wrap otherwise? | 21:25 |
| jakeyip | I am ok. just want to say thank you for the work on reviews recently. that and abandoning old reviews will make it easier for us to help out with reviewing | 21:26 |
| flwang | sorry, i'm late | 21:27 |
| brtknr | o/ hey all | 21:27 |
| jakeyip | o/ | 21:27 |
| strigazi | o/ | 21:27 |
| flwang | strigazi: hey, i miss you | 21:27 |
| strigazi | :) | 21:28 |
| flwang | strigazi: did you see my question in the os patching patch? | 21:28 |
| strigazi | in which one? os upgrade? | 21:29 |
| flwang | now i'm stuck on the issue that i'm trying to create a temp service to do uncordon after upgrade/reboot, but after fedora atomic reboot, all the service files under /etc/systemd/system will be deleted | 21:29 |
| flwang | any idea? | 21:29 |
| flwang | i even tried to use ostree commit to commit current file system, but no help | 21:29 |
| flwang | os upgrade | 21:30 |
| strigazi | nothing on top of my head, I'll have a look | 21:31 |
| flwang | strigazi: thank you | 21:32 |
| flwang | strigazi: and recently, i'm working the fedora atomic 29 | 21:32 |
| strigazi | flwang: You need two things for f29 | 21:33 |
| flwang | i just found we have to enable the hwrng for nova | 21:33 |
| strigazi | one is the patch I did with cni (for calico maybe not an issue) | 21:33 |
| strigazi | the other is what you said | 21:33 |
| jakeyip | ah yes we have that too :) | 21:33 |
| strigazi | hwrng | 21:33 |
| strigazi | we have this in all our flavors now and all images | 21:33 |
| flwang | strigazi: hwrng in nova.conf and nova flavors, and a property on the image | 21:34 |
| jakeyip | strigazi: do you have any rate limits? | 21:34 |
| strigazi | not in nova.cin | 21:34 |
| strigazi | not in nova.conf | 21:34 |
| strigazi | not rate limits | 21:34 |
| flwang | strigazi: you mean don't need it for nova.conf? | 21:34 |
| strigazi | only one property in the flavor and one in the image | 21:34 |
| strigazi | nothings in nova.cinf | 21:34 |
| jakeyip | don't think so, as strigazi say just flavor and images | 21:34 |
| flwang | strigazi: ok, i will double check it again | 21:34 |
| flwang | jakeyip: are you saying you guys also didn't change the nova.conf, but just the flavor and image? | 21:35 |
| strigazi | yes | 21:35 |
| jakeyip | yeap it worked for us with flavor + image | 21:35 |
| flwang | strigazi: nice, it's much nicer | 21:35 |
| flwang | great | 21:35 |
| brtknr | flwang: strigazi: perhaps we should add some nodes in the docs to inform users about the hwrng quirk | 21:35 |
| strigazi | flavor: properties | hw_rng:allowed='True' | 21:35 |
| jakeyip | what is the nova.conf option you added? I can check what's in our nova.conf | 21:36 |
| brtknr | s/nodes/notes | 21:36 |
| strigazi | image hw_rng_model='virtio', | 21:36 |
| flwang | rng_dev_path=/dev/hwrng | 21:36 |
| jakeyip | yeah we would like a table of k8s version + os version + magnum version | 21:36 |
| flwang | i wonder if there is a default value for that | 21:36 |
| flwang | jakeyip: i will start to work out a matrix for that | 21:37 |
| flwang | jakeyip: pls help contribute when reviewing it | 21:37 |
| brtknr | strigazi: we did the same for our fa29 and it fixed the bootstrapping | 21:38 |
| strigazi | https://review.opendev.org/#/c/616603/ | 21:38 |
| strigazi | nova team doesn | 21:38 |
| strigazi | nova team doesn't bother it seems | 21:38 |
| strigazi | it is feature in kernels 4.19 or greater | 21:39 |
| flwang | strigazi: thanks for sharing that link, we should push that in | 21:39 |
| strigazi | the kernel needs more entropy to generate random numbers required somewhere in cloud-init | 21:39 |
| flwang | strigazi: btw, did you have a chance to try fc30? | 21:40 |
| flwang | given there is cloud-init in fc30, i think we may need a big change for our code? | 21:40 |
| flwang | there is no | 21:40 |
| jakeyip | is fc30 work being tracked in a story ? | 21:41 |
| brtknr | i tried to boot fc30 baremetal and did not get very far | 21:42 |
| strigazi | I have tried fedora core | 21:43 |
| strigazi | works fine for vms | 21:43 |
| flwang | jakeyip: https://storyboard.openstack.org/#!/story/2006209 | 21:43 |
| strigazi | needs some work, not a drop in replacement | 21:43 |
| flwang | strigazi: cool | 21:43 |
| flwang | strigazi: pls use https://storyboard.openstack.org/#!/story/2006209 to track the status | 21:44 |
| strigazi | what storage class has to do with fedora core? | 21:44 |
| *** henriqueof has quit IRC | 21:45 | |
| brtknr | I think he means this issue: https://storyboard.openstack.org/#!/story/2006348 | 21:45 |
| brtknr | flwang: ^ | 21:45 |
| flwang | strigazi: sorry, yes, this one https://storyboard.openstack.org/#!/story/2006348 | 21:48 |
| strigazi | ok | 21:48 |
| flwang | jakeyip: ^ | 21:48 |
| jakeyip | yeah thanks flwang I saw that | 21:49 |
| jakeyip | storageclass is interesting too I might need that too. any wip patches yet? | 21:49 |
| *** danil has quit IRC | 21:50 | |
| strigazi | not sure if StorageClass can be generic enough | 21:50 |
| flwang | strigazi: my idea is having a special config as a post-install-script | 21:51 |
| flwang | so that each vendor can define their own yaml file | 21:51 |
| flwang | for this case, just simple yaml to create the storageclass | 21:52 |
| flwang | with kubectl apply -f | 21:52 |
| flwang | post-install-yaml | 21:52 |
| jakeyip | where is this script going to be located? | 21:53 |
| jakeyip | master node? | 21:53 |
| flwang | wherever you want | 21:53 |
| strigazi | So we are not talking about a patch for storageclass | 21:53 |
| flwang | it can be a link pointed to a file on swift | 21:53 |
| flwang | strigazi: we're talking about https://storyboard.openstack.org/#!/story/2006209 | 21:53 |
| flwang | to have a out of box usable storage class | 21:54 |
| strigazi | yes, but the proposed design is to have the posthook do it, right? | 21:54 |
| flwang | yes, it's just an option | 21:54 |
| flwang | i'd like to get inputs from you guys which is the better way | 21:55 |
| strigazi | I'm not against it, fine for me | 21:55 |
| jakeyip | i kubectl from desktop using KUBECONFIG env var. writing a file to swift might work, but it seems clunky | 21:56 |
| flwang | jakeyip: another way we can do is, like the one we have done for the default k8s-keystone-auth policy file | 21:56 |
| strigazi | generic url might be better | 21:56 |
| flwang | strigazi: yep, i prefer a generic url as well | 21:57 |
| strigazi | could be s3, an http server | 21:57 |
| flwang | brtknr: any comment? | 21:58 |
| brtknr | sorry i was just reading about how ignition works | 21:58 |
| brtknr | we were thinking of adding a native support for manila | 21:59 |
| strigazi | Anything else to discuss guys? The time is alsmot up | 21:59 |
| brtknr | is this too much bloat or would this be desirable | 21:59 |
| brtknr | ? | 21:59 |
| flwang | strigazi: i'm good, thank you for joining us | 22:00 |
| strigazi | ignition + manila? | 22:00 |
| brtknr | e.g. get magnum to configure manila as default storage class | 22:00 |
| strigazi | flwang: cheers | 22:00 |
| brtknr | similar to what you get with google cloud | 22:00 |
| strigazi | brtknr: it can't be generic, manila has types | 22:00 |
| strigazi | each cloud has different names | 22:01 |
| strigazi | eg for "Meyrin Cephfs" | 22:01 |
| brtknr | strigazi: so what if MANILA_SHARE_TYPE is defined? | 22:01 |
| strigazi | and "Geneva testing" | 22:01 |
| jakeyip | just wondering, can we set up a default using labels passed in for magnum cluster? | 22:02 |
| strigazi | we have two for all users and more on demand for special users | 22:02 |
| jakeyip | e.g. if cinder similar options are passed in for docker-volume-type. | 22:02 |
| brtknr | there are already pieces for keystone authentication to generate share secrets | 22:03 |
| flwang | jakeyip: pass in what? | 22:03 |
| strigazi | We could, eg https://gitlab.cern.ch/strigazi/csi-plugins/blob/master/manila-provisioner.yaml#L82 | 22:03 |
| brtknr | not the end of the world if this is a post-deployment step... | 22:03 |
| strigazi | but it has many params | 22:03 |
| flwang | jakeyip: there are too many attributes in a storage class yaml | 22:03 |
| flwang | strigazi: +1 | 22:03 |
| brtknr | yes exactly | 22:04 |
| strigazi | I need to leave you guys, shall I end the meeting? | 22:04 |
| flwang | strigazi: let's end it | 22:04 |
| strigazi | thanks flwang jakeyip brtknr | 22:04 |
| flwang | jakeyip: can you see the point? with labels, it's too complicated | 22:04 |
| brtknr | thank you! | 22:04 |
| flwang | jakeyip: that's why i propose to pass a file/url directly to make things easier | 22:04 |
| brtknr | as far as i can see, the only parameter i can see is: type: "Meyrin CephFS" | 22:05 |
| strigazi | #endmeeting | 22:05 |
| *** openstack changes topic to "OpenStack Containers Team" | 22:05 | |
| openstack | Meeting ended Tue Aug 6 22:05:10 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 22:05 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/containers/2019/containers.2019-08-06-21.01.html | 22:05 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/containers/2019/containers.2019-08-06-21.01.txt | 22:05 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/containers/2019/containers.2019-08-06-21.01.log.html | 22:05 |
| brtknr | we already have username and password | 22:05 |
| brtknr | for authentication | 22:05 |
| strigazi | zone and it can have kernel or ceph-fuse too | 22:06 |
| strigazi | we can leave comments in the story, see you all | 22:06 |
| brtknr | ok no worries | 22:06 |
| brtknr | bye bye | 22:06 |
| jakeyip | ok | 22:06 |
| jakeyip | the story at https://storyboard.openstack.org/#!/story/2006209 is for cinder? | 22:06 |
| flwang | actually, it can be used for more | 22:07 |
| jakeyip | for cinder what's needed are az and vol type? | 22:07 |
| flwang | if we go for it as a post-install-yaml file | 22:07 |
| flwang | and names, description | 22:07 |
| flwang | there are many params you can define | 22:07 |
| flwang | and different cloud providers have different preferences | 22:08 |
| jakeyip | yeap | 22:08 |
| brtknr | yes, i think it makes more sense to have post-install-yaml i guess | 22:08 |
| brtknr | sometimes, one can over complicate things | 22:08 |
| jakeyip | so to create this as a post-install-yaml where will the information be gather from? | 22:09 |
| flwang | you can put everything in the yaml | 22:09 |
| brtknr | perhaps we ought to support a post install yaml that is tethered to a cluster template? | 22:10 |
| jakeyip | sorry, I mean where will the user provide things like protocol = CEPHFS and such | 22:10 |
| brtknr | so that when a cluster get provisioned, the template is applied automatically | 22:10 |
| jakeyip | as label in booting up cluster? in cluster template? | 22:10 |
| jakeyip | yes similar to what brtknr is saying | 22:11 |
| brtknr | jakeyip: in a kubernetes manifest | 22:11 |
| brtknr | jakeyip: answer to your question | 22:11 |
| jakeyip | so labels in cluster template -> k8s manifest ? | 22:12 |
| jakeyip | I think I probably need a play with this first... | 22:13 |
| *** henriqueof has joined #openstack-containers | 22:43 | |
| *** rcernin has joined #openstack-containers | 23:26 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!