Incorrect flannel version in old charm

Bug #1809395 reported by Tim Van Steenburgh
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Flannel Charm
New
Undecided
Unassigned

Bug Description

Opened by Adriien-M on 2018-09-24 17:27:05+00:00 at https://github.com/juju-solutions/charm-flannel/issues/48

------------------------------------------------------------

Today we tried to clone our kubernetes production environnement (which is currently working).
However, Flannel fails to start, it throws a segmentation violation error (probably related to this issue coreos/flannel#977)
Indeed, when we compare the flannel version for the exact same charm (revision 35) we have the version 0.9.1 in production whereas the version in cloned environnement is 0.10.0.

How is it possible that the flannel version changed in an old charm?
How can we fix it because it is impossible currently to launch flannel because of the go version?

====================== COMMENTS ============================

Comment created by Cynerva on 2018-09-24 18:22:15+00:00

> How is it possible that the flannel version changed in an old charm?

This is a consequence of how Juju resources were designed, and how the Juju charm store relates them to charm revisions.

In short, when you deploy flannel charm revision 35, you _are_ deploying the same charm code that runs in your production environment, but the charm code is being deployed with a resource that is _not_ the same resource that runs in your production environment. The resource contains the actual flannel binary, hence why you get 0.10.0 instead of 0.9.1.

It's unfortunate, but the charm store does not keep track of which resource revisions were used with each charm revision. Resource revisions are attached to charm channels instead (stable, candidate, beta, edge). These change over time.

> How can we fix it because it is impossible currently to launch flannel because of the go version?

I think you should be able to reproduce your production deployment by specifying the resource revision along with the charm revision.

First, run this in your production environment to get the resource revision(s):
```
$ juju list-resources flannel
Resource Supplied by Revision
flannel-amd64 charmstore 3
flannel-arm64 charmstore 1
flannel-s390x charmstore 3
```

Then, in your testing environment, deploy flannel with both the charm revision and resource revision specified:
```
juju deploy cs:~containers/flannel-81 --resource flannel-amd64=3
```

------------------------------------------------------------

Comment created by Adriien-M on 2018-09-25 07:39:29+00:00

Thanks it is working now, I didn't know this concept of resources versionning.

Before to close the issue, is it possible to run the last flannel version (v0.10.0) in juju without get the segment violation error (coreos/flannel#977)?

------------------------------------------------------------

Comment created by Cynerva on 2018-09-25 14:06:22+00:00

> Before to close the issue, is it possible to run the last flannel version (v0.10.0) in juju without get the segment violation error (coreos/flannel#977)?

Typically yes - we haven't encountered this in testing, and I think you're the first user to report it.

Are you able to reproduce this with the latest stable flannel charm (rev 81)?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.