weave: cloud.weave.works is down + missing page in weave documentation
Hi!
I noticed that cloud.weave.works was down. (According to https://downforeveryoneorjustme.com/cloud.weave.works?proto=https, it’s not just me, at least at the moment.)
This is (or at least, was) mentioned as the method of choice to install Weave on Kubernetes clusters:
kubever=$(kubectl version | base64 | tr -d '\n')
kubectl apply -f https://cloud.weave.works/k8s/net?k8s-version=$kubever
It worked a few days ago (at least last Monday 26-SEP-2022 according to my logs) but doesn’t work today (Monday 03-OCT-2022). I thought - maybe this was decommissioned, and I should update my deployment scripts? But when I go to the Weave documentation (https://www.weave.works/docs/net/latest/kubernetes/), it says “The recommended way of using Weave with Kubernetes is via the new Kubernetes Addon”. But the link to “Kubernetes Addon” redirects to the Weave Net overview (https://www.weave.works/docs/net/latest/overview/).
I’m not sure what to do next; I’ll fetch a cached copy of the Weave YAML somewhere but I thought it might help others to report this and get it fixed ♥
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 3
- Comments: 38 (20 by maintainers)
Encountered the same issue this morning.
I was able to install weave on both a 1.24 and 1.25 cluster using the 1.11 yaml from the release page: https://github.com/weaveworks/weave/releases/tag/v2.8.1
That seems like an older version so I’m unsure if that’s going to continue being supported, but so far things are working as expected.
Thanks for updating the documentation, and confirming that the YAML on the GitHub release pages is now the canonical source; that’s very much appreciated! ♥
One little remark: the YAML that was just released there a few days ago (weave-daemonset-k8s.yaml) uses the
:latest
image tag. Personally, I would rather use a pinned version, like in the other manifests in that release page. Pinned versions avoid issues due to unexpected upgrades; they ensure consistent versions across nodes; and they’re easier to troubleshoot (becausekubectl describe
on the DaemonSet or Pod will show you exactly what you’re running).For folks wondering about the differences between the -1.8, -1.9, -1.11 YAML manifests:
priorityClassName: system-node-critical
to the Weave PodsThere was no change in DaemonSet API or behavior since then, so the 1.11 manifest (in fact, the 1.9 manifest!) will work just fine on Kubernetes 1.25.
Thanks again!
We had our meeting today, and we committed to join another meeting at the same time next month:
Goals: to run all of the tests and build infrastructure, to provide an environment that can run all the tests (for public good) and demonstrate its use, to make an inventory of any dependencies and submit a PR for upgrading them… we can hope to bring in more volunteers next month, and share our experiences from running the tests.
Thanks for doing this Tomoya and Raj 👍
The consensus of the group was, we need more volunteers, or at least party members, in order to make this a sustainable enterprise.
The discussion continues:
Hi @kingdonb, all that is needed for multi-arch support is to update the released YAML so that it references tag
:2.8.1
instead of:latest
(see #3974 for details). I don’t know how to update Github releases (it looks like they were done manually, at least the last YAML) otherwise I’d offer a PR. Let me know if that’s not clear, I’m happy to provide better details!Hi, we are looking into a workaround if we can provide, or some alternatives. Watch this space.
Let’s set a date. It would be nice to have some more people (perhaps @fujitatomoya ?) in the meeting.
I would like to help you amplify this, but maybe a meeting would be better first. Thank you for sharing Weave Net with your students! 😃
Let’s meet some time, again. I would like to meet you personally, but maybe it makes sense to put another date on the calendar for the working group, in case any other members are still interested.
🔔 🪐 ringy bell ringy It will take some time to establish a new group and decide what it should be called, as well as formalize leadership. Let’s continue the conversation. 💯
Look closer, there have been less than 10 commits since the end of 2021, and there have been no releases other than the changes necessary to avoid leaving everyone stranded when Weave Cloud service and domain name was decommissioned.
It’s not that there is no living person who has write access, it’s that there is no active maintainer or “product owner” if Open Source can be considered a product, which it can.
There has been some small docs contributed yet, but I work at Weaveworks and have been in the conversations, so I can tell you with certainty, there is no commitment from Weaveworks Inc. to maintain Weave Net going on forward. It will have to come from the community, and I hope that it does. Weave Net may be formally sunset if it can’t be maintained effectively.
I appreciate you @fujitatomoya I am just a user of Weave Net, too. I hope it does not come off as too presumptuous stating that I will volunteer to facilitate the new maintainer when we don’t yet know who that person or group is. I cannot be the volunteer myself, I have too many other roles at Weaveworks and other commitments in open source. But I have taken over Open Source projects before that were left behind by a company when the project was in some transitionary state.
I can offer mentorship based on that experience, and material support (server hosting) to whoever wants to do the hard work – building and testing, and preparing the next release, and documenting what issues, etc. – all those jobs of a maintainer!
I can be reached on Slack (CNCF #flux) by anyone who is looking for help to answer this call.
OK, so this is really bad. I think this means that new clusters on Weave Net that just follow the released instructions cannot have Arm64 nodes without some modifications. This is really bad because, the arm64 support exists, it is there, it’s just obscured by some mistake that occurred during triage of the cloud.weave.works website itself sunsetting, with Weave Cloud.
And it can technically be fixed with a single change, but there is no commitment from us at Weaveworks to continue the maintenance of Weave Net distro, as has been echoed from the start of this issue. And there has been a loose formation of a new team, and then the holidays. I’m just repeating the events so far, for anyone that is just joining the conversation.
I think the instructions that are hosted at Weaveworks that “need to be updated” now are actually on the Weaveworks blog or corporate brand site. I don’t believe any keys have been handed over to anyone.
So if a new team is being formed that’s composed of people who are not at Weaveworks, they’re going to need somewhere else to post the instructions that explain how to get at the latest release. I’m not sure if that team has a name. Does anyone know the answer yet?
Or has this conversation already been covered somewhere and I need to catch up with the recording? I think the team needs a name first, (and not to put the cart before the horse, but then there is the possibility that more than one competing team springs up… I’d be happy to work with one point of contact or multiple but I’d prefer a single team with at least one committed point of contact that I can name.)
I’m doing the best to facilitate this next step right now without being antagonistic to anyone, please nobody read this note as passive-aggressive or anything else, as I genuinely don’t know if there is a new maintainer yet… but I want to help! 🌷
@monadic Any chance of creating a helm chart? Would be useful to be able to configure things like IPALLOC_RANGE
Would you accept a PR for one?
@lucj see the update on scope docs
let me know any feedback at the back of it
Oof https://www.weave.works/blog/weave-cloud-end-of-service