From paye600 at gmail.com Fri Mar 1 13:42:59 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Fri, 1 Mar 2019 14:42:59 +0100 Subject: [Airship-discuss] Weekly Airship IRC Meeting time: 14:00 to 16:00 UTC Message-ID: All, Following up on e-mail thread [0], and conversations on IRC meetings [1] 2019-02-12 and 2019-02-19, Airship weekly meeting time is proposed to be moved from 14:00 UTC to 16:00 UTC on every Tuesday. Please, vote on the patch set https://review.openstack.org/#/c/640359/. Thank you. [0] http://lists.airshipit.org/pipermail/airship-discuss/2019-February/000294.html [1] http://eavesdrop.openstack.org/meetings/airship/2019/ -- Roman Gorshunov From rp2723 at att.com Fri Mar 1 15:52:05 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Fri, 1 Mar 2019 15:52:05 +0000 Subject: [Airship-discuss] Canceled: Discuss target state implementation of Docker/Kernel/Os/Security Patches etc Message-ID: <99088997CCAD0C4BA20008FD0943449632773CF3@MISOUT7MSGUSRDI.ITServices.sbc.com> Sorry, I need to cancel this occurrence, will continue this discussion next week. Discuss target state implementation of Airship Docker/Kubelet/Kernel/OS etc upgrade I scheduled a series, will figure out when it’s appropriate What do we need to discuss ? The ability to manage the delivery of any update across groups of hosts in a declarative way. The ability to control disruption effects from those updates Next Meeting: Looking at the https://github.com/GoogleCloudPlatform/metacontroller approach and comparing against what we discussed today. Everyone (in Airship Community) is welcome to participate on this discussions. Approach Discussed on our 1st Meeting https://go.gliffy.com/go/publish/12934972 Sample CR’s .. apiVersion: airship/v1 kind: MultiNodeAction metadata: name: DoSomethingPerRack spec: # List of sets of nodes that theis applies to. Indicates the cadence. 1 set at a time failureSet: set1: rack: rack1 set2: rack: rack2 # - Indicate the Action(What are we doing) - # - Indicate effect Upgrade and Reboot, Reboot Only, .. intentions: - UpgradeDockerAction - UpgradeKubeletAction - RebootAction ## This is teh CR that a node agent consumes apiVersion: airship/v1 kind: NodeAction metadata: name: Set1 spec: setIndicator: rack: rack1 intentions: ListOFActions: - UpgradeDocker - UpgradeKubelet - Reboot ## This is the CR's for ACTIONS that the NodeAgent ingests as well apiVersion: airship/v1 kind: Action metadata: name: Reboot spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeDocker spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeKubelet spec: script ..... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 4337 bytes Desc: not available URL: From rp2723 at att.com Fri Mar 1 15:53:42 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Fri, 1 Mar 2019 15:53:42 +0000 Subject: [Airship-discuss] Canceled: Discuss target state implementation of Docker/Kernel/Os/Security Patches etc Message-ID: <83BD15AD-9E27-44ED-A6BB-DD4A590E191C@att.com> Sorry, I need to cancel this occurrence, will continue this discussion next week. Discuss target state implementation of Airship Docker/Kubelet/Kernel/OS etc upgrade I scheduled a series, will figure out when it’s appropriate What do we need to discuss ? The ability to manage the delivery of any update across groups of hosts in a declarative way. The ability to control disruption effects from those updates Next Meeting: Looking at the https://github.com/GoogleCloudPlatform/metacontroller approach and comparing against what we discussed today. Everyone (in Airship Community) is welcome to participate on this discussions. Approach Discussed on our 1st Meeting https://go.gliffy.com/go/publish/12934972 Sample CR’s .. apiVersion: airship/v1 kind: MultiNodeAction metadata: name: DoSomethingPerRack spec: # List of sets of nodes that theis applies to. Indicates the cadence. 1 set at a time failureSet: set1: rack: rack1 set2: rack: rack2 # - Indicate the Action(What are we doing) - # - Indicate effect Upgrade and Reboot, Reboot Only, .. intentions: - UpgradeDockerAction - UpgradeKubeletAction - RebootAction ## This is teh CR that a node agent consumes apiVersion: airship/v1 kind: NodeAction metadata: name: Set1 spec: setIndicator: rack: rack1 intentions: ListOFActions: - UpgradeDocker - UpgradeKubelet - Reboot ## This is the CR's for ACTIONS that the NodeAgent ingests as well apiVersion: airship/v1 kind: Action metadata: name: Reboot spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeDocker spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeKubelet spec: script ..... -------------- next part -------------- An HTML attachment was scrubbed... URL: From santosh.thapamager at as.ntt-at.co.jp Tue Mar 5 00:20:31 2019 From: santosh.thapamager at as.ntt-at.co.jp (santosh.thapamager) Date: Tue, 5 Mar 2019 09:20:31 +0900 Subject: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error Message-ID: <00d201d4d2e9$3e2ac3f0$ba804bd0$@as.ntt-at.co.jp> Hi all I tried to install AIAB dev_single_node in no proxy environment. However i got stuck on error. The mass-ingress pod gets stuck on Error and CrashLoopBackOff state. I tried to install multiple times creating new VM the result was same. Following is the snippet of the installation log. ***Snip*** ucp maas-import-resources-kttkm 1/1 Running 0 5m ucp maas-ingress-7489b6fc8-zww2n 1/2 CrashLoopBackOff 5 5m . . . ucp maas-import-resources-kttkm 1/1 Running 0 6m ucp maas-ingress-7489b6fc8-zww2n 1/2 Error 6 6m ***Snip*** I would be greatly appreciated if anyone could help me solving this issue. Best Regards Santosh Thapa Magar From prem00kat at gmail.com Tue Mar 5 03:50:06 2019 From: prem00kat at gmail.com (Ramadas M R) Date: Tue, 5 Mar 2019 09:20:06 +0530 Subject: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error In-Reply-To: <00d201d4d2e9$3e2ac3f0$ba804bd0$@as.ntt-at.co.jp> References: <00d201d4d2e9$3e2ac3f0$ba804bd0$@as.ntt-at.co.jp> Message-ID: You can try these commands to get a hint on the issue "kubectl describe -n ucp pod/maas-ingress-7489b6fc8-zww2n" and " kubectl logs -n ucp pod/ maas-ingress-7489b6fc8-zww2n" Regards, Ram On Tue, Mar 5, 2019, 05:52 santosh.thapamager < santosh.thapamager at as.ntt-at.co.jp> wrote: > Hi all > > I tried to install AIAB dev_single_node in no proxy environment. > However i got stuck on error. > The mass-ingress pod gets stuck on Error and CrashLoopBackOff state. > > I tried to install multiple times creating new VM the result was same. > Following is the snippet of the installation log. > > ***Snip*** > > ucp maas-import-resources-kttkm > 1/1 Running 0 5m > ucp maas-ingress-7489b6fc8-zww2n > 1/2 CrashLoopBackOff 5 5m > > . > . > . > > ucp maas-import-resources-kttkm > 1/1 Running 0 6m > ucp maas-ingress-7489b6fc8-zww2n > 1/2 Error 6 6m > > ***Snip*** > > I would be greatly appreciated if anyone could help me solving this issue. > > Best Regards > Santosh Thapa Magar > > > > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmts at intracom-telecom.com Tue Mar 5 08:38:55 2019 From: dmts at intracom-telecom.com (TSIOLAKIS DIMITRIOS) Date: Tue, 05 Mar 2019 10:38:55 +0200 Subject: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error In-Reply-To: Message-ID: Hi, Same issue with multi node deployment, maas-ingress and maas-import-resources stuck CrashLoopBackOff status. ucp maas-import-resources-xczwt 0/1 CrashLoopBackOff 16 1h ucp maas-ingress-6c67b89c45-7vvq6 1/2 CrashLoopBackOff 20 1h here [1] are kubectl describe pod maas-ingress-6c67b89c45-7vvq6 -n ucp and kubectl logs -c maas-ingress maas-ingress-6c67b89c45-7vvq6 -n ucp logs from node n0. The error states: “F0304 15:33:42.073468 8 main.go:72] Port 8181 is already in use. Please check the flag --default-server-port” BRs Dimitris [1] https://hastebin.com/etotirupuk.m From: Ramadas M R [mailto:prem00kat at gmail.com] Sent: Tuesday, March 05, 2019 5:50 AM To: santosh.thapamager Cc: airship-discuss at lists.airshipit.org Subject: Re: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error You can try these commands to get a hint on the issue "kubectl describe -n ucp pod/maas-ingress-7489b6fc8-zww2n" and " kubectl logs -n ucp pod/maas-ingress-7489b6fc8-zww2n" Regards, Ram On Tue, Mar 5, 2019, 05:52 santosh.thapamager > wrote: Hi all I tried to install AIAB dev_single_node in no proxy environment. However i got stuck on error. The mass-ingress pod gets stuck on Error and CrashLoopBackOff state. I tried to install multiple times creating new VM the result was same. Following is the snippet of the installation log. ***Snip*** ucp maas-import-resources-kttkm 1/1 Running 0 5m ucp maas-ingress-7489b6fc8-zww2n 1/2 CrashLoopBackOff 5 5m . . . ucp maas-import-resources-kttkm 1/1 Running 0 6m ucp maas-ingress-7489b6fc8-zww2n 1/2 Error 6 6m ***Snip*** I would be greatly appreciated if anyone could help me solving this issue. Best Regards Santosh Thapa Magar _______________________________________________ Airship-discuss mailing list Airship-discuss at lists.airshipit.org http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From paye600 at gmail.com Wed Mar 6 12:23:55 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Wed, 6 Mar 2019 13:23:55 +0100 Subject: [Airship-discuss] Weekly Airship IRC Meeting time: Tuesday, 16:00 UTC Message-ID: All, Following up on e-mail thread [0], and conversations on IRC meetings [1] 2019-02-12 and 2019-02-19, Airship weekly meeting time is now at 16:00 UTC on every Tuesday. Please, join our next meeting on 12th of March, 2019, at 16:00 UTC. Agenda: https://etherpad.openstack.org/p/airship-meeting-2019-03-19 Thank you. [0] http://lists.airshipit.org/pipermail/airship-discuss/2019-February/000294.html [1] http://eavesdrop.openstack.org/meetings/airship/2019/ -- Roman Gorshunov From rp2723 at att.com Wed Mar 6 14:50:25 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Wed, 6 Mar 2019 14:50:25 +0000 Subject: [Airship-discuss] Airship - Open Design Call - AM EST Call Message-ID: <99088997CCAD0C4BA20008FD09434496327802B2@MISOUT7MSGUSRDI.ITServices.sbc.com> When: Occurs every Thursday from 11:00 AM to 12:00 PM effective 8/30/2018 until 6/28/2019. (UTC-05:00) Eastern Time (US & Canada) Where: https://attcorp.webex.com/meet/rp2723 *~*~*~*~*~*~*~*~*~* Reminder Etherpad for the Airship Open Design discussion https://etherpad.openstack.org/p/Airship_OpenDesignDiscussions Storyboard in flight Specs https://storyboard.openstack.org/#!/project/openstack/airship-specs Github Airship Specs https://github.com/openstack/airship-specs/tree/master/specs Inflight/reviewing specs https://review.openstack.org/#/q/status:open+airship-specs __________________________________________ Join by video system i Dial rp2723 at attcorp.webex.com and enter your host PIN 02083790. You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-844-517-1415 United States Toll Free 1-618-230-6039 United States Toll Access code: 733 333 726 Host PIN: 02083790 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2555 bytes Desc: not available URL: From l.legal.astellia at gmail.com Wed Mar 6 15:46:56 2019 From: l.legal.astellia at gmail.com (Loic Le Gal) Date: Wed, 6 Mar 2019 16:46:56 +0100 Subject: [Airship-discuss] Airship-discuss Digest, Vol 10, Issue 3 In-Reply-To: References: Message-ID: Hi Airshipers, Same issue for me, going back to previous commit (ad53fbf5c312929e8d0873e5095c5a0d1dcdd7f5), but another problem arise with maas-import-resources. I will open new thread if can't fix. Why is maas required even for AiaB as we don't have any baremetal involved ?? BR, Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.legal.astellia at gmail.com Wed Mar 6 15:48:51 2019 From: l.legal.astellia at gmail.com (Loic Le Gal) Date: Wed, 6 Mar 2019 16:48:51 +0100 Subject: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error In-Reply-To: References: Message-ID: Hi Airshipers, Same issue for me, going back to previous commit (ad53fbf5c312929e8d0873e5095c5a0d1dcdd7f5), but another problem arise with maas-import-resources. I will open new thread if can't fix. Why is maas required even for AiaB as we don't have any baremetal involved ?? BR, Loïc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paye600 at gmail.com Wed Mar 6 16:49:45 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Wed, 6 Mar 2019 17:49:45 +0100 Subject: [Airship-discuss] Divingbell overrides functionality regression - Assistance needed In-Reply-To: References: Message-ID: Hello Craig, team, With some help from Scott I've found exact commit in dependency of helm - mergo, which breaks functionality: https://github.com/imdario/mergo/commit/df0700a1e899196d8020767981b82623c8738932 If line 52 (new one) returns `false`, then everything seems to work again. Would appreciate any help. Thank you. Details I have collected are in this Story: https://storyboard.openstack.org/#!/story/2005095#comment-117207, including some help on how to reproduce the issue and test different versions. Best regards, -- Roman Gorshunov On Thu, Feb 28, 2019 at 5:32 PM ANDERSON, CRAIG wrote: > > Ok, our version of Helm must not be new enough to contain the version of Sprig library which has that patchset, so I guess it must be a different issue. But I would still suspect something with `merge` or one of the other changes to dict.go between helm versions. > > -----Original Message----- > From: Roman Gorshunov [mailto:paye600 at gmail.com] > Sent: Thursday, February 28, 2019 2:52 AM > To: airship-discuss at lists.airshipit.org > Cc: TANG, ROY ; ANDERSON, CRAIG > Subject: Re: Divingbell overrides functionality regression - Assistance needed > > Hello Craig, > Thank you for your reply and support. > I have tried to do a quick replace of `merge` to `mergeOverwrite`, and it didn't work. Linting fails on the following error: > > > [ERROR] templates/: parse error in > > "helm-toolkit/templates/utils/_daemonset_overrides.tpl": template: > > helm-toolkit/templates/utils/_daemonset_overrides.tpl:52: function > > "mergeOvewrite" not defined > > Best regards, > -- Roman Gorshunov From paye600 at gmail.com Wed Mar 6 17:28:22 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Wed, 6 Mar 2019 18:28:22 +0100 Subject: [Airship-discuss] Divingbell overrides functionality regression - Assistance needed In-Reply-To: References: Message-ID: Oops, update: .. with the help of Pete, not Scott. Sorry. On Wed, Mar 6, 2019 at 5:49 PM Roman Gorshunov wrote: > > Hello Craig, team, > > With some help from Scott I've found exact commit in dependency of helm - mergo, > which breaks functionality: > https://github.com/imdario/mergo/commit/df0700a1e899196d8020767981b82623c8738932 > If line 52 (new one) returns `false`, then everything seems to work again. > > Would appreciate any help. Thank you. > > Details I have collected are in this Story: > https://storyboard.openstack.org/#!/story/2005095#comment-117207, > including some help on how to reproduce the issue and test different > versions. > > Best regards, > -- Roman Gorshunov > > On Thu, Feb 28, 2019 at 5:32 PM ANDERSON, CRAIG wrote: > > > > Ok, our version of Helm must not be new enough to contain the version of Sprig library which has that patchset, so I guess it must be a different issue. But I would still suspect something with `merge` or one of the other changes to dict.go between helm versions. > > > > -----Original Message----- > > From: Roman Gorshunov [mailto:paye600 at gmail.com] > > Sent: Thursday, February 28, 2019 2:52 AM > > To: airship-discuss at lists.airshipit.org > > Cc: TANG, ROY ; ANDERSON, CRAIG > > Subject: Re: Divingbell overrides functionality regression - Assistance needed > > > > Hello Craig, > > Thank you for your reply and support. > > I have tried to do a quick replace of `merge` to `mergeOverwrite`, and it didn't work. Linting fails on the following error: > > > > > [ERROR] templates/: parse error in > > > "helm-toolkit/templates/utils/_daemonset_overrides.tpl": template: > > > helm-toolkit/templates/utils/_daemonset_overrides.tpl:52: function > > > "mergeOvewrite" not defined > > > > Best regards, > > -- Roman Gorshunov From ca846m at att.com Wed Mar 6 17:47:21 2019 From: ca846m at att.com (ANDERSON, CRAIG) Date: Wed, 6 Mar 2019 17:47:21 +0000 Subject: [Airship-discuss] Divingbell overrides functionality regression - Assistance needed In-Reply-To: References: Message-ID: According to https://github.com/imdario/mergo/blob/master/merge.go#L212-L214 : // MergeWithOverwrite will do the same as Merge except that non-empty dst attributes will be overriden by // non-empty src attribute values. // Deprecated: use Merge(…) with WithOverride So it would appear that this library made a change that broke backwards compatibility with their interface added in version 0.3.7, and that MergeWithOverwrite should be used with this verison of the library. Sprig exposes this with its `mergeOverwrite` function. Note that Sprig made the mergo version update (from 0.2.2 to 0.3.7) in the same commit that mergeOverwrite was added: https://github.com/Masterminds/sprig/commit/4c59c1250a68e7f7a7e48c54f68c38b5c4c26d20#diff-040def46b3be654b6673438b43faf644 Given this as the case, I don't know how it would be possible that we could have a version of helm which both fails (because of new mergo version) and at the same time doesn't have mergeOverwrite (which was missing according to your earlier test). Just to confirm, were you using Helm 1.12.x when you tried replacing `merge` with `mergOverwrite`? -----Original Message----- From: Roman Gorshunov [mailto:paye600 at gmail.com] Sent: Wednesday, March 06, 2019 9:28 AM To: ANDERSON, CRAIG ; airship-discuss at lists.airshipit.org Cc: TANG, ROY Subject: Re: Divingbell overrides functionality regression - Assistance needed Oops, update: .. with the help of Pete, not Scott. Sorry. On Wed, Mar 6, 2019 at 5:49 PM Roman Gorshunov wrote: > > Hello Craig, team, > > With some help from Scott I've found exact commit in dependency of > helm - mergo, which breaks functionality: > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_imdari > o_mergo_commit_df0700a1e899196d8020767981b82623c8738932&d=DwIFaQ&c=LFY > Z-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_aS85wtQ&m=1MOIIBAVEcoin5q75GkbgRj > DRRkoS7kHgavWlrLPTj0&s=jwfTMA8dPqMjzUGEXnUJ9nSrsD7jI8B_LVuBu0HhnJQ&e= > If line 52 (new one) returns `false`, then everything seems to work again. > > Would appreciate any help. Thank you. > > Details I have collected are in this Story: > https://urldefense.proofpoint.com/v2/url?u=https-3A__storyboard.openst > ack.org_-23-21_story_2005095-23comment-2D117207&d=DwIFaQ&c=LFYZ-o9_HUM > eMTSQicvjIg&r=aimn2OylFgog_5_aS85wtQ&m=1MOIIBAVEcoin5q75GkbgRjDRRkoS7k > HgavWlrLPTj0&s=4wYIA7lsyCya6IttBmz8A2mwUDQg-HEAYt3AbYfjuQ4&e=, > including some help on how to reproduce the issue and test different > versions. > > Best regards, > -- Roman Gorshunov > > On Thu, Feb 28, 2019 at 5:32 PM ANDERSON, CRAIG wrote: > > > > Ok, our version of Helm must not be new enough to contain the version of Sprig library which has that patchset, so I guess it must be a different issue. But I would still suspect something with `merge` or one of the other changes to dict.go between helm versions. > > > > -----Original Message----- > > From: Roman Gorshunov [mailto:paye600 at gmail.com] > > Sent: Thursday, February 28, 2019 2:52 AM > > To: airship-discuss at lists.airshipit.org > > Cc: TANG, ROY ; ANDERSON, CRAIG > > Subject: Re: Divingbell overrides functionality regression - > > Assistance needed > > > > Hello Craig, > > Thank you for your reply and support. > > I have tried to do a quick replace of `merge` to `mergeOverwrite`, and it didn't work. Linting fails on the following error: > > > > > [ERROR] templates/: parse error in > > > "helm-toolkit/templates/utils/_daemonset_overrides.tpl": template: > > > helm-toolkit/templates/utils/_daemonset_overrides.tpl:52: function > > > "mergeOvewrite" not defined > > > > Best regards, > > -- Roman Gorshunov From MM9745 at att.com Wed Mar 6 21:16:33 2019 From: MM9745 at att.com (MCEUEN, MATT) Date: Wed, 6 Mar 2019 21:16:33 +0000 Subject: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error In-Reply-To: References: Message-ID: <7C64A75C21BB8D43BD75BB18635E4D896D25AA6E@MOSTLS1MSGUSRFF.ITServices.sbc.com> Hi Loïc & Dimitrios, Shoot, sorry you guys hit this. This looks like the Airship-in-a-Bottle single node dev site may have gotten stale. We have a few different sets of YAMLs that should be aligned to one another to keep this from happening; I’ve captured the issue and proposed resolution in this story[1]. If you’d like to help with this it would be very much appreciated :-), and if anyone has some time to get the AiaB single-node dev site definition trued up in the meantime that would be valuable too. For a MaaS-free dev deployment, I suggest looking at the Airskiff [2] deployment scripts. These deploy the software provisioning components (no MaaS, Drydock, Promenade) in a bring-your-own-k8s setup. Dwalt has a patchset in progress to align these site manifests fully to the treasuremap reference globals, per the story. [1]: https://storyboard.openstack.org/#!/story/2005123 [2]: https://airship-treasuremap.readthedocs.io/en/latest/airskiff.html Thanks, Matt From: Loic Le Gal Sent: Wednesday, March 6, 2019 9:49 AM To: airship-discuss at lists.airshipit.org Subject: Re: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error Hi Airshipers, Same issue for me, going back to previous commit (ad53fbf5c312929e8d0873e5095c5a0d1dcdd7f5), but another problem arise with maas-import-resources. I will open new thread if can't fix. Why is maas required even for AiaB as we don't have any baremetal involved ?? BR, Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.legal.astellia at gmail.com Thu Mar 7 09:16:41 2019 From: l.legal.astellia at gmail.com (Loic Le Gal) Date: Thu, 7 Mar 2019 10:16:41 +0100 Subject: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error In-Reply-To: <7C64A75C21BB8D43BD75BB18635E4D896D25AA6E@MOSTLS1MSGUSRFF.ITServices.sbc.com> References: <7C64A75C21BB8D43BD75BB18635E4D896D25AA6E@MOSTLS1MSGUSRFF.ITServices.sbc.com> Message-ID: Thanks Matt for the feedback, I'd like to help as I can but as I'm noob to Airship it won't be easy at the beginning. My aim (as many of firstcomers) is to try to get a functionning Airship demo with k8s & Openstack setup + a little VM on top (clearwater later :-)); all this installed on a big VM : That's AiaB! Regarding Airskiff, I've already tryied it but as it is not AIO and require setting-up and plugging all layers together, it might not be the easiest staring point IMHO. BTW, i'm close to have a Heat template to automate the building of such a AiaB VM (and with proxy management), this will ease future tests while waiting the Treasuremap's story you mentionned. Have you got a commit ID that is secured (like a stable one)? even if we don't have latest features/fixes. BR, Loïc Le mer. 6 mars 2019 à 22:16, MCEUEN, MATT a écrit : > Hi Loïc & Dimitrios, > > > > Shoot, sorry you guys hit this. This looks like the Airship-in-a-Bottle > single node dev site may have gotten stale. We have a few different sets > of YAMLs that should be aligned to one another to keep this from happening; > I’ve captured the issue and proposed resolution in this story[1]. If you’d > like to help with this it would be very much appreciated :-), and if anyone > has some time to get the AiaB single-node dev site definition trued up in > the meantime that would be valuable too. > > > > For a MaaS-free dev deployment, I suggest looking at the Airskiff [2] > deployment scripts. These deploy the software provisioning components (no > MaaS, Drydock, Promenade) in a bring-your-own-k8s setup. Dwalt has a > patchset in progress to align these site manifests fully to the treasuremap > reference globals, per the story. > > > > [1]: https://storyboard.openstack.org/#!/story/2005123 > > [2]: https://airship-treasuremap.readthedocs.io/en/latest/airskiff.html > > > > Thanks, > > Matt > > > > *From:* Loic Le Gal > *Sent:* Wednesday, March 6, 2019 9:49 AM > *To:* airship-discuss at lists.airshipit.org > *Subject:* Re: [Airship-discuss] > Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error > > > > Hi Airshipers, > > > > Same issue for me, going back to previous commit > (ad53fbf5c312929e8d0873e5095c5a0d1dcdd7f5), but another problem arise with > maas-import-resources. I will open new thread if can't fix. > > Why is maas required even for AiaB as we don't have any baremetal involved > ?? > > > > BR, > > > > Loïc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paye600 at gmail.com Thu Mar 7 12:55:27 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Thu, 7 Mar 2019 13:55:27 +0100 Subject: [Airship-discuss] Divingbell overrides functionality regression - Assistance needed In-Reply-To: References: Message-ID: > Just to confirm, were you using Helm 1.12.x when you tried replacing `merge` with `mergOverwrite`? I used helm 2.12.3.I confirm that mergeOverwrite does not work. Link with test: http://paste.openstack.org/show/747400/ Details: - line 4: helm client version v2.12.3 (this version is used in openstack-helm-infra by default) - line 16: latest openstack-helm-infra (commit id e836707ad070e910d6130eced066bc0e50481d2b) - line 30: `helm lint` of helm-toolkit - line 33: ./templates/utils/_daemonset_overrides.tpl uses `merge` - line 40: replace `merge` with `mergeOverwrite` - line 41: confirm replacement - line 50: linting fails with error `function "mergeOverwrite" not defined` Thank you for your help, Craig. -- Roman Gorshunov From paye600 at gmail.com Thu Mar 7 13:17:20 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Thu, 7 Mar 2019 14:17:20 +0100 Subject: [Airship-discuss] Divingbell overrides functionality regression - Assistance needed In-Reply-To: References: Message-ID: Playing a little bit, I have just found out that using helm version v2.13.0-rc.1 and higher, AND `mergeOverwrite` allows to pass linting. Log: http://paste.openstack.org/show/747402/ I've submitted a test PS to see if it would pass standard voting gates: https://review.openstack.org/#/c/641656/ The non-voting `openstack-helm-infra-airship-divingbell` gate should still fail, as it would use old `merge`. Waiting for gates to complete the work. -- Roman Gorshunov On Thu, Mar 7, 2019 at 1:55 PM Roman Gorshunov wrote: > > > Just to confirm, were you using Helm 1.12.x when you tried replacing `merge` with `mergOverwrite`? > I used helm 2.12.3.I confirm that mergeOverwrite does not work. > > Link with test: http://paste.openstack.org/show/747400/ > Details: > - line 4: helm client version v2.12.3 (this version is used in > openstack-helm-infra by default) > - line 16: latest openstack-helm-infra (commit id > e836707ad070e910d6130eced066bc0e50481d2b) > - line 30: `helm lint` of helm-toolkit > - line 33: ./templates/utils/_daemonset_overrides.tpl uses `merge` > - line 40: replace `merge` with `mergeOverwrite` > - line 41: confirm replacement > - line 50: linting fails with error `function "mergeOverwrite" not defined` > > Thank you for your help, Craig. > > -- Roman Gorshunov From MM9745 at att.com Thu Mar 7 19:30:21 2019 From: MM9745 at att.com (MCEUEN, MATT) Date: Thu, 7 Mar 2019 19:30:21 +0000 Subject: [Airship-discuss] Airship core reviewer team updates Message-ID: <7C64A75C21BB8D43BD75BB18635E4D896D26A181@MOSTLS1MSGUSRFF.ITServices.sbc.com> Based on unanimous voting results, I am pleased to welcome Evgeniy Li and Drew Walters to the Airship core review team, effective immediately! Happy to have you on board, and looking forward to working with you to push toward our 1.0 release. We also bid adieu to Mark Burnett, Marshall Margenau, and Anthony Lin, whose focus has shifted elsewhere over the past year or so, and who have decided to bow out of core responsibilities. Your efforts to found the Airship community have been most welcome; please feel welcome to drop in and Airship with us any time in the future. Thanks, Matt McEuen -------------- next part -------------- An HTML attachment was scrubbed... URL: From corvus at inaugust.com Thu Mar 7 21:47:37 2019 From: corvus at inaugust.com (James E. Blair) Date: Thu, 07 Mar 2019 13:47:37 -0800 Subject: [Airship-discuss] Migrating git repos to OpenDev Message-ID: <87wolas6fa.fsf@meyer.lemoncheese.net> Hi, As discussed in November[1], the OpenStack project infrastructure is being rebranded as "OpenDev" to better support a wider community of projects. We are nearly ready to perform the part of this transition with the largest impact: moving the authoritative git repositories for existing projects. In this email, I'd like to introduce the new hosting system we are preparing, discuss the transition, and invite projects to work with us on the logistics of the change. Gerrit ====== Gerrit is the core of our system and it will remain so in OpenDev. As part of this move, we will rename the gerrit server from review.openstack.org to review.opendev.org. As part of the transition, we will automatically merge appropriate changes to all branches of all repositories updating .gitreview and Zuul configuration files. Any further changes (README files, etc.) we expect to be made by individual project contributors. Repository Browsing =================== Currently our canonical *public* repository system is the cgit server at https://git.openstack.org/ (and git.airshipit.org, git.starlingx.io, and git.zuul-ci.org). This is a load balanced cluster of several servers which is designed to handle all the public git repository traffic, as it scales much better than Gerrit (and has a more friendly domain name). >From a technical standpoint, it's excellent, but its usability could be improved. Therefore, as part of this transition, we will replace the cgit servers with a new system based on Gitea. Gitea is a complete development collaboration system, but it's very flexible and will allow us to disable components which we aren't using. We will operate it in a read-only configuration where it will act as the public mirror for Gerrit. The advantages it has over the current system are: * Shorter domain name in project URLs: https://git.openstack.org/openstack/nova vs https://opendev.org/openstack/nova * Clone and browsing URLs are the same (with cgit, the browsing URL has an extra path component) * More visually pleasing code browsing * Integrated code searching * Ability to highlight multiple lines in links When we perform the transition we will install redirects from git.openstack.org (and the other git sites) to opendev.org, and will maintain those redirects for the foreseeable future. We will construct them so that even existing deep links to individual files in individual commits to cgit will redirect to the correct location on opendev.org. This system is up and running now with a live mirror of data from Gerrit, and you can start testing it out today at https://opendev.org/ Please let us know if you encounter any problems. If you would like to read more about the design of this system and the transition, see the infra-spec[2]. GitHub ====== Currently all OpenStack projects are replicated to GitHub. We do not plan on changing that during the transition, however, any projects outside of the openstack*/ namespaces will not automatically be replicated to GitHub, and we do not plan on adding that in the future. We do, however, support projects using Zuul to run post-merge jobs to push updates to GitHub or any other third-party mirrors with their own credentials. We will be happy to work with anyone interested in that to help set up jobs to do so. We are adopting this approach so that individual projects can have more control over how they are represented in social media, and to give us more flexibility in supporting our own organizational namespaces on OpenDev without assuming they map directly to GitHub. Eventually we plan on moving the OpenStack project to that system as well and retiring direct replication from Gerrit to GitHub completely. But we will defer that work until after this transition. Logistics ========= We can prepare much of the system in advance (as we have for the hosting system on opendev.org), but the actual transition and renaming of the Gerrit server will need to happen at once during an outage window. We need to schedule that outage and begin preparing for it. Since all of the project git URLs are going to change (to replace git.openstack.org with opendev.org and review.openstack.org with review.opendev.org), we can additionally take the opportunity to reorganize projects into different organizations. For example, during the transition we will rename Zuul, and it's associated projects, from the "openstack-infra" org to "zuul". So their new names will be "zuul/zuul", "zuul/nodepool", etc. This is an excellent time for the rest of the OpenStack Foundation pilot projects to do the same. If the OpenStack project desires this, it would also be a good time to move unofficial projects out of the openstack/ namespace. Therefore, we need your help: Action Items ============ We need each of the following projects: * OpenStack * Airship * StarlingX * Zuul To nominate a single point of contact to work with us on the transition. It would be helpful for that person to attend the next (and possibly next several) openstack infra team meetings in IRC [3]. We will work with those people on scheduling the transition, as well as finalizing the list of projects which should be renamed as part of the transition. If you manage an unofficial project and would like to take the opportunity to move or rename your project, please add it to this ethercalc[4]. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html [2] http://specs.openstack.org/openstack-infra/infra-specs/specs/opendev-gerrit.html [3] http://eavesdrop.openstack.org/#Project_Infrastructure_Team_Meeting [4] https://ethercalc.openstack.org/opendev-transition From paye600 at gmail.com Fri Mar 8 00:04:06 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Fri, 8 Mar 2019 01:04:06 +0100 Subject: [Airship-discuss] Divingbell overrides functionality regression - Assistance needed In-Reply-To: References: Message-ID: Good news: Tests on gates have succeeded. I have formatted a proper patch set which is now ready for review [0]. If applied, this patch will update Helm from v2.12.3 to v2.13.0, and replace `merge` with `mergeOverwrite` where appropriate in *daemonset_overrides.tpl files from helm-toolkit and ceph-osd. I'm actually not sure how to test if changes in *daemonset_overrides.tpl are correct. Not so good news: This didn't help to the divingbell overrides, and they are still not working. Logs: http://paste.openstack.org/show/747433/ I'm stuck again. [0] https://review.openstack.org/#/c/641656/5 -- Roman Gorshunov On Thu, Mar 7, 2019 at 2:17 PM Roman Gorshunov wrote: > > Playing a little bit, I have just found out that using helm version > v2.13.0-rc.1 and higher, AND `mergeOverwrite` allows to pass linting. > Log: http://paste.openstack.org/show/747402/ > > I've submitted a test PS to see if it would pass standard voting > gates: https://review.openstack.org/#/c/641656/ > The non-voting `openstack-helm-infra-airship-divingbell` gate should > still fail, as it would use old `merge`. > > Waiting for gates to complete the work. > > -- Roman Gorshunov > > On Thu, Mar 7, 2019 at 1:55 PM Roman Gorshunov wrote: > > > > > Just to confirm, were you using Helm 1.12.x when you tried replacing `merge` with `mergOverwrite`? > > I used helm 2.12.3.I confirm that mergeOverwrite does not work. > > > > Link with test: http://paste.openstack.org/show/747400/ > > Details: > > - line 4: helm client version v2.12.3 (this version is used in > > openstack-helm-infra by default) > > - line 16: latest openstack-helm-infra (commit id > > e836707ad070e910d6130eced066bc0e50481d2b) > > - line 30: `helm lint` of helm-toolkit > > - line 33: ./templates/utils/_daemonset_overrides.tpl uses `merge` > > - line 40: replace `merge` with `mergeOverwrite` > > - line 41: confirm replacement > > - line 50: linting fails with error `function "mergeOverwrite" not defined` > > > > Thank you for your help, Craig. > > > > -- Roman Gorshunov From ca846m at att.com Fri Mar 8 05:22:36 2019 From: ca846m at att.com (ANDERSON, CRAIG) Date: Fri, 8 Mar 2019 05:22:36 +0000 Subject: [Airship-discuss] Divingbell overrides functionality regression - Assistance needed In-Reply-To: References: Message-ID: I was able to get it working, so the PS is green now. Swapping the arguments order for the calls made to `mergeOverwrite` fixed it to give the correct (overrides) dict precedence. The reason the arguments were "backwards" before was because mergo was very fussy about ordering and would core dump when we tried using merge with the "intuitive" argument order. Given that the test passed without encountering that error either, it seems we can conclude this is resolved in the current version of mergo. The original problem must have been due to a change in the original `merge` function, which actually appears to be behaving the same as the `mergeOverwrite` function added in Helm after the mergo update. Therefore I believe the test would likely also pass on Helm v2.12.3 using the `merge` function as before but with swapped argument positions. However I think we should just do the Helm v2.13.0 upgrade anyway unless someone has an objection, or before someone proves my Helm v2.12.3 theory wrong :) Roy, it may also be interesting to see if we have issues with `null` parameters in this version of Helm. If this works now without throwing nil pointer exceptions, we could just add this test into the gate script to make sure it doesn't show up again (I'm crossing my fingers). Thanks, -----Original Message----- From: Roman Gorshunov [mailto:paye600 at gmail.com] Sent: Thursday, March 07, 2019 4:04 PM To: ANDERSON, CRAIG ; airship-discuss at lists.airshipit.org Cc: TANG, ROY Subject: Re: Divingbell overrides functionality regression - Assistance needed Good news: Tests on gates have succeeded. I have formatted a proper patch set which is now ready for review [0]. If applied, this patch will update Helm from v2.12.3 to v2.13.0, and replace `merge` with `mergeOverwrite` where appropriate in *daemonset_overrides.tpl files from helm-toolkit and ceph-osd. I'm actually not sure how to test if changes in *daemonset_overrides.tpl are correct. Not so good news: This didn't help to the divingbell overrides, and they are still not working. Logs: https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.openstack.org_show_747433_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_aS85wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=AzlCjMLPTU89x1SC_X7C2jE78TYtRST2DUGPMmM0Jpc&e= I'm stuck again. [0] https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_641656_5&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_aS85wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=_tTepiy_shl58qYy5kHFP0r3wx6-JHpiCYDEq5pxJh8&e= -- Roman Gorshunov On Thu, Mar 7, 2019 at 2:17 PM Roman Gorshunov wrote: > > Playing a little bit, I have just found out that using helm version > v2.13.0-rc.1 and higher, AND `mergeOverwrite` allows to pass linting. > Log: > https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.openstack.or > g_show_747402_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_aS85 > wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=d-lYsZ5PXoRxgXFJCW > dj84tcen9JqEuTvztcEEujT3I&e= > > I've submitted a test PS to see if it would pass standard voting > gates: > https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack. > org_-23_c_641656_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_a > S85wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=hSiLdJ1M9Hv0zlQ > pbKg2gogxOuiMZ6jVdmRQaTdp1D0&e= The non-voting > `openstack-helm-infra-airship-divingbell` gate should still fail, as > it would use old `merge`. > > Waiting for gates to complete the work. > > -- Roman Gorshunov > > On Thu, Mar 7, 2019 at 1:55 PM Roman Gorshunov wrote: > > > > > Just to confirm, were you using Helm 1.12.x when you tried replacing `merge` with `mergOverwrite`? > > I used helm 2.12.3.I confirm that mergeOverwrite does not work. > > > > Link with test: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.openstack. > > org_show_747400_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_ > > aS85wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=AwTIrAw_OBoL > > 4c98ESbnyVIQzkeFPy5YFi9CFL8Ewak&e= > > Details: > > - line 4: helm client version v2.12.3 (this version is used in > > openstack-helm-infra by default) > > - line 16: latest openstack-helm-infra (commit id > > e836707ad070e910d6130eced066bc0e50481d2b) > > - line 30: `helm lint` of helm-toolkit > > - line 33: ./templates/utils/_daemonset_overrides.tpl uses `merge` > > - line 40: replace `merge` with `mergeOverwrite` > > - line 41: confirm replacement > > - line 50: linting fails with error `function "mergeOverwrite" not > > defined` > > > > Thank you for your help, Craig. > > > > -- Roman Gorshunov From rp2723 at att.com Fri Mar 8 13:29:05 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Fri, 8 Mar 2019 13:29:05 +0000 Subject: [Airship-discuss] Canceled: Discuss target state implementation of Docker/Kernel/Os/Security Patches etc Message-ID: Canceling for today since many of the more vocal parties cannot make it. Discuss target state implementation of Airship Docker/Kubelet/Kernel/OS etc upgrade I scheduled a series, will figure out when it’s appropriate What do we need to discuss ? The ability to manage the delivery of any update across groups of hosts in a declarative way. The ability to control disruption effects from those updates Next Meeting: Looking at the https://github.com/GoogleCloudPlatform/metacontroller approach and comparing against what we discussed today. Everyone (in Airship Community) is welcome to participate on this discussions. Approach Discussed on our 1st Meeting https://go.gliffy.com/go/publish/12934972 Sample CR’s .. apiVersion: airship/v1 kind: MultiNodeAction metadata: name: DoSomethingPerRack spec: # List of sets of nodes that theis applies to. Indicates the cadence. 1 set at a time failureSet: set1: rack: rack1 set2: rack: rack2 # - Indicate the Action(What are we doing) - # - Indicate effect Upgrade and Reboot, Reboot Only, .. intentions: - UpgradeDockerAction - UpgradeKubeletAction - RebootAction ## This is teh CR that a node agent consumes apiVersion: airship/v1 kind: NodeAction metadata: name: Set1 spec: setIndicator: rack: rack1 intentions: ListOFActions: - UpgradeDocker - UpgradeKubelet - Reboot ## This is the CR's for ACTIONS that the NodeAgent ingests as well apiVersion: airship/v1 kind: Action metadata: name: Reboot spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeDocker spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeKubelet spec: script ..... -------------- next part -------------- An HTML attachment was scrubbed... URL: From rp2723 at att.com Fri Mar 8 13:27:38 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Fri, 8 Mar 2019 13:27:38 +0000 Subject: [Airship-discuss] Canceled: Discuss target state implementation of Docker/Kernel/Os/Security Patches etc Message-ID: <99088997CCAD0C4BA20008FD0943449632785B58@MISOUT7MSGUSRDI.ITServices.sbc.com> Canceling for today since many of the more vocal parties cannot make it. Discuss target state implementation of Airship Docker/Kubelet/Kernel/OS etc upgrade I scheduled a series, will figure out when it’s appropriate What do we need to discuss ? The ability to manage the delivery of any update across groups of hosts in a declarative way. The ability to control disruption effects from those updates Next Meeting: Looking at the https://github.com/GoogleCloudPlatform/metacontroller approach and comparing against what we discussed today. Everyone (in Airship Community) is welcome to participate on this discussions. Approach Discussed on our 1st Meeting https://go.gliffy.com/go/publish/12934972 Sample CR’s .. apiVersion: airship/v1 kind: MultiNodeAction metadata: name: DoSomethingPerRack spec: # List of sets of nodes that theis applies to. Indicates the cadence. 1 set at a time failureSet: set1: rack: rack1 set2: rack: rack2 # - Indicate the Action(What are we doing) - # - Indicate effect Upgrade and Reboot, Reboot Only, .. intentions: - UpgradeDockerAction - UpgradeKubeletAction - RebootAction ## This is teh CR that a node agent consumes apiVersion: airship/v1 kind: NodeAction metadata: name: Set1 spec: setIndicator: rack: rack1 intentions: ListOFActions: - UpgradeDocker - UpgradeKubelet - Reboot ## This is the CR's for ACTIONS that the NodeAgent ingests as well apiVersion: airship/v1 kind: Action metadata: name: Reboot spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeDocker spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeKubelet spec: script ..... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 4431 bytes Desc: not available URL: From rt7380 at att.com Fri Mar 8 14:45:38 2019 From: rt7380 at att.com (TANG, ROY) Date: Fri, 8 Mar 2019 14:45:38 +0000 Subject: [Airship-discuss] Divingbell overrides functionality regression - Assistance needed In-Reply-To: References: Message-ID: Craig, sure I can give it a spin, it does look more promising. Do you have your working version somewhere I can pull? I lost track of the ps and don't see it in this email thread. -----Original Message----- From: ANDERSON, CRAIG Sent: Thursday, March 7, 2019 11:23 PM To: Roman Gorshunov ; airship-discuss at lists.airshipit.org Cc: TANG, ROY Subject: RE: Divingbell overrides functionality regression - Assistance needed I was able to get it working, so the PS is green now. Swapping the arguments order for the calls made to `mergeOverwrite` fixed it to give the correct (overrides) dict precedence. The reason the arguments were "backwards" before was because mergo was very fussy about ordering and would core dump when we tried using merge with the "intuitive" argument order. Given that the test passed without encountering that error either, it seems we can conclude this is resolved in the current version of mergo. The original problem must have been due to a change in the original `merge` function, which actually appears to be behaving the same as the `mergeOverwrite` function added in Helm after the mergo update. Therefore I believe the test would likely also pass on Helm v2.12.3 using the `merge` function as before but with swapped argument positions. However I think we should just do the Helm v2.13.0 upgrade anyway unless someone has an objection, or before someone proves my Helm v2.12.3 theory wrong :) Roy, it may also be interesting to see if we have issues with `null` parameters in this version of Helm. If this works now without throwing nil pointer exceptions, we could just add this test into the gate script to make sure it doesn't show up again (I'm crossing my fingers). Thanks, -----Original Message----- From: Roman Gorshunov [mailto:paye600 at gmail.com] Sent: Thursday, March 07, 2019 4:04 PM To: ANDERSON, CRAIG ; airship-discuss at lists.airshipit.org Cc: TANG, ROY Subject: Re: Divingbell overrides functionality regression - Assistance needed Good news: Tests on gates have succeeded. I have formatted a proper patch set which is now ready for review [0]. If applied, this patch will update Helm from v2.12.3 to v2.13.0, and replace `merge` with `mergeOverwrite` where appropriate in *daemonset_overrides.tpl files from helm-toolkit and ceph-osd. I'm actually not sure how to test if changes in *daemonset_overrides.tpl are correct. Not so good news: This didn't help to the divingbell overrides, and they are still not working. Logs: https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.openstack.org_show_747433_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_aS85wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=AzlCjMLPTU89x1SC_X7C2jE78TYtRST2DUGPMmM0Jpc&e= I'm stuck again. [0] https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_641656_5&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_aS85wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=_tTepiy_shl58qYy5kHFP0r3wx6-JHpiCYDEq5pxJh8&e= -- Roman Gorshunov On Thu, Mar 7, 2019 at 2:17 PM Roman Gorshunov wrote: > > Playing a little bit, I have just found out that using helm version > v2.13.0-rc.1 and higher, AND `mergeOverwrite` allows to pass linting. > Log: > https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.openstack.or > g_show_747402_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_aS85 > wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=d-lYsZ5PXoRxgXFJCW > dj84tcen9JqEuTvztcEEujT3I&e= > > I've submitted a test PS to see if it would pass standard voting > gates: > https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack. > org_-23_c_641656_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_a > S85wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=hSiLdJ1M9Hv0zlQ > pbKg2gogxOuiMZ6jVdmRQaTdp1D0&e= The non-voting > `openstack-helm-infra-airship-divingbell` gate should still fail, as > it would use old `merge`. > > Waiting for gates to complete the work. > > -- Roman Gorshunov > > On Thu, Mar 7, 2019 at 1:55 PM Roman Gorshunov wrote: > > > > > Just to confirm, were you using Helm 1.12.x when you tried replacing `merge` with `mergOverwrite`? > > I used helm 2.12.3.I confirm that mergeOverwrite does not work. > > > > Link with test: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.openstack. > > org_show_747400_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_ > > aS85wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=AwTIrAw_OBoL > > 4c98ESbnyVIQzkeFPy5YFi9CFL8Ewak&e= > > Details: > > - line 4: helm client version v2.12.3 (this version is used in > > openstack-helm-infra by default) > > - line 16: latest openstack-helm-infra (commit id > > e836707ad070e910d6130eced066bc0e50481d2b) > > - line 30: `helm lint` of helm-toolkit > > - line 33: ./templates/utils/_daemonset_overrides.tpl uses `merge` > > - line 40: replace `merge` with `mergeOverwrite` > > - line 41: confirm replacement > > - line 50: linting fails with error `function "mergeOverwrite" not > > defined` > > > > Thank you for your help, Craig. > > > > -- Roman Gorshunov From paye600 at gmail.com Fri Mar 8 15:28:25 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Fri, 8 Mar 2019 16:28:25 +0100 Subject: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error In-Reply-To: References: <7C64A75C21BB8D43BD75BB18635E4D896D25AA6E@MOSTLS1MSGUSRFF.ITServices.sbc.com> Message-ID: Hello team, I'm working on getting maas-ingress working again. This patch set [0] I believe solves this specific problem when applied onto a current master [1]. Try to apply it from inside of cloned airship-in-a-bottle repository by running commands under Download -> Checkout menu in the right corner [2]. For me it passes trough maas initialization and helm tests. [0] https://review.openstack.org/#/c/629950/ [1] 539f777c637ffd1927659469072ec6235188b247 [2] git fetch https://git.openstack.org/openstack/airship-in-a-bottle refs/changes/50/629950/3 && git checkout FETCH_HEAD -- Roman Gorshunov On Thu, Mar 7, 2019 at 10:17 AM Loic Le Gal wrote: > > Thanks Matt for the feedback, > > I'd like to help as I can but as I'm noob to Airship it won't be easy at the beginning. > My aim (as many of firstcomers) is to try to get a functionning Airship demo with k8s & Openstack setup + a little VM on top (clearwater later :-)); all this installed on a big VM : That's AiaB! > Regarding Airskiff, I've already tryied it but as it is not AIO and require setting-up and plugging all layers together, it might not be the easiest staring point IMHO. > BTW, i'm close to have a Heat template to automate the building of such a AiaB VM (and with proxy management), this will ease future tests while waiting the Treasuremap's story you mentionned. > > Have you got a commit ID that is secured (like a stable one)? even if we don't have latest features/fixes. > > BR, > > Loïc > > Le mer. 6 mars 2019 à 22:16, MCEUEN, MATT a écrit : >> >> Hi Loïc & Dimitrios, >> >> >> >> Shoot, sorry you guys hit this. This looks like the Airship-in-a-Bottle single node dev site may have gotten stale. We have a few different sets of YAMLs that should be aligned to one another to keep this from happening; I’ve captured the issue and proposed resolution in this story[1]. If you’d like to help with this it would be very much appreciated :-), and if anyone has some time to get the AiaB single-node dev site definition trued up in the meantime that would be valuable too. >> >> >> >> For a MaaS-free dev deployment, I suggest looking at the Airskiff [2] deployment scripts. These deploy the software provisioning components (no MaaS, Drydock, Promenade) in a bring-your-own-k8s setup. Dwalt has a patchset in progress to align these site manifests fully to the treasuremap reference globals, per the story. >> >> >> >> [1]: https://storyboard.openstack.org/#!/story/2005123 >> >> [2]: https://airship-treasuremap.readthedocs.io/en/latest/airskiff.html >> >> >> >> Thanks, >> >> Matt >> >> >> >> From: Loic Le Gal >> Sent: Wednesday, March 6, 2019 9:49 AM >> To: airship-discuss at lists.airshipit.org >> Subject: Re: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error >> >> >> >> Hi Airshipers, >> >> >> >> Same issue for me, going back to previous commit (ad53fbf5c312929e8d0873e5095c5a0d1dcdd7f5), but another problem arise with maas-import-resources. I will open new thread if can't fix. >> >> Why is maas required even for AiaB as we don't have any baremetal involved ?? >> >> >> >> BR, >> >> >> >> Loïc > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss From paye600 at gmail.com Fri Mar 8 16:56:46 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Fri, 8 Mar 2019 17:56:46 +0100 Subject: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error In-Reply-To: References: <7C64A75C21BB8D43BD75BB18635E4D896D25AA6E@MOSTLS1MSGUSRFF.ITServices.sbc.com> Message-ID: Almost there. The patch [0] works and really fixes maas ingress problem. Genesis part gets finished, and everything fails on the actual site deploy (error message is below [1]). But later I've run commands [2] to deploy site manually, and everything seems to be working fine. You then should be able to see Airflow interface and running `deploy_site` on the IP address of the VM on port 30004: http://:30004/. Port is taken from `kubectl get services -n ucp | grep airflow-web-int` command output. [0] https://review.openstack.org/#/c/629950/3 [1]: > + sudo docker run -t --rm --net=host -e http_proxy= -e https_proxy= -e no_proxy= -e OS_AUTH_URL=http://keystone.ucp.svc.cluster.local:80/v3 -e OS_USERNAME=shipyard -e OS_USER_DOMAIN_NAME=default -e OS_PASSWORD=password18 -e OS_PROJECT_DOMAIN_NAME=default -e OS_PROJECT_NAME=service quay.io/airshipit/shipyard:master create action deploy_site > Error: Unable to complete request to Airflow > Reason: Airflow could not be contacted properly by Shipyard. > - Error: [2]: cd /root/deploy/site source creds.sh # "create configdocs design", "create configdocs secrets", "commit configdocs" have succeeded previously via "./airship-in-a-bottle.sh -y" script; only deploy_site` dropped an error ./run_shipyard.sh create action deploy_site -- Roman Gorshunov On Fri, Mar 8, 2019 at 4:28 PM Roman Gorshunov wrote: > > Hello team, > I'm working on getting maas-ingress working again. This patch set [0] > I believe solves this specific problem when applied onto a current > master [1]. Try to apply it from inside of cloned airship-in-a-bottle > repository by running commands under Download -> Checkout menu in the > right corner [2]. For me it passes trough maas initialization and helm > tests. > > [0] https://review.openstack.org/#/c/629950/ > [1] 539f777c637ffd1927659469072ec6235188b247 > [2] git fetch https://git.openstack.org/openstack/airship-in-a-bottle > refs/changes/50/629950/3 && git checkout FETCH_HEAD > > -- Roman Gorshunov > > On Thu, Mar 7, 2019 at 10:17 AM Loic Le Gal wrote: > > > > Thanks Matt for the feedback, > > > > I'd like to help as I can but as I'm noob to Airship it won't be easy at the beginning. > > My aim (as many of firstcomers) is to try to get a functionning Airship demo with k8s & Openstack setup + a little VM on top (clearwater later :-)); all this installed on a big VM : That's AiaB! > > Regarding Airskiff, I've already tryied it but as it is not AIO and require setting-up and plugging all layers together, it might not be the easiest staring point IMHO. > > BTW, i'm close to have a Heat template to automate the building of such a AiaB VM (and with proxy management), this will ease future tests while waiting the Treasuremap's story you mentionned. > > > > Have you got a commit ID that is secured (like a stable one)? even if we don't have latest features/fixes. > > > > BR, > > > > Loïc > > > > Le mer. 6 mars 2019 à 22:16, MCEUEN, MATT a écrit : > >> > >> Hi Loïc & Dimitrios, > >> > >> > >> > >> Shoot, sorry you guys hit this. This looks like the Airship-in-a-Bottle single node dev site may have gotten stale. We have a few different sets of YAMLs that should be aligned to one another to keep this from happening; I’ve captured the issue and proposed resolution in this story[1]. If you’d like to help with this it would be very much appreciated :-), and if anyone has some time to get the AiaB single-node dev site definition trued up in the meantime that would be valuable too. > >> > >> > >> > >> For a MaaS-free dev deployment, I suggest looking at the Airskiff [2] deployment scripts. These deploy the software provisioning components (no MaaS, Drydock, Promenade) in a bring-your-own-k8s setup. Dwalt has a patchset in progress to align these site manifests fully to the treasuremap reference globals, per the story. > >> > >> > >> > >> [1]: https://storyboard.openstack.org/#!/story/2005123 > >> > >> [2]: https://airship-treasuremap.readthedocs.io/en/latest/airskiff.html > >> > >> > >> > >> Thanks, > >> > >> Matt > >> > >> > >> > >> From: Loic Le Gal > >> Sent: Wednesday, March 6, 2019 9:49 AM > >> To: airship-discuss at lists.airshipit.org > >> Subject: Re: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error > >> > >> > >> > >> Hi Airshipers, > >> > >> > >> > >> Same issue for me, going back to previous commit (ad53fbf5c312929e8d0873e5095c5a0d1dcdd7f5), but another problem arise with maas-import-resources. I will open new thread if can't fix. > >> > >> Why is maas required even for AiaB as we don't have any baremetal involved ?? > >> > >> > >> > >> BR, > >> > >> > >> > >> Loïc > > > > _______________________________________________ > > Airship-discuss mailing list > > Airship-discuss at lists.airshipit.org > > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss From bs4939 at att.com Fri Mar 8 17:04:07 2019 From: bs4939 at att.com (STRASSNER, BRYAN) Date: Fri, 8 Mar 2019 17:04:07 +0000 Subject: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error In-Reply-To: References: <7C64A75C21BB8D43BD75BB18635E4D896D25AA6E@MOSTLS1MSGUSRFF.ITServices.sbc.com> Message-ID: <651A1B0DF16CC24CBBA3ABFDB19EE69E4ECE74EB@MOSTLS1MSGUSRFA.ITServices.sbc.com> Please be aware: https://review.openstack.org/#/c/634813/ is a change that updates Shipyard in airship-in-a-bottle. This change has been After this update, there is no Airflow GUI exposed. Users would use shipyard commands to inspect their workflows. Bryan Strassner -----Original Message----- From: Roman Gorshunov Sent: Friday, March 08, 2019 10:57 AM To: airship-discuss at lists.airshipit.org Cc: MCEUEN, MATT ; Loic Le Gal Subject: Re: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error Almost there. The patch [0] works and really fixes maas ingress problem. Genesis part gets finished, and everything fails on the actual site deploy (error message is below [1]). But later I've run commands [2] to deploy site manually, and everything seems to be working fine. You then should be able to see Airflow interface and running `deploy_site` on the IP address of the VM on port 30004: http://:30004/. Port is taken from `kubectl get services -n ucp | grep airflow-web-int` command output. [0] https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_629950_3&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6hrI4hb9rm_Ue6DOyw&s=D0e_LQy-6KkoIYX5ZS1BiAgOYSkfV4dXcRreugipac0&e= [1]: > + sudo docker run -t --rm --net=host -e http_proxy= -e https_proxy= -e > + no_proxy= -e > + OS_AUTH_URL=https://urldefense.proofpoint.com/v2/url?u=http-3A__keys > + tone.ucp.svc.cluster.local-3A80_v3&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg > + &r=lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6hrI4hb9rm_Ue6D > + Oyw&s=f1dIO0kygz9h-C4XxV9dcGTZlXBMwjB5uBRUt6AKPjI&e= -e > + OS_USERNAME=shipyard -e OS_USER_DOMAIN_NAME=default -e > + OS_PASSWORD=password18 -e OS_PROJECT_DOMAIN_NAME=default -e > + OS_PROJECT_NAME=service quay.io/airshipit/shipyard:master create > + action deploy_site > Error: Unable to complete request to Airflow > Reason: Airflow could not be contacted properly by Shipyard. > - Error: [2]: cd /root/deploy/site source creds.sh # "create configdocs design", "create configdocs secrets", "commit configdocs" have succeeded previously via "./airship-in-a-bottle.sh -y" script; only deploy_site` dropped an error ./run_shipyard.sh create action deploy_site -- Roman Gorshunov On Fri, Mar 8, 2019 at 4:28 PM Roman Gorshunov wrote: > > Hello team, > I'm working on getting maas-ingress working again. This patch set [0] > I believe solves this specific problem when applied onto a current > master [1]. Try to apply it from inside of cloned airship-in-a-bottle > repository by running commands under Download -> Checkout menu in the > right corner [2]. For me it passes trough maas initialization and helm > tests. > > [0] > https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack. > org_-23_c_629950_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=lg0Gw5OaH7fHGAPx > U-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6hrI4hb9rm_Ue6DOyw&s=aq1NLATcaayJV5- > n6sxm3ZNx1R8TPX-MThCBUMotjFE&e= [1] > 539f777c637ffd1927659469072ec6235188b247 > [2] git fetch > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openstack.org > _openstack_airship-2Din-2Da-2Dbottle&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg > &r=lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6hrI4hb9rm_Ue6DOy > w&s=BzldpD9DgSWJ5DhOMkcTTYRuuXt0XYCQcV1MmTZAJos&e= > refs/changes/50/629950/3 && git checkout FETCH_HEAD > > -- Roman Gorshunov > > On Thu, Mar 7, 2019 at 10:17 AM Loic Le Gal wrote: > > > > Thanks Matt for the feedback, > > > > I'd like to help as I can but as I'm noob to Airship it won't be easy at the beginning. > > My aim (as many of firstcomers) is to try to get a functionning Airship demo with k8s & Openstack setup + a little VM on top (clearwater later :-)); all this installed on a big VM : That's AiaB! > > Regarding Airskiff, I've already tryied it but as it is not AIO and require setting-up and plugging all layers together, it might not be the easiest staring point IMHO. > > BTW, i'm close to have a Heat template to automate the building of such a AiaB VM (and with proxy management), this will ease future tests while waiting the Treasuremap's story you mentionned. > > > > Have you got a commit ID that is secured (like a stable one)? even if we don't have latest features/fixes. > > > > BR, > > > > Loïc > > > > Le mer. 6 mars 2019 à 22:16, MCEUEN, MATT a écrit : > >> > >> Hi Loïc & Dimitrios, > >> > >> > >> > >> Shoot, sorry you guys hit this. This looks like the Airship-in-a-Bottle single node dev site may have gotten stale. We have a few different sets of YAMLs that should be aligned to one another to keep this from happening; I’ve captured the issue and proposed resolution in this story[1]. If you’d like to help with this it would be very much appreciated :-), and if anyone has some time to get the AiaB single-node dev site definition trued up in the meantime that would be valuable too. > >> > >> > >> > >> For a MaaS-free dev deployment, I suggest looking at the Airskiff [2] deployment scripts. These deploy the software provisioning components (no MaaS, Drydock, Promenade) in a bring-your-own-k8s setup. Dwalt has a patchset in progress to align these site manifests fully to the treasuremap reference globals, per the story. > >> > >> > >> > >> [1]: > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__storyboard.ope > >> nstack.org_-23-21_story_2005123&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r > >> =lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6hrI4hb9rm_Ue6DO > >> yw&s=5rVJvyhZ78s-u8qRHgQdsfFmRFj62XcwGlk7jRh5S2U&e= > >> > >> [2]: > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__airship-2Dtrea > >> suremap.readthedocs.io_en_latest_airskiff.html&d=DwIGaQ&c=LFYZ-o9_H > >> UMeMTSQicvjIg&r=lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6 > >> hrI4hb9rm_Ue6DOyw&s=umXc-T-9hR-ACN4zqjXn7xm2iO8_r3oBui0v42Af21w&e= > >> > >> > >> > >> Thanks, > >> > >> Matt > >> > >> > >> > >> From: Loic Le Gal > >> Sent: Wednesday, March 6, 2019 9:49 AM > >> To: airship-discuss at lists.airshipit.org > >> Subject: Re: [Airship-discuss] > >> Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingre > >> ss_Error > >> > >> > >> > >> Hi Airshipers, > >> > >> > >> > >> Same issue for me, going back to previous commit (ad53fbf5c312929e8d0873e5095c5a0d1dcdd7f5), but another problem arise with maas-import-resources. I will open new thread if can't fix. > >> > >> Why is maas required even for AiaB as we don't have any baremetal involved ?? > >> > >> > >> > >> BR, > >> > >> > >> > >> Loïc > > > > _______________________________________________ > > Airship-discuss mailing list > > Airship-discuss at lists.airshipit.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.airshipit. > > org_cgi-2Dbin_mailman_listinfo_airship-2Ddiscuss&d=DwIGaQ&c=LFYZ-o9_ > > HUMeMTSQicvjIg&r=lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6 > > hrI4hb9rm_Ue6DOyw&s=pRUR3rU5WUpenI8XAdqiZRT6DLc6Jsnh_RACCWDYbEs&e= _______________________________________________ Airship-discuss mailing list Airship-discuss at lists.airshipit.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.airshipit.org_cgi-2Dbin_mailman_listinfo_airship-2Ddiscuss&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6hrI4hb9rm_Ue6DOyw&s=pRUR3rU5WUpenI8XAdqiZRT6DLc6Jsnh_RACCWDYbEs&e= From ca846m at att.com Fri Mar 8 17:49:09 2019 From: ca846m at att.com (ANDERSON, CRAIG) Date: Fri, 8 Mar 2019 17:49:09 +0000 Subject: [Airship-discuss] Divingbell overrides functionality regression - Assistance needed In-Reply-To: References: Message-ID: https://review.openstack.org/#/c/632200 Thanks -----Original Message----- From: TANG, ROY Sent: Friday, March 08, 2019 6:46 AM To: ANDERSON, CRAIG ; Roman Gorshunov ; airship-discuss at lists.airshipit.org Subject: RE: Divingbell overrides functionality regression - Assistance needed Craig, sure I can give it a spin, it does look more promising. Do you have your working version somewhere I can pull? I lost track of the ps and don't see it in this email thread. -----Original Message----- From: ANDERSON, CRAIG Sent: Thursday, March 7, 2019 11:23 PM To: Roman Gorshunov ; airship-discuss at lists.airshipit.org Cc: TANG, ROY Subject: RE: Divingbell overrides functionality regression - Assistance needed I was able to get it working, so the PS is green now. Swapping the arguments order for the calls made to `mergeOverwrite` fixed it to give the correct (overrides) dict precedence. The reason the arguments were "backwards" before was because mergo was very fussy about ordering and would core dump when we tried using merge with the "intuitive" argument order. Given that the test passed without encountering that error either, it seems we can conclude this is resolved in the current version of mergo. The original problem must have been due to a change in the original `merge` function, which actually appears to be behaving the same as the `mergeOverwrite` function added in Helm after the mergo update. Therefore I believe the test would likely also pass on Helm v2.12.3 using the `merge` function as before but with swapped argument positions. However I think we should just do the Helm v2.13.0 upgrade anyway unless someone has an objection, or before someone proves my Helm v2.12.3 theory wrong :) Roy, it may also be interesting to see if we have issues with `null` parameters in this version of Helm. If this works now without throwing nil pointer exceptions, we could just add this test into the gate script to make sure it doesn't show up again (I'm crossing my fingers). Thanks, -----Original Message----- From: Roman Gorshunov [mailto:paye600 at gmail.com] Sent: Thursday, March 07, 2019 4:04 PM To: ANDERSON, CRAIG ; airship-discuss at lists.airshipit.org Cc: TANG, ROY Subject: Re: Divingbell overrides functionality regression - Assistance needed Good news: Tests on gates have succeeded. I have formatted a proper patch set which is now ready for review [0]. If applied, this patch will update Helm from v2.12.3 to v2.13.0, and replace `merge` with `mergeOverwrite` where appropriate in *daemonset_overrides.tpl files from helm-toolkit and ceph-osd. I'm actually not sure how to test if changes in *daemonset_overrides.tpl are correct. Not so good news: This didn't help to the divingbell overrides, and they are still not working. Logs: https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.openstack.org_show_747433_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_aS85wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=AzlCjMLPTU89x1SC_X7C2jE78TYtRST2DUGPMmM0Jpc&e= I'm stuck again. [0] https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_641656_5&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_aS85wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=_tTepiy_shl58qYy5kHFP0r3wx6-JHpiCYDEq5pxJh8&e= -- Roman Gorshunov On Thu, Mar 7, 2019 at 2:17 PM Roman Gorshunov wrote: > > Playing a little bit, I have just found out that using helm version > v2.13.0-rc.1 and higher, AND `mergeOverwrite` allows to pass linting. > Log: > https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.openstack.or > g_show_747402_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_aS85 > wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=d-lYsZ5PXoRxgXFJCW > dj84tcen9JqEuTvztcEEujT3I&e= > > I've submitted a test PS to see if it would pass standard voting > gates: > https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack. > org_-23_c_641656_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_a > S85wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=hSiLdJ1M9Hv0zlQ > pbKg2gogxOuiMZ6jVdmRQaTdp1D0&e= The non-voting > `openstack-helm-infra-airship-divingbell` gate should still fail, as > it would use old `merge`. > > Waiting for gates to complete the work. > > -- Roman Gorshunov > > On Thu, Mar 7, 2019 at 1:55 PM Roman Gorshunov wrote: > > > > > Just to confirm, were you using Helm 1.12.x when you tried replacing `merge` with `mergOverwrite`? > > I used helm 2.12.3.I confirm that mergeOverwrite does not work. > > > > Link with test: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.openstack. > > org_show_747400_&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=aimn2OylFgog_5_ > > aS85wtQ&m=C3ro_V1fT7fdpF_d9veBkPBnYfsWSeCOKV8ajDB3C-8&s=AwTIrAw_OBoL > > 4c98ESbnyVIQzkeFPy5YFi9CFL8Ewak&e= > > Details: > > - line 4: helm client version v2.12.3 (this version is used in > > openstack-helm-infra by default) > > - line 16: latest openstack-helm-infra (commit id > > e836707ad070e910d6130eced066bc0e50481d2b) > > - line 30: `helm lint` of helm-toolkit > > - line 33: ./templates/utils/_daemonset_overrides.tpl uses `merge` > > - line 40: replace `merge` with `mergeOverwrite` > > - line 41: confirm replacement > > - line 50: linting fails with error `function "mergeOverwrite" not > > defined` > > > > Thank you for your help, Craig. > > > > -- Roman Gorshunov From l.legal.astellia at gmail.com Mon Mar 11 16:33:25 2019 From: l.legal.astellia at gmail.com (Loic Le Gal) Date: Mon, 11 Mar 2019 17:33:25 +0100 Subject: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error In-Reply-To: <651A1B0DF16CC24CBBA3ABFDB19EE69E4ECE74EB@MOSTLS1MSGUSRFA.ITServices.sbc.com> References: <7C64A75C21BB8D43BD75BB18635E4D896D25AA6E@MOSTLS1MSGUSRFF.ITServices.sbc.com> <651A1B0DF16CC24CBBA3ABFDB19EE69E4ECE74EB@MOSTLS1MSGUSRFA.ITServices.sbc.com> Message-ID: Hi and thanks Roman & Bryan for previous hints, I've tried the patchset 629950 as mentionned, and it fixes the maas-ingress Crashloop. Nevertheless, now I've got an endless restart from pod maas-import-resources for readiness probe failure of container region-import-resources (describe log below). No way to remove the maas module pods? The log gives: >sudo kubectl logs maas-import-resources-vbdc5 -n ucp -c region-import-resources Boot resources currently importing + echo -e '\nBoot resources currently importing\n' + let JOB_TIMEOUT-=10 + sleep 10 + [[ 790 -gt 0 ]] + maas admin boot-resources is-importing + grep -q true ++ maas admin boot-resources read ++ tail -n +1 ++ jq '.[] | select( .type | contains("Synced")) | .name ' ++ grep -c xenial Import failed! + synced_imgs=0 + [[ 0 -gt 0 ]] + echo 'Import failed!' + return 1 + [[ 1 -eq 0 ]] + [[ 1 -lt 1 ]] + return 1 + [[ 1 -eq 0 ]] + echo 'Image import FAILED!' + exit 1 Image import FAILED! ubuntu at airship:~$ sudo kubectl describe pod maas-import-resources-vbdc5 -n ucp Name: maas-import-resources-vbdc5 Namespace: ucp Node: airship/10.10.0.18 Start Time: Mon, 11 Mar 2019 14:59:50 +0000 Labels: application=maas component=import-resources controller-uid=519ea8fd-440e-11e9-b0ca-fa16aae5c6c9 job-name=maas-import-resources release_group=airship-maas Annotations: Status: Running IP: 10.97.196.156 Controlled By: Job/maas-import-resources Init Containers: init: Container ID: docker://b9bcb2853339a06280e3c41b3fcdd3bddafaaa5a467e0567554b6b9d6ea631a7 Image: quay.io/stackanetes/kubernetes-entrypoint:v0.3.1 Image ID: docker-pullable:// quay.io/stackanetes/kubernetes-entrypoint at sha256:32b1b657ee4bcc9cc7a1529e31d8e1a06376172373ee020f97f3e78168fde4b6 Port: Host Port: Command: kubernetes-entrypoint State: Terminated Reason: Completed Exit Code: 0 Started: Mon, 11 Mar 2019 14:59:55 +0000 Finished: Mon, 11 Mar 2019 15:02:41 +0000 Ready: True Restart Count: 0 Environment: POD_NAME: maas-import-resources-vbdc5 (v1:metadata.name) NAMESPACE: ucp (v1:metadata.namespace) INTERFACE_NAME: eth0 PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/ DEPENDENCY_SERVICE: ucp:maas-region,ucp:postgresql DEPENDENCY_DAEMONSET: DEPENDENCY_CONTAINER: DEPENDENCY_POD_JSON: COMMAND: echo done Mounts: /var/run/secrets/kubernetes.io/serviceaccount from maas-import-resources-token-mxvgx (ro) Containers: region-import-resources: Container ID: docker://99fabebf7b40a91efff76b1df3904cf95552df8fc8cf92a4891dc65e670678cf Image: quay.io/airshipit/maas-region-controller:bb81a1cecd27520b858e00f0bcf519ceb2d07582 Image ID: docker-pullable:// quay.io/airshipit/maas-region-controller at sha256:dc6694b3883624ebbdd4245e4bac2bba8e7e54a3b12e7f4fc54bc345312187ca Port: Host Port: Command: /tmp/import-boot-resources.sh State: Running Started: Mon, 11 Mar 2019 16:13:53 +0000 Last State: Terminated Reason: Error Exit Code: 1 Started: Mon, 11 Mar 2019 16:07:35 +0000 Finished: Mon, 11 Mar 2019 16:12:24 +0000 Ready: True Restart Count: 11 Readiness: exec [/tmp/job-readiness.sh] delay=60s timeout=1s period=10s #success=1 #failure=3 Environment: USE_IMAGE_CACHE: false JOB_TIMEOUT: 900 ADMIN_USERNAME: Optional: false RETRY_TIMER: 10 TRY_LIMIT: 1 MAAS_ENDPOINT: http://maas-region.ucp.svc.cluster.local:80/MAAS MAAS_PROXY_ENABLED: false MAAS_PEER_PROXY_ENABLED: false MAAS_PROXY_SERVER: MAAS_INTERNAL_PROXY_PORT: http://maas-region.ucp.svc.cluster.local:8000/MAAS MAAS_HTTP_BOOT: true MAAS_NTP_SERVERS: ntp.ubuntu.com MAAS_NTP_EXTERNAL_ONLY: false MAAS_DNS_DNSSEC_REQUIRED: no MAAS_DNS_SERVERS: 10.50.50.120,10.50.50.97 MAAS_DEFAULT_OS: ubuntu MAAS_DEFAULT_DISTRO: xenial MAAS_DEFAULT_KERNEL: ga-16.04 Mounts: /etc/bind/named.conf.options from maas-etc (ro) /etc/maas/regiond.conf from maas-etc (ro) /tmp/import-boot-resources.sh from maas-bin (ro) /tmp/job-readiness.sh from maas-bin (ro) /var/run/secrets/kubernetes.io/serviceaccount from maas-import-resources-token-mxvgx (ro) Conditions: Type Status Initialized True Ready True PodScheduled True Volumes: maas-bin: Type: ConfigMap (a volume populated by a ConfigMap) Name: maas-bin Optional: false maas-etc: Type: ConfigMap (a volume populated by a ConfigMap) Name: maas-etc Optional: false maas-import-resources-token-mxvgx: Type: Secret (a volume populated by a Secret) SecretName: maas-import-resources-token-mxvgx Optional: false QoS Class: BestEffort Node-Selectors: ucp-control-plane=enabled Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Unhealthy 53m kubelet, airship Readiness probe errored: rpc error: code = Unknown desc = container not running (e5ce115cfa833e6416b5ada892aaf859c57355552fffcfd164c2857bd0588364) Normal Pulled 47m (x5 over 1h) kubelet, airship Container image " quay.io/airshipit/maas-region-controller:bb81a1cecd27520b858e00f0bcf519ceb2d07582" already present on machine Normal Created 47m (x5 over 1h) kubelet, airship Created container Normal Started 47m (x5 over 1h) kubelet, airship Started container Warning BackOff 8m (x53 over 58m) kubelet, airship Back-off restarting failed container Warning Unhealthy 3m (x2 over 36m) kubelet, airship Readiness probe failed: + maas-region apikey --username=admin BR, Loïc Le ven. 8 mars 2019 à 18:04, STRASSNER, BRYAN a écrit : > Please be aware: https://review.openstack.org/#/c/634813/ is a change > that updates Shipyard in airship-in-a-bottle. This change has been > After this update, there is no Airflow GUI exposed. Users would use > shipyard commands to inspect their workflows. > > Bryan Strassner > > -----Original Message----- > From: Roman Gorshunov > Sent: Friday, March 08, 2019 10:57 AM > To: airship-discuss at lists.airshipit.org > Cc: MCEUEN, MATT ; Loic Le Gal > > Subject: Re: [Airship-discuss] > Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error > > Almost there. > The patch [0] works and really fixes maas ingress problem. Genesis part > gets finished, and everything fails on the actual site deploy (error > message is below [1]). > But later I've run commands [2] to deploy site manually, and everything > seems to be working fine. > You then should be able to see Airflow interface and running `deploy_site` > on the IP address of the VM on port 30004: http:// VM>:30004/. Port is taken from `kubectl get services -n ucp | grep > airflow-web-int` command output. > > [0] > https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_629950_3&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6hrI4hb9rm_Ue6DOyw&s=D0e_LQy-6KkoIYX5ZS1BiAgOYSkfV4dXcRreugipac0&e= > > [1]: > > + sudo docker run -t --rm --net=host -e http_proxy= -e https_proxy= -e > > + no_proxy= -e > > + OS_AUTH_URL=https://urldefense.proofpoint.com/v2/url?u=http-3A__keys > > + tone.ucp.svc.cluster.local-3A80_v3&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg > > + &r=lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6hrI4hb9rm_Ue6D > > + Oyw&s=f1dIO0kygz9h-C4XxV9dcGTZlXBMwjB5uBRUt6AKPjI&e= -e > > + OS_USERNAME=shipyard -e OS_USER_DOMAIN_NAME=default -e > > + OS_PASSWORD=password18 -e OS_PROJECT_DOMAIN_NAME=default -e > > + OS_PROJECT_NAME=service quay.io/airshipit/shipyard:master create > > + action deploy_site > > Error: Unable to complete request to Airflow > > Reason: Airflow could not be contacted properly by Shipyard. > > - Error: > > [2]: > cd /root/deploy/site > source creds.sh > # "create configdocs design", "create configdocs secrets", "commit > configdocs" have succeeded previously via "./airship-in-a-bottle.sh -y" > script; only deploy_site` dropped an error ./run_shipyard.sh create action > deploy_site > > -- Roman Gorshunov > > On Fri, Mar 8, 2019 at 4:28 PM Roman Gorshunov wrote: > > > > Hello team, > > I'm working on getting maas-ingress working again. This patch set [0] > > I believe solves this specific problem when applied onto a current > > master [1]. Try to apply it from inside of cloned airship-in-a-bottle > > repository by running commands under Download -> Checkout menu in the > > right corner [2]. For me it passes trough maas initialization and helm > > tests. > > > > [0] > > https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack. > > org_-23_c_629950_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=lg0Gw5OaH7fHGAPx > > U-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6hrI4hb9rm_Ue6DOyw&s=aq1NLATcaayJV5- > > n6sxm3ZNx1R8TPX-MThCBUMotjFE&e= [1] > > 539f777c637ffd1927659469072ec6235188b247 > > [2] git fetch > > https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openstack.org > > _openstack_airship-2Din-2Da-2Dbottle&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg > > &r=lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6hrI4hb9rm_Ue6DOy > > w&s=BzldpD9DgSWJ5DhOMkcTTYRuuXt0XYCQcV1MmTZAJos&e= > > refs/changes/50/629950/3 && git checkout FETCH_HEAD > > > > -- Roman Gorshunov > > > > On Thu, Mar 7, 2019 at 10:17 AM Loic Le Gal > wrote: > > > > > > Thanks Matt for the feedback, > > > > > > I'd like to help as I can but as I'm noob to Airship it won't be easy > at the beginning. > > > My aim (as many of firstcomers) is to try to get a functionning > Airship demo with k8s & Openstack setup + a little VM on top (clearwater > later :-)); all this installed on a big VM : That's AiaB! > > > Regarding Airskiff, I've already tryied it but as it is not AIO and > require setting-up and plugging all layers together, it might not be the > easiest staring point IMHO. > > > BTW, i'm close to have a Heat template to automate the building of > such a AiaB VM (and with proxy management), this will ease future tests > while waiting the Treasuremap's story you mentionned. > > > > > > Have you got a commit ID that is secured (like a stable one)? even if > we don't have latest features/fixes. > > > > > > BR, > > > > > > Loïc > > > > > > Le mer. 6 mars 2019 à 22:16, MCEUEN, MATT a écrit : > > >> > > >> Hi Loïc & Dimitrios, > > >> > > >> > > >> > > >> Shoot, sorry you guys hit this. This looks like the > Airship-in-a-Bottle single node dev site may have gotten stale. We have a > few different sets of YAMLs that should be aligned to one another to keep > this from happening; I’ve captured the issue and proposed resolution in > this story[1]. If you’d like to help with this it would be very much > appreciated :-), and if anyone has some time to get the AiaB single-node > dev site definition trued up in the meantime that would be valuable too. > > >> > > >> > > >> > > >> For a MaaS-free dev deployment, I suggest looking at the Airskiff [2] > deployment scripts. These deploy the software provisioning components (no > MaaS, Drydock, Promenade) in a bring-your-own-k8s setup. Dwalt has a > patchset in progress to align these site manifests fully to the treasuremap > reference globals, per the story. > > >> > > >> > > >> > > >> [1]: > > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__storyboard.ope > > >> nstack.org_-23-21_story_2005123&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r > > >> =lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6hrI4hb9rm_Ue6DO > > >> yw&s=5rVJvyhZ78s-u8qRHgQdsfFmRFj62XcwGlk7jRh5S2U&e= > > >> > > >> [2]: > > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__airship-2Dtrea > > >> suremap.readthedocs.io_en_latest_airskiff.html&d=DwIGaQ&c=LFYZ-o9_H > > >> UMeMTSQicvjIg&r=lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6 > > >> hrI4hb9rm_Ue6DOyw&s=umXc-T-9hR-ACN4zqjXn7xm2iO8_r3oBui0v42Af21w&e= > > >> > > >> > > >> > > >> Thanks, > > >> > > >> Matt > > >> > > >> > > >> > > >> From: Loic Le Gal > > >> Sent: Wednesday, March 6, 2019 9:49 AM > > >> To: airship-discuss at lists.airshipit.org > > >> Subject: Re: [Airship-discuss] > > >> Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingre > > >> ss_Error > > >> > > >> > > >> > > >> Hi Airshipers, > > >> > > >> > > >> > > >> Same issue for me, going back to previous commit > (ad53fbf5c312929e8d0873e5095c5a0d1dcdd7f5), but another problem arise with > maas-import-resources. I will open new thread if can't fix. > > >> > > >> Why is maas required even for AiaB as we don't have any baremetal > involved ?? > > >> > > >> > > >> > > >> BR, > > >> > > >> > > >> > > >> Loïc > > > > > > _______________________________________________ > > > Airship-discuss mailing list > > > Airship-discuss at lists.airshipit.org > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.airshipit. > > > org_cgi-2Dbin_mailman_listinfo_airship-2Ddiscuss&d=DwIGaQ&c=LFYZ-o9_ > > > HUMeMTSQicvjIg&r=lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6 > > > hrI4hb9rm_Ue6DOyw&s=pRUR3rU5WUpenI8XAdqiZRT6DLc6Jsnh_RACCWDYbEs&e= > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.airshipit.org_cgi-2Dbin_mailman_listinfo_airship-2Ddiscuss&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=lg0Gw5OaH7fHGAPxU-Bffg&m=8wngGZfwVs4IIaJiQ7aLYRDgG6hrI4hb9rm_Ue6DOyw&s=pRUR3rU5WUpenI8XAdqiZRT6DLc6Jsnh_RACCWDYbEs&e= > -------------- next part -------------- An HTML attachment was scrubbed... URL: From MM9745 at att.com Mon Mar 11 17:22:18 2019 From: MM9745 at att.com (MCEUEN, MATT) Date: Mon, 11 Mar 2019 17:22:18 +0000 Subject: [Airship-discuss] new Airship IRC meeting time starting 3/12 Message-ID: <7C64A75C21BB8D43BD75BB18635E4D896D28D11F@MOSTLS1MSGUSRFF.ITServices.sbc.com> All, as noted in this PS[1], team meeting, and in the ML, we are shifting our weekly team meeting in IRC slightly to Tuesdays at 16:00 UTC. This will take effect tomorrow, 3/12. For those subject to daylight savings time, don't forget that just kicked in for many of us - e.g. for me, the meeting will now be a 11am CDT. Look forward to seeing you there! Thanks, Matt [1]: https://review.openstack.org/#/c/640359/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nchase at mirantis.com Tue Mar 12 03:59:30 2019 From: nchase at mirantis.com (Nick Chase) Date: Mon, 11 Mar 2019 23:59:30 -0400 Subject: [Airship-discuss] Error installing Airship In A Bottle Message-ID: I'm trying to install AIB on a Unbutu Virtualbox VM with 48GB of RAM, 4 CPU and a 300GB hard drive. Everything seems to go along fine, until we get here: Digest: sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db Status: Downloaded newer image for gcr.io/google_containers/hyperkube-amd64:v1.10.2 Unable to connect to the server: EOF .Unable to connect to the server: net/http: request canceled (Client.Timeout exceeded while awaiting headers) >From there, it just keeps giving these two errors. Any thoughts? Thanks... ---- Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From rp2723 at att.com Tue Mar 12 18:05:41 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Tue, 12 Mar 2019 18:05:41 +0000 Subject: [Airship-discuss] Discuss target state implementation of Docker/Kernel/Os/Security Patches etc Message-ID: <99088997CCAD0C4BA20008FD09434496327901B2@MISOUT7MSGUSRDI.ITServices.sbc.com> When: Tuesday, March 12, 2019 1:00 PM-2:00 PM. (UTC-05:00) Eastern Time (US & Canada) Where: https://attcorp.webex.com/join/rp2723 *~*~*~*~*~*~*~*~*~* Discuss target state implementation of Airship Docker/Kubelet/Kernel/OS etc upgrade Etherpad of the ongoing discussion * https://etherpad.openstack.org/p/Airship_NodeControlledDeployment -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1827 bytes Desc: not available URL: From chris at openstack.org Wed Mar 13 06:55:49 2019 From: chris at openstack.org (Chris Hoge) Date: Tue, 12 Mar 2019 23:55:49 -0700 Subject: [Airship-discuss] OSF/Airship Governance and Release Planning Meetings Message-ID: The Airship team and OpenStack Foundation have started weekly meetings to help coordinate the release and governance efforts of the Airship project. These meetings, held Fridays at 17:00 UTC/12:00 CDT, are open to the community. We invite you to join us to engage in these, and other topics related to the Airship project. Agenda and connection details in the linked etherpad. https://etherpad.openstack.org/p/2019_Airship_OSF_sync Thanks! Chris Hoge Strategic Program Manager OpenStack Foundation -------------- next part -------------- A non-text attachment was scrubbed... Name: Airship-OSF.ics Type: text/calendar Size: 2827 bytes Desc: not available URL: From paye600 at gmail.com Wed Mar 13 14:29:09 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Wed, 13 Mar 2019 15:29:09 +0100 Subject: [Airship-discuss] Discuss target state implementation of Docker/Kernel/Os/Security Patches etc In-Reply-To: <99088997CCAD0C4BA20008FD09434496327901B2@MISOUT7MSGUSRDI.ITServices.sbc.com> References: <99088997CCAD0C4BA20008FD09434496327901B2@MISOUT7MSGUSRDI.ITServices.sbc.com> Message-ID: Hello Rodolfo,Where could we see a list of recorded sessions of this and other design calls, if any?If not yet being done, it would be nice to get calls recorded and a list of recordings to be published somewhere, so that people from other time zones could be kept informed.Thank you!Best regards,-- Roman Gorshunov On Tue, Mar 12, 2019 at 7:06 PM PACHECO, RODOLFO J wrote: > > When: Tuesday, March 12, 2019 1:00 PM-2:00 PM. (UTC-05:00) Eastern Time (US & Canada) > Where: https://attcorp.webex.com/join/rp2723 > > *~*~*~*~*~*~*~*~*~* > > Discuss target state implementation of Airship Docker/Kubelet/Kernel/OS etc upgrade > > > Etherpad of the ongoing discussion > > https://etherpad.openstack.org/p/Airship_NodeControlledDeployment > > > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss From rp2723 at att.com Wed Mar 13 15:30:39 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Wed, 13 Mar 2019 15:30:39 +0000 Subject: [Airship-discuss] Discuss target state implementation of Docker/Kernel/Os/Security Patches etc In-Reply-To: References: <99088997CCAD0C4BA20008FD09434496327901B2@MISOUT7MSGUSRDI.ITServices.sbc.com> Message-ID: <22986BBD-3FB3-489B-ACD7-6CEA6CBA5B52@att.com> Roman Recording links of Airship Design calls are pasted into the Etherpad at https://etherpad.openstack.org/p/Airship_OpenDesignDiscussions Regards Rodolfo Pacheco Home/Office 732 5337671 On 3/13/19, 10:29 AM, "Roman Gorshunov" wrote: Hello Rodolfo,Where could we see a list of recorded sessions of this and other design calls, if any?If not yet being done, it would be nice to get calls recorded and a list of recordings to be published somewhere, so that people from other time zones could be kept informed.Thank you!Best regards,-- Roman Gorshunov On Tue, Mar 12, 2019 at 7:06 PM PACHECO, RODOLFO J wrote: > > When: Tuesday, March 12, 2019 1:00 PM-2:00 PM. (UTC-05:00) Eastern Time (US & Canada) > Where: https://urldefense.proofpoint.com/v2/url?u=https-3A__attcorp.webex.com_join_rp2723&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Bjzj_RciGLj21LnNXoD5dw&m=Y6aW7tiln-ST3i0aICd3TYmd10DIVsNc_BRtxTvyVAg&s=l0vu-vk_ytj1fOqfIqxOPsNIJ9rpHHiCQTG2mBMenPY&e= > > *~*~*~*~*~*~*~*~*~* > > Discuss target state implementation of Airship Docker/Kubelet/Kernel/OS etc upgrade > > > Etherpad of the ongoing discussion > > https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_Airship-5FNodeControlledDeployment&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Bjzj_RciGLj21LnNXoD5dw&m=Y6aW7tiln-ST3i0aICd3TYmd10DIVsNc_BRtxTvyVAg&s=rC08u6KUlOZ12AG3czjJmpNV6Z_0aMioK0uuHtD1KgI&e= > > > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.airshipit.org_cgi-2Dbin_mailman_listinfo_airship-2Ddiscuss&d=DwIBaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=Bjzj_RciGLj21LnNXoD5dw&m=Y6aW7tiln-ST3i0aICd3TYmd10DIVsNc_BRtxTvyVAg&s=PO8w-GgFEP7gPFIw-qZ4foOpqMWEGd7_Jqkt-08Erpg&e= From eli at mirantis.com Wed Mar 13 17:58:34 2019 From: eli at mirantis.com (Evgeny L) Date: Wed, 13 Mar 2019 10:58:34 -0700 Subject: [Airship-discuss] Error installing Airship In A Bottle In-Reply-To: References: Message-ID: Hi Nick, As far as I remember these errors are just retries that wait until Kubernetes is up and running, have you tried to wait a bit? If it still fails for you, can you please send us a complete log? You can use http://paste.openstack.org/ for that. Thanks! On Mon, Mar 11, 2019 at 8:59 PM Nick Chase wrote: > I'm trying to install AIB on a Unbutu Virtualbox VM with 48GB of RAM, 4 > CPU and a 300GB hard drive. Everything seems to go along fine, until we > get here: > > Digest: > sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db > Status: Downloaded newer image for > gcr.io/google_containers/hyperkube-amd64:v1.10.2 > Unable to connect to the server: EOF > .Unable to connect to the server: net/http: request canceled > (Client.Timeout exceeded while awaiting headers) > > From there, it just keeps giving these two errors. > > Any thoughts? > > Thanks... > > ---- Nick > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From paye600 at gmail.com Wed Mar 13 18:21:04 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Wed, 13 Mar 2019 19:21:04 +0100 Subject: [Airship-discuss] Discuss target state implementation of Docker/Kernel/Os/Security Patches etc In-Reply-To: <22986BBD-3FB3-489B-ACD7-6CEA6CBA5B52@att.com> References: <99088997CCAD0C4BA20008FD09434496327901B2@MISOUT7MSGUSRDI.ITServices.sbc.com> <22986BBD-3FB3-489B-ACD7-6CEA6CBA5B52@att.com> Message-ID: Thank you, Rodolfo! On Wed, Mar 13, 2019 at 4:30 PM PACHECO, RODOLFO J wrote: > Roman > > Recording links of Airship Design calls are pasted into the Etherpad at https://etherpad.openstack.org/p/Airship_OpenDesignDiscussions > > Regards > Rodolfo Pacheco From rp2723 at att.com Wed Mar 13 19:56:24 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Wed, 13 Mar 2019 19:56:24 +0000 Subject: [Airship-discuss] Discuss target state implementation of Docker/Kernel/Os/Security Patches etc In-Reply-To: <99088997CCAD0C4BA20008FD0943449632792FDA@MISOUT7MSGUSRDI.ITServices.sbc.com> References: <99088997CCAD0C4BA20008FD0943449632792FDA@MISOUT7MSGUSRDI.ITServices.sbc.com> Message-ID: <4C60E51D-763B-4298-97E2-B78E2387C0A7@att.com> When: Occurs every Tuesday from 1:00 PM to 2:00 PM effective 2/26/2019 until 3/29/2019. (UTC-05:00) Eastern Time (US & Canada) Where: https://attcorp.webex.com/join/rp2723 *~*~*~*~*~*~*~*~*~* Reducing to a single day Discuss target state implementation of Airship Docker/Kubelet/Kernel/OS etc upgrade I scheduled a series, will figure out when it’s appropriate What do we need to discuss ? The ability to manage the delivery of any update across groups of hosts in a declarative way. The ability to control disruption effects from those updates Next Meeting: Looking at the https://github.com/GoogleCloudPlatform/metacontroller approach and comparing against what we discussed today. Everyone (in Airship Community) is welcome to participate on this discussions. Approach Discussed on our 1st Meeting https://go.gliffy.com/go/publish/12934972 Sample CR’s .. apiVersion: airship/v1 kind: MultiNodeAction metadata: name: DoSomethingPerRack spec: # List of sets of nodes that theis applies to. Indicates the cadence. 1 set at a time failureSet: set1: rack: rack1 set2: rack: rack2 # - Indicate the Action(What are we doing) - # - Indicate effect Upgrade and Reboot, Reboot Only, .. intentions: - UpgradeDockerAction - UpgradeKubeletAction - RebootAction ## This is teh CR that a node agent consumes apiVersion: airship/v1 kind: NodeAction metadata: name: Set1 spec: setIndicator: rack: rack1 intentions: ListOFActions: - UpgradeDocker - UpgradeKubelet - Reboot ## This is the CR's for ACTIONS that the NodeAgent ingests as well apiVersion: airship/v1 kind: Action metadata: name: Reboot spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeDocker spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeKubelet spec: script ..... -------------- next part -------------- An HTML attachment was scrubbed... URL: From MM9745 at att.com Wed Mar 13 22:38:59 2019 From: MM9745 at att.com (MCEUEN, MATT) Date: Wed, 13 Mar 2019 22:38:59 +0000 Subject: [Airship-discuss] Error installing Airship In A Bottle In-Reply-To: References: Message-ID: <7C64A75C21BB8D43BD75BB18635E4D896D2BA968@MOSTLS1MSGUSRFF.ITServices.sbc.com> Agree, and I’d add to check the docker logs of the kube apiserver to make sure it’s starting up healthy. If you’re not seeing a smoking gun, can you do a `docker ps -a` and pastebin the results? Thanks, Matt From: Evgeny L Sent: Wednesday, March 13, 2019 12:59 PM To: Nick Chase Cc: airship-discuss at lists.airshipit.org Subject: Re: [Airship-discuss] Error installing Airship In A Bottle Hi Nick, As far as I remember these errors are just retries that wait until Kubernetes is up and running, have you tried to wait a bit? If it still fails for you, can you please send us a complete log? You can use http://paste.openstack.org/ for that. Thanks! On Mon, Mar 11, 2019 at 8:59 PM Nick Chase > wrote: I'm trying to install AIB on a Unbutu Virtualbox VM with 48GB of RAM, 4 CPU and a 300GB hard drive. Everything seems to go along fine, until we get here: Digest: sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db Status: Downloaded newer image for gcr.io/google_containers/hyperkube-amd64:v1.10.2 Unable to connect to the server: EOF .Unable to connect to the server: net/http: request canceled (Client.Timeout exceeded while awaiting headers) From there, it just keeps giving these two errors. Any thoughts? Thanks... ---- Nick _______________________________________________ Airship-discuss mailing list Airship-discuss at lists.airshipit.org http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From nchase at mirantis.com Tue Mar 12 17:55:36 2019 From: nchase at mirantis.com (Nick Chase) Date: Tue, 12 Mar 2019 13:55:36 -0400 Subject: [Airship-discuss] Error installing Airship In A Bottle In-Reply-To: <7C64A75C21BB8D43BD75BB18635E4D896D2BA968@MOSTLS1MSGUSRFF.ITServices.sbc.com> References: <7C64A75C21BB8D43BD75BB18635E4D896D2BA968@MOSTLS1MSGUSRFF.ITServices.sbc.com> Message-ID: Will do! On Wed, Mar 13, 2019 at 6:39 PM MCEUEN, MATT wrote: > Agree, and I’d add to check the docker logs of the kube apiserver to make > sure it’s starting up healthy. > > > > If you’re not seeing a smoking gun, can you do a `docker ps -a` and > pastebin the results? > > > > Thanks, > > Matt > > > > *From:* Evgeny L > *Sent:* Wednesday, March 13, 2019 12:59 PM > *To:* Nick Chase > *Cc:* airship-discuss at lists.airshipit.org > *Subject:* Re: [Airship-discuss] Error installing Airship In A Bottle > > > > Hi Nick, > > > > As far as I remember these errors are just retries that wait until > Kubernetes is up and running, have you tried to wait a bit? > > If it still fails for you, can you please send us a complete log? You can > use http://paste.openstack.org/ > > for that. > > > > Thanks! > > > > On Mon, Mar 11, 2019 at 8:59 PM Nick Chase wrote: > > I'm trying to install AIB on a Unbutu Virtualbox VM with 48GB of RAM, 4 > CPU and a 300GB hard drive. Everything seems to go along fine, until we > get here: > > > > Digest: > sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db > Status: Downloaded newer image for > gcr.io/google_containers/hyperkube-amd64:v1.10.2 > > Unable to connect to the server: EOF > .Unable to connect to the server: net/http: request canceled > (Client.Timeout exceeded while awaiting headers) > > > > From there, it just keeps giving these two errors. > > > > Any thoughts? > > > > Thanks... > > > > ---- Nick > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nchase at mirantis.com Tue Mar 12 21:01:51 2019 From: nchase at mirantis.com (Nick Chase) Date: Tue, 12 Mar 2019 17:01:51 -0400 Subject: [Airship-discuss] Error installing Airship In A Bottle In-Reply-To: <7C64A75C21BB8D43BD75BB18635E4D896D2BA968@MOSTLS1MSGUSRFF.ITServices.sbc.com> References: <7C64A75C21BB8D43BD75BB18635E4D896D2BA968@MOSTLS1MSGUSRFF.ITServices.sbc.com> Message-ID: OK, so if it IS a timeout thing, if you can tell me how to increase it, I'll appreciate it, because the script finishes, it just finishes with an error. So the Airship script log is here: http://paste.openstack.org/show/747758/ Docker processes here: http://paste.openstack.org/show/747759/ Thanks.... ---- Nick On Wed, Mar 13, 2019 at 6:39 PM MCEUEN, MATT wrote: > Agree, and I’d add to check the docker logs of the kube apiserver to make > sure it’s starting up healthy. > > > > If you’re not seeing a smoking gun, can you do a `docker ps -a` and > pastebin the results? > > > > Thanks, > > Matt > > > > *From:* Evgeny L > *Sent:* Wednesday, March 13, 2019 12:59 PM > *To:* Nick Chase > *Cc:* airship-discuss at lists.airshipit.org > *Subject:* Re: [Airship-discuss] Error installing Airship In A Bottle > > > > Hi Nick, > > > > As far as I remember these errors are just retries that wait until > Kubernetes is up and running, have you tried to wait a bit? > > If it still fails for you, can you please send us a complete log? You can > use http://paste.openstack.org/ > > for that. > > > > Thanks! > > > > On Mon, Mar 11, 2019 at 8:59 PM Nick Chase wrote: > > I'm trying to install AIB on a Unbutu Virtualbox VM with 48GB of RAM, 4 > CPU and a 300GB hard drive. Everything seems to go along fine, until we > get here: > > > > Digest: > sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db > Status: Downloaded newer image for > gcr.io/google_containers/hyperkube-amd64:v1.10.2 > > Unable to connect to the server: EOF > .Unable to connect to the server: net/http: request canceled > (Client.Timeout exceeded while awaiting headers) > > > > From there, it just keeps giving these two errors. > > > > Any thoughts? > > > > Thanks... > > > > ---- Nick > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail2hemanth.n at gmail.com Thu Mar 14 02:56:11 2019 From: mail2hemanth.n at gmail.com (Hemanth N) Date: Thu, 14 Mar 2019 08:26:11 +0530 Subject: [Airship-discuss] Error installing Airship In A Bottle In-Reply-To: References: Message-ID: Hi Nick First thing i would do, is look for apiserver and etcd container errors Can you check the following as well 1. Verify if etcd service is up or not On VM, run netstat -ntulp | grep 2379 2. journalctl -u kubelet.service | grep "Invalid value" Look for errros, it might point out any pod spec issues Also please provide following information 3. cat /etc/kubernetes/manifests/kubernetes-etcd.yaml Check under volumes section if the names have any CAPITAL letters 4. hostname -s My hunch is you have hostname with a CAPS letter which is triggering this failure. Above commands should give an idea if that is the cause. If thats the case, change your hostname to all lowercase and then run airship-in-a-bottle. Regards, Hemanth > Message: 3 > Date: Tue, 12 Mar 2019 17:01:51 -0400 > From: Nick Chase > To: "MCEUEN, MATT" > Cc: Evgeny L , > "airship-discuss at lists.airshipit.org" > > Subject: Re: [Airship-discuss] Error installing Airship In A Bottle > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > OK, so if it IS a timeout thing, if you can tell me how to increase it, > I'll appreciate it, because the script finishes, it just finishes with an > error. > > So the Airship script log is here: http://paste.openstack.org/show/747758/ > Docker processes here: http://paste.openstack.org/show/747759/ > > Thanks.... > > ---- Nick > > > On Wed, Mar 13, 2019 at 6:39 PM MCEUEN, MATT wrote: > > > Agree, and I’d add to check the docker logs of the kube apiserver to make > > sure it’s starting up healthy. > > > > > > > > If you’re not seeing a smoking gun, can you do a `docker ps -a` and > > pastebin the results? > > > > > > > > Thanks, > > > > Matt > > > > > > > > *From:* Evgeny L > > *Sent:* Wednesday, March 13, 2019 12:59 PM > > *To:* Nick Chase > > *Cc:* airship-discuss at lists.airshipit.org > > *Subject:* Re: [Airship-discuss] Error installing Airship In A Bottle > > > > > > > > Hi Nick, > > > > > > > > As far as I remember these errors are just retries that wait until > > Kubernetes is up and running, have you tried to wait a bit? > > > > If it still fails for you, can you please send us a complete log? You can > > use http://paste.openstack.org/ > > > > for that. > > > > > > > > Thanks! > > > > > > > > On Mon, Mar 11, 2019 at 8:59 PM Nick Chase wrote: > > > > I'm trying to install AIB on a Unbutu Virtualbox VM with 48GB of RAM, 4 > > CPU and a 300GB hard drive. Everything seems to go along fine, until we > > get here: > > > > > > > > Digest: > > sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db > > Status: Downloaded newer image for > > gcr.io/google_containers/hyperkube-amd64:v1.10.2 > > > > Unable to connect to the server: EOF > > .Unable to connect to the server: net/http: request canceled > > (Client.Timeout exceeded while awaiting headers) > > > > > > > > From there, it just keeps giving these two errors. > > > > > > > > Any thoughts? > > > > > > > > Thanks... > > > > > > > > ---- Nick > > > > _______________________________________________ > > Airship-discuss mailing list > > Airship-discuss at lists.airshipit.org > > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss > > ------------------------------ > > End of Airship-discuss Digest, Vol 10, Issue 12 > *********************************************** From eli at mirantis.com Thu Mar 14 19:32:18 2019 From: eli at mirantis.com (Evgeny L) Date: Thu, 14 Mar 2019 12:32:18 -0700 Subject: [Airship-discuss] Error installing Airship In A Bottle In-Reply-To: References: <7C64A75C21BB8D43BD75BB18635E4D896D2BA968@MOSTLS1MSGUSRFF.ITServices.sbc.com> Message-ID: Hmm, looks like Airship script log got reduced due to paste.openstack.org limits, can you please share these logs over some cloud drive? (dropbox/gdrive/etc) Looking into "docker ps" output, it seems like there are some problems with apiserver startup, can you run "docker logs 184e3aeef62d" and send us the output? Thanks! On Wed, Mar 13, 2019 at 7:08 PM Nick Chase wrote: > OK, so if it IS a timeout thing, if you can tell me how to increase it, > I'll appreciate it, because the script finishes, it just finishes with an > error. > > So the Airship script log is here: > http://paste.openstack.org/show/747758/ > Docker processes here: http://paste.openstack.org/show/747759/ > > Thanks.... > > ---- Nick > > > On Wed, Mar 13, 2019 at 6:39 PM MCEUEN, MATT wrote: > >> Agree, and I’d add to check the docker logs of the kube apiserver to make >> sure it’s starting up healthy. >> >> >> >> If you’re not seeing a smoking gun, can you do a `docker ps -a` and >> pastebin the results? >> >> >> >> Thanks, >> >> Matt >> >> >> >> *From:* Evgeny L >> *Sent:* Wednesday, March 13, 2019 12:59 PM >> *To:* Nick Chase >> *Cc:* airship-discuss at lists.airshipit.org >> *Subject:* Re: [Airship-discuss] Error installing Airship In A Bottle >> >> >> >> Hi Nick, >> >> >> >> As far as I remember these errors are just retries that wait until >> Kubernetes is up and running, have you tried to wait a bit? >> >> If it still fails for you, can you please send us a complete log? You can >> use http://paste.openstack.org/ >> >> for that. >> >> >> >> Thanks! >> >> >> >> On Mon, Mar 11, 2019 at 8:59 PM Nick Chase wrote: >> >> I'm trying to install AIB on a Unbutu Virtualbox VM with 48GB of RAM, 4 >> CPU and a 300GB hard drive. Everything seems to go along fine, until we >> get here: >> >> >> >> Digest: >> sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db >> Status: Downloaded newer image for >> gcr.io/google_containers/hyperkube-amd64:v1.10.2 >> >> Unable to connect to the server: EOF >> .Unable to connect to the server: net/http: request canceled >> (Client.Timeout exceeded while awaiting headers) >> >> >> >> From there, it just keeps giving these two errors. >> >> >> >> Any thoughts? >> >> >> >> Thanks... >> >> >> >> ---- Nick >> >> _______________________________________________ >> Airship-discuss mailing list >> Airship-discuss at lists.airshipit.org >> http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.legal.astellia at gmail.com Fri Mar 15 16:25:32 2019 From: l.legal.astellia at gmail.com (Loic Le Gal) Date: Fri, 15 Mar 2019 17:25:32 +0100 Subject: [Airship-discuss] Airship-In-A-Bottle_Dev-Single-Node_No-Proxy-Environment_Mass-Ingress_Error In-Reply-To: References: <7C64A75C21BB8D43BD75BB18635E4D896D25AA6E@MOSTLS1MSGUSRFF.ITServices.sbc.com> <651A1B0DF16CC24CBBA3ABFDB19EE69E4ECE74EB@MOSTLS1MSGUSRFA.ITServices.sbc.com> Message-ID: > > > Hi everyone, > > Sorry to bother you with this again... I still have a remaining problem to > run airship-in-a-bottle (either dev_single_node or dev_minimal sites: I > target the 1st). > Even going back to previous commits failed: > - some lead to rabbitmq container error > (a9f5fc93e33163f51fc56d1bf886d4d433251f8e) : fixed also by moving from 3.7 > to 3.7.4 (found in later commits) but lead to maas-ingress then mass-import > pb > - maas_ingress error also has been encountered > (539f777c637ffd1927659469072ec6235188b247) patchset 629950 fix this, but I > got stuck to "maas-import-resources' error (previously mentioned in this > thread) > - latest also lead me to this "maas-import-resources error" > In fact 'maas admin boot-resources read' seems to fail a be the root cause > of my problems > > The whole output of kubectl logs of the faulty pod can be found here: > https://drive.google.com/open?id=1smgmynynkUcdtLGw72nbtEXNwXjIW2HH > > Otherwise, as a B plan if I use Airskiff can this fix this problem?and > what will be the next steps to reach the same level than Aiab (ie. K8s + > Openstack running on the same host :a VM) or maybe different VMs will be > required : Build, Genesis and Control + Dataplane? > > Thanks in advance. > BR, > Loïc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nchase at mirantis.com Tue Mar 12 23:51:59 2019 From: nchase at mirantis.com (Nick Chase) Date: Tue, 12 Mar 2019 19:51:59 -0400 Subject: [Airship-discuss] Error installing Airship In A Bottle In-Reply-To: References: <7C64A75C21BB8D43BD75BB18635E4D896D2BA968@MOSTLS1MSGUSRFF.ITServices.sbc.com> Message-ID: OK, so the full log is here: https://drive.google.com/file/d/1UVlm9dq3jQAW87Rj44eL0Iyl8bOtxWjS/view?usp=sharing As for docker logs 184e3aeef62d, # docker logs 184e3aeef62d Error: No such container: 184e3aeef62d which makes sense because it had already exited, and I assume it's been cleaned up by now. I'll try running it again. if that will be helpful. Thanks! ----- Nick On Thu, Mar 14, 2019 at 3:32 PM Evgeny L wrote: > Hmm, looks like Airship script log got reduced due to paste.openstack.org > limits, can you please share these logs over some cloud drive? > (dropbox/gdrive/etc) > Looking into "docker ps" output, it seems like there are some problems > with apiserver startup, can you run "docker logs 184e3aeef62d" and send us > the output? > > Thanks! > > On Wed, Mar 13, 2019 at 7:08 PM Nick Chase wrote: > >> OK, so if it IS a timeout thing, if you can tell me how to increase it, >> I'll appreciate it, because the script finishes, it just finishes with an >> error. >> >> So the Airship script log is here: >> http://paste.openstack.org/show/747758/ >> Docker processes here: http://paste.openstack.org/show/747759/ >> >> Thanks.... >> >> ---- Nick >> >> >> On Wed, Mar 13, 2019 at 6:39 PM MCEUEN, MATT wrote: >> >>> Agree, and I’d add to check the docker logs of the kube apiserver to >>> make sure it’s starting up healthy. >>> >>> >>> >>> If you’re not seeing a smoking gun, can you do a `docker ps -a` and >>> pastebin the results? >>> >>> >>> >>> Thanks, >>> >>> Matt >>> >>> >>> >>> *From:* Evgeny L >>> *Sent:* Wednesday, March 13, 2019 12:59 PM >>> *To:* Nick Chase >>> *Cc:* airship-discuss at lists.airshipit.org >>> *Subject:* Re: [Airship-discuss] Error installing Airship In A Bottle >>> >>> >>> >>> Hi Nick, >>> >>> >>> >>> As far as I remember these errors are just retries that wait until >>> Kubernetes is up and running, have you tried to wait a bit? >>> >>> If it still fails for you, can you please send us a complete log? You >>> can use http://paste.openstack.org/ >>> >>> for that. >>> >>> >>> >>> Thanks! >>> >>> >>> >>> On Mon, Mar 11, 2019 at 8:59 PM Nick Chase wrote: >>> >>> I'm trying to install AIB on a Unbutu Virtualbox VM with 48GB of RAM, 4 >>> CPU and a 300GB hard drive. Everything seems to go along fine, until we >>> get here: >>> >>> >>> >>> Digest: >>> sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db >>> Status: Downloaded newer image for >>> gcr.io/google_containers/hyperkube-amd64:v1.10.2 >>> >>> Unable to connect to the server: EOF >>> .Unable to connect to the server: net/http: request canceled >>> (Client.Timeout exceeded while awaiting headers) >>> >>> >>> >>> From there, it just keeps giving these two errors. >>> >>> >>> >>> Any thoughts? >>> >>> >>> >>> Thanks... >>> >>> >>> >>> ---- Nick >>> >>> _______________________________________________ >>> Airship-discuss mailing list >>> Airship-discuss at lists.airshipit.org >>> http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nchase at mirantis.com Sun Mar 17 17:45:34 2019 From: nchase at mirantis.com (Nick Chase) Date: Sun, 17 Mar 2019 13:45:34 -0400 Subject: [Airship-discuss] Error installing Airship In A Bottle In-Reply-To: References: Message-ID: Very nice! Capital letters was indeed the problem -- or at least, THAT problem. I created a new VM without them and started again, getting past that point. However, I'm now stuck with CrashLoopBack on the coredns pods. I've been trying to grab logs without success. However, I am seeing this: 2019-03-17 17:31:29.142 3396 INFO armada.handlers.armada [-] Processing ChartGroup: kubernetes-proxy (Kubernetes proxy), sequenced=True 2019-03-17 17:31:29.143 3396 INFO armada.handlers.chart_deploy [-] [chart=proxy]: Processing Chart, release=airship-kubernetes-proxy 2019-03-17 17:31:29.145 3396 INFO armada.handlers.chartbuilder [-] [chart=proxy]: Building dependency chart kubernetes-proxy-htk for release kubernetes-proxy. 2019-03-17 17:31:29.196 3396 INFO armada.handlers.chart_deploy [-] [chart=proxy]: Existing release airship-kubernetes-proxy found in namespace kube-system 2019-03-17 17:31:29.200 3396 INFO armada.handlers.chart_deploy [-] [chart=proxy]: Checking for updates to chart release inputs. 2019-03-17 17:31:29.238 3396 INFO armada.handlers.chart_deploy [-] [chart=proxy]: Found no updates to chart release inputs 2019-03-17 17:31:29.239 3396 INFO armada.handlers.wait [-] [chart=proxy]: Waiting for resource type=job, namespace=kube-system labels=release_group=airship-kubernetes-proxy for 600s (k8s wait 1 times, sleep 1s) 2019-03-17 17:31:29.279 3396 INFO armada.handlers.wait [-] [chart=proxy]: Waiting for resource type=pod, namespace=kube-system labels=release_group=airship-kubernetes-proxy for 600s (k8s wait 1 times, sleep 1s) 2019-03-17 17:31:29.297 3396 INFO armada.handlers.armada [-] All Charts applied in ChartGroup kubernetes-proxy. 2019-03-17 17:31:29.298 3396 INFO armada.handlers.armada [-] Processing ChartGroup: kubernetes-container-networking (Container networking via Calico), sequenced=True 2019-03-17 17:31:29.298 3396 INFO armada.handlers.chart_deploy [-] [chart=etcd]: Processing Chart, release=airship-kubernetes-calico-etcd 2019-03-17 17:31:29.298 3396 INFO armada.handlers.chartbuilder [-] [chart=etcd]: Building dependency chart kubernetes-calico-etcd-htk for release kubernetes-calico-etcd. 2019-03-17 17:31:29.312 3396 INFO armada.handlers.chart_deploy [-] [chart=etcd]: Existing release airship-kubernetes-calico-etcd found in namespace kube-system 2019-03-17 17:31:29.347 3396 INFO armada.handlers.chart_deploy [-] [chart=etcd]: Checking for updates to chart release inputs. 2019-03-17 17:31:29.421 3396 INFO armada.handlers.chart_deploy [-] [chart=etcd]: Found no updates to chart release inputs 2019-03-17 17:31:29.422 3396 INFO armada.handlers.wait [-] [chart=etcd]: Waiting for resource type=job, namespace=kube-system labels=release_group=airship-kubernetes-calico-etcd for 600s (k8s wait 1 times, sleep 1s) 2019-03-17 17:31:29.425 3396 INFO armada.handlers.wait [-] [chart=etcd]: Waiting for resource type=pod, namespace=kube-system labels=release_group=airship-kubernetes-calico-etcd for 600s (k8s wait 1 times, sleep 1s) 2019-03-17 17:31:29.432 3396 INFO armada.handlers.chart_deploy [-] [chart=calico]: Processing Chart, release=airship-kubernetes-calico 2019-03-17 17:31:29.432 3396 INFO armada.handlers.chartbuilder [-] [chart=calico]: Building dependency chart calico-htk for release kubernetes-calico. 2019-03-17 17:31:29.456 3396 INFO armada.handlers.chart_deploy [-] [chart=calico]: Existing release airship-kubernetes-calico found in namespace kube-system 2019-03-17 17:31:29.498 3396 INFO armada.handlers.chart_deploy [-] [chart=calico]: Checking for updates to chart release inputs. 2019-03-17 17:31:29.642 3396 INFO armada.handlers.chart_deploy [-] [chart=calico]: Found no updates to chart release inputs 2019-03-17 17:31:29.642 3396 INFO armada.handlers.wait [-] [chart=calico]: Waiting for resource type=job, namespace=kube-system labels=release_group=airship-kubernetes-calico for 600s (k8s wait 1 times, sleep 1s) 2019-03-17 17:31:29.648 3396 INFO armada.handlers.wait [-] [chart=calico]: Waiting for resource type=pod, namespace=kube-system labels=release_group=airship-kubernetes-calico for 600s (k8s wait 1 times, sleep 1s) 2019-03-17 17:31:29.667 3396 INFO armada.handlers.armada [-] All Charts applied in ChartGroup kubernetes-container-networking. 2019-03-17 17:31:29.667 3396 INFO armada.handlers.armada [-] Processing ChartGroup: kubernetes-dns (Cluster DNS), sequenced=False 2019-03-17 17:31:29.668 3396 INFO armada.handlers.chart_deploy [-] [chart=coredns]: Processing Chart, release=airship-coredns 2019-03-17 17:31:29.668 3396 INFO armada.handlers.chartbuilder [-] [chart=coredns]: Building dependency chart coredns-htk for release coredns. 2019-03-17 17:31:29.685 3396 INFO armada.handlers.chart_deploy [-] [chart=coredns]: Purging FAILED release airship-coredns before deployment. 2019-03-17 17:31:29.685 3396 INFO armada.handlers.tiller [-] [chart=coredns]: Uninstall airship-coredns release with disable_hooks=False, purge=True flags 2019-03-17 17:31:31.016 3396 INFO armada.handlers.chart_deploy [-] [chart=coredns]: Installing release airship-coredns in namespace kube-system, wait=True, timeout=599s 2019-03-17 17:31:31.018 3396 INFO armada.handlers.tiller [-] [chart=coredns]: Helm install release: wait=True, timeout=599 Any thoughts? ---- Nick On Wed, Mar 13, 2019 at 10:56 PM Hemanth N wrote: > Hi Nick > > First thing i would do, is look for apiserver and etcd container errors > > Can you check the following as well > > 1. Verify if etcd service is up or not > On VM, run netstat -ntulp | grep 2379 > > 2. journalctl -u kubelet.service | grep "Invalid value" > Look for errros, it might point out any pod spec issues > > Also please provide following information > 3. cat /etc/kubernetes/manifests/kubernetes-etcd.yaml > Check under volumes section if the names have any CAPITAL letters > > 4. hostname -s > > My hunch is you have hostname with a CAPS letter which is triggering > this failure. Above commands should give an idea if that is the cause. > If thats the case, change your hostname to all lowercase and then run > airship-in-a-bottle. > > Regards, > Hemanth > > > > > > > > Message: 3 > > Date: Tue, 12 Mar 2019 17:01:51 -0400 > > From: Nick Chase > > To: "MCEUEN, MATT" > > Cc: Evgeny L , > > "airship-discuss at lists.airshipit.org" > > > > Subject: Re: [Airship-discuss] Error installing Airship In A Bottle > > Message-ID: > > 55CxMPnC7bytG+RSg4w at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > OK, so if it IS a timeout thing, if you can tell me how to increase it, > > I'll appreciate it, because the script finishes, it just finishes with an > > error. > > > > So the Airship script log is here: > http://paste.openstack.org/show/747758/ > > Docker processes here: http://paste.openstack.org/show/747759/ > > > > Thanks.... > > > > ---- Nick > > > > > > On Wed, Mar 13, 2019 at 6:39 PM MCEUEN, MATT wrote: > > > > > Agree, and I’d add to check the docker logs of the kube apiserver to > make > > > sure it’s starting up healthy. > > > > > > > > > > > > If you’re not seeing a smoking gun, can you do a `docker ps -a` and > > > pastebin the results? > > > > > > > > > > > > Thanks, > > > > > > Matt > > > > > > > > > > > > *From:* Evgeny L > > > *Sent:* Wednesday, March 13, 2019 12:59 PM > > > *To:* Nick Chase > > > *Cc:* airship-discuss at lists.airshipit.org > > > *Subject:* Re: [Airship-discuss] Error installing Airship In A Bottle > > > > > > > > > > > > Hi Nick, > > > > > > > > > > > > As far as I remember these errors are just retries that wait until > > > Kubernetes is up and running, have you tried to wait a bit? > > > > > > If it still fails for you, can you please send us a complete log? You > can > > > use http://paste.openstack.org/ > > > < > https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.openstack.org_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=WhNp-VjTw70e2z_QbunOZc8fyS-zMWVbK70DnNjJMS0&s=8BzvCwZPVXNqnW1cYOCO0Av7scqQCiZlumjUr7A2dk8&e= > > > > > for that. > > > > > > > > > > > > Thanks! > > > > > > > > > > > > On Mon, Mar 11, 2019 at 8:59 PM Nick Chase > wrote: > > > > > > I'm trying to install AIB on a Unbutu Virtualbox VM with 48GB of RAM, 4 > > > CPU and a 300GB hard drive. Everything seems to go along fine, until > we > > > get here: > > > > > > > > > > > > Digest: > > > sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db > > > Status: Downloaded newer image for > > > gcr.io/google_containers/hyperkube-amd64:v1.10.2 > > > < > https://urldefense.proofpoint.com/v2/url?u=http-3A__gcr.io_google-5Fcontainers_hyperkube-2Damd64-3Av1.10.2&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=WhNp-VjTw70e2z_QbunOZc8fyS-zMWVbK70DnNjJMS0&s=RON0xE-JpIMxDTL_Ja4E7LJK_asUyNLjZiaJmHyci3M&e= > > > > > Unable to connect to the server: EOF > > > .Unable to connect to the server: net/http: request canceled > > > (Client.Timeout exceeded while awaiting headers) > > > > > > > > > > > > From there, it just keeps giving these two errors. > > > > > > > > > > > > Any thoughts? > > > > > > > > > > > > Thanks... > > > > > > > > > > > > ---- Nick > > > > > > _______________________________________________ > > > Airship-discuss mailing list > > > Airship-discuss at lists.airshipit.org > > > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss > > > < > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.airshipit.org_cgi-2Dbin_mailman_listinfo_airship-2Ddiscuss&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=WhNp-VjTw70e2z_QbunOZc8fyS-zMWVbK70DnNjJMS0&s=nBDu-ohIh1kHRZSZCF0aSC5mIryxhGUOu9y-I8hj7dc&e= > > > > > > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > http://lists.airshipit.org/pipermail/airship-discuss/attachments/20190312/5c30236d/attachment.html > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > Airship-discuss mailing list > > Airship-discuss at lists.airshipit.org > > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss > > > > ------------------------------ > > > > End of Airship-discuss Digest, Vol 10, Issue 12 > > *********************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.legal.astellia at gmail.com Mon Mar 18 08:54:21 2019 From: l.legal.astellia at gmail.com (Loic Le Gal) Date: Mon, 18 Mar 2019 09:54:21 +0100 Subject: [Airship-discuss] Error installing Airship In A Bottle In-Reply-To: References: Message-ID: Hi Nick, I think I face a similar problem in my first attempts to install AiaB (I'm a bit further but also stuck too). Note that I'm behind a proxy and that some filters are activated by our IT so I need to replace the default google nameservers. I fix this by adding 2 dns nameservers in /etc/resolv.conf and in the 'common-addresses.yaml' file: echo "nameserver __dns1__" >>/etc/resolv.conf echo "nameserver __dns2__" >>/etc/resolv.conf export common_adr_file=/root/deploy/airship-in-a-bottle/deployment_files/site/demo/networks/common-addresses.yaml sed -i 's/8.8.8.8/__dns1__/g' $common_adr_file sed -i 's/8.8.4.4/__dns2__/g' $common_adr_file Hope it helps, BR, Loïc Le dim. 17 mars 2019 à 18:46, Nick Chase a écrit : > Very nice! Capital letters was indeed the problem -- or at least, THAT > problem. I created a new VM without them and started again, getting past > that point. However, I'm now stuck with CrashLoopBack on the coredns > pods. I've been trying to grab logs without success. However, I am seeing > this: > > 2019-03-17 17:31:29.142 3396 INFO armada.handlers.armada [-] Processing > ChartGroup: kubernetes-proxy (Kubernetes proxy), sequenced=True > 2019-03-17 17:31:29.143 3396 INFO armada.handlers.chart_deploy [-] > [chart=proxy]: Processing Chart, release=airship-kubernetes-proxy > 2019-03-17 17:31:29.145 3396 INFO armada.handlers.chartbuilder [-] > [chart=proxy]: Building dependency chart kubernetes-proxy-htk for release > kubernetes-proxy. > 2019-03-17 17:31:29.196 3396 INFO armada.handlers.chart_deploy [-] > [chart=proxy]: Existing release airship-kubernetes-proxy found in namespace > kube-system > 2019-03-17 17:31:29.200 3396 INFO armada.handlers.chart_deploy [-] > [chart=proxy]: Checking for updates to chart release inputs. > 2019-03-17 17:31:29.238 3396 INFO armada.handlers.chart_deploy [-] > [chart=proxy]: Found no updates to chart release inputs > 2019-03-17 17:31:29.239 3396 INFO armada.handlers.wait [-] [chart=proxy]: > Waiting for resource type=job, namespace=kube-system > labels=release_group=airship-kubernetes-proxy for 600s (k8s wait 1 times, > sleep 1s) > 2019-03-17 17:31:29.279 3396 INFO armada.handlers.wait [-] [chart=proxy]: > Waiting for resource type=pod, namespace=kube-system > labels=release_group=airship-kubernetes-proxy for 600s (k8s wait 1 times, > sleep 1s) > 2019-03-17 17:31:29.297 3396 INFO armada.handlers.armada [-] All Charts > applied in ChartGroup kubernetes-proxy. > 2019-03-17 17:31:29.298 3396 INFO armada.handlers.armada [-] Processing > ChartGroup: kubernetes-container-networking (Container networking via > Calico), sequenced=True > 2019-03-17 17:31:29.298 3396 INFO armada.handlers.chart_deploy [-] > [chart=etcd]: Processing Chart, release=airship-kubernetes-calico-etcd > 2019-03-17 17:31:29.298 3396 INFO armada.handlers.chartbuilder [-] > [chart=etcd]: Building dependency chart kubernetes-calico-etcd-htk for > release kubernetes-calico-etcd. > 2019-03-17 17:31:29.312 3396 INFO armada.handlers.chart_deploy [-] > [chart=etcd]: Existing release airship-kubernetes-calico-etcd found in > namespace kube-system > 2019-03-17 17:31:29.347 3396 INFO armada.handlers.chart_deploy [-] > [chart=etcd]: Checking for updates to chart release inputs. > 2019-03-17 17:31:29.421 3396 INFO armada.handlers.chart_deploy [-] > [chart=etcd]: Found no updates to chart release inputs > 2019-03-17 17:31:29.422 3396 INFO armada.handlers.wait [-] [chart=etcd]: > Waiting for resource type=job, namespace=kube-system > labels=release_group=airship-kubernetes-calico-etcd for 600s (k8s wait 1 > times, sleep 1s) > 2019-03-17 17:31:29.425 3396 INFO armada.handlers.wait [-] [chart=etcd]: > Waiting for resource type=pod, namespace=kube-system > labels=release_group=airship-kubernetes-calico-etcd for 600s (k8s wait 1 > times, sleep 1s) > 2019-03-17 17:31:29.432 3396 INFO armada.handlers.chart_deploy [-] > [chart=calico]: Processing Chart, release=airship-kubernetes-calico > 2019-03-17 17:31:29.432 3396 INFO armada.handlers.chartbuilder [-] > [chart=calico]: Building dependency chart calico-htk for release > kubernetes-calico. > 2019-03-17 17:31:29.456 3396 INFO armada.handlers.chart_deploy [-] > [chart=calico]: Existing release airship-kubernetes-calico found in > namespace kube-system > 2019-03-17 17:31:29.498 3396 INFO armada.handlers.chart_deploy [-] > [chart=calico]: Checking for updates to chart release inputs. > 2019-03-17 17:31:29.642 3396 INFO armada.handlers.chart_deploy [-] > [chart=calico]: Found no updates to chart release inputs > 2019-03-17 17:31:29.642 3396 INFO armada.handlers.wait [-] [chart=calico]: > Waiting for resource type=job, namespace=kube-system > labels=release_group=airship-kubernetes-calico for 600s (k8s wait 1 times, > sleep 1s) > 2019-03-17 17:31:29.648 3396 INFO armada.handlers.wait [-] [chart=calico]: > Waiting for resource type=pod, namespace=kube-system > labels=release_group=airship-kubernetes-calico for 600s (k8s wait 1 times, > sleep 1s) > 2019-03-17 17:31:29.667 3396 INFO armada.handlers.armada [-] All Charts > applied in ChartGroup kubernetes-container-networking. > 2019-03-17 17:31:29.667 3396 INFO armada.handlers.armada [-] Processing > ChartGroup: kubernetes-dns (Cluster DNS), sequenced=False > 2019-03-17 17:31:29.668 3396 INFO armada.handlers.chart_deploy [-] > [chart=coredns]: Processing Chart, release=airship-coredns > 2019-03-17 17:31:29.668 3396 INFO armada.handlers.chartbuilder [-] > [chart=coredns]: Building dependency chart coredns-htk for release coredns. > 2019-03-17 17:31:29.685 3396 INFO armada.handlers.chart_deploy [-] > [chart=coredns]: Purging FAILED release airship-coredns before deployment. > 2019-03-17 17:31:29.685 3396 INFO armada.handlers.tiller [-] > [chart=coredns]: Uninstall airship-coredns release with > disable_hooks=False, purge=True flags > 2019-03-17 17:31:31.016 3396 INFO armada.handlers.chart_deploy [-] > [chart=coredns]: Installing release airship-coredns in namespace > kube-system, wait=True, timeout=599s > 2019-03-17 17:31:31.018 3396 INFO armada.handlers.tiller [-] > [chart=coredns]: Helm install release: wait=True, timeout=599 > > Any thoughts? > > ---- Nick > > On Wed, Mar 13, 2019 at 10:56 PM Hemanth N > wrote: > >> Hi Nick >> >> First thing i would do, is look for apiserver and etcd container errors >> >> Can you check the following as well >> >> 1. Verify if etcd service is up or not >> On VM, run netstat -ntulp | grep 2379 >> >> 2. journalctl -u kubelet.service | grep "Invalid value" >> Look for errros, it might point out any pod spec issues >> >> Also please provide following information >> 3. cat /etc/kubernetes/manifests/kubernetes-etcd.yaml >> Check under volumes section if the names have any CAPITAL letters >> >> 4. hostname -s >> >> My hunch is you have hostname with a CAPS letter which is triggering >> this failure. Above commands should give an idea if that is the cause. >> If thats the case, change your hostname to all lowercase and then run >> airship-in-a-bottle. >> >> Regards, >> Hemanth >> >> >> >> >> >> >> > Message: 3 >> > Date: Tue, 12 Mar 2019 17:01:51 -0400 >> > From: Nick Chase >> > To: "MCEUEN, MATT" >> > Cc: Evgeny L , >> > "airship-discuss at lists.airshipit.org" >> > >> > Subject: Re: [Airship-discuss] Error installing Airship In A Bottle >> > Message-ID: >> > > 55CxMPnC7bytG+RSg4w at mail.gmail.com> >> > Content-Type: text/plain; charset="utf-8" >> > >> > OK, so if it IS a timeout thing, if you can tell me how to increase it, >> > I'll appreciate it, because the script finishes, it just finishes with >> an >> > error. >> > >> > So the Airship script log is here: >> http://paste.openstack.org/show/747758/ >> > Docker processes here: http://paste.openstack.org/show/747759/ >> > >> > Thanks.... >> > >> > ---- Nick >> > >> > >> > On Wed, Mar 13, 2019 at 6:39 PM MCEUEN, MATT wrote: >> > >> > > Agree, and I’d add to check the docker logs of the kube apiserver to >> make >> > > sure it’s starting up healthy. >> > > >> > > >> > > >> > > If you’re not seeing a smoking gun, can you do a `docker ps -a` and >> > > pastebin the results? >> > > >> > > >> > > >> > > Thanks, >> > > >> > > Matt >> > > >> > > >> > > >> > > *From:* Evgeny L >> > > *Sent:* Wednesday, March 13, 2019 12:59 PM >> > > *To:* Nick Chase >> > > *Cc:* airship-discuss at lists.airshipit.org >> > > *Subject:* Re: [Airship-discuss] Error installing Airship In A Bottle >> > > >> > > >> > > >> > > Hi Nick, >> > > >> > > >> > > >> > > As far as I remember these errors are just retries that wait until >> > > Kubernetes is up and running, have you tried to wait a bit? >> > > >> > > If it still fails for you, can you please send us a complete log? You >> can >> > > use http://paste.openstack.org/ >> > > < >> https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.openstack.org_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=WhNp-VjTw70e2z_QbunOZc8fyS-zMWVbK70DnNjJMS0&s=8BzvCwZPVXNqnW1cYOCO0Av7scqQCiZlumjUr7A2dk8&e= >> > >> > > for that. >> > > >> > > >> > > >> > > Thanks! >> > > >> > > >> > > >> > > On Mon, Mar 11, 2019 at 8:59 PM Nick Chase >> wrote: >> > > >> > > I'm trying to install AIB on a Unbutu Virtualbox VM with 48GB of RAM, >> 4 >> > > CPU and a 300GB hard drive. Everything seems to go along fine, until >> we >> > > get here: >> > > >> > > >> > > >> > > Digest: >> > > >> sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db >> > > Status: Downloaded newer image for >> > > gcr.io/google_containers/hyperkube-amd64:v1.10.2 >> > > < >> https://urldefense.proofpoint.com/v2/url?u=http-3A__gcr.io_google-5Fcontainers_hyperkube-2Damd64-3Av1.10.2&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=WhNp-VjTw70e2z_QbunOZc8fyS-zMWVbK70DnNjJMS0&s=RON0xE-JpIMxDTL_Ja4E7LJK_asUyNLjZiaJmHyci3M&e= >> > >> > > Unable to connect to the server: EOF >> > > .Unable to connect to the server: net/http: request canceled >> > > (Client.Timeout exceeded while awaiting headers) >> > > >> > > >> > > >> > > From there, it just keeps giving these two errors. >> > > >> > > >> > > >> > > Any thoughts? >> > > >> > > >> > > >> > > Thanks... >> > > >> > > >> > > >> > > ---- Nick >> > > >> > > _______________________________________________ >> > > Airship-discuss mailing list >> > > Airship-discuss at lists.airshipit.org >> > > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss >> > > < >> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.airshipit.org_cgi-2Dbin_mailman_listinfo_airship-2Ddiscuss&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=WhNp-VjTw70e2z_QbunOZc8fyS-zMWVbK70DnNjJMS0&s=nBDu-ohIh1kHRZSZCF0aSC5mIryxhGUOu9y-I8hj7dc&e= >> > >> > > >> > > >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: < >> http://lists.airshipit.org/pipermail/airship-discuss/attachments/20190312/5c30236d/attachment.html >> > >> > >> > ------------------------------ >> > >> > Subject: Digest Footer >> > >> > _______________________________________________ >> > Airship-discuss mailing list >> > Airship-discuss at lists.airshipit.org >> > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss >> > >> > ------------------------------ >> > >> > End of Airship-discuss Digest, Vol 10, Issue 12 >> > *********************************************** >> > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From rp2723 at att.com Wed Mar 13 19:55:21 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Wed, 13 Mar 2019 19:55:21 +0000 Subject: [Airship-discuss] Discuss target state implementation of Docker/Kernel/Os/Security Patches etc Message-ID: <99088997CCAD0C4BA20008FD0943449632792FDA@MISOUT7MSGUSRDI.ITServices.sbc.com> When: Occurs every Tuesday from 1:00 PM to 2:00 PM effective 2/26/2019 until 3/29/2019. (UTC-05:00) Eastern Time (US & Canada) Where: https://attcorp.webex.com/join/rp2723 *~*~*~*~*~*~*~*~*~* Reducing to a single day Discuss target state implementation of Airship Docker/Kubelet/Kernel/OS etc upgrade I scheduled a series, will figure out when it’s appropriate What do we need to discuss ? The ability to manage the delivery of any update across groups of hosts in a declarative way. The ability to control disruption effects from those updates Next Meeting: Looking at the https://github.com/GoogleCloudPlatform/metacontroller approach and comparing against what we discussed today. Everyone (in Airship Community) is welcome to participate on this discussions. Approach Discussed on our 1st Meeting https://go.gliffy.com/go/publish/12934972 Sample CR’s .. apiVersion: airship/v1 kind: MultiNodeAction metadata: name: DoSomethingPerRack spec: # List of sets of nodes that theis applies to. Indicates the cadence. 1 set at a time failureSet: set1: rack: rack1 set2: rack: rack2 # - Indicate the Action(What are we doing) - # - Indicate effect Upgrade and Reboot, Reboot Only, .. intentions: - UpgradeDockerAction - UpgradeKubeletAction - RebootAction ## This is teh CR that a node agent consumes apiVersion: airship/v1 kind: NodeAction metadata: name: Set1 spec: setIndicator: rack: rack1 intentions: ListOFActions: - UpgradeDocker - UpgradeKubelet - Reboot ## This is the CR's for ACTIONS that the NodeAgent ingests as well apiVersion: airship/v1 kind: Action metadata: name: Reboot spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeDocker spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeKubelet spec: script ..... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 4596 bytes Desc: not available URL: From rp2723 at att.com Wed Mar 13 19:55:20 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Wed, 13 Mar 2019 19:55:20 +0000 Subject: [Airship-discuss] Canceled: Discuss target state implementation of Docker/Kernel/Os/Security Patches etc Message-ID: <99088997CCAD0C4BA20008FD0943449632792FD3@MISOUT7MSGUSRDI.ITServices.sbc.com> When: Friday, March 15, 2019 1:00 PM-2:00 PM. (UTC-05:00) Eastern Time (US & Canada) Where: https://attcorp.webex.com/join/rp2723 *~*~*~*~*~*~*~*~*~* Reducing to a single day Discuss target state implementation of Airship Docker/Kubelet/Kernel/OS etc upgrade I scheduled a series, will figure out when it’s appropriate What do we need to discuss ? The ability to manage the delivery of any update across groups of hosts in a declarative way. The ability to control disruption effects from those updates Next Meeting: Looking at the https://github.com/GoogleCloudPlatform/metacontroller approach and comparing against what we discussed today. Everyone (in Airship Community) is welcome to participate on this discussions. Approach Discussed on our 1st Meeting https://go.gliffy.com/go/publish/12934972 Sample CR’s .. apiVersion: airship/v1 kind: MultiNodeAction metadata: name: DoSomethingPerRack spec: # List of sets of nodes that theis applies to. Indicates the cadence. 1 set at a time failureSet: set1: rack: rack1 set2: rack: rack2 # - Indicate the Action(What are we doing) - # - Indicate effect Upgrade and Reboot, Reboot Only, .. intentions: - UpgradeDockerAction - UpgradeKubeletAction - RebootAction ## This is teh CR that a node agent consumes apiVersion: airship/v1 kind: NodeAction metadata: name: Set1 spec: setIndicator: rack: rack1 intentions: ListOFActions: - UpgradeDocker - UpgradeKubelet - Reboot ## This is the CR's for ACTIONS that the NodeAgent ingests as well apiVersion: airship/v1 kind: Action metadata: name: Reboot spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeDocker spec: script ..... apiVersion: nc.att.com/v1 kind: Action metadata: name: UpgradeKubelet spec: script ..... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 4548 bytes Desc: not available URL: From kennelson11 at gmail.com Mon Mar 18 17:25:11 2019 From: kennelson11 at gmail.com (Kendall Nelson) Date: Mon, 18 Mar 2019 10:25:11 -0700 Subject: [Airship-discuss] [all][PTG] Strawman Schedule In-Reply-To: References: Message-ID: Hello Everyone, In the attached picture or link [0] you will find the proposed schedule for the various tracks at the Denver PTG in April/May. We did our best to avoid the key conflicts that the track leads (PTLs, SIG leads...) mentioned in their PTG survey responses, although there was no perfect solution that would avoid all conflicts especially when the event is three days long and we have over 40 teams meeting. If there is a critical conflict that was missed, please let us know, but otherwise we are not planning to change this proposal. You'll notice that: - Like in Dublin and the last time we were in Denver, a number of tracks do not get pre-allocated time, and will be scheduled on the spot in available rooms at the time that makes the most sense for the participants. - Every track will be able to book extra time and space in available extra rooms at the event via the PTGBot once its configured for the event. More details to come on that. - Airship & OpenStack Helm will each have a day and a half (with the opportunity to book more time as they need) but we hadn't decided which will go first And here are links to more information about the event[1], on registration[2] or booking a room at the event hotel[3] in case you haven't booked or registered yet :) See you there! -Kendall Nelson (diablo_rojo) [0] https://screenshotscdn.firefoxusercontent.com/images/8c880d0a-b41e-4cea-8ff7-8f34073852ca.png?embedded=og [1]https://www.openstack.org/ptg [2]https://www.eventbrite.com/e/open-infrastructure-summit-project-teams-gathering-tickets-52606153421?_ga=2.190991274.1609728385.1552928145-572792429.1538091877 [3]https://www.hyatt.com/en-US/group-booking/DENCC/G-FNTE -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: train_ptg_strawman.png Type: image/png Size: 48457 bytes Desc: not available URL: From rp2723 at att.com Tue Mar 19 17:32:49 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Tue, 19 Mar 2019 17:32:49 +0000 Subject: [Airship-discuss] Canceled: Discuss target state implementation of Docker/Kernel/Os/Security Patches etc Message-ID: <893A2005-460D-46A2-B32F-D89EE6315262@att.com> We are moving to a Spec writing Phase for this. Will continue the discussion on the spec , and the Design calls. Thanks for the participation, this is the Etherpad from our discussions: https://etherpad.openstack.org/p/Airship_NodeControlledDeployment Target for an initial Draft for the spec is the Design Call for March 28. Regards Rodolfo Pacheco Home/Office 732 5337671 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nchase at mirantis.com Wed Mar 20 01:58:35 2019 From: nchase at mirantis.com (Nick Chase) Date: Tue, 19 Mar 2019 21:58:35 -0400 Subject: [Airship-discuss] Error installing Airship In A Bottle In-Reply-To: References: Message-ID: Nope, unfortunately not. :( Thanks, though. ---- Nick On Mon, Mar 18, 2019 at 4:54 AM Loic Le Gal wrote: > Hi Nick, > > I think I face a similar problem in my first attempts to install AiaB (I'm > a bit further but also stuck too). > Note that I'm behind a proxy and that some filters are activated by our IT > so I need to replace the default google nameservers. > I fix this by adding 2 dns nameservers in /etc/resolv.conf and in the > 'common-addresses.yaml' file: > > echo "nameserver __dns1__" >>/etc/resolv.conf > echo "nameserver __dns2__" >>/etc/resolv.conf > > export > common_adr_file=/root/deploy/airship-in-a-bottle/deployment_files/site/demo/networks/common-addresses.yaml > sed -i 's/8.8.8.8/__dns1__/g' $common_adr_file > sed -i 's/8.8.4.4/__dns2__/g' $common_adr_file > > Hope it helps, BR, > Loïc > > > Le dim. 17 mars 2019 à 18:46, Nick Chase a écrit : > >> Very nice! Capital letters was indeed the problem -- or at least, THAT >> problem. I created a new VM without them and started again, getting past >> that point. However, I'm now stuck with CrashLoopBack on the coredns >> pods. I've been trying to grab logs without success. However, I am seeing >> this: >> >> 2019-03-17 17:31:29.142 3396 INFO armada.handlers.armada [-] Processing >> ChartGroup: kubernetes-proxy (Kubernetes proxy), sequenced=True >> 2019-03-17 17:31:29.143 3396 INFO armada.handlers.chart_deploy [-] >> [chart=proxy]: Processing Chart, release=airship-kubernetes-proxy >> 2019-03-17 17:31:29.145 3396 INFO armada.handlers.chartbuilder [-] >> [chart=proxy]: Building dependency chart kubernetes-proxy-htk for release >> kubernetes-proxy. >> 2019-03-17 17:31:29.196 3396 INFO armada.handlers.chart_deploy [-] >> [chart=proxy]: Existing release airship-kubernetes-proxy found in namespace >> kube-system >> 2019-03-17 17:31:29.200 3396 INFO armada.handlers.chart_deploy [-] >> [chart=proxy]: Checking for updates to chart release inputs. >> 2019-03-17 17:31:29.238 3396 INFO armada.handlers.chart_deploy [-] >> [chart=proxy]: Found no updates to chart release inputs >> 2019-03-17 17:31:29.239 3396 INFO armada.handlers.wait [-] [chart=proxy]: >> Waiting for resource type=job, namespace=kube-system >> labels=release_group=airship-kubernetes-proxy for 600s (k8s wait 1 times, >> sleep 1s) >> 2019-03-17 17:31:29.279 3396 INFO armada.handlers.wait [-] [chart=proxy]: >> Waiting for resource type=pod, namespace=kube-system >> labels=release_group=airship-kubernetes-proxy for 600s (k8s wait 1 times, >> sleep 1s) >> 2019-03-17 17:31:29.297 3396 INFO armada.handlers.armada [-] All Charts >> applied in ChartGroup kubernetes-proxy. >> 2019-03-17 17:31:29.298 3396 INFO armada.handlers.armada [-] Processing >> ChartGroup: kubernetes-container-networking (Container networking via >> Calico), sequenced=True >> 2019-03-17 17:31:29.298 3396 INFO armada.handlers.chart_deploy [-] >> [chart=etcd]: Processing Chart, release=airship-kubernetes-calico-etcd >> 2019-03-17 17:31:29.298 3396 INFO armada.handlers.chartbuilder [-] >> [chart=etcd]: Building dependency chart kubernetes-calico-etcd-htk for >> release kubernetes-calico-etcd. >> 2019-03-17 17:31:29.312 3396 INFO armada.handlers.chart_deploy [-] >> [chart=etcd]: Existing release airship-kubernetes-calico-etcd found in >> namespace kube-system >> 2019-03-17 17:31:29.347 3396 INFO armada.handlers.chart_deploy [-] >> [chart=etcd]: Checking for updates to chart release inputs. >> 2019-03-17 17:31:29.421 3396 INFO armada.handlers.chart_deploy [-] >> [chart=etcd]: Found no updates to chart release inputs >> 2019-03-17 17:31:29.422 3396 INFO armada.handlers.wait [-] [chart=etcd]: >> Waiting for resource type=job, namespace=kube-system >> labels=release_group=airship-kubernetes-calico-etcd for 600s (k8s wait 1 >> times, sleep 1s) >> 2019-03-17 17:31:29.425 3396 INFO armada.handlers.wait [-] [chart=etcd]: >> Waiting for resource type=pod, namespace=kube-system >> labels=release_group=airship-kubernetes-calico-etcd for 600s (k8s wait 1 >> times, sleep 1s) >> 2019-03-17 17:31:29.432 3396 INFO armada.handlers.chart_deploy [-] >> [chart=calico]: Processing Chart, release=airship-kubernetes-calico >> 2019-03-17 17:31:29.432 3396 INFO armada.handlers.chartbuilder [-] >> [chart=calico]: Building dependency chart calico-htk for release >> kubernetes-calico. >> 2019-03-17 17:31:29.456 3396 INFO armada.handlers.chart_deploy [-] >> [chart=calico]: Existing release airship-kubernetes-calico found in >> namespace kube-system >> 2019-03-17 17:31:29.498 3396 INFO armada.handlers.chart_deploy [-] >> [chart=calico]: Checking for updates to chart release inputs. >> 2019-03-17 17:31:29.642 3396 INFO armada.handlers.chart_deploy [-] >> [chart=calico]: Found no updates to chart release inputs >> 2019-03-17 17:31:29.642 3396 INFO armada.handlers.wait [-] >> [chart=calico]: Waiting for resource type=job, namespace=kube-system >> labels=release_group=airship-kubernetes-calico for 600s (k8s wait 1 times, >> sleep 1s) >> 2019-03-17 17:31:29.648 3396 INFO armada.handlers.wait [-] >> [chart=calico]: Waiting for resource type=pod, namespace=kube-system >> labels=release_group=airship-kubernetes-calico for 600s (k8s wait 1 times, >> sleep 1s) >> 2019-03-17 17:31:29.667 3396 INFO armada.handlers.armada [-] All Charts >> applied in ChartGroup kubernetes-container-networking. >> 2019-03-17 17:31:29.667 3396 INFO armada.handlers.armada [-] Processing >> ChartGroup: kubernetes-dns (Cluster DNS), sequenced=False >> 2019-03-17 17:31:29.668 3396 INFO armada.handlers.chart_deploy [-] >> [chart=coredns]: Processing Chart, release=airship-coredns >> 2019-03-17 17:31:29.668 3396 INFO armada.handlers.chartbuilder [-] >> [chart=coredns]: Building dependency chart coredns-htk for release coredns. >> 2019-03-17 17:31:29.685 3396 INFO armada.handlers.chart_deploy [-] >> [chart=coredns]: Purging FAILED release airship-coredns before deployment. >> 2019-03-17 17:31:29.685 3396 INFO armada.handlers.tiller [-] >> [chart=coredns]: Uninstall airship-coredns release with >> disable_hooks=False, purge=True flags >> 2019-03-17 17:31:31.016 3396 INFO armada.handlers.chart_deploy [-] >> [chart=coredns]: Installing release airship-coredns in namespace >> kube-system, wait=True, timeout=599s >> 2019-03-17 17:31:31.018 3396 INFO armada.handlers.tiller [-] >> [chart=coredns]: Helm install release: wait=True, timeout=599 >> >> Any thoughts? >> >> ---- Nick >> >> On Wed, Mar 13, 2019 at 10:56 PM Hemanth N >> wrote: >> >>> Hi Nick >>> >>> First thing i would do, is look for apiserver and etcd container errors >>> >>> Can you check the following as well >>> >>> 1. Verify if etcd service is up or not >>> On VM, run netstat -ntulp | grep 2379 >>> >>> 2. journalctl -u kubelet.service | grep "Invalid value" >>> Look for errros, it might point out any pod spec issues >>> >>> Also please provide following information >>> 3. cat /etc/kubernetes/manifests/kubernetes-etcd.yaml >>> Check under volumes section if the names have any CAPITAL letters >>> >>> 4. hostname -s >>> >>> My hunch is you have hostname with a CAPS letter which is triggering >>> this failure. Above commands should give an idea if that is the cause. >>> If thats the case, change your hostname to all lowercase and then run >>> airship-in-a-bottle. >>> >>> Regards, >>> Hemanth >>> >>> >>> >>> >>> >>> >>> > Message: 3 >>> > Date: Tue, 12 Mar 2019 17:01:51 -0400 >>> > From: Nick Chase >>> > To: "MCEUEN, MATT" >>> > Cc: Evgeny L , >>> > "airship-discuss at lists.airshipit.org" >>> > >>> > Subject: Re: [Airship-discuss] Error installing Airship In A Bottle >>> > Message-ID: >>> > >> 55CxMPnC7bytG+RSg4w at mail.gmail.com> >>> > Content-Type: text/plain; charset="utf-8" >>> > >>> > OK, so if it IS a timeout thing, if you can tell me how to increase it, >>> > I'll appreciate it, because the script finishes, it just finishes with >>> an >>> > error. >>> > >>> > So the Airship script log is here: >>> http://paste.openstack.org/show/747758/ >>> > Docker processes here: http://paste.openstack.org/show/747759/ >>> > >>> > Thanks.... >>> > >>> > ---- Nick >>> > >>> > >>> > On Wed, Mar 13, 2019 at 6:39 PM MCEUEN, MATT wrote: >>> > >>> > > Agree, and I’d add to check the docker logs of the kube apiserver to >>> make >>> > > sure it’s starting up healthy. >>> > > >>> > > >>> > > >>> > > If you’re not seeing a smoking gun, can you do a `docker ps -a` and >>> > > pastebin the results? >>> > > >>> > > >>> > > >>> > > Thanks, >>> > > >>> > > Matt >>> > > >>> > > >>> > > >>> > > *From:* Evgeny L >>> > > *Sent:* Wednesday, March 13, 2019 12:59 PM >>> > > *To:* Nick Chase >>> > > *Cc:* airship-discuss at lists.airshipit.org >>> > > *Subject:* Re: [Airship-discuss] Error installing Airship In A Bottle >>> > > >>> > > >>> > > >>> > > Hi Nick, >>> > > >>> > > >>> > > >>> > > As far as I remember these errors are just retries that wait until >>> > > Kubernetes is up and running, have you tried to wait a bit? >>> > > >>> > > If it still fails for you, can you please send us a complete log? >>> You can >>> > > use http://paste.openstack.org/ >>> > > < >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__paste.openstack.org_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=WhNp-VjTw70e2z_QbunOZc8fyS-zMWVbK70DnNjJMS0&s=8BzvCwZPVXNqnW1cYOCO0Av7scqQCiZlumjUr7A2dk8&e= >>> > >>> > > for that. >>> > > >>> > > >>> > > >>> > > Thanks! >>> > > >>> > > >>> > > >>> > > On Mon, Mar 11, 2019 at 8:59 PM Nick Chase >>> wrote: >>> > > >>> > > I'm trying to install AIB on a Unbutu Virtualbox VM with 48GB of >>> RAM, 4 >>> > > CPU and a 300GB hard drive. Everything seems to go along fine, >>> until we >>> > > get here: >>> > > >>> > > >>> > > >>> > > Digest: >>> > > >>> sha256:badd2b1da29d4d530b10b920f64bf66a1b41150db46c3c99b49d56f3f18a82db >>> > > Status: Downloaded newer image for >>> > > gcr.io/google_containers/hyperkube-amd64:v1.10.2 >>> > > < >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__gcr.io_google-5Fcontainers_hyperkube-2Damd64-3Av1.10.2&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=WhNp-VjTw70e2z_QbunOZc8fyS-zMWVbK70DnNjJMS0&s=RON0xE-JpIMxDTL_Ja4E7LJK_asUyNLjZiaJmHyci3M&e= >>> > >>> > > Unable to connect to the server: EOF >>> > > .Unable to connect to the server: net/http: request canceled >>> > > (Client.Timeout exceeded while awaiting headers) >>> > > >>> > > >>> > > >>> > > From there, it just keeps giving these two errors. >>> > > >>> > > >>> > > >>> > > Any thoughts? >>> > > >>> > > >>> > > >>> > > Thanks... >>> > > >>> > > >>> > > >>> > > ---- Nick >>> > > >>> > > _______________________________________________ >>> > > Airship-discuss mailing list >>> > > Airship-discuss at lists.airshipit.org >>> > > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss >>> > > < >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.airshipit.org_cgi-2Dbin_mailman_listinfo_airship-2Ddiscuss&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_C5hC_103uW491yNPPpNmA&m=WhNp-VjTw70e2z_QbunOZc8fyS-zMWVbK70DnNjJMS0&s=nBDu-ohIh1kHRZSZCF0aSC5mIryxhGUOu9y-I8hj7dc&e= >>> > >>> > > >>> > > >>> > -------------- next part -------------- >>> > An HTML attachment was scrubbed... >>> > URL: < >>> http://lists.airshipit.org/pipermail/airship-discuss/attachments/20190312/5c30236d/attachment.html >>> > >>> > >>> > ------------------------------ >>> > >>> > Subject: Digest Footer >>> > >>> > _______________________________________________ >>> > Airship-discuss mailing list >>> > Airship-discuss at lists.airshipit.org >>> > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss >>> > >>> > ------------------------------ >>> > >>> > End of Airship-discuss Digest, Vol 10, Issue 12 >>> > *********************************************** >>> >> _______________________________________________ >> Airship-discuss mailing list >> Airship-discuss at lists.airshipit.org >> http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corvus at inaugust.com Wed Mar 20 19:56:24 2019 From: corvus at inaugust.com (James E. Blair) Date: Wed, 20 Mar 2019 12:56:24 -0700 Subject: [Airship-discuss] Migrating git repos to OpenDev Message-ID: <874l7xpbfb.fsf@meyer.lemoncheese.net> corvus at inaugust.com (James E. Blair) writes: > Hi, > > As discussed in November[1], the OpenStack project infrastructure is > being rebranded as "OpenDev" to better support a wider community of > projects. > > We are nearly ready to perform the part of this transition with the > largest impact: moving the authoritative git repositories for existing > projects. Working with the folks representing each of the affected OSF projects, we've scheduled the migration for Friday, April 19, 2019. This is shortly after the next OpenStack release. Please see [2] for further details about what this will involve. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html -Jim From paye600 at gmail.com Wed Mar 20 22:36:27 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Wed, 20 Mar 2019 23:36:27 +0100 Subject: [Airship-discuss] Airship - Multi-OS: image builds - repository per distributive Message-ID: Hello everyone, We have had a few discussions previously and now have an approved spec [0] and a story [1] (many thanks to James Gu) which will help us to make Airship work with (on) various Linux distributives. One of the first steps towards implementation of the above mentioned specification is an in-progress effort to support OpenSUSE as a base image for Airship components containers. This has started as a set of patches under `airship_suse` Gerrit topic [2] (many thanks to Arun Kant). During the work on this patches, it has become clear that we would need to formalize the way we would build and publish images which are based on different distributives. To help with that I have created a PS [3] to set some rules on image builds & publishing, and left it for a discussion. Discussion [3] has shown, that we have controversial opinions on implementation details. On a latest IRC meeting we have had I've volunteered to move the discussion onto the Airship community discussions mailing list (this one). This has been done: - to reach wider audience, collect more opinions and reasoning both in ML and in PS, - to collectively come to the conclusion and agreement on implementation details, - to reflect decision in a PS [3] and get it merged to the specification [0], - and then use specification [0] as a guidance for implementation ([2] and others in the future) The topic and opinions are the following: Topic Statement: Non-Ubuntu container images repository naming convention is to add a dash separator, following with a distributive flavour, optionally specifying version after dash: ``airshipit/-[-]``; e.g. ``airshipit/armada-opensuse`` (based on recommendation from `quay.io` technical support). Opinion 1: I think this ended up with using tags because otherwise the overhead of supporting a new distribution base or version is high (create a new quay.io docker registry). So it would be 'airshipit/drydock:ubuntu-latest' or 'airshipit/drydock:ubuntu-'. I think to maintain that backwards compatibility we can say here that if no distribution base is in the tag, it refers to an Ubuntu based image. Opinion 2: I agree (to use tags), although the general naming scheme that I've seen in the majority of other docker repositories is: --. So for our case that would end up being airshipit/armada:latest-ubuntu-1604 or airshipit/armada:latest-xenial Opinion 3: IMHO Ubuntu images should have the distro in its image name so it is clear and avoid any confusion when we start have suse, centos images etc. Opinion 4: Should we also mandate that Ubuntu includes it (distro in image name), even if it is default? Just for consistency and transparency (otherwise, looking at the Quay website, you cannot be sure which distro was used). Opinion 5: Creation of another image repository is a one time effort; usage of separate image repositories for different base images is a recommendation from Quay.io tech.support; usage of separate image repositories for different base images allows to easily distinguish between images when trying to `docker pull ...` image without specifying a tag (assuming :latest) Question: would we use ``airshipit/-[-]:`` or ``airshipit/:[-]-``? [0] https://airship-specs.readthedocs.io/en/latest/specs/approved/airship_multi_linux_distros.html [1] https://storyboard.openstack.org/#!/story/2003699 [2] https://review.openstack.org/#/q/topic:airship_suse [3] https://review.openstack.org/#/c/643106/ Thank you. Best regards, -- Roman Gorshunov From chris at openstack.org Wed Mar 20 23:09:51 2019 From: chris at openstack.org (Chris Hoge) Date: Wed, 20 Mar 2019 16:09:51 -0700 Subject: [Airship-discuss] OSF/Airship Governance and Release Planning Meetings In-Reply-To: References: Message-ID: <6932CC64-BD6D-4598-A540-EDF7A9E17525@openstack.org> This meeting has been updated to Thursdays at 21:00 UTC/16:00 CDT. https://etherpad.openstack.org/p/2019_Airship_OSF_sync Thanks! Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: Airship-OSF.ics Type: text/calendar Size: 2833 bytes Desc: not available URL: -------------- next part -------------- > On Mar 12, 2019, at 11:55 PM, Chris Hoge wrote: > > The Airship team and OpenStack Foundation have started weekly meetings to > help coordinate the release and governance efforts of the Airship > project. These meetings, held Fridays at 17:00 UTC/12:00 CDT, are open to > the community. We invite you to join us to engage in these, and other > topics related to the Airship project. Agenda and connection details in > the linked etherpad. > > https://etherpad.openstack.org/p/2019_Airship_OSF_sync > > Thanks! > Chris Hoge > Strategic Program Manager > OpenStack Foundation > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss From paye600 at gmail.com Thu Mar 21 00:45:32 2019 From: paye600 at gmail.com (Roman Gorshunov) Date: Thu, 21 Mar 2019 01:45:32 +0100 Subject: [Airship-discuss] OpenStack Infra to OpenDev: new tenant namespace - Airship Message-ID: Hello everyone, OpenStack Infrastructure and their awesome services are being re-branded (oversimplifying here) to a neutral name - OpenDev Infrastructure [0]. This affects many of the infrastructure components we use for the Airship development. The closest expected change is a semi-automated replacement of git:// URL schema in OpenStack Git repositories of source code to https:// - this would be done to set up http redirects from old repositories location to the new locations. Some of repositories would no longer be accessible via git:// URLs after the transition is complete. If you use git:// schema to access OpenStack git repositories, make sure to update it to https:// to get advantage of http redirects which would be set up. Planned transition date is April, 19th. One of other significant changes is a change of Gerrit service host name from review.openstack.org to review.opendev.org. This would be done automatically for the Zuul configuration and .gitreview files, but other references would need to be updated manually. We have been given the opportunity to have our own tenant namespace to be registered: `airship`. Currently we are using `openstack` tenant namespace, you can see it as a part of gerrit project names or git repositories names. While being under `openstack/` tenant namespace, we used `airship-` prefix for our Airship components, e.g. `openstack/airship-armada` to easily distinguish them. Before that, when Airship has been hosted on GitHub in `att-comdev` repository, independent Airship components have had no prefix at all. Questions for a discussion: 1. Would we want to use `airship` tenant, or stay under `openstack` tenant? Example: openstack/airship-armada -> airship/airship-armada 2. If we move to `airship` tenant, would we want to drop technical `airship-` prefix from components? Example: openstack/airship-armada -> airship/armada 3. Would we want to mirror Airship repositories to some other repository hosting (GitLab, BitBucket, GitHub, etc.)? If yes, then to which one and under which name? Pros and Cons: - Moving from `openstack` to `airship` tenant would help to message that Airship project is not exclusively about running OpenStack (OpenStack-Helm) - We would need to change git.openstack.org/openstack/airship-* -like URLs to git.airshipit.org/airship-* or to git.airshipit.org/* (where * is an independent component name, e.g. armada) in many places - We would stop having automatic replication to the GitHub which we enjoyed using, but we are offered help to set up replication via post-merge Zuul job to the repository we would choose (airship and airshipit are already in use on GitHub) - Many used GitHub as a convenient way to search and explore source code of Airship; with introduction of Gitea Git web-UI in OpenDev Infrastructure, we could just use it and nothing more, as it's functionality covers use cases we use GitHub for [1] Gitea features [1]: * Shorter domain name in project URLs: https://git.openstack.org/openstack/nova vs https://opendev.org/openstack/nova * Clone and browsing URLs are the same (with cgit, the browsing URL has an extra path component) * More visually pleasing code browsing * Integrated code searching * Ability to highlight multiple lines in links Impacted components: - pretty much all Airship components have references to something what would possibly chage - many of third-party systems, many source code repositories refer to git:// schema and/or to Airship under opentack/ tenant namespace - Jenkins servers running third-party gates for Airship, including code in openstack/airship-treasuremap and att-comdev/cicd repositories, and possibly Jenkins variables Implementation: - action item to Airship users: If you use git:// schema to access OpenStack git repositories, make sure to update it to https:// to get advantage of http redirects which would be set up Other action items would be communicated via this and airship-announce mailing lists - Roman Gorshunov (roman_g on Freenode) is a single point of contact to OpenDev Infra team for the transition - opinions on the questions above are collected until 29th of March, and decision is made on weekly IRC meeting [2] on 2nd of April - Roman will send announcement with further details to this and airship-announce mailing lists - Roman communicates changes to OpenDev Infrastructure - source code change requests to the Airship components would be submitted by Core reviewers closer to the transition date, after decision on the questions above is made, "Workforce: -1" will be applied to disable merge - closer to or on the transition date the changes in infrastructure will be tested (http redirects, gerrit and gitea should work), and changes would be submitted for merge ("Workforce: +1"); gates would be checked to be green and passing [0] http://lists.airshipit.org/pipermail/airship-discuss/2018-November/000166.html , http://lists.airshipit.org/pipermail/airship-discuss/2019-March/000345.html , http://lists.airshipit.org/pipermail/airship-discuss/2019-March/000379.html [1] see https://opendev.org/openstack/horizon as example [2] http://eavesdrop.openstack.org/#Airship_Team_Meeting Thank you. Best regards, -- Roman Gorshunov From jean-philippe at evrard.me Thu Mar 21 07:53:28 2019 From: jean-philippe at evrard.me (Jean-Philippe Evrard) Date: Thu, 21 Mar 2019 03:53:28 -0400 Subject: [Airship-discuss] =?utf-8?q?Airship_-_Multi-OS=3A_image_builds_-_?= =?utf-8?q?repository_per=09distributive?= In-Reply-To: References: Message-ID: <41719a57-f8b8-40e5-88d6-8b0bd476023e@www.fastmail.com> On Wed, Mar 20, 2019, at 23:36, Roman Gorshunov wrote: > Hello everyone, > > We have had a few discussions previously and now have an approved spec > [0] and a story [1] (many thanks to James Gu) which will help us to > make Airship work with (on) various Linux distributives. > > One of the first steps towards implementation of the above mentioned > specification is an in-progress effort to support OpenSUSE as a base > image for Airship components containers. This has started as a set of > patches under `airship_suse` Gerrit topic [2] (many thanks to Arun > Kant). > > During the work on this patches, it has become clear that we would > need to formalize the way we would build and publish images which are > based on different distributives. To help with that I have created a > PS [3] to set some rules on image builds & publishing, and left it for > a discussion. > > Discussion [3] has shown, that we have controversial opinions on > implementation details. On a latest IRC meeting we have had I've > volunteered to move the discussion onto the Airship community > discussions mailing list (this one). This has been done: > - to reach wider audience, collect more opinions and reasoning both > in ML and in PS, > - to collectively come to the conclusion and agreement on > implementation details, > - to reflect decision in a PS [3] and get it merged to the specification [0], > - and then use specification [0] as a guidance for implementation > ([2] and others in the future) > > The topic and opinions are the following: > > Topic Statement: > Non-Ubuntu container images repository naming convention is to add a > dash separator, following with a distributive flavour, optionally > specifying version after dash: ``airshipit/ component>-[-]``; e.g. > ``airshipit/armada-opensuse`` (based on recommendation from `quay.io` > technical support). > > Opinion 1: I think this ended up with using tags because otherwise the > overhead of supporting a new distribution base or version is high > (create a new quay.io docker registry). So it would be > 'airshipit/drydock:ubuntu-latest' or > 'airshipit/drydock:ubuntu-'. I think to maintain that > backwards compatibility we can say here that if no distribution base > is in the tag, it refers to an Ubuntu based image. > > Opinion 2: I agree (to use tags), although the general naming scheme > that I've seen in the majority of other docker repositories is: > -- specifics>. So for our case that would end up being > airshipit/armada:latest-ubuntu-1604 or airshipit/armada:latest-xenial > > Opinion 3: IMHO Ubuntu images should have the distro in its image name > so it is clear and avoid any confusion when we start have suse, centos > images etc. > > Opinion 4: Should we also mandate that Ubuntu includes it (distro in > image name), even if it is default? Just for consistency and > transparency (otherwise, looking at the Quay website, you cannot be > sure which distro was used). > > Opinion 5: Creation of another image repository is a one time effort; > usage of separate image repositories for different base images is a > recommendation from Quay.io tech.support; usage of separate image > repositories for different base images allows to easily distinguish > between images when trying to `docker pull ...` image without > specifying a tag (assuming :latest) > > Question: would we use ``airshipit/- flavour>[-]:`` or ``airshipit/ component>:[-]-``? > > [0] > https://airship-specs.readthedocs.io/en/latest/specs/approved/airship_multi_linux_distros.html > [1] https://storyboard.openstack.org/#!/story/2003699 > [2] https://review.openstack.org/#/q/topic:airship_suse > [3] https://review.openstack.org/#/c/643106/ > > Thank you. > > Best regards, > -- Roman Gorshunov > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss In OSH, we (I should say Pete) have decided to use -. Which makes it latest-opensuse_15 , latest-ubuntu_xenial (for non openstack images), master-ubuntu_xenial, master-opensuse_15, rocky-opensuse_15, etc. Those are always updated images. Frozen images can be tagged when necessary. Just change the 'version' with tag or sha. We can also have labels to give extra info. I would prefer if we used the same convention. For the image building process, I suppose it's better if you have it directly in your repo, and reuse as much as possible what's out there. For example, reusing openstack-infra Zuul roles. OSH just builds in a single repo because we don't have the opportunity to build next to the source code. Regards, Jean-Philippe Evrard (evrardjp) From pshchelokovskyy at mirantis.com Thu Mar 21 14:33:25 2019 From: pshchelokovskyy at mirantis.com (Pavlo Shchelokovskyy) Date: Thu, 21 Mar 2019 16:33:25 +0200 Subject: [Airship-discuss] OpenStack Infra to OpenDev: new tenant namespace - Airship In-Reply-To: References: Message-ID: Hi, just to note, W-1 does not actually prevent merging, it is more like a hint for reviewers. To make a change impossible to be submitted in Gerrit, a CodeReview: -2 vote from a core reviewer is needed (and this is a common practice in openstack projects, named 'procedural -2', for example for feature-adding patches after feature freeze until stable branches are cut). On the subject - I'd vote for 'airship/armada'-like naming, is more proper and intuitive from PR side (even though requires more work to be done for seamless transition). However that might be tough or unintuitive to replicate to Github as there's already an 'airship' org there. It has zero repos and zero projects - may be find owners of that and talk to them on whether it would be possible for them to surrender this org? Cheers, - Pavlo On Thu, Mar 21, 2019 at 2:46 AM Roman Gorshunov wrote: > Hello everyone, > > OpenStack Infrastructure and their awesome services are being > re-branded (oversimplifying here) to a neutral name - OpenDev > Infrastructure [0]. This affects many of the infrastructure components > we use for the Airship development. > > The closest expected change is a semi-automated replacement of git:// > URL schema in OpenStack Git repositories of source code to https:// - > this would be done to set up http redirects from old repositories > location to the new locations. Some of repositories would no longer be > accessible via git:// URLs after the transition is complete. If you > use git:// schema to access OpenStack git repositories, make sure to > update it to https:// to get advantage of http redirects which would > be set up. > > Planned transition date is April, 19th. > > One of other significant changes is a change of Gerrit service host > name from review.openstack.org to review.opendev.org. This would be > done automatically for the Zuul configuration and .gitreview files, > but other references would need to be updated manually. > > We have been given the opportunity to have our own tenant namespace to > be registered: `airship`. Currently we are using `openstack` tenant > namespace, you can see it as a part of gerrit project names or git > repositories names. > > While being under `openstack/` tenant namespace, we used `airship-` > prefix for our Airship components, e.g. `openstack/airship-armada` to > easily distinguish them. Before that, when Airship has been hosted on > GitHub in `att-comdev` repository, independent Airship components have > had no prefix at all. > > Questions for a discussion: > 1. Would we want to use `airship` tenant, or stay under `openstack` tenant? > Example: openstack/airship-armada -> airship/airship-armada > > 2. If we move to `airship` tenant, would we want to drop technical > `airship-` prefix from components? > Example: openstack/airship-armada -> airship/armada > > 3. Would we want to mirror Airship repositories to some other > repository hosting (GitLab, BitBucket, GitHub, etc.)? If yes, then to > which one and under which name? > > Pros and Cons: > - Moving from `openstack` to `airship` tenant would help to message > that Airship project is not exclusively about running OpenStack > (OpenStack-Helm) > - We would need to change git.openstack.org/openstack/airship-* -like > URLs to git.airshipit.org/airship-* or to git.airshipit.org/* (where * > is an independent component name, e.g. armada) in many places > - We would stop having automatic replication to the GitHub which we > enjoyed using, but we are offered help to set up replication via > post-merge Zuul job to the repository we would choose (airship and > airshipit are already in use on GitHub) > - Many used GitHub as a convenient way to search and explore source > code of Airship; with introduction of Gitea Git web-UI in OpenDev > Infrastructure, we could just use it and nothing more, as it's > functionality covers use cases we use GitHub for [1] > > Gitea features [1]: > * Shorter domain name in project URLs: > https://git.openstack.org/openstack/nova vs > https://opendev.org/openstack/nova > * Clone and browsing URLs are the same (with cgit, the browsing URL > has an extra path component) > * More visually pleasing code browsing > * Integrated code searching > * Ability to highlight multiple lines in links > > Impacted components: > - pretty much all Airship components have references to something what > would possibly chage > - many of third-party systems, many source code repositories refer to > git:// schema and/or to Airship under opentack/ tenant namespace > - Jenkins servers running third-party gates for Airship, including > code in openstack/airship-treasuremap and att-comdev/cicd > repositories, and possibly Jenkins variables > > Implementation: > - action item to Airship users: > If you use git:// schema to access OpenStack git repositories, make > sure to update it to https:// to get advantage of http redirects which > would be set up > Other action items would be communicated via this and > airship-announce mailing lists > - Roman Gorshunov (roman_g on Freenode) is a single point of contact > to OpenDev Infra team for the transition > - opinions on the questions above are collected until 29th of March, > and decision is made on weekly IRC meeting [2] on 2nd of April > - Roman will send announcement with further details to this and > airship-announce mailing lists > - Roman communicates changes to OpenDev Infrastructure > - source code change requests to the Airship components would be > submitted by Core reviewers closer to the transition date, after > decision on the questions above is made, "Workforce: -1" will be > applied to disable merge > - closer to or on the transition date the changes in infrastructure > will be tested (http redirects, gerrit and gitea should work), and > changes would be submitted for merge ("Workforce: +1"); gates would be > checked to be green and passing > > [0] > http://lists.airshipit.org/pipermail/airship-discuss/2018-November/000166.html > , > http://lists.airshipit.org/pipermail/airship-discuss/2019-March/000345.html > , > http://lists.airshipit.org/pipermail/airship-discuss/2019-March/000379.html > [1] see https://opendev.org/openstack/horizon as example > [2] http://eavesdrop.openstack.org/#Airship_Team_Meeting > > Thank you. > > Best regards, > -- Roman Gorshunov > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss at lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pshchelokovskyy at mirantis.com Thu Mar 21 14:58:15 2019 From: pshchelokovskyy at mirantis.com (Pavlo Shchelokovskyy) Date: Thu, 21 Mar 2019 16:58:15 +0200 Subject: [Airship-discuss] OpenStack Infra to OpenDev: new tenant namespace - Airship In-Reply-To: References: Message-ID: Sorry, correction, https://github.com/airship is a user, not an organization. Cheers, - Pavlo On Thu, Mar 21, 2019 at 4:33 PM Pavlo Shchelokovskyy < pshchelokovskyy at mirantis.com> wrote: > Hi, > > just to note, W-1 does not actually prevent merging, it is more like a > hint for reviewers. > To make a change impossible to be submitted in Gerrit, a CodeReview: -2 > vote from a core reviewer is needed > (and this is a common practice in openstack projects, named 'procedural > -2', for example for feature-adding patches after feature freeze > until stable branches are cut). > > On the subject - I'd vote for 'airship/armada'-like naming, is more proper > and intuitive from PR side (even though requires more work to be done for > seamless transition). > However that might be tough or unintuitive to replicate to Github as > there's already an 'airship' org there. > It has zero repos and zero projects - may be find owners of that and talk > to them on whether it would be possible for them to surrender this org? > > Cheers, > - Pavlo > > On Thu, Mar 21, 2019 at 2:46 AM Roman Gorshunov wrote: > >> Hello everyone, >> >> OpenStack Infrastructure and their awesome services are being >> re-branded (oversimplifying here) to a neutral name - OpenDev >> Infrastructure [0]. This affects many of the infrastructure components >> we use for the Airship development. >> >> The closest expected change is a semi-automated replacement of git:// >> URL schema in OpenStack Git repositories of source code to https:// - >> this would be done to set up http redirects from old repositories >> location to the new locations. Some of repositories would no longer be >> accessible via git:// URLs after the transition is complete. If you >> use git:// schema to access OpenStack git repositories, make sure to >> update it to https:// to get advantage of http redirects which would >> be set up. >> >> Planned transition date is April, 19th. >> >> One of other significant changes is a change of Gerrit service host >> name from review.openstack.org to review.opendev.org. This would be >> done automatically for the Zuul configuration and .gitreview files, >> but other references would need to be updated manually. >> >> We have been given the opportunity to have our own tenant namespace to >> be registered: `airship`. Currently we are using `openstack` tenant >> namespace, you can see it as a part of gerrit project names or git >> repositories names. >> >> While being under `openstack/` tenant namespace, we used `airship-` >> prefix for our Airship components, e.g. `openstack/airship-armada` to >> easily distinguish them. Before that, when Airship has been hosted on >> GitHub in `att-comdev` repository, independent Airship components have >> had no prefix at all. >> >> Questions for a discussion: >> 1. Would we want to use `airship` tenant, or stay under `openstack` >> tenant? >> Example: openstack/airship-armada -> airship/airship-armada >> >> 2. If we move to `airship` tenant, would we want to drop technical >> `airship-` prefix from components? >> Example: openstack/airship-armada -> airship/armada >> >> 3. Would we want to mirror Airship repositories to some other >> repository hosting (GitLab, BitBucket, GitHub, etc.)? If yes, then to >> which one and under which name? >> >> Pros and Cons: >> - Moving from `openstack` to `airship` tenant would help to message >> that Airship project is not exclusively about running OpenStack >> (OpenStack-Helm) >> - We would need to change git.openstack.org/openstack/airship-* -like >> URLs to git.airshipit.org/airship-* or to git.airshipit.org/* (where * >> is an independent component name, e.g. armada) in many places >> - We would stop having automatic replication to the GitHub which we >> enjoyed using, but we are offered help to set up replication via >> post-merge Zuul job to the repository we would choose (airship and >> airshipit are already in use on GitHub) >> - Many used GitHub as a convenient way to search and explore source >> code of Airship; with introduction of Gitea Git web-UI in OpenDev >> Infrastructure, we could just use it and nothing more, as it's >> functionality covers use cases we use GitHub for [1] >> >> Gitea features [1]: >> * Shorter domain name in project URLs: >> https://git.openstack.org/openstack/nova vs >> https://opendev.org/openstack/nova >> * Clone and browsing URLs are the same (with cgit, the browsing URL >> has an extra path component) >> * More visually pleasing code browsing >> * Integrated code searching >> * Ability to highlight multiple lines in links >> >> Impacted components: >> - pretty much all Airship components have references to something what >> would possibly chage >> - many of third-party systems, many source code repositories refer to >> git:// schema and/or to Airship under opentack/ tenant namespace >> - Jenkins servers running third-party gates for Airship, including >> code in openstack/airship-treasuremap and att-comdev/cicd >> repositories, and possibly Jenkins variables >> >> Implementation: >> - action item to Airship users: >> If you use git:// schema to access OpenStack git repositories, make >> sure to update it to https:// to get advantage of http redirects which >> would be set up >> Other action items would be communicated via this and >> airship-announce mailing lists >> - Roman Gorshunov (roman_g on Freenode) is a single point of contact >> to OpenDev Infra team for the transition >> - opinions on the questions above are collected until 29th of March, >> and decision is made on weekly IRC meeting [2] on 2nd of April >> - Roman will send announcement with further details to this and >> airship-announce mailing lists >> - Roman communicates changes to OpenDev Infrastructure >> - source code change requests to the Airship components would be >> submitted by Core reviewers closer to the transition date, after >> decision on the questions above is made, "Workforce: -1" will be >> applied to disable merge >> - closer to or on the transition date the changes in infrastructure >> will be tested (http redirects, gerrit and gitea should work), and >> changes would be submitted for merge ("Workforce: +1"); gates would be >> checked to be green and passing >> >> [0] >> http://lists.airshipit.org/pipermail/airship-discuss/2018-November/000166.html >> , >> >> http://lists.airshipit.org/pipermail/airship-discuss/2019-March/000345.html >> , >> >> http://lists.airshipit.org/pipermail/airship-discuss/2019-March/000379.html >> [1] see https://opendev.org/openstack/horizon as example >> [2] http://eavesdrop.openstack.org/#Airship_Team_Meeting >> >> Thank you. >> >> Best regards, >> -- Roman Gorshunov >> >> _______________________________________________ >> Airship-discuss mailing list >> Airship-discuss at lists.airshipit.org >> http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss > > > > -- > Dr. Pavlo Shchelokovskyy > Principal Software Engineer > Mirantis Inc > www.mirantis.com > -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From drewwalters96 at gmail.com Thu Mar 21 17:27:40 2019 From: drewwalters96 at gmail.com (Drew Walters) Date: Thu, 21 Mar 2019 12:27:40 -0500 Subject: [Airship-discuss] Airship - Multi-OS: image builds - repository per distributive In-Reply-To: <41719a57-f8b8-40e5-88d6-8b0bd476023e@www.fastmail.com> References: <41719a57-f8b8-40e5-88d6-8b0bd476023e@www.fastmail.com> Message-ID: Roman, Thanks for bringing this to the ML. Ubuntu images should have the distro in its image name > so it is clear and avoid any confusion when we start have suse, centos > images etc. > +1 to this. It also drives consistency. Creation of another image repository is a one time effort; > usage of separate image repositories for different base images is a > recommendation from Quay.io tech.support; usage of separate image > repositories for different base images allows to easily distinguish > between images when trying to `docker pull ...` image without > specifying a tag (assuming :latest) > If we create an additional repository, could it make multi-OS integration in scripts and tooling (e.g. Airskiff) more difficult? For example, if using the same image repository, you would just have to substitute ${DISTRO} when pulling docker images; however, if using an additional repository, the repository name must be substituted as well. The former seems like a cleaner approach. would we use ``airshipit/- flavour>[-]:`` or ``airshipit/ component>:[-]-``? > ``airshipit/-[-]:`` is more readable to me, and I think it's what is used in OSH-images. Best, Drew Walters (dwalt) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ag878f at att.com Sat Mar 23 19:31:19 2019 From: ag878f at att.com (GAUTAM, ANIRUDDHA) Date: Sat, 23 Mar 2019 19:31:19 +0000 Subject: [Airship-discuss] Airship-in-a-bottle_Dev_Minimal Behind Proxy: Error in site deployment Message-ID: Hi all, I am trying to build AiaB Dev_Minimal behind proxy. In genesis stage, after installation of docker and kubelet, it waits for availability of Kube-api server, while waiting on 127.0.0.1:6553. Sat Mar 23 17:46:10 UTC 2019 === Waiting for Kubernetes API availablity === + wait_for_kubernetes_api 3600 + set +x Sat Mar 23 17:46:10 UTC 2019 Waiting 3600 seconds for API response. The connection to the server 127.0.0.1:6553 was refused - did you specify the right host or port? .Unable to connect to the server: net/http: request canceled (Client.Timeout exceeded while awaiting headers) .Unable to connect to the server: net/http: request canceled (Client.Timeout exceeded while awaiting headers) .Unable to connect to the server: net/http: request canceled (Client.Timeout exceeded while awaiting headers) Not sure it is because of Promenade’s updated /etc/hosts entry of host name. I made any entry in this file for HOSTIP but it was overwritten. $ cat /etc/hosts # This file is controlled by Promenade. Do not modify. # 127.0.0.1 aiab.gate.local aiab 127.0.0.1 localhost Can someone help me what I am missing here? Regards, Aniruddha -------------- next part -------------- An HTML attachment was scrubbed... URL: From rp2723 at att.com Tue Mar 19 17:32:01 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Tue, 19 Mar 2019 17:32:01 +0000 Subject: [Airship-discuss] Canceled: Discuss target state implementation of Docker/Kernel/Os/Security Patches etc Message-ID: <99088997CCAD0C4BA20008FD09434496327ABA53@MISOUT7MSGUSRDI.ITServices.sbc.com> We are moving to a Spec writing Phase for this. Will continue the discussion on the spec , and the Design calls. Thanks for the participation, this is the Etherpad from our discussions: https://etherpad.openstack.org/p/Airship_NodeControlledDeployment Target for an initial Draft for the spec is the Design Call for March 28. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 3017 bytes Desc: not available URL: From ag878f at att.com Sun Mar 24 19:08:32 2019 From: ag878f at att.com (GAUTAM, ANIRUDDHA) Date: Sun, 24 Mar 2019 19:08:32 +0000 Subject: [Airship-discuss] Airship-in-a-bottle_Dev_Minimal: Error in site deployment Message-ID: Hi all, I am trying to build AiaB Dev_Minimal and it is NOT running behind proxy. In genesis stage, when it is downloading kube-adm packages, it loses DNS resolution and then it is not able to download anything and script ultimately fails. It is consistently reproducible. So need help from the experts here… Console out of deploy-site.sh is attached. Other details are pasted below: =========================================updates in dev-configurables.yaml and set-env.sh====================================== root at AIAB:~/deploy/airship-in-a-bottle# git diff diff --git a/deployment_files/site/dev/deployment/dev-configurables.yaml b/deployment_files/site/dev/deployment/dev-configurables.yaml index ad6da40..f5cb03b 100644 --- a/deployment_files/site/dev/deployment/dev-configurables.yaml +++ b/deployment_files/site/dev/deployment/dev-configurables.yaml @@ -8,3 +8,14 @@ metadata: layer: site storagePolicy: cleartext # Data section provided by deploy_ucp.sh script +data: + hostname: AIAB + hostip: 192.168.56.151 + hostcidr: 192.168.56.0/24 + interface: enp0s3 +data: + hostname: AIAB + hostip: 192.168.56.151 + hostcidr: 192.168.56.0/24 + interface: enp0s3 + maas-ingress: '192.169.1.5/32' diff --git a/manifests/dev_minimal/set-env.sh b/manifests/dev_minimal/set-env.sh index 27daa77..bcc3b9d 100644 --- a/manifests/dev_minimal/set-env.sh +++ b/manifests/dev_minimal/set-env.sh @@ -24,13 +24,13 @@ # frequently changed # The hostname for the genesis node -export SHORT_HOSTNAME=testvm1 +export SHORT_HOSTNAME=AIAB # The IP address of the genesis node -export HOSTIP=10.0.0.9 +export HOSTIP=192.168.56.151 # The CIDR of the network for the genesis node -export HOSTCIDR=10.0.0.0/24 +export HOSTCIDR=192.168.56.0/24 # The network interface on the genesis node -export NODE_NET_IFACE=ens3 +export NODE_NET_IFACE=enp0s3 # Repositories # export AIRSHIP_IN_A_BOTTLE_REPO="https://git.openstack.org/openstack/airship-in-a-bottle" ================================================================================================================= ============================================/etc/hosts and /etc/resolv.conf before running deploy-airship.sh========================================= root at AIAB:~# cat /etc/hosts && cat /etc/resolv.conf 127.0.0.1 localhost 192.168.56.151 AIAB #127.0.1.1 AIAB # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1 search ITServices.sbc.com ===================================================================================================================================================== ============================================/etc/hosts and /etc/resolv.conf after running deploy-airship.sh========================================= root at AIAB:~# cat /etc/hosts /etc/resolv.conf # This file is controlled by Promenade. Do not modify. # 127.0.0.1 AIAB.gate.local AIAB 127.0.0.1 localhostoptions timeout:1 attempts:1 domain gate.local nameserver 10.96.0.10 nameserver 8.8.8.8 nameserver 8.8.4.4 ===================================================================================================================================================== Regards, Aniruddha -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: deploy-airship-sh_logs.txt URL: From rp2723 at att.com Sun Mar 24 21:32:49 2019 From: rp2723 at att.com (PACHECO, RODOLFO J) Date: Sun, 24 Mar 2019 21:32:49 -0000 Subject: [Airship-discuss] Cancelled: Discuss target state implementation of Docker/Kernel/Os/Security Patches etc @ Tuesday, 26 February 2019 Message-ID: <385093372.93.1553463166096.JavaMail.yahoo@tardis108.cal.gq1.yahoo.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 4622 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 4622 bytes Desc: not available URL: From cheng1.li at intel.com Thu Mar 28 03:01:06 2019 From: cheng1.li at intel.com (Li, Cheng1) Date: Thu, 28 Mar 2019 03:01:06 +0000 Subject: [Airship-discuss] ovs-dpdk support in airship Message-ID: Hi Georg, This is Cheng. We had a short talk on irc yesterday, about ovs-dpdk support in airship/akraino I am pulling your patch to deploy openstack-helm, to see if any problem, to help the patch merge. I also would like to know some details of the two dpdk related akraino BPs. https://wiki.akraino.org/display/AK/Support+of+OVS-DPDK+in+Airship https://wiki.akraino.org/display/AK/OVS-DPDK+Unicycle+Blueprint+Proposal ovs-dpdk support in airship: Seems we need work in openstack-helm and airship-* projects. For openstack-helm part, you have created two patches in review. For airship-* part, does it need much code work? I didn't see airship-* patch links. Ovs-dpdk unicycle BP: I tried to understand what this BP does, but seem a little info on the BP page. Could you help to provide some info about this BP? Thanks BTW, if any issue I found with your openstack-helm patch, I will discuss with you on gerrit or irc or email. Thanks, Cheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennelson11 at gmail.com Fri Mar 29 00:03:29 2019 From: kennelson11 at gmail.com (Kendall Nelson) Date: Thu, 28 Mar 2019 17:03:29 -0700 Subject: [Airship-discuss] PTG Team Photos Message-ID: Hello! If your team is interested in having a team photo taken, here is the signup[1]! There are slots Thursday and Friday from 10:00 AM to 4:30 PM. The location is TBD but will likely be close to where registration will be. I'll send an email out the day before with a reminder of your time slot and an exact location. -Kendall (diablo_rojo) [1] https://docs.google.com/spreadsheets/d/1DgsRHVWW2YLv7ewfX0M21zWJRf4wUfPG4ff2V5XtaMg/edit?usp=sharing -------------- next part -------------- An HTML attachment was scrubbed... URL: From mm621n at att.com Wed Mar 27 23:12:12 2019 From: mm621n at att.com (MUEEN, MUZAMMIL) Date: Wed, 27 Mar 2019 23:12:12 +0000 Subject: [Airship-discuss] Airship-in-a-Bottle Message-ID: <57EAC2FD9780DD4CA3D0C854CC86914E0E64B683@CAFRFD1MSGUSRID.ITServices.sbc.com> Hi Team, While installing airship in a bottle on a physical node, behind a proxy, with dev minimal configuration. The setup is stuck with maas pod in a crashloop ... Below mentioned are the display from the installation script and the kubectl describe for maas pod. I'll be grateful if anyone can help me solve how to get maas out of this loop? NAMESPACE NAME READY STATUS RESTARTS AGE kube-system auxiliary-etcd-mtn15r07c001 3/3 Running 12 23h kube-system bootstrap-armada-mtn15r07c001 4/4 Running 16 23h kube-system calico-etcd-anchor-56fjc 1/1 Running 0 23h kube-system calico-etcd-mtn15r07c001 1/1 Running 0 23h kube-system calico-kube-controllers-56c54d8cf8-r955j 1/1 Running 0 23h kube-system calico-node-r9bdv 1/1 Running 0 23h kube-system calico-settings-866vn 0/1 Completed 0 23h kube-system coredns-764f47bb78-5tsc4 1/1 Running 0 23h kube-system coredns-764f47bb78-hv5j6 1/1 Running 0 23h kube-system coredns-764f47bb78-zsjst 1/1 Running 0 23h kube-system haproxy-mtn15r07c001 1/1 Running 4 23h kube-system ingress-error-pages-5ccf96bf7d-d7955 1/1 Running 0 23h kube-system ingress-error-pages-5ccf96bf7d-mxz68 1/1 Running 0 23h kube-system ingress-ggdvw 1/1 Running 0 23h kube-system kubernetes-apiserver-anchor-8btb7 1/1 Running 0 23h kube-system kubernetes-apiserver-mtn15r07c001 1/1 Running 0 23h kube-system kubernetes-controller-manager-anchor-b4ztr 1/1 Running 0 23h kube-system kubernetes-controller-manager-mtn15r07c001 1/1 Running 0 23h kube-system kubernetes-etcd-anchor-n9fwl 1/1 Running 0 23h kube-system kubernetes-etcd-mtn15r07c001 1/1 Running 0 23h kube-system kubernetes-proxy-2x2l9 1/1 Running 0 23h kube-system kubernetes-scheduler-anchor-mqw5j 1/1 Running 0 23h kube-system kubernetes-scheduler-mtn15r07c001 1/1 Running 0 23h kube-system nfs-provisioner-7799d64d59-z2wwd 1/1 Running 0 23h ucp airship-ucp-keystone-memcached-memcached-74d79d8896-cff8q 1/1 Running 0 23h ucp airship-ucp-rabbitmq-rabbitmq-0 1/1 Running 0 23h ucp divingbell-apparmor-default-7czhv 1/1 Running 0 22h ucp divingbell-apt-default-trvxq 1/1 Running 0 22h ucp divingbell-ethtool-default-mdkdv 1/1 Running 0 22h ucp divingbell-exec-default-n8z7r 1/1 Running 0 22h ucp divingbell-limits-default-wp2p9 1/1 Running 0 22h ucp divingbell-mounts-default-fc036fae-vrwmv 1/1 Running 0 22h ucp divingbell-perm-default-rv4ff 1/1 Running 0 22h ucp divingbell-sysctl-default-x8jpz 1/1 Running 0 22h ucp divingbell-uamlite-default-g9dnv 1/1 Running 0 22h ucp ingress-86576d6599-zdf7q 1/1 Running 0 23h ucp ingress-error-pages-5c97bb46bb-c9jhz 1/1 Running 0 23h ucp keystone-api-7c99d578b7-fvf6j 1/1 Running 0 23h ucp keystone-bootstrap-qsf4g 0/1 Completed 0 23h ucp keystone-credential-setup-6xsjs 0/1 Completed 0 23h ucp keystone-db-init-lpj2t 0/1 Completed 0 23h ucp keystone-db-sync-m28br 0/1 Completed 0 23h ucp keystone-domain-manage-rj66q 0/1 Completed 0 23h ucp keystone-fernet-rotate-1553644800-m2gx8 0/1 Init:0/1 0 21h ucp keystone-fernet-setup-8ffkj 0/1 Completed 0 23h ucp keystone-rabbit-init-95xht 0/1 Completed 0 23h ucp maas-bootstrap-admin-user-7bfgx 0/1 Init:0/1 0 21h ucp maas-db-init-r5mkj 0/1 Init:0/1 0 21h ucp maas-db-sync-gpwq2 0/1 Init:0/1 0 21h ucp maas-export-api-key-tk9c8 0/1 Init:0/1 0 21h ucp maas-import-resources-kftsl 0/1 Init:0/1 0 21h ucp maas-ingress-567777887c-v9fzp 1/2 CrashLoopBackOff 261 21h ucp maas-ingress-errors-798cbd8c4c-q987s 0/1 ContainerCreating 0 21h ucp maas-rack-0 0/1 Init:0/1 0 21h ucp maas-rack-1 0/1 Pending 0 21h ucp maas-region-0 0/1 Init:0/1 0 21h ucp mariadb-ingress-6c9dcbc755-bp5r6 1/1 Running 0 23h ucp mariadb-ingress-error-pages-b7f9f85c7-qbnh8 1/1 Running 0 23h ucp mariadb-server-0 1/1 Running 0 23h ucp postgresql-0 1/1 Running 0 23h root at mtn15r07c001:~# kubectl describe pods maas-ingress-567777887c-v9fzp --namespace=ucp Name: maas-ingress-567777887c-v9fzp Namespace: ucp Node: mtn15r07c001/135.21.35.69 Start Time: Tue, 26 Mar 2019 23:55:29 +0000 Labels: application=maas component=ingress pod-template-hash=1233334437 release_group=airship-maas Annotations: configmap-bin-hash=4b7d801062899a7d636c1f3e1c943bfad865192b964fea74b9057d85eec28d52 configmap-etc-hash=6ae6a39a1a7edf9c6d28d6952cf28fa1673062dc655a10ed04484f4ac80ffb8a Status: Running IP: 135.21.35.69 Controlled By: ReplicaSet/maas-ingress-567777887c Init Containers: init: Container ID: docker://6abdaa7b1adc8a1c3e1a3e7cb39c20684c63aa19a72b3261298cfdff21cd0188 Image: quay.io/stackanetes/kubernetes-entrypoint:v0.3.1 Image ID: docker-pullable://quay.io/stackanetes/kubernetes-entrypoint at sha256:32b1b657ee4bcc9cc7a1529e31d8e1a06376172373ee020f97f3e78168fde4b6 Port: Host Port: Command: kubernetes-entrypoint State: Terminated Reason: Completed Exit Code: 0 Started: Tue, 26 Mar 2019 23:55:33 +0000 Finished: Tue, 26 Mar 2019 23:55:33 +0000 Ready: True Restart Count: 0 Environment: POD_NAME: maas-ingress-567777887c-v9fzp (v1:metadata.name) NAMESPACE: ucp (v1:metadata.namespace) INTERFACE_NAME: eth0 PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/ DEPENDENCY_SERVICE: DEPENDENCY_DAEMONSET: DEPENDENCY_CONTAINER: DEPENDENCY_POD_JSON: COMMAND: echo done Mounts: /var/run/secrets/kubernetes.io/serviceaccount from maas-ingress-token-8qlcl (ro) maas-ingress-vip-init: Container ID: docker://195e75792c7592c90cff15703a7a977c721b4f863e0834033a72302e683a3a7d Image: docker.io/busybox:latest Image ID: docker-pullable://busybox at sha256:061ca9704a714ee3e8b80523ec720c64f6209ad3f97c0ff7cb9ec7d19f15149f Port: Host Port: Command: /tmp/maas-vip-configure.sh start State: Terminated Reason: Completed Exit Code: 0 Started: Tue, 26 Mar 2019 23:55:34 +0000 Finished: Tue, 26 Mar 2019 23:55:34 +0000 Ready: True Restart Count: 0 Environment: addr: 192.169.1.5/32 interface: maas-vip mode: routed Mounts: /mnt/host-rootfs from host-rootfs (ro) /tmp/maas-vip-configure.sh from maas-bin (ro) /var/run/secrets/kubernetes.io/serviceaccount from maas-ingress-token-8qlcl (ro) Containers: maas-ingress-vip: Container ID: docker://8be5e78def6312c70d48f0bbe57c77e4b95ab3e5a417416cc0c6d1d3d44ff536 Image: docker.io/busybox:latest Image ID: docker-pullable://busybox at sha256:061ca9704a714ee3e8b80523ec720c64f6209ad3f97c0ff7cb9ec7d19f15149f Port: Host Port: Command: /bin/init State: Running Started: Tue, 26 Mar 2019 23:55:35 +0000 Ready: True Restart Count: 0 Environment: addr: 192.169.1.5/32 interface: maas-vip mode: routed Mounts: /etc/inittab from maas-etc (ro) /tmp/maas-vip-configure.sh from maas-bin (ro) /var/run/secrets/kubernetes.io/serviceaccount from maas-ingress-token-8qlcl (ro) maas-ingress: Container ID: docker://a892c56049d267479c0298e3fe077eed4cc0a73968d069ad5b4eee8fb6f9431f Image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.20.0 Image ID: docker-pullable://quay.io/kubernetes-ingress-controller/nginx-ingress-controller at sha256:f6180c5397d2361c317aff1314dc192ab0f9f515346a5319422cdc264f05d2d9 Port: Host Port: Command: /tmp/maas-ingress.sh start State: Waiting Reason: CrashLoopBackOff Last State: Terminated Reason: Error Exit Code: 255 Started: Wed, 27 Mar 2019 20:13:16 +0000 Finished: Wed, 27 Mar 2019 20:13:16 +0000 Ready: False Restart Count: 243 Environment: POD_NAMESPACE: ucp (v1:metadata.namespace) POD_NAME: maas-ingress-567777887c-v9fzp (v1:metadata.name) RELEASE_NAME: airship-maas HTTP_PORT: 80 HTTPS_PORT: 443 HEALTHZ_PORT: 10254 STATUS_PORT: 18080 ERROR_PAGE_SERVICE: maas-ingress-error DEFAULT_ERROR_PORT: 8181 Mounts: /tmp/maas-ingress.sh from maas-bin (ro) /var/run/secrets/kubernetes.io/serviceaccount from maas-ingress-token-8qlcl (ro) Conditions: Type Status Initialized True Ready False PodScheduled True Volumes: maas-bin: Type: ConfigMap (a volume populated by a ConfigMap) Name: maas-bin Optional: false maas-etc: Type: ConfigMap (a volume populated by a ConfigMap) Name: maas-etc Optional: false host-rootfs: Type: HostPath (bare host directory volume) Path: / HostPathType: maas-ingress-token-8qlcl: Type: Secret (a volume populated by a Secret) SecretName: maas-ingress-token-8qlcl Optional: false QoS Class: BestEffort Node-Selectors: ucp-control-plane=enabled Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s node.kubernetes.io/unreachable:NoExecute for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning BackOff 2m (x5500 over 20h) kubelet, mtn15r07c001 Back-off restarting failed container root at mtn15r07c001:~# Regards, Muzammil Architect Network & Shared Services 469-600-0477 [cid:image001.png at 01D32007.C3B5AE40] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 11051 bytes Desc: image003.png URL: