From stephane.lebihan at amundi.com Mon Sep 9 08:30:21 2019 From: stephane.lebihan at amundi.com (=?iso-8859-1?Q?Le_Bihan_St=E9phane_=28AMUNDI-ITS=29?=) Date: Mon, 9 Sep 2019 14:30:21 +0000 Subject: [caasp-beta] platform architecture and filesystem Message-ID: Hi all, In CAAS v3 we have dedicated devie for /var/lib/docker. For Caas V4, we also want to use this device. But I see copy-and-write is disable for subvolume /var on base installation SLES15. So, from your opinion, what is best solution : ? Keep /var on subvolumes with no copy-and-write, and mount device in /var/lib/container ? Mout device on /var (But I can see where in autoyast or other I can disble copy-and-write with no subvolume) ? Mount device on /var, create subvolume with no copy-ad-write for /var/lib/container, /var/lib/kubelet, /var/lib/crio etc .... Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From vmoutoussamy at suse.com Tue Sep 10 06:42:25 2019 From: vmoutoussamy at suse.com (Vincent Moutoussamy) Date: Tue, 10 Sep 2019 12:42:25 +0000 Subject: [caasp-beta] Q: How to get more output from skuba? In-Reply-To: <2e2f3a50f9954ee0a2662d56c813d5e8@akdb.de> References: <2e2f3a50f9954ee0a2662d56c813d5e8@akdb.de> Message-ID: <3C8FFA50-8619-4E0F-B857-232640B47382@suse.com> Hi there, Sorry for the late followup on this, did you had the chance to retest with RC1? Did you still face the same issue? Regards, -- Vincent Moutoussamy SUSE Beta Program, JeOS and SDK Project Manager > On 22 Jul 2019, at 15:10, egov-devops wrote: > > Howdy, > > I?m still stuck at joining my second master ?master2?, after initially bootstrapping master1, successfully and an supposedly running cluster. > caasp-admin:~/caasp4b4 # skuba cluster status > ** This is a BETA release and NOT intended for production usage. ** > NAME OS-IMAGE KERNEL-VERSION KUBELET-VERSION CONTAINER-RUNTIME HAS-UPDATES HAS-DISRUPTIVE-UPDATES > caasp-master1 SUSE Linux Enterprise Server 15 SP1 4.12.14-197.10-default v1.15.0 cri-o://1.15.0 no no > > Is there a way to get more debug output from skuba? Yes, I?ve already set ?v 9, see my command bleow? > > I still get the error: > caasp-admin:~/caasp4b4 # skuba node join -v 9 --role master --user sles --sudo --target 10.255.1.4 caasp-master2 2 > >&1 | tee out.m2.txt > ** This is a BETA release and NOT intended for production usage. ** > I0722 15:03:19.034550 8926 loader.go:359] Config loaded from file: admin.conf > I0722 15:03:19.035579 8926 round_trippers.go:419] curl -k -v -XGET -H "Accept: application/json, */*" -H "User > -Agent: skuba/v0.0.0 (linux/amd64) kubernetes/fd919f4" 'https://10.255.1.2:6443/api/v1/nodes/caasp-master2' > I0722 15:03:19.047282 8926 round_trippers.go:438] GET https://10.255.1.2:6443/api/v1/nodes/caasp-master2 404 No > t Found in 11 milliseconds > I0722 15:03:19.047359 8926 round_trippers.go:444] Response Headers: > I0722 15:03:19.047388 8926 round_trippers.go:447] Content-Type: application/json > I0722 15:03:19.047415 8926 round_trippers.go:447] Content-Length: 196 > I0722 15:03:19.047444 8926 round_trippers.go:447] Date: Mon, 22 Jul 2019 13:03:30 GMT > I0722 15:03:19.047510 8926 request.go:947] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"sta > tus":"Failure","message":"nodes \"caasp-master2\" not found","reason":"NotFound","details":{"name":"caasp-master2" > ,"kind":"nodes"},"code":404} > [join] applying states to new node > I0722 15:03:19.047945 8926 states.go:35] === applying state kubernetes.join.upload-secrets === > I0722 15:03:19.047981 8926 deployments.go:50] uploading local file "pki/ca.crt" to remote file "/etc/kubernetes > /pki/ca.crt" > I0722 15:03:19.048080 8926 files.go:29] uploading to remote file "/etc/kubernetes/pki/ca.crt" with contents > [join] failed to apply join to node failed to apply state kubernetes.join.upload-secrets: Process exited with status 1 > F0722 15:03:19.318024 8926 join.go:50] error joining node caasp-master2: failed to apply state kubernetes.join.upload-secrets: Process exited with status 1 > > So how to debug, what the problem is? > > Mit freundlichen Gr??en > > Alexander Schie?l > Team DevOps > Gesch?ftsfeld eGovernment > > Telefon +49 800 2553222-65 > egov-devops at adkb.de > __________________________________________________________ > > AKDB ? Anstalt des ?ffentlichen Rechts ? Hauptverwaltung M?nchen > Hansastr. 12 - 16 ? 80686 M?nchen ? www.akdb.de > > _______________________________________________ > caasp-beta mailing list > caasp-beta at lists.suse.com > Check the mailing list archives or Unsubscribe at http://lists.suse.com/mailman/listinfo/caasp-beta From dennis.loos at ctac.nl Tue Sep 10 03:12:35 2019 From: dennis.loos at ctac.nl (Dennis Loos) Date: Tue, 10 Sep 2019 09:12:35 +0000 Subject: [caasp-beta] Error bootstrapping first node with skuba Message-ID: Hi, I am trying to set up a cluster, but it seems files have been moved on the updates.suse.com website: I0910 11:03:52.926763 21839 ssh.go:190] stdout | In cache python3-cephfs-14.2.2.349+g6716a1e448-3.9.1.x86_64.rpm (49/65), 192.8 KiB (369.2 KiB unpacked) I0910 11:03:52.940155 21839 ssh.go:190] stdout | In cache ceph-common-14.2.2.349+g6716a1e448-3.9.1.x86_64.rpm (50/65), 3.9 MiB ( 13.5 MiB unpacked) I0910 11:03:52.944249 21839 ssh.go:190] stdout | In cache cni-0.6.0-1.11.x86_64.rpm (51/65), 1.1 MiB ( 5.6 MiB unpacked) I0910 11:03:52.950438 21839 ssh.go:190] stdout | In cache runc-1.0.0~rc6-1.3.1.x86_64.rpm (52/65), 1.7 MiB ( 7.3 MiB unpacked) I0910 11:03:53.005544 21839 ssh.go:190] stdout | In cache cni-plugins-0.7.4-1.11.x86_64.rpm (53/65), 16.4 MiB ( 52.0 MiB unpacked) I0910 11:03:53.006451 21839 ssh.go:190] stdout | Retrieving package cri-tools-1.15.0-1.1.x86_64 (54/65), 20.0 MiB ( 68.6 MiB unpacked) I0910 11:03:53.197418 21839 ssh.go:190] stderr | Media source 'https://updates.suse.com/SUSE/Products/SUSE-CAASP/4.0/x86_64/product?gnEAAAAAAAAAAAAAaCre0mwzsxdmYAWhFPJljcOQ6l7i-dWpsvsPVeyFA-o- nYhGP48-bAq1PfUGSe596IiI8QW1ttAjOdqBDteTxWWb7ug32yBiRrb7L6_zYSF8Cc9-LSmin0zCYQLAHg' does not contain the desired medium I0910 11:03:53.197491 21839 ssh.go:190] stdout | Abort, retry, ignore? [a/r/i/...? shows all options] (a): a I0910 11:03:53.302195 21839 ssh.go:190] stderr | Problem occurred during or after installation or removal of packages: I0910 11:03:53.302218 21839 ssh.go:190] stderr | Installation has been aborted as directed. I0910 11:03:53.302228 21839 ssh.go:190] stderr | Please see the above error message for a hint. F0910 11:03:53.307056 21839 bootstrap.go:49] error bootstraping node: failed to apply state kubernetes.install-node-pattern: Process exited with status 8 When I try that URL manually I get a http 301 Moved Permanently error, get directed to the root html page: Index of /SUSE/Products/SUSE-CAASP/4.0/x86_64/product

