Wednesday, 2020-04-01

*** dave-mccowan has quit IRC01:01
*** flwang1 has quit IRC03:34
*** ykarel|away is now known as ykarel04:10
*** udesale has joined #openstack-containers05:12
*** udesale has quit IRC05:14
*** udesale has joined #openstack-containers05:14
*** vishalmanchanda has joined #openstack-containers05:22
brtknrflwang1: hey06:10
*** irclogbot_1 has quit IRC06:49
*** spotz has quit IRC06:51
*** irclogbot_1 has joined #openstack-containers06:52
*** jhesketh has quit IRC06:52
*** irclogbot_1 has quit IRC06:53
*** jhesketh has joined #openstack-containers06:53
*** irclogbot_3 has joined #openstack-containers06:53
*** dtomasgu has quit IRC06:54
*** dtomasgu has joined #openstack-containers06:54
*** rcernin has quit IRC07:15
*** belmoreira has joined #openstack-containers07:16
*** ttsiouts has joined #openstack-containers07:46
openstackgerritBharat Kunwar proposed openstack/magnum master: fcos: Upgrade etcd to v3.4.6, use quay.io/coreos/etcd  https://review.opendev.org/71471908:21
*** ykarel is now known as ykarel|lunch08:30
openstackgerritBharat Kunwar proposed openstack/magnum master: fcos: Upgrade default flannel_tag to v0.12.0-amd64  https://review.opendev.org/71472008:41
*** flwang1 has joined #openstack-containers08:49
openstackgerritMerged openstack/magnum master: [k8s] Upgrade calico to the latest stable version  https://review.opendev.org/70559908:59
flwang1#startmeeting magnum09:01
openstackMeeting started Wed Apr  1 09:01:00 2020 UTC and is due to finish in 60 minutes.  The chair is flwang1. Information about MeetBot at http://wiki.debian.org/MeetBot.09:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.09:01
*** openstack changes topic to " (Meeting topic: magnum)"09:01
openstackThe meeting name has been set to 'magnum'09:01
flwang1#topic roll call09:01
*** openstack changes topic to "roll call (Meeting topic: magnum)"09:01
flwang1o/09:01
strigazio/09:01
flwang1brtknr:09:02
brtknr/09:02
brtknro/09:02
flwang1cool09:02
flwang1before go through the topics, just want to let you guys know, i will be serving Magnum PTL for the V cycle09:03
flwang1thank you for you guys support in the last 2 cycles09:03
brtknrthank you!09:04
strigazicheers09:04
flwang1strigazi: cheers09:04
flwang1#topic train 9.3.009:05
*** openstack changes topic to "train 9.3.0 (Meeting topic: magnum)"09:05
flwang1anything else we need to discuss about the 9.3.0?09:05
brtknrnot really, just that we should add release notes for important fixes09:05
brtknri think there were quite a few in this release09:05
ttsioutsο/09:05
brtknroh hi ttsiouts !09:06
strigazinothing from me09:06
flwang1brtknr: i agree we should provide more detailed release note09:06
strigaziI ususally -1 for reno09:06
strigaziwhat we missed09:06
strigazibrtknr: explain09:06
flwang1brtknr means we need more detailed release note, is it?09:06
strigaziI mean, which fixed we didn't add reno for, specifically09:07
strigazis/fixed/fixes/09:07
brtknrnot more detailed, but rather add them for various fixes we merged09:07
brtknri will need to go search09:07
brtknrwill add it to etherpad09:07
brtknrnot worth further discussion here09:08
flwang1like this https://review.opendev.org/#/c/715661/ :) ?09:09
strigazi17c6034e Add fcct config for coreos user_data09:09
flwang1https://review.opendev.org/#/c/715410/ :(09:09
brtknrflwang1: thats right09:09
brtknrmostly me :P09:10
flwang1brtknr: those are your baby09:10
strigazi17c6034e Add fcct config for coreos user_data, if this this needs a reno thne every single commit needs a reno.09:10
brtknrstrigazi: more of the user facing stuff09:10
brtknri would disagree that 17c6034e Add fcct config for coreos user_data needs a reno09:10
strigaziyou pasted it in etherpad :)09:11
flwang1ok, i think we're aware of the issue now and we just need to pay more attention and case by case?09:11
brtknrstrigazi: i am deleting thme one  by one,09:12
brtknrmy brain can only work so fast09:12
strigazilet's move one09:12
flwang1#topic health status update09:13
*** openstack changes topic to "health status update (Meeting topic: magnum)"09:13
strigazianything to dicsuss?09:13
strigazibrtknr: needs to review it first09:13
flwang1do you guys have new comments about this?09:13
strigaziI don't09:14
brtknrstrigazi: i already added my comments once, need to retest it with the magnum_auto_healer label, havent found time, sorry09:14
flwang1ok, let's move on then09:14
flwang1#topic Multi AZ support for master nodes https://review.opendev.org/71434709:14
*** openstack changes topic to "Multi AZ support for master nodes https://review.opendev.org/714347 (Meeting topic: magnum)"09:14
flwang1strigazi: brtknr: did you get a chance to review this idea?09:14
flwang1strigazi: i know cern is using multi az, does it sound right to you?09:15
strigaziwithout fixing add/del etcd members from etcd not heat, this makes little sense.09:15
strigaziwe don't use multi az for masters09:16
flwang1i know you don't, but why 'add/remove etcd' is a blocker for this one?09:16
strigazimulti-az without NGs sounds like overengineering to me, but we discussed this before.09:16
flwang1this is for masters, we already have the mutli az support for worker based on NG09:17
strigaziyou need to remove a dead memeber from etcd09:17
flwang1we can use auto healing09:17
strigazino09:17
flwang1why09:18
strigazias you want guys, do it with autohealing09:18
strigaziIf it is opt in, lgtm09:18
flwang1why don't you explain more to help us understand?09:19
flwang1i know this is not the perfect solution, but i can see the benefits09:20
strigazietcd uses the raft algorithm for concensus09:20
strigaziIt starts with one master and more membres are added09:20
strigazieach member contacts the all other memeber and they elect a leader.09:21
flwang1i understand your concern, you mean user may lost 1/2 etcd members in 1 az?09:21
strigaziIn magnum, we use discovery.etcd.io to advertise the IP of all member so they can elect a leader09:21
flwang1let's say there are 3 az and 3 master nodes or 5 master nodes09:22
flwang1can you please help me understand why it doesn't work?09:22
strigaziWhen you change the number of members, smth needs to drop or add the old/new memeber from the the etcd API/leader09:22
strigazi^^09:23
flwang1why do we have to change the number of members?  when losing an AZ?09:23
strigaziWhat if an etcd member is running there?09:24
strigaziWho is going to delete it?09:24
flwang1sorry, why do we have to delete the member? in current design, when do we have to delete a member?09:25
brtknrstrigazi: where does an etcd member need to be deleted from?09:25
strigaziAnd on then, a new member is added, how it will be added? with the discovery url it is not possible, the url is used only for bootstrap09:25
strigazisorry, why do we have to delete the member? in current design, when do we have to delete a member?09:26
strigazinever ^^ we don't change master nods09:26
strigazistrigazi: where does an etcd member need to be deleted from?09:26
strigazietcd ^^09:26
strigazihttps://etcd.io/docs/v3.3.12/op-guide/runtime-configuration/#remove-a-member09:27
brtknrso the master_az_list should work with fixed number of masters but not when we have scalable masters09:27
strigaziyes09:27
flwang1strigazi: yep, i can see where are come from, but i  think i'm trying to fix this based on current design09:27
brtknrdoes the leader election fail if a member is dead?09:27
flwang1and even if we could support the resized master later, my current way should also work09:28
brtknror will the remaining members elect a leader and carry on?09:28
strigaziso you plan to leave it dangling09:28
strigaziI haven't tried, but the docs don't say: stop the member and everything is good.09:28
flwang1strigazi: the list is automatically generated based on the new number09:28
strigaziok09:29
*** belmoreira has quit IRC09:29
flwang1strigazi: see https://review.opendev.org/#/c/714347/2/magnum/drivers/heat/k8s_fedora_template_def.py@22509:29
flwang1it's not a fixed list09:29
strigaziok09:29
flwang1are we on the same page now? do you think my current solution could work ?09:30
strigaziI don't knwo09:30
strigaziI don't know09:30
strigazilet's move on, when is is complete we can test09:30
flwang1TBH, i haven't done a fully testing, but the idea is there09:31
brtknrwhat i dont understand is what the multi_az_list has to do with removing etcd member09:31
flwang1ok, i will keep polish it09:31
brtknrseems like two separate issues09:31
flwang1brtknr: +109:31
strigazilet;s move on09:31
brtknrmight be missing a point here09:31
flwang1#topic Allowed CIDRs for master LB  https://review.opendev.org/#/c/715747/09:31
*** openstack changes topic to "Allowed CIDRs for master LB  https://review.opendev.org/#/c/715747/ (Meeting topic: magnum)"09:31
flwang1here is a new feature introduced in Octavia stein release09:31
flwang1to allow setting a CIDR list for lb09:32
brtknrthis is conditional on heat merging the equivalent change right?09:32
brtknri.e. its not supported in heat yet09:32
brtknri.e. its not supported in stable/train branch yet09:32
flwang1it's supported in heat master branch09:32
brtknryep09:32
flwang1i'm trying to cherrypick to train09:32
brtknrah i see09:32
flwang1since it's a very useful feature09:33
flwang1especially when you want to open the lb on public09:33
brtknri'm happy with this patch09:33
flwang1strigazi: i need your help https://review.opendev.org/#/c/715747/1..2/magnum/drivers/common/templates/lb_api.yaml09:33
flwang1how should we deal with this case?09:34
strigazithis was added where?09:34
flwang1we're using old heat template version, but how can we use a good new feature in latest heat version09:34
strigazithe feature in heat09:34
flwang1https://review.opendev.org/#/c/715747/2/magnum/drivers/k8s_fedora_atomic_v1/templates/kubecluster.yaml09:35
brtknrcan we not upgrade the template version?09:35
strigazithis was added where? the feature in heat09:35
flwang1strigazi: wait a sec09:35
flwang1https://review.opendev.org/#/c/715748/09:35
strigaziWhich version we need change to09:35
strigaziso train09:36
flwang1heat support this https://review.opendev.org/#/c/715748/1/heat/engine/resources/openstack/octavia/listener.py@13709:36
strigazior ussuri09:36
flwang1but i haven't test if heat can automatically respect the version09:36
flwang1yep, Ussuri now09:36
flwang1and i'm trying to cherry pick it to train09:36
flwang1let's assume it can't be cherrypicked09:37
flwang1strigazi: any idea?09:37
strigaziso change to  ussuri, then heat ussuri/train is a hard dep for magnum when API LB is required09:37
flwang1that's what my concern09:38
flwang1that's why i'm asking you if there is a better solution09:38
flwang1to avoid the hard depedency09:38
strigaziAdd one more template?09:38
strigazifyi, at CERN it is not issue, we upgrade heat and we drop this part anyway.09:39
flwang1yep, another template may work09:39
brtknrdrop what part?09:40
flwang1i will think about it09:40
strigaziMaybe it will be an issue, but we will add one more local patch09:40
flwang1will cern be interested in this feature?09:40
brtknris there a way to set allowed_cidr to the loadbalancer09:41
brtknris there a way to set allowed_cidr to the loadbalancer directly?09:41
strigaziwe don't have LBaaS. It is a very new feature with tungten.09:41
flwang1brtknr: should be, but it's not handy09:41
flwang1are you talking about set it by python code by calling octavia client?09:42
flwang1brtknr: ^09:42
brtknrwe already have train heat requirement for train magnum09:42
brtknrbecause of fedora coreos09:42
strigaziMaybe we take this in gerrit? Is there anything else for the meeting?09:43
flwang1right09:43
flwang1nothing else09:43
flwang1i'm good09:43
flwang1anything else you guys want to discuss?09:43
brtknrttsiouts: dioguerra said you are working on the labels09:43
strigaziwe don't have a spec yet09:44
strigaziwhen can discuss it then09:44
strigaziwe can discuss it then09:44
brtknrok sure09:44
ttsioutsbrtknr: I'm drafting the spec09:44
ttsioutsI'll try to upload it today09:44
brtknrttsiouts: sounds good :)09:45
brtknr1 more thing09:47
brtknrflwang1: strigazi: what are the curentl limitations for enabling resizable masters09:47
flwang1etcd09:47
brtknris that it?09:48
brtknrbecause we dont have a way of adding/removing members dynamically?09:48
strigazihave you every tried it?09:48
strigaziyou can use the heat api to change the number of masters09:49
*** osmanlicilegi has quit IRC09:49
brtknrstrigazi: havent tried yet09:49
*** osmanlicilegi has joined #openstack-containers09:50
flwang1strigazi: i'm a bit confused, do you mean calling heat api directly to resize master could work?09:50
strigaziit will work towards failure09:51
flwang1right09:51
brtknrstrigazi: how do you resize directly using heat api?09:51
flwang1let's end the meeting09:51
openstackgerritMerged openstack/magnum master: Update hacking for Python3  https://review.opendev.org/71634709:52
flwang1we can continue the discussion09:52
flwang1#endmeeting09:52
*** openstack changes topic to "OpenStack Containers Team | Meeting: every Wednesday @ 9AM UTC | Agenda: https://etherpad.openstack.org/p/magnum-weekly-meeting"09:52
openstackMeeting ended Wed Apr  1 09:52:13 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)09:52
openstackMinutes:        http://eavesdrop.openstack.org/meetings/magnum/2020/magnum.2020-04-01-09.01.html09:52
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/magnum/2020/magnum.2020-04-01-09.01.txt09:52
openstackLog:            http://eavesdrop.openstack.org/meetings/magnum/2020/magnum.2020-04-01-09.01.log.html09:52
flwang1thank you team09:52
*** k_mouza has joined #openstack-containers09:53
flwang1brtknr: if you're interested in the resize master work, i'm happy to support you09:54
strigaziflwang1: aren't you doing this already?09:54
brtknrstrigazi: openstack stack update --parameter number_of_masters=3 <stackid>?09:55
flwang1i did some investigation before, but haven't done any code09:55
strigaziyes09:55
strigaziAre brtknr are going to write the code?09:55
flwang1strigazi: i'm trying to convince him ;)09:56
brtknrlol09:56
strigazibrtknr: are you going to write the code?09:56
flwang1strigazi: i can see you're interested in this too09:56
strigaziit seems I can't type.09:56
flwang1strigazi: why don't you do it? you're the best person can do this job09:56
brtknrI need to convince my company to pay me to do this first09:56
flwang1me and brtknr don't have enough knowledge to finish it09:57
strigaziI try to not overengineer magnum and then even for me it is impossible to patch09:57
flwang1i will leave this topic to you guys, i have to go09:57
flwang1thank you guys, good to have you in the team09:58
flwang1stay safe09:58
brtknrlooks like the command to use is: openstack stack update --parameter number_of_masters=2 k8s-flannel-coreos-r6k223a4cny3 --existing09:58
strigazigood night09:58
strigaziyes09:58
brtknretcd has failed09:58
flwang1brtknr: you can get the new master node, but the etcd member may fail to join09:58
*** ykarel|lunch is now known as ykarel09:59
strigaziso it works as I said :)09:59
strigazifailure reached successfully ;)09:59
strigazibrtknr: so you are working on it10:00
brtknrstrigazi: i jus wanted to see what would happen10:00
brtknri have no idea how to deal with this10:01
strigazibut you can 't work on it yet10:01
strigaziAnyway, see you later, I have a meeting in a bit.10:02
strigazihave a nice day10:02
brtknryou too strigazi10:02
openstackgerritMerged openstack/magnum master: fcos: Upgrade etcd to v3.4.6, use quay.io/coreos/etcd  https://review.opendev.org/71471910:06
*** rcernin has joined #openstack-containers10:35
cosmicsoundbrtknr , i was refering to the docker service daemon if it needs to advertise the etcd10:35
openstackgerritMerged openstack/magnum master: fcos: Upgrade default flannel_tag to v0.12.0-amd64  https://review.opendev.org/71472010:45
*** ttsiouts has quit IRC11:42
*** ttsiouts has joined #openstack-containers11:44
*** ricolin has quit IRC11:54
*** sapd1_x has quit IRC12:03
*** spotz has joined #openstack-containers12:07
openstackgerritTheodoros Tsioutsias proposed openstack/magnum-specs master: [WIP] Magnum Labels Override  https://review.opendev.org/71657112:36
ttsioutsstrigazi, brtknr: ^^12:37
ttsioutsit's still wip, but all comments are more than welcome12:37
cosmicsoundbrtknr , latest heat agent log12:38
cosmicsoundit failes with: Create Failed12:38
cosmicsoundResource Create Failed: Error: Resources[0].Resources.Master Config Deployment: Deployment To Server Failed: Deploy Status Code: Deployment Exited With Non-Zero Status Code: 112:38
cosmicsoundwhile the journalctl -u heat-agent gives me: Apr 01 12:39:06 kubernetes-bi25yp3cc4ta-master-0.novalocal runc[1622]: /var/lib/os-collect-config/local-data not found. Skipping12:39
*** dave-mccowan has joined #openstack-containers12:50
*** dave-mccowan has quit IRC12:54
*** sapd1_x has joined #openstack-containers12:57
k_mouzagood afternoon all! Quick question please. I'm trying to deploy a K8s cluster via Openstack Magnum (stable/rocky), based on fedora-atomic-29 images. The environment I'm working on doesn't have internet access and I've set up a local registry for the K8s components. I've set that registry in the container_infra_prefix label, but it's insecure and the stack fails when trying to pull images from12:59
k_mouzait. I've also tried the insecure_registry flag in the template, but that's for the app images from what I can tell. Any help please? Is it possible to have a Magnum K8s deployed in an air-gapped environment? Thanks!12:59
*** ricolin_ has joined #openstack-containers13:01
*** udesale_ has joined #openstack-containers13:09
*** udesale has quit IRC13:11
guilhermesphey brtknr flwang1 ! morgnins. I just applied the latest commit of master on our deployment! I'm about to try to create both v1.17 and v1.18 clusters and run conformance, but I have a little question for ya13:13
guilhermesphow you guys deals with upgrades? I mean, sometimes we have new labels to add in the cluster templates ( i.e https://github.com/openstack/magnum/commit/454b0f55ec1b3e1cb561317bc0d52949916078ab )13:13
guilhermespand it happens that we have some public cluster templates for our customers, but I noticed that, if a cluster template is being used we cannot update it and neither delete it. So which means we need to create another public cluster template to offer the latest magnum features13:14
cosmicsoundDo I need Octavia to run Magnum?13:16
guilhermespfor multimaster, yes cosmicsound13:17
cosmicsoundI use only one master13:17
cosmicsoundalto even that one keeps on failing13:17
cosmicsoundI was thinking is mandatory13:19
cosmicsoundSince our cluster keeps on failing at start13:19
*** mgariepy has quit IRC13:24
*** mgariepy has joined #openstack-containers13:25
brtknrguilhermesp: new features == new template13:31
brtknrits by design13:32
*** ttsiouts has quit IRC13:38
*** sapd1_x has quit IRC13:42
*** ykarel is now known as ykarel|afk13:43
*** ttsiouts has joined #openstack-containers13:48
*** sapd1_x has joined #openstack-containers13:55
guilhermespi see, thanks for clarifying brtknr13:55
brtknrguilhermesp: in train, you can upgrade user cluster to a new template, after which the old cluster can be deleted13:57
guilhermesphum interesting... we've been trying to find ways to do this, coz nowadays we just say to customer: delete your cluster and create a new one with this new template, which makes them a bit sad13:58
*** ykarel|afk is now known as ykarel14:02
guilhermespim currently using Fedora Atomic 29 [2019-08-20], should we use a newer version for current master?14:10
guilhermespafter bumping shas to current master it seems my cluster is stuck on api_lb creation14:10
*** ttsiouts has quit IRC14:17
*** sapd1_x has quit IRC14:17
brtknrguilhermesp: not sure why that would be14:22
brtknrfrom using a new image14:22
guilhermespyeah not sure. My cluster is stuck on creating master and as I can see journalctl shows me14:24
guilhermespabr 01 14:24:22 v17-conformance-hfxchcas2wl6-master-0.vexxhost.local bash[3631]: E0401 14:24:22.602980    3694 kubelet.go:2263] node "v17-conformance-hfxchcas2wl6-master-0" not found14:24
guilhermespand14:25
guilhermesphttps://www.irccloud.com/pastebin/4qRIBg0P/14:25
guilhermespi was using a relatively old sha 1115672e7284bdd77a5951e93d47b22495c33d9114:27
guilhermespupgraded to 0fffdd1956af06c0f9bbcb325cbef2773816799a14:27
*** sapd1_x has joined #openstack-containers14:30
guilhermespand finally the labels Im using :)14:32
guilhermesphttps://www.irccloud.com/pastebin/hFmbTHMC/14:32
*** sapd1_x has quit IRC14:41
*** sapd1_x has joined #openstack-containers14:46
*** ttsiouts has joined #openstack-containers15:03
*** sapd1_x has quit IRC15:15
*** ykarel is now known as ykarel|away15:22
guilhermesphuum ok i removed that label etcd_tag': u'3.4.3'15:23
guilhermespnow I have a cluster completed15:23
*** sapd1_x has joined #openstack-containers15:28
*** pcaruana has quit IRC15:32
guilhermesphuum but UNHEALTHY  . There is no kubectl command as well. Do we have to set an specific etcd_tag?15:37
brtknrguilhermesp: are you using fedora atomic with use_podman=true?15:41
guilhermespyep, i remember once you guys saying etcd needs to be >= 3.4.3 right?15:43
guilhermespI removed etc_tag as above and failed, which i think is expected as it is getting an old version by default15:43
guilhermespI'm about to test 3.4.615:43
brtknrok15:43
brtknr3.4.3 should work but no harm in testing newer15:44
brtknrwhats in the error logs?15:44
brtknrssh into the master15:44
brtknrnow, there should be log inside /var/log/heat-config15:44
brtknrif you are using ussuri-dev heat_container_agent tag which is the default if you are using train15:45
brtknr1.17.4 is the latest kube_tag15:46
brtknrv1.17.415:46
brtknrim looking at thi15:46
brtknrhttps://www.irccloud.com/pastebin/hFmbTHMC/15:46
brtknryou dont need kube_version label15:46
*** pcaruana has joined #openstack-containers15:48
guilhermesphum which means then i should be using etcd_tag=3.4.3 or higher and kube_tag=1.17.415:51
guilhermespi will give a try, using these tags above + etcd_tag=3.4.6 also fails.15:52
guilhermespi can see the heat-config logs here15:52
guilhermespand HEAT_CONTAINER_AGENT_TAG=ussuri-dev15:52
brtknrthat etcd registry is unofficial and lags behind latest etcd release15:52
brtknri think the latest supported there is 3.4.415:53
guilhermespi will change my template to use kube_tag=1.17.4 and etcd_tag=3.4.315:53
brtknrare you using 9.2.0 train?15:53
brtknror master?15:53
guilhermespcurrent master15:53
brtknrah okay15:53
guilhermespto apply the fixes for conformance15:53
brtknrlatest master?15:53
brtknror recent master?15:53
guilhermespand also add support to v1.1815:53
guilhermesp0fffdd1956af06c0f9bbcb325cbef2773816799a this hsa15:54
brtknrthis is important because we merged a change for etcd15:54
guilhermespsha*15:54
brtknrah okay15:54
brtknrso you should use v3.4.615:54
brtknrbeacuse we've change the etcd registery15:55
brtknrwhich follows the same release tag convention as main etcd development repo15:55
brtknrv1.18 is already supported15:55
guilhermespyeah so currently my cluster template is using etcd_tag=3.4.3. But I guess I also need to change the kube_tag to 1.17.4 right?15:56
brtknrin fact, you dont need to specify etcd_tag :)15:56
brtknrits already using the latest15:56
brtknrif you are using fedora coreos15:57
guilhermespfedora-atomic15:57
brtknri have not tested atomic with podman15:57
brtknratomic is eol, no more security updates15:57
guilhermesphuuum that might be an answer then, We've been using fedora-atomic15:57
brtknractually if you are using use_podman, v3.4.6 etcd_tag should work15:58
brtknras it uses the same common script15:58
guilhermespfor atomic?15:58
brtknrboth atomic and coreos15:58
brtknryes15:58
guilhermesphum15:58
brtknrits just not the default value15:58
brtknrso you have to set it manually15:58
brtknrbecause use_podman is an opt-in feature in atomic15:58
brtknruse_podman=true by default is coreos15:58
guilhermespi though podeman as a requirement for both atomic and coreos prior to v1.1715:59
guilhermesphttps://www.irccloud.com/pastebin/C3HIyHnk/16:01
guilhermespok currently those are my labels that are not working with fedora atomic16:01
guilhermespi will remove kube_version and edit kube_tag to 1.17.416:01
brtknrguilhermesp: do not remove the v from 3.4.616:03
brtknrit should be v3.4.616:03
brtknrnot 3.4.616:03
guilhermespah ok, fixing this16:03
guilhermespok testing this one now16:04
guilhermesphttps://www.irccloud.com/pastebin/4nDJXB7E/16:05
guilhermespok create complete. Let me check how the cluster is16:19
guilhermesphttps://www.irccloud.com/pastebin/Zi5FVGxq/16:20
guilhermespwatching to see if they become ReadY16:20
guilhermespfor now the cluster status is UNHEALTHY16:21
guilhermesphttps://www.irccloud.com/pastebin/gMK3372i/16:22
guilhermespyeah i guess it might be better for me to start using fedora coreos. Do you have an image come in handy for me to test brtknr ?16:50
guilhermespthink i found it http://beta.release.core-os.net/amd64-usr/current/coreos_production_openstack_image.img.bz217:09
*** udesale_ has quit IRC17:29
*** k_mouza has quit IRC18:03
*** k_mouza has joined #openstack-containers18:06
*** k_mouza has quit IRC18:19
*** k_mouza has joined #openstack-containers18:33
*** k_mouza has quit IRC18:34
*** k_mouza has joined #openstack-containers18:35
*** k_mouza has quit IRC18:39
*** sapd1_x has quit IRC18:43
brtknrguilhermesp: not coreos, fedora coreos19:04
brtknryou can try this script: https://github.com/stackhpc/magnum-terraform/blob/master/upload-coreos.sh19:05
guilhermespyeah I havent had much success with that image19:05
* guilhermesp looking 19:05
brtknrguilhermesp: you need jq installed19:05
brtknrit always uploads the latest stable image19:06
guilhermespive noticed in that failed cluster above is that is it using some train tags for calico, coreos, but as I'm running the latest master commit, I think those values should be default to ussuri?19:06
guilhermespok i will give a try with that image19:06
guilhermespit seems that fedora-atomic is no longer be an option in the future ( or now actually ) ?19:07
* guilhermesp uploads using script :)19:10
guilhermespok so as you said earlier no need to set label use_podman as it is by default for fedora-coreos right?19:21
guilhermesphum yeah it seems that image is not booting up in our cloud19:29
flwang1guilhermesp: it would be nice if you can share you template19:34
guilhermesphttps://www.irccloud.com/pastebin/LoODmw2E/19:35
guilhermespthere it is flwang119:35
guilhermespbut yeah, not sure but instances with that image are stuck on cloud-init19:35
guilhermespps: first time I use a fedora-cores image19:36
guilhermespive been using atomic till now so, I think is preferable for now on fedora-coreos19:36
flwang1guilhermesp: what's your heat version?19:36
guilhermesplet me grab it here19:36
flwang1guilhermesp: fedora atomic has been EOL since last November19:37
guilhermespbtw some logs of cloud-init  of master node ( with coreos ) http://paste.openstack.org/show/791484/19:37
guilhermespyeah, that was  a good point, I want to switch to coreos for now on19:37
flwang1fedora Coreos doesn't support cloud-init, it's using Ignition19:38
guilhermesphuum ok so that explains19:39
guilhermespbtw these are the parameters we use for heat19:39
guilhermesphttps://www.irccloud.com/pastebin/tvqbCOgr/19:40
guilhermespso flwang1 we are not able then to run fedora-coreos with cloud-init?19:40
flwang1guilhermesp: there is no cloud-init inside fedora-coreos19:41
flwang1guilhermesp: you probably have to upgrade heat to train or cherrypick patch like this https://review.opendev.org/#/c/696327/19:42
guilhermespi think upgrading heat to train would be better. As I understood, with train or this patch I am be able to create the nodes with fedora-coreos through heat right?19:46
flwang1guilhermesp: yes19:48
*** k_mouza has joined #openstack-containers19:48
flwang1guilhermesp: are you responsible for taking care k8s/magnum in vexxhost?19:49
*** k_mouza has quit IRC19:50
guilhermespyep flwang119:50
guilhermespfrom time to time19:50
guilhermespwhen I have a stable cluster template19:50
guilhermespi start testing new k8s version19:50
flwang1nice, then i'd like invite you to join magnum team and our weekly meeting19:51
guilhermespwould be important i guess. I'm missing a lot of stuff :P19:51
flwang1so that you can know what's happening ;)19:51
guilhermespyep19:52
guilhermespis there some sort of reminder for the meeting?19:52
flwang1https://etherpad.openstack.org/p/magnum-weekly-meeting guilhermesp19:53
guilhermespthanks flwang119:54
guilhermespwell yeah I'm discussing here with mohammed what patch we should follow19:54
guilhermespupgrade our heat to train or just cherry pick19:54
guilhermespthe thing is we offer magnum for some customers, and there are clouds that are still stein19:55
guilhermespso maybe a cherry pick would be a quick option to test fedora-coreos19:55
guilhermespflwang1: did you see the cluster template above? i guess the labels might be ok with fedora-coreos19:56
flwang1i saw that20:05
flwang1it  shouldn't be a problem20:05
flwang1i think cherrypick it an easier option20:06
flwang1guilhermesp: ^20:11
guilhermespyeah i will try to cherry pick here in the env Im working and then i will use that cluster template to see what happens :P20:13
guilhermespi will tell you my results20:13
flwang1guilhermesp: no problem20:17
flwang1brtknr: re the health status update patch, what's the document you would like to see in the user guide?20:18
brtknrflwang1: The effect magnum auto healer has on the poller20:19
flwang1brtknr: ok, i see.20:19
flwang1i will add a section to explain the current health monitoring20:19
brtknrflwang1: are you able to provide an auto healer Docker image that I can deploy to test this feature?20:24
*** flwang1 has quit IRC20:25
*** flwang1 has joined #openstack-containers20:28
flwang1https://hub.docker.com/r/k8scloudprovider/magnum-auto-healer/tags20:28
flwang1brtknr: ^20:28
guilhermespbtw flwang1 brtknr is this going to be backported to train? https://review.opendev.org/#/c/716420/20:35
flwang1i need to think about it, but i can't see why not20:37
guilhermespyeah, as I was getting a v1.17 + fedora atomic with traino 9.2.0, i think we have this commit in train I can keep using mangum train and have support to v1.17 ( + conformance ) until we decide to upgrade our envs20:39
*** vishalmanchanda has quit IRC20:39
flwang1guilhermesp: yep, but are you sure your customer will be happy using an EOL operating system for their k8s?20:40
flwang1so my personal suggestion is starting to consider the upgrade :)20:40
guilhermespyeah that would be good to take into consideration20:41
guilhermespi still need some of the mohammed's time to discuss :P20:41
guilhermespjust thinking in some option, but yeah good point flwang120:41
flwang1:) let me know if you need any help20:42
*** bline has joined #openstack-containers21:09
*** N3l1x has joined #openstack-containers21:15
*** ttsiouts has quit IRC21:22
*** ttsiouts has joined #openstack-containers21:54
*** ttsiouts has quit IRC21:59
*** aspiers has quit IRC22:08
*** k_mouza has joined #openstack-containers22:15
*** flwang1 has quit IRC22:22
*** ttsiouts has joined #openstack-containers22:36
*** aspiers has joined #openstack-containers22:40
*** k_mouza has quit IRC23:30
*** flwang1 has joined #openstack-containers23:43
*** flwang1 has quit IRC23:45

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!