Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Mar 27 15:05
    dependabot[bot] synchronize #113
  • Mar 27 15:05
    dependabot[bot] edited #113
  • Mar 27 15:04
    dependabot[bot] edited #113
  • Mar 27 15:04
    curoverse-bot closed #102
  • Mar 27 15:04
    curoverse-bot closed #116
  • Mar 27 15:04
    curoverse-bot closed #117
  • Mar 27 15:04
    curoverse-bot closed #120
  • Mar 27 15:04
    curoverse-bot closed #121
  • Mar 25 17:55
    curoverse-bot closed #122
  • Mar 25 07:07
    snyk-bot opened #124
  • Mar 25 00:54
    snyk-bot opened #123
  • Mar 17 07:53
    MajewskiKrzysztof opened #122
  • Mar 03 21:27
    dependabot[bot] synchronize #120
  • Mar 03 21:27
    dependabot[bot] edited #120
  • Mar 03 21:27
    dependabot[bot] synchronize #121
  • Mar 03 21:27
    dependabot[bot] edited #121
  • Mar 03 21:26
    dependabot[bot] edited #120
  • Mar 03 21:26
    dependabot[bot] edited #121
  • Feb 29 09:13
    dependabot[bot] labeled #121
  • Feb 29 09:13
    dependabot[bot] opened #121
Peter Amstutz
@tetron
UserMerge -> I have to migrate one user account to another on a specific cluster
when LoginCluster is set, UserList gets redirected to the LoginCluster
UserUpdate gets redirected to the cluster that own the record. which is a problem in this specific case of needing to change the username of the user record on a remote cluster because I'm about to migrate to a new user who needs that username
Peter Amstutz
@tetron
UserMerge -> current behavior is master is to redirect the request to the cluster that owns the "old user", but I need to do the merge on the cluster that own the user as well, and I could even be merging one remote user to another remote user
on a 3rd cluster
again, I worked this all out already provided I have a way to tell controller's federation logic to get out of the way and I can reason about a single cluster at a time
Tom Clegg
@tomclegg
does the migration script assume the clusters are otherwise idle?
Peter Amstutz
@tetron
yes, I think the documentation says as much
"To avoid disruption, advise users to log out and avoid running workflows while performing the migration."
Tom Clegg
@tomclegg
so, for the UserUpdate problem. You need to create a new user account aaaaa-2, which has the same username as aaaaa-1, but aaaaa-1's record is already cached on B and would conflict, so you need an "update B's cached copy of aaaaa-1" API...?
Peter Amstutz
@tetron
yes
well the existing update API works fine if it doesn't redirect the update to another cluster
usernames are awkward because they are unique on a given cluster but if you have several remote accounts you end up with username username2 username3
so there's no "right" username
so if say the account associated with username3 is going to be the new one, it renames username to usernamemigrate and username3 to username and then as part of the account merges usernamemigrate and username2 go away
Peter Amstutz
@tetron
@tomclegg so I added a no_federation flag to user update and finally the federation user migrate test passes again. so I'm open to changing the specific API or parameter or flag if you have opinions but I need to know what it is
Tom Clegg
@tomclegg
hm. well, editing the cached record seems kinda kludgy but I don't want to get too pedantic about it. I can see the attraction of an admin-only "bypass federation and go straight to local" flag, basically just for admin tools like this.
So "update user" is the only API that needs a bypass?
Peter Amstutz
@tetron
ListUser and MergeUser as well
well for MergeUser it is unclear federation makes sense at all, it should probably always go to local
@tomclegg so in the current branch ListOptions and UpdateOptions gets an additional no_federation flag
@tomclegg it isn't being enforced admin-only mainly because I didn't dig deep enough into the code to see if the current user record is available in the context at that point or not
Tom Clegg
@tomclegg
ok. IMO bypass_federation would be a bit more obvious (doesn't mean "don't do it if federation is in play") and it should be ignored/rejected for regular users, although as you say that might be too annoying to implement
Peter Amstutz
@tetron
happy to rename the parameter
Tom Clegg
@tomclegg
Is the extra param going to crash the script if the cluster doesn't advertise it in discovery doc? (and do we care?)
I mean, if one of the clusters is old
Peter Amstutz
@tetron
I don't know. I can add an assertion that it is present and/or check the API revision.
this definitely won't work with any cluster pre-2.0.2 I think
Tom Clegg
@tomclegg
yeah, it might be fine/desirable for the script to error out if some participants are too old
Peter Amstutz
@tetron
so it is easy for the Ruby API server to reject the request if a non-admin provides bypass_federation, on the other hand the controller would already have changed its behavior because of the flag, which sort of (although not completely) defeats the purpose of rejecting it, if we are already looking up the user by token in controller then it is easy, but if we are not doing that, I don't really want to do it now
the only other idea I had was if the parameter should be cluster_id=(local) instead of bypass_federation=true
Tom Clegg
@tomclegg
yeah rejecting it in Rails if non-admin sounds good
overloading the cluster_id param sounds like the sort of thing that gets messy later
Peter Amstutz
@tetron
is it overloading it though? I thought purpose of that parameter (in other places it is used) is to by explicit which cluster gets the request
although it might also imply some extra functionality around redirecting requests that we don't really want to get into now
Peter Amstutz
@tetron
ok
bypass_federation it is
Tom Clegg
@tomclegg
yeah generally overloading becomes painful, no need to sign up & find out for sure this time :)
Lucas Di Pentima
@ldipenti
@tomclegg I finally was able to start an arvbox instance with the latest Pam login updates. I’m getting this: request failed: http://localhost:8004/arvados/v1/users/authenticate?forwarded_for=&remote=: 401 Unauthorized: Not logged in (req-1k63b8naqzmnb18ay4w0)
Seems that railsAPI is expecting a token?
My cluster config override file is:
Clusters:
  x2gdd:
    Login:
      PAM: true
      PAMService: arvados
      PAMDefaultEmailDomain: example.com
      ProviderAppID: ""
Tom Clegg
@tomclegg
hm, it shouldn't be sending a request to Rails at all. That config looks right. Is it possible you didn't rebuild cmd/arvados-server?
Peter Amstutz
@tetron
possibly related but I noticed that because forwarded_for and remote don't have omitempty they get added to queries and makes some things behave strangly
Lucas Di Pentima
@ldipenti
I had to start a fresh arvbox from master and then re-write arvados dir with the branch version, but if it’s using the master version it wouldn’t have Login.PAM exported, correct?
Peter Amstutz
@tetron
I fixed that already in the user listing branch
Tom Clegg
@tomclegg
yeah, that's true about exporting Login.PAM in config... yeah I can't see why it would be forwarding the req to rails.
Tom Clegg
@tomclegg
@ldipenti I'm heading out but maybe/hopefully I come up with another clue about that. For now I'm mystified.
Lucas Di Pentima
@ldipenti
Ok, I’ll try to see if there’s more data on the logs
Lucas Di Pentima
@ldipenti
@tomclegg It was because I was passing 'X-Http-Method-Override': 'GET'
Lucas Di Pentima
@ldipenti