Index of /SUSE/Products/SUSE-CAASP/4.0/x86_64/product

Icon  Name                                  Last modified      Size  Description
[DIR] Parent Directory - [   ] CHECKSUMS 09-Sep-2019 08:02 163 [TXT] CHECKSUMS.asc 09-Sep-2019 08:02 481 [DIR] media.1/ 09-Sep-2019 08:13 - [DIR] noarch/ 09-Sep-2019 08:13 - [DIR] repodata/ 09-Sep-2019 08:13 - [DIR] x86_64/ 09-Sep-2019 08:13 -
Apache/2.2.12 (Linux/SUSE) Server at updates.suse.com Port 80
The skuba process is aborted. I already tried zypper ref to update the repo's but that doesn't seem to help. Does anybody have a clue for me where to look next ? With kind regards, Dennis Loos -------------- next part -------------- An HTML attachment was scrubbed... URL: From PGonin at suse.com Wed Sep 11 03:50:06 2019 From: PGonin at suse.com (Paul Gonin) Date: Wed, 11 Sep 2019 09:50:06 +0000 Subject: [caasp-beta] Error bootstrapping first node with skuba In-Reply-To: References: Message-ID: Hi Dennis, When did you download skuba ? What is your skuba version ? You can try to update your system to check if a new skuba version is available. thanks Paul Le mardi 10 septembre 2019 ? 09:12 +0000, Dennis Loos a ?crit : Hi, I am trying to set up a cluster, but it seems files have been moved on the updates.suse.com website: I0910 11:03:52.926763 21839 ssh.go:190] stdout | In cache python3-cephfs-14.2.2.349+g6716a1e448-3.9.1.x86_64.rpm (49/65), 192.8 KiB (369.2 KiB unpacked) I0910 11:03:52.940155 21839 ssh.go:190] stdout | In cache ceph-common-14.2.2.349+g6716a1e448-3.9.1.x86_64.rpm (50/65), 3.9 MiB ( 13.5 MiB unpacked) I0910 11:03:52.944249 21839 ssh.go:190] stdout | In cache cni-0.6.0-1.11.x86_64.rpm (51/65), 1.1 MiB ( 5.6 MiB unpacked) I0910 11:03:52.950438 21839 ssh.go:190] stdout | In cache runc-1.0.0~rc6-1.3.1.x86_64.rpm (52/65), 1.7 MiB ( 7.3 MiB unpacked) I0910 11:03:53.005544 21839 ssh.go:190] stdout | In cache cni-plugins-0.7.4-1.11.x86_64.rpm (53/65), 16.4 MiB ( 52.0 MiB unpacked) I0910 11:03:53.006451 21839 ssh.go:190] stdout | Retrieving package cri-tools-1.15.0-1.1.x86_64 (54/65), 20.0 MiB ( 68.6 MiB unpacked) I0910 11:03:53.197418 21839 ssh.go:190] stderr | Media source 'https://updates.suse.com/SUSE/Products/SUSE-CAASP/4.0/x86_64/product?gnEAAAAAAAAAAAAAaCre0mwzsxdmYAWhFPJljcOQ6l7i-dWpsvsPVeyFA-o- nYhGP48-bAq1PfUGSe596IiI8QW1ttAjOdqBDteTxWWb7ug32yBiRrb7L6_zYSF8Cc9-LSmin0zCYQLAHg' does not contain the desired medium I0910 11:03:53.197491 21839 ssh.go:190] stdout | Abort, retry, ignore? [a/r/i/...? shows all options] (a): a I0910 11:03:53.302195 21839 ssh.go:190] stderr | Problem occurred during or after installation or removal of packages: I0910 11:03:53.302218 21839 ssh.go:190] stderr | Installation has been aborted as directed. I0910 11:03:53.302228 21839 ssh.go:190] stderr | Please see the above error message for a hint. F0910 11:03:53.307056 21839 bootstrap.go:49] error bootstraping node: failed to apply state kubernetes.install-node-pattern: Process exited with status 8 When I try that URL manually I get a http 301 Moved Permanently error, get directed to the root html page: Index of /SUSE/Products/SUSE-CAASP/4.0/x86_64/product

