Remove feature to assign different service accounts based on admin status

2i2c-org / infrastructure

Infrastructure for configuring and deploying our community JupyterHubs.

https://infrastructure.2i2c.org

BSD 3-Clause "New" or "Revised" License

105 stars 64 forks source link

Remove feature to assign different service accounts based on admin status #4818

Open yuvipanda opened 1 month ago

yuvipanda commented 1 month ago

More conversation in https://2i2c.slack.com/archives/C055A1J1DRP/p1724674978690759?thread_ts=1724058742.347159&cid=C055A1J1DRP.

We accidentally committed to a product feature (allowing different cloud permissions based on admin status) via tech support rather than through the product process. This means we have a half complete feature lying around.

Based on the prior linked slack message, we have decided to remove this feature. It can be reprioritized as a product feature and deployed as needed.

Tasks

[x] Check with @jmunroe if anyone will be sad to see this feature go from the opensci hub (https://github.com/2i2c-org/infrastructure/issues/4818#issuecomment-2472220610)
[ ] Remove all code that supports admin-sa feature from our codebase

Definition of done

[ ] Ability to setup different cloud permissions based on admin status is fully removed from our codebase

haroldcampbell commented 3 weeks ago

@Gman0909 please review this and figure out where it goes on the product roadmap.

Gman0909 commented 3 weeks ago

I've added the feature to the product roadmap, but would like an update from @yuvipanda as to whether this task, of removing the half finished implementation, still needs doing.

yuvipanda commented 3 weeks ago

It does need doing!

Gman0909 commented 3 weeks ago

OK, moving back to refined.

sgibson91 commented 2 days ago

A couple of clarifying questions here since, as noted, this is a half-baked feature so the knowledge is not distributed across the team.

Check to see if the community we deployed it for is actually using this feature

Who is the community? I'm guessing from the mention of Ryan Abernathy in the linked issue copied to product board that is linked to from a Slack thread linked in this issue that the community may be LEAP. Can we confirm and propagate that info into this issue so that whoever picks it up doesn't have to go down the same rabbit hole I just did? There is also a mention that we support this on GCP and AWS - who (if anyone) is the likely community on AWS?
Can we have links to at least the files that contain the code that needs removing?

With these two points answered, I would consider this issue to be truly refined and easily picked up by anyone.

sgibson91 commented 2 days ago

AWS community may have been M2LInES? I can't remember if they were AWS or GCP, and they've been decommissioned now anyway.

yuvipanda commented 2 days ago

https://github.com/2i2c-org/infrastructure/pull/3952 was the PR partially adding this feature. Digging through that, I see that opensci is the community this was enabled for. And it was used to give admins ability to upload files to the [opensci-persistent-sciencecore](https://us-west-2.console.aws.amazon.com/s3/buckets/opensci-persistent-sciencecore) s3 bucket. I see files in there mostly from April 16 - the same day the PR was deployed, and untouched since.

So I think the confirmation is to ask @jmunroe (original requestor of this feature) wether this can be removed. I'll update the body

yuvipanda commented 2 days ago

Thanks for spotting what was missing, @sgibson91. I've updated the description and it's back to refined now I think.

jmunroe commented 2 days ago

I agree this looks like it was a one-off solution to a need that a community needed in April 2024. I concur with removing the feature if it not part of our standard offerings.

If and when there is demand for such a feature it rightly should be go through the product process.