Codius v1.2.5 is out! View https://medium.com/codius/codiusd-1-2-0-upgrading-and-websocket-support-42f712a0cee9 for details. Having trouble? Try the post at https://ilp-ix.link/1-2-1-selftest-fix/ from @WilcoC_gitlab
# kubectl get services -A
NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
acme-dns acme-dns ClusterIP 10.43.174.99 <none> 443/TCP,80/TCP,53/TCP,53/UDP 84d
cert-manager cert-manager-webhook ClusterIP 10.43.202.63 <none> 443/TCP 84d
codiusd codiusd-service LoadBalancer 10.43.10.165 147.75.109.65 3000:31955/TCP 84d
default kubernetes ClusterIP 10.43.0.1 <none> 443/TCP 84d
ingress-nginx ingress-nginx ClusterIP 10.43.155.132 <none> 80/TCP,443/TCP,53/TCP,53/UDP 84d
kube-system calico-typha ClusterIP 10.43.130.214 <none> 5473/TCP 84d
kube-system kube-dns ClusterIP 10.43.0.10 <none> 53/UDP,53/TCP,9153/TCP 84d
kube-system traefik LoadBalancer 10.43.132.134 147.75.109.65 80:31076/TCP,443:31892/TCP 84d
moneyd moneyd NodePort 10.43.238.50 <none> 7768:31873/TCP 84d
So so inner workings are missing a firewall-rule or more in Kubernetes. Question is how easy is it to fix? :)
I'm still stuck on
I'm still stuck on
kubectl wait --for=condition=Ready --timeout=600s -n codiusd certificate/codius-host-certificateto get the ball running
I've studied this battleship a bit firewall-wise. Doesn't seem to matter what firewall-rules one has before installing. Because this stuff is "smart" and injects mainrules in linenumber 1 on any given chain
Ok? Shouldn't the installer fix 'everything'?
No-one deals with certificates manually anymore? :)
And if it gets codius up on http.. only cert-manager left
I've wondered a few times how you got your one 2-preview host up? ;)
Manual hacking not replicated in the installer? :)
Nice work anyways. Codius is not to be recognized compared to 1.2.5
The preview host was pure installer but no firewall
Easier todo stuff by dividing it up in object
ok, install script now asks if you want to use an existing ssl certificate
wilsonianb/codius-install@e4849ce
so for instance, I'll be doing a normal install that generates a certificate and then exporting the certificate and key by running the following in order to re-use them while testing changes to the install process
wilsonianb/codius-install@e4849ce
so for instance, I'll be doing a normal install that generates a certificate and then exporting the certificate and key by running the following in order to re-use them while testing changes to the install process
kubectl get secret -n codiusd codiusd-certificate -o go-template='{{ index .data "tls.crt" | base64decode }}' > tls.crt
kubectl get secret -n codiusd codiusd-certificate -o go-template='{{ index .data "tls.key" | base64decode }}' > tls.key
@wilsonianb
Any idea what these imply?
Any idea what these imply?
Sep 27 11:06:12 hodling-xrp k3s: W0927 11:06:12.902490 1486489 reflector.go:302] object-"kube-system"/"coredns": watch of *v1.ConfigMap ended with: too old resource version: 527 (1381)
Sep 27 11:06:18 hodling-xrp k3s: W0927 11:06:18.762159 1486489 reflector.go:302] object-"acme-dns"/"acme-dns-config": watch of *v1.ConfigMap ended with: too old resource version: 637 (1389)
This guy says the messages are benign
https://github.com/kubernetes/kubernetes/issues/22024#issuecomment-479741335
https://github.com/kubernetes/kubernetes/issues/22024#issuecomment-479741335
kubectl describe orders -A that doesn't get through.. How do I 'retry' that one? :)
Need to read docs, no time
Still at it .. So many friggin chains on that Kubernetes-firewall. Impossible to tailor a allow-rule :(
Guess the ILP-connector is obsolete?
I'm not sure exactly (re: changes to ilp connector implementations)
I think the primary hurdle is having a btp uplink at all for moneyd to connect to: https://forum.interledger.org/t/community-call-september-18th-2019/753/3
My understanding is that ilp wallets will start offering btp access to their users (as opposed to connecting moneyd to public connectors https://github.com/interledgerjs/moneyd-uplink-xrp/blob/master/connector_list.json#L3)
I think the primary hurdle is having a btp uplink at all for moneyd to connect to: https://forum.interledger.org/t/community-call-september-18th-2019/753/3
My understanding is that ilp wallets will start offering btp access to their users (as opposed to connecting moneyd to public connectors https://github.com/interledgerjs/moneyd-uplink-xrp/blob/master/connector_list.json#L3)
I'm also looking into having a variation of codius that uses web monetization so that the host only needs an ilp payment pointer (and no moneyd!)
Coil is here to stay I guess we can agree on 😁
Since secret is not known for xrptipbot-users
latest k3s includes local storage and network policy support, which means codius setup no longer needs to install local-path-provisioner and calico
https://github.com/rancher/k3s/releases/tag/v0.10.0
That said, I'm actually working on codius setup instructions for installing on an already running kubernetes cluster without all of the
https://github.com/rancher/k3s/releases/tag/v0.10.0
That said, I'm actually working on codius setup instructions for installing on an already running kubernetes cluster without all of the
sed shortcuts in the current install script. Then I hope to update the zero-to-codius script (with k3s) accordingly
@wilsonianb if you're running on packet, we helped implement the container storage interfaces (CSI). Here's the helm template https://github.com/ovrclk/disco/tree/master/layer1/csi/packet