Index of /SUSE/Products/SUSE-CAASP/4.0/x86_64/product

Icon  Name                                  Last modified      Size  Description
[DIR] Parent Directory - [   ] CHECKSUMS 09-Sep-2019 08:02 163 [TXT] CHECKSUMS.asc 09-Sep-2019 08:02 481 [DIR] media.1/ 09-Sep-2019 08:13 - [DIR] noarch/ 09-Sep-2019 08:13 - [DIR] repodata/ 09-Sep-2019 08:13 - [DIR] x86_64/ 09-Sep-2019 08:13 -
Apache/2.2.12 (Linux/SUSE) Server at updates.suse.com Port 80
The skuba process is aborted. I already tried zypper ref to update the repo?s but that doesn?t seem to help. Does anybody have a clue for me where to look next ? With kind regards, Dennis Loos _______________________________________________ caasp-beta mailing list caasp-beta at lists.suse.com Check the mailing list archives or Unsubscribe at http://lists.suse.com/mailman/listinfo/caasp-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkaempf at suse.de Wed Sep 11 04:21:35 2019 From: kkaempf at suse.de (Klaus =?utf-8?B?S8OkbXBm?=) Date: Wed, 11 Sep 2019 12:21:35 +0200 Subject: [caasp-beta] Error bootstrapping first node with skuba In-Reply-To: References: Message-ID: <20190911102135.GE22881@heron.suse.de> * Paul Gonin [Sep 11. 2019 11:50]: > Hi Dennis, > > When did you download skuba ? > What is your skuba version ? You can try to update your system to check if a new skuba version is available. > > thanks > Paul > > Le mardi 10 septembre 2019 ? 09:12 +0000, Dennis Loos a ?crit : > I0910 11:03:53.197418 21839 ssh.go:190] stderr | Media source 'https://updates.suse.com/SUSE/Products/SUSE-CAASP/4.0/x86_64/product?gnEAAAAAAAAAAAAAaCre0mwzsxdmYAWhFPJljcOQ6l7i-dWpsvsPVeyFA-o- > nYhGP48-bAq1PfUGSe596IiI8QW1ttAjOdqBDteTxWWb7ug32yBiRrb7L6_zYSF8Cc9-LSmin0zCYQLAHg' does not contain the desired medium This doesn't look like a skuba problem. This is probably SCC denying access since the beta test period has ended. Please apply for a 60-day trial access via https://www.suse.com/products/caas-platform Klaus -- SUSE Software Solutions Germany GmbH; GF: Felix Imend?rffer; HRB 247165 (AG M?nchen) From dennis.loos at ctac.nl Fri Sep 13 02:47:07 2019 From: dennis.loos at ctac.nl (Dennis Loos) Date: Fri, 13 Sep 2019 08:47:07 +0000 Subject: [caasp-beta] Error bootstrapping first node with skuba In-Reply-To: <20190911102135.GE22881@heron.suse.de> References: <20190911102135.GE22881@heron.suse.de> Message-ID: Hi, Thank you all for your replies. I think it had something to do with the product going to RC1 and the updating of the repo's accordingly. I waited a few days and was able to install everything without any problems. Only comment that I have is that Kubernetes v1.15.2 is used instead of the security release v1.15.3. I hope the GA version will have that update included so we can go productive. Thank again! Regards, Dennis. -----Original Message----- From: Klaus K?mpf Sent: woensdag 11 september 2019 12:22 To: Dennis Loos Cc: caasp-beta at lists.suse.com Subject: Re: [caasp-beta] Error bootstrapping first node with skuba * Paul Gonin [Sep 11. 2019 11:50]: > Hi Dennis, > > When did you download skuba ? > What is your skuba version ? You can try to update your system to check if a new skuba version is available. > > thanks > Paul > > Le mardi 10 septembre 2019 ? 09:12 +0000, Dennis Loos a ?crit : > I0910 11:03:53.197418 21839 ssh.go:190] stderr | Media source 'https://updates.suse.com/SUSE/Products/SUSE-CAASP/4.0/x86_64/product?gnEAAAAAAAAAAAAAaCre0mwzsxdmYAWhFPJljcOQ6l7i-dWpsvsPVeyFA-o- > nYhGP48-bAq1PfUGSe596IiI8QW1ttAjOdqBDteTxWWb7ug32yBiRrb7L6_zYSF8Cc9-LS > min0zCYQLAHg' does not contain the desired medium This doesn't look like a skuba problem. This is probably SCC denying access since the beta test period has ended. Please apply for a 60-day trial access via https://www.suse.com/products/caas-platform Klaus -- SUSE Software Solutions Germany GmbH; GF: Felix Imend?rffer; HRB 247165 (AG M?nchen) From jmassaguerpla at suse.de Fri Sep 13 02:52:23 2019 From: jmassaguerpla at suse.de (Jordi Massaguer Pla) Date: Fri, 13 Sep 2019 10:52:23 +0200 Subject: [caasp-beta] Error bootstrapping first node with skuba In-Reply-To: References: <20190911102135.GE22881@heron.suse.de> Message-ID: <16426be3-5f5c-3902-f955-ea78e916b139@suse.de> On 09/13/2019 10:47 AM, Dennis Loos wrote: > Hi, > > Thank you all for your replies. > I think it had something to do with the product going to RC1 and the updating of the repo's accordingly. > I waited a few days and was able to install everything without any problems. > > Only comment that I have is that Kubernetes v1.15.2 is used instead of the security release v1.15.3. > I hope the GA version will have that update included so we can go productive. The fix for the CVE-2019-9512 and CVE-2019-9514 were added as a patch, so even if you see v1.15.2, this version is safe. > > Thank again! > > Regards, > Dennis. > > -----Original Message----- > From: Klaus K?mpf > Sent: woensdag 11 september 2019 12:22 > To: Dennis Loos > Cc: caasp-beta at lists.suse.com > Subject: Re: [caasp-beta] Error bootstrapping first node with skuba > > * Paul Gonin [Sep 11. 2019 11:50]: >> Hi Dennis, >> >> When did you download skuba ? >> What is your skuba version ? You can try to update your system to check if a new skuba version is available. >> >> thanks >> Paul >> >> Le mardi 10 septembre 2019 ? 09:12 +0000, Dennis Loos a ?crit : >> I0910 11:03:53.197418 21839 ssh.go:190] stderr | Media source 'https://updates.suse.com/SUSE/Products/SUSE-CAASP/4.0/x86_64/product?gnEAAAAAAAAAAAAAaCre0mwzsxdmYAWhFPJljcOQ6l7i-dWpsvsPVeyFA-o- >> nYhGP48-bAq1PfUGSe596IiI8QW1ttAjOdqBDteTxWWb7ug32yBiRrb7L6_zYSF8Cc9-LS >> min0zCYQLAHg' does not contain the desired medium > This doesn't look like a skuba problem. This is probably SCC denying access since the beta test period has ended. > > Please apply for a 60-day trial access via https://www.suse.com/products/caas-platform > > Klaus > -- > SUSE Software Solutions Germany GmbH; GF: Felix Imend?rffer; HRB 247165 (AG M?nchen) > _______________________________________________ > caasp-beta mailing list > caasp-beta at lists.suse.com > Check the mailing list archives or Unsubscribe at http://lists.suse.com/mailman/listinfo/caasp-beta -- Jordi Massaguer Pla Release Manager for SUSE CaaS Platform SUSE Linux https://www.suse.com From beta-programs at lists.suse.com Fri Sep 13 09:43:10 2019 From: beta-programs at lists.suse.com (SUSE Beta Program) Date: Fri, 13 Sep 2019 17:43:10 +0200 Subject: [caasp-beta] [ANNOUNCE] SUSE CaaS Platform 4 End of Beta Program Message-ID: <5d7bb90ea62c7_5edb2af9107945f8178d@zourite.lab.gb.mail> Thank you all! We hope that you have enjoyed beta testing SUSE Container as a Service Platform 4 Beta and that we have provided the necessary help in your ongoing project. SUSE Container as a Service Platform 4 is officially out, please check out the release announcement here![1] Closing the Beta Program - Web pages: caasp-beta web page[2] will be "cleaned-up" and will be updated when we have more information to share for the next Beta Program, - Download link: Beta links and online channels are disabled, - Mailing List: The caasp-beta at lists.suse.com is left untouched. However please use our support process to report SUSE CaaS Platform 4 issues, other than that feel free to post in the mailing list for any other inquiry. - Bugzilla: You won't be able to create any new bug for "Beta SUSE CaaS Platform 4". And if you still have bugs opened please make sure that, the bug information is up to date. Your SUSE CaaS Platform Team You received this email because you're signed up to get updates from us. Click here to unsubscribe.[3] Do not hesitate to contact us at beta-programs at lists.suse.com if you have any questions. [1]:https://www.suse.com/c/announcing-suse-caas-platform-4/ [2]:https://www.suse.com/betaprogram/caasp-beta/ [3]:mailto:beta-programs at lists.suse.com?subject=Unsubscribe%2 0from%20CaaSP%20Beta&body=Unsubscribe%20from%20CaaSP%20Beta -------------- next part -------------- An HTML attachment was scrubbed... URL: From FCastelli at suse.com Wed Sep 18 02:24:34 2019 From: FCastelli at suse.com (Flavio Castelli) Date: Wed, 18 Sep 2019 08:24:34 +0000 Subject: [caasp-beta] platform architecture and filesystem In-Reply-To: References: Message-ID: Starting from CaaSP v4 there's no special need to have a dedicated subvolume for "/var/lib/kubelet". There's also no need to create a new one for "/var/lib/crio" We recommend to use the overlay graph driver both for docker, podman (on standard SLE machines that are not part of CaaS Platform) and for CRI-O. It's totally fine to use overlay over btrfs or other file systems; for example our AutoYaST profile creates a /var partition that uses xfs. We recommend to enable copy-on-write (COW) for the overall container storage (/var/lib/containers), independently if it's btrfs or xfs. To come back to what you wrote: it would be fine to keep /var on subvolumes with no COW, and mount their device in /var/lib/containers, which should enable COW. I hope that helps. Thanks Flavio On 9/9/19 4:30 PM, Le Bihan St?phane (AMUNDI-ITS) wrote: > Hi all, > > In CAAS v3 we have dedicated devie for /var/lib/docker. > > For Caas V4, we also want to use this device. > But I see copy-and-write is disable for subvolume /var on base installation SLES15. > > So, from your opinion, what is best solution : > > ? Keep /var on subvolumes with no copy-and-write, and mount device in /var/lib/container > > ? Mout device on /var (But I can see where in autoyast or other I can disble copy-and-write with no subvolume) > > ? Mount device on /var, create subvolume with no copy-ad-write for /var/lib/container, /var/lib/kubelet, /var/lib/crio etc .... > > Regards, > > > _______________________________________________ > caasp-beta mailing list > caasp-beta at lists.suse.com > Check the mailing list archives or Unsubscribe at http://lists.suse.com/mailman/listinfo/caasp-beta > From stephane.lebihan at amundi.com Wed Sep 18 02:38:36 2019 From: stephane.lebihan at amundi.com (=?iso-8859-1?Q?Le_Bihan_St=E9phane_=28AMUNDI-ITS=29?=) Date: Wed, 18 Sep 2019 08:38:36 +0000 Subject: [caasp-beta] platform architecture and filesystem In-Reply-To: References: Message-ID: Hi, Thanks Flavio. It confirms what I thought. In beta, I keep /var/lib subvolume default, but I mount another device, on /var/lib/containers with btrfs and COW. For information, if you do this, think to change mount dependencies in system. Regards, -----Original Message----- From: caasp-beta On Behalf Of Flavio Castelli Sent: mercredi 18 septembre 2019 10:25 To: caasp-beta at lists.suse.com Subject: Re: [caasp-beta] platform architecture and filesystem Starting from CaaSP v4 there's no special need to have a dedicated subvolume for "/var/lib/kubelet". There's also no need to create a new one for "/var/lib/crio" We recommend to use the overlay graph driver both for docker, podman (on standard SLE machines that are not part of CaaS Platform) and for CRI-O. It's totally fine to use overlay over btrfs or other file systems; for example our AutoYaST profile creates a /var partition that uses xfs. We recommend to enable copy-on-write (COW) for the overall container storage (/var/lib/containers), independently if it's btrfs or xfs. To come back to what you wrote: it would be fine to keep /var on subvolumes with no COW, and mount their device in /var/lib/containers, which should enable COW. I hope that helps. Thanks Flavio On 9/9/19 4:30 PM, Le Bihan St?phane (AMUNDI-ITS) wrote: > Hi all, > > In CAAS v3 we have dedicated devie for /var/lib/docker. > > For Caas V4, we also want to use this device. > But I see copy-and-write is disable for subvolume /var on base installation SLES15. > > So, from your opinion, what is best solution : > > ? Keep /var on subvolumes with no copy-and-write, and mount device in /var/lib/container > > ? Mout device on /var (But I can see where in autoyast or other I can disble copy-and-write with no subvolume) > > ? Mount device on /var, create subvolume with no copy-ad-write for /var/lib/container, /var/lib/kubelet, /var/lib/crio etc .... > > Regards, > > > _______________________________________________ > caasp-beta mailing list > caasp-beta at lists.suse.com > Check the mailing list archives or Unsubscribe at > http://lists.suse.com/mailman/listinfo/caasp-beta > _______________________________________________ caasp-beta mailing list caasp-beta at lists.suse.com Check the mailing list archives or Unsubscribe at http://lists.suse.com/mailman/listinfo/caasp-beta From jmassaguerpla at suse.de Wed Sep 18 03:15:13 2019 From: jmassaguerpla at suse.de (Jordi Massaguer Pla) Date: Wed, 18 Sep 2019 11:15:13 +0200 Subject: [caasp-beta] platform architecture and filesystem In-Reply-To: References: Message-ID: On 09/18/2019 10:38 AM, Le Bihan St?phane (AMUNDI-ITS) wrote: > Hi, > > Thanks Flavio. > It confirms what I thought. > > In beta, I keep /var/lib subvolume default, but I mount another device, on /var/lib/containers with btrfs and COW. > For information, if you do this, think to change mount dependencies in system. Thanks for reporting this. We have a bug identified as bsc#1151028 for tracking this issue now. Cri-o is checking if /var/lib is mounted with btrfs filesystem, and if so it changes the configuration to use that driver. However, this is not tacking into account that the user could mount /var/lib/containers with a different filesystem, and this is the issue. Our? Engineers are looking into this. Thanks again for the feedback > > Regards, > > -----Original Message----- > From: caasp-beta On Behalf Of Flavio Castelli > Sent: mercredi 18 septembre 2019 10:25 > To: caasp-beta at lists.suse.com > Subject: Re: [caasp-beta] platform architecture and filesystem > > Starting from CaaSP v4 there's no special need to have a dedicated subvolume for "/var/lib/kubelet". There's also no need to create a new one for "/var/lib/crio" > > We recommend to use the overlay graph driver both for docker, podman (on standard SLE machines that are not part of CaaS Platform) and for CRI-O. > It's totally fine to use overlay over btrfs or other file systems; for example our AutoYaST profile creates a /var partition that uses xfs. > > We recommend to enable copy-on-write (COW) for the overall container storage (/var/lib/containers), independently if it's btrfs or xfs. > > To come back to what you wrote: it would be fine to keep /var on subvolumes with no COW, and mount their device in /var/lib/containers, which should enable COW. > > I hope that helps. > > Thanks > Flavio > > On 9/9/19 4:30 PM, Le Bihan St?phane (AMUNDI-ITS) wrote: >> Hi all, >> >> In CAAS v3 we have dedicated devie for /var/lib/docker. >> >> For Caas V4, we also want to use this device. >> But I see copy-and-write is disable for subvolume /var on base installation SLES15. >> >> So, from your opinion, what is best solution : >> >> ? Keep /var on subvolumes with no copy-and-write, and mount device in /var/lib/container >> >> ? Mout device on /var (But I can see where in autoyast or other I can disble copy-and-write with no subvolume) >> >> ? Mount device on /var, create subvolume with no copy-ad-write for /var/lib/container, /var/lib/kubelet, /var/lib/crio etc .... >> >> Regards, >> >> >> _______________________________________________ >> caasp-beta mailing list >> caasp-beta at lists.suse.com >> Check the mailing list archives or Unsubscribe at >> http://lists.suse.com/mailman/listinfo/caasp-beta >> > _______________________________________________ > caasp-beta mailing list > caasp-beta at lists.suse.com > Check the mailing list archives or Unsubscribe at http://lists.suse.com/mailman/listinfo/caasp-beta > _______________________________________________ > caasp-beta mailing list > caasp-beta at lists.suse.com > Check the mailing list archives or Unsubscribe at http://lists.suse.com/mailman/listinfo/caasp-beta -- Jordi Massaguer Pla Release Manager for SUSE CaaS Platform SUSE Linux https://www.suse.com From Ian.Donaldson at NGIC.COM Mon Sep 23 10:20:51 2019 From: Ian.Donaldson at NGIC.COM (Donaldson, Ian) Date: Mon, 23 Sep 2019 16:20:51 +0000 Subject: [caasp-beta] Dex/Gangway erorr after login to Caas V4 GMC1 Message-ID: Rebuilt cluster on latest caas v4 update but am hitting an issue now. Any ideas? After logging into dex/gangway we get the following error in any browser: oauth2: cannot fetch token: 401 Unauthorized Response: {"error":"invalid_client","error_description":"Invalid client credentials."} The logs show that login successful and correct AD groups mapped. Thanks, Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ian.Donaldson at NGIC.COM Mon Sep 23 10:49:53 2019 From: Ian.Donaldson at NGIC.COM (Donaldson, Ian) Date: Mon, 23 Sep 2019 16:49:53 +0000 Subject: [caasp-beta] caas v4 gmc1 network errors Message-ID: <384fe84580004706a0a918caff0996de@NGIC.COM> Since building out our GMC1 cluster on Caas v4 we have start4ed to see the following in /var/log/messages. I have tried rebuilding but am still seeing these systemd-udevd[4853]: Could not generate persistent MAC address for lxc20946f621732: No such file or directory kernel: [ 50.111251] IPv6: ADDRCONF(NETDEV_CHANGE): lxc20946f621732: link becomes ready systemd-udevd[4852]: link_config: could not get ethtool features for tmp46fbc systemd-udevd[4852]: Could not set offload features of tmp46fbc: No such device kernel: [ 50.259174] IPv6: ADDRCONF(NETDEV_UP): lxc33cdce3788d6: link is not ready wickedd-nanny[1266]: /org/opensuse/Network/Interface/10.getManagedObjects failed. Server responds: wickedd-nanny[1266]: org.freedesktop.DBus.Error.UnknownMethod: Method "GetManagedObjects" with signature "" on interface "org.freedesktop.DBus.ObjectManager" doesn't exist kernel: [ 50.273533] eth0: renamed from tmp94af7 systemd-udevd[4941]: Could not generate persistent MAC address for lxc33cdce3788d6: No such file or directory systemd-udevd[4940]: link_config: could not get ethtool features for tmp94af7 systemd-udevd[4940]: Could not set offload features of tmp94af7: No such device Ian Donaldson Unix Systems Administrator Office: 336-435-3983 ian.donaldson at NGIC.com [cid:image001.png at 01CF32FA.7C387000] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2857 bytes Desc: image001.png URL: From lcavajani at suse.com Tue Sep 24 00:55:29 2019 From: lcavajani at suse.com (Ludovic Cavajani) Date: Tue, 24 Sep 2019 08:55:29 +0200 Subject: [caasp-beta] Dex/Gangway erorr after login to Caas V4 GMC1 In-Reply-To: References: Message-ID: Hello, Can you provide the full logs from the pod if there are no sensitive data (names etc) as well as the dex/ldap configuration ? Have you successfully tested this configuration before ? Thanks, On 9/23/19 6:20 PM, Donaldson, Ian wrote: > Rebuilt cluster on latest caas v4 update but am hitting an issue now. Any ideas? > > After logging into dex/gangway we get the following error in any browser: > > oauth2: cannot fetch token: 401 Unauthorized > Response: {"error":"invalid_client","error_description":"Invalid client credentials."} > > > The logs show that login successful and correct AD groups mapped. > > > Thanks, > > Ian > > > _______________________________________________ > caasp-beta mailing list > caasp-beta at lists.suse.com > Check the mailing list archives or Unsubscribe at http://lists.suse.com/mailman/listinfo/caasp-beta -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From vmoutoussamy at suse.com Tue Sep 24 03:30:40 2019 From: vmoutoussamy at suse.com (Vincent Moutoussamy) Date: Tue, 24 Sep 2019 09:30:40 +0000 Subject: [caasp-beta] Dex/Gangway erorr after login to Caas V4 GMC1 In-Reply-To: References: Message-ID: Hi, Please note that since SUSE CaaS Platform 4 is officially released*, we only do best effort support here for V4 and discuss features requests. So at some point we might request you to create an official support ticket for your issue. Have a nice day, Regards, * https://www.suse.com/c/announcing-suse-caas-platform-4/ -- Vincent Moutoussamy SUSE Beta Program, JeOS and SDK Project Manager > On 24 Sep 2019, at 08:55, Ludovic Cavajani wrote: > > Hello, > > Can you provide the full logs from the pod if there are no sensitive > data (names etc) as well as the dex/ldap configuration ? > > Have you successfully tested this configuration before ? > > Thanks, > > On 9/23/19 6:20 PM, Donaldson, Ian wrote: >> Rebuilt cluster on latest caas v4 update but am hitting an issue now. Any ideas? >> >> After logging into dex/gangway we get the following error in any browser: >> >> oauth2: cannot fetch token: 401 Unauthorized >> Response: {"error":"invalid_client","error_description":"Invalid client credentials."} >> >> >> The logs show that login successful and correct AD groups mapped. >> >> >> Thanks, >> >> Ian >> >> >> _______________________________________________ >> caasp-beta mailing list >> caasp-beta at lists.suse.com >> Check the mailing list archives or Unsubscribe at http://lists.suse.com/mailman/listinfo/caasp-beta > > _______________________________________________ > caasp-beta mailing list > caasp-beta at lists.suse.com > Check the mailing list archives or Unsubscribe at http://lists.suse.com/mailman/listinfo/caasp-beta From kkaempf at suse.de Tue Sep 24 03:14:53 2019 From: kkaempf at suse.de (Klaus =?utf-8?B?S8OkbXBm?=) Date: Tue, 24 Sep 2019 11:14:53 +0200 Subject: [caasp-beta] caas v4 gmc1 network errors In-Reply-To: <384fe84580004706a0a918caff0996de@NGIC.COM> References: <384fe84580004706a0a918caff0996de@NGIC.COM> Message-ID: <20190924091453.GI13786@heron.suse.de> * Donaldson, Ian [Sep 23. 2019 18:50]: > Since building out our GMC1 cluster on Caas v4 we have start4ed to see the following in /var/log/messages. I have tried rebuilding but am still seeing these CaaSP v4 has been released meanwhile and contains a handful of fixes compared to 'gmc1'. Please retry with the official release. Thanks, Klaus -- SUSE Software Solutions Germany GmbH; GF: Felix Imend?rffer; HRB 247165 (AG M?nchen)