Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 07 10:36
    Deaddy closed #221
  • Nov 07 10:36
    Deaddy edited #221
  • Nov 07 10:31
    Deaddy ready_for_review #221
  • Nov 07 10:26
    Deaddy converted_to_draft #221
  • Nov 07 10:25
    Deaddy review_requested #221
  • Nov 07 10:25
    Deaddy opened #221
  • Nov 04 13:35
    Deaddy closed #219
  • Nov 04 13:05
    davetromp synchronize #219
  • Nov 04 11:43
    Deaddy closed #220
  • Nov 04 11:31
    Deaddy synchronize #220
  • Nov 04 11:24
    Deaddy synchronize #220
  • Nov 04 11:18
    Deaddy review_request_removed #220
  • Nov 04 11:01
    Deaddy opened #220
  • Nov 04 11:01
    Deaddy review_requested #220
  • Nov 04 11:01
    Deaddy review_requested #220
  • Nov 04 10:57
    davetromp synchronize #219
  • Nov 04 10:49
    davetromp opened #219
  • Nov 04 09:26
    Deaddy closed #218
  • Nov 04 09:16
    juriroemer review_requested #218
  • Nov 04 09:13
    davetromp opened #218
Enrique Pérez Arnaud
@enriquepablo
layer3 tokenstorage would only add a user upon receiving a POST to:
And that POST should be coming from:
That POST is not happening, and so no user is created.
That POST should happen as a consequence of interactions between the rds js app, which lives within the iframe, and the nexcloud js app, which lives outside the iframe. I am now going to add some console.log statements to see if I catch the problem - but I can only add them in the nextcloud js app, since the RDS js app comes from Münster, so we'll see
Micke Nordin
@mickenordin
Ok, nice work! Do you know what should be posted? I can try maybe to manually post and see if it works with the correct object in redis?
Enrique Pérez Arnaud
@enriquepablo
The payload would be the "informations" object, give me a couple of min and I'll provide the needed structure...
Enrique Pérez Arnaud
@enriquepablo
The payload would be the jwt produced by the nextcloud app. Not sure if it should be decoded... When you load the rds app, it is logged on the js console, look for a "got response" entry in the log
Micke Nordin
@mickenordin
I found the problem!
layer1-port-owncloud was missing!
Now it works!
Enrique Pérez Arnaud
@enriquepablo
Yay!
Micke Nordin
@mickenordin
Many thanks @enriquepablo !
Enrique Pérez Arnaud
@enriquepablo
Very nice Micke!
Micke Nordin
@mickenordin
deaddy: @juriroemer The doris connector is not showing up as a service in rds. Do I have to name it in some specific manner och add it to the values file? The deployment is currently called doris-connector but it should maybe be called layer1-port-doris instead and be set to enabled in values.yaml?
Micke Nordin
@mickenordin
Yes, that did the trick :)
Juri
@juriroemer
🎉
Yes, afaik all connectors have to be enabled in the values.yaml :)
Micke Nordin
@mickenordin
Now that I have everything working in a reproducable way for me, I will convert the helmcharts to native k8s manifest yamlfiles and use kustomize to deploy from now on, so I can manage secrets and such the way I like. When I am done with that, would someone else be interested in that you think, or should I just keep it to my self (or more specifically, to anyone digging around in sunets github...)?
Juri
@juriroemer
@mickenordin secret's management is definitely something we want to improve as well, but I don't know if we want to switch to native manifests (I guess not) - I'm sure @Deaddy has something to say about that
Micke Nordin
@mickenordin
I was not suggesting that you should switch, but maybe something to offer on the side?
1 reply
Marcel Wunderlich
@Deaddy
yes yes
I have words related to that topic
very words
Micke Nordin
@mickenordin
Let them all out :D
Marcel Wunderlich
@Deaddy
I need to sort them
so let me start by lying and saying there are three different topics
the first lies is that the secret handling currently as it is documented just plain sucks and I think we can get away without changing anything but the documentation to get into a state where you would not need to put any secret values in the helm values and have them kept externally in secrets, which would be what I'd like to see for our cluster so far
sadly the second point is, the way we handle secrets in our cluster is not the best way to do things, and what might be even worse, possibly there is might not be a best way to do this ultimately
so we are stuck with supporting different approaches
Micke Nordin
@mickenordin
A sidenote on the topic of secrets, I think it would be a good idea to make layer0-web read domains from the environment, or possibly have an init container create the domains.json file from environment variables and/or from secrets in configmaps that is not a complete file
Marcel Wunderlich
@Deaddy
the third is basically that I don't think anyone is currently vhappy with the helm values documentation state and we do lack a good way of testing changes to the helm charts and collecting how people deploy things in general is a good thing to do to get a further understanding on ... what we actually have built there :D and how people use it
Marcel Wunderlich
@Deaddy
so that being said, I mean basically I am interested in any pipeline snippets and tastefully edited helm value files, and I mean in case of doubt just infodumping stuff in the wiki is better than not having it anywhere, but possibly you have ideas which would be superior
Micke Nordin
@mickenordin
Since I cant use the helmcharts from the official repo, due to the dns issue, my idea is now to dump out the manifests that is running now and use that as the kustomize base layer. And then I can create overlays for prod and test (and if I want to deploy a completly rds-setup for each of our customers). That way I can learn what is actually running and not have a black box created from helm and I can easily manage secrets and have different settings for each customer and such. I have an export of everything running now which I am going through now looking for all secrets and such.
Juri
@juriroemer
@Deaddy While I fully support this, I want to suggest to use the documentation/website and to avoid use of the github wiki for as much as possible and sensible. A single source of truth will be way easier to maintain.
Maybe we can come up with a good distinction between what goes into the website and what might go into the wiki. E.g. having troubleshooting related stuff in the wiki, as Marcel already kind of started with. Although I'm not fully convinced that that shouldn't go into the website instead of the wiki.
Marcel Wunderlich
@Deaddy
I always think of websites as curated wikis, so as stuff matures it ends up on the website
or maybe I think of as wikis as dumping grounds just to make sure stuff is somewhere
Marcel Wunderlich
@Deaddy
speaking of not being able to use the helm charts, we are currently disagreeing with the things dnsviz shows and can not reproduce any error there :-)
so when doing the dig things which people who know about dns do, it all looks pretty much exactly as it should
also when updating the dnsviz page it sometimes just displays different things
Micke Nordin
@mickenordin
So both ms1.k8s.wwu.de and k8s.wwu.de have their own SOA records?
Marcel Wunderlich
@Deaddy
I think so?!
dig SOA {ms1.,}k8s.wwu.de looks good
Micke Nordin
@mickenordin
Because I was stairing at the dns issue yesterday, and I was wondering if the problem was that ms1.k8s.wwu.de was delegated to its own dns-server/zonefile but k8s.wwu.de was handled in the same dns-server/zonefile as wwu.de, but I am not a dns-expert by any means so I don't know
Marcel Wunderlich
@Deaddy
so we accidentally looked at things and I think it would be best if we migrate the helm charts to our own helm repo service
instead of doing whatever we currently are doing
Dave Tromp
@davetromp
I just ran into following issue that might interest you all: Sciebo-RDS/connexion-plus#2
Juri
@juriroemer
@davetromp thanks! I will bring up and discuss this with Peter on Friday and get back to you/comment on the issue. But looks to me like switching to OpenTelemetry is the way to go