IT Bureaucracy #8

Open
opened 2022-10-10 23:51:37 +00:00 by jonny · 1 comment
Owner

The work I'm proposing will be largely that of building networking and public-facing digital infrastructure, and I think that could be substantially hindered if I can't have relatively fluid control over networked devices and hardware. It sounded like there were some options for how we could deal with it, but I don't think I'd be able to actually accomplish the kind of project I have in mind if I have to rely on externally controlled hardware without root access connected to a very strictly controlled network. The worst-case scenario for me would be to spend >6 months building something on a test server but then find out, for one reason or another, it was impossible to deploy it either in our lab or between labs, so I wanted to raise this concern to maybe game out some options.

A few possibilities here:

  • It seemed like the restrictions were largely confined to the medical school, so we might consider setting up some of our servers in a different department - eg. here we have a datacenter where labs can set up, host, and administer their own servers but the servers live in a common temperature/security controlled place. The question would then be to what degree we are able to virtualize that by shelling into the server/communicating it via nonstandard protocols from computers in the labspace. If it's possible to just stream all the data we'll be collecting to a server in another place instead of literally in the room our lab is in, then that seems fine, but I think I just need more clarity generally on what the restrictions are.
  • In the short term I could set up a local development network (that would probably be the best idea anyway) but it would still need access to the internet - is that allowed? Eg. Can I put multiple servers behind a router/switch, and then either tunnel all of their connection through a VPN or else have them banned from connecting to other computers on the broader network, whatever IT needs? I'd really need to have reimaging the machines not be a problem to do this kind of work, because being able to control the entirety of the environment is pretty critical to being able to develop system-level software - it sounds like that's already the norm, but since these will be pretty loudly connecting to the network I just wanted to check that that wouldn't be a problem.
  • Related to #7, I'd like to hear more about efforts at a broader department-level push towards more reasonable IT restrictions, because eventually I'd like to start experimenting with connecting multiple labs data systems together.
The work I'm proposing will be largely that of building networking and public-facing digital infrastructure, and I think that could be substantially hindered if I can't have relatively fluid control over networked devices and hardware. It sounded like there were some options for how we could deal with it, but I don't think I'd be able to actually accomplish the kind of project I have in mind if I have to rely on externally controlled hardware without root access connected to a very strictly controlled network. The worst-case scenario for me would be to spend >6 months building something on a test server but then find out, for one reason or another, it was impossible to deploy it either in our lab or between labs, so I wanted to raise this concern to maybe game out some options. A few possibilities here: - It seemed like the restrictions were largely confined to the medical school, so we might consider setting up some of our servers in a different department - eg. here we have a datacenter where labs can set up, host, and administer their own servers but the servers live in a common temperature/security controlled place. The question would then be to what degree we are able to virtualize that by shelling into the server/communicating it via nonstandard protocols from computers in the labspace. If it's possible to just stream all the data we'll be collecting to a server in another place instead of literally in the room our lab is in, then that seems fine, but I think I just need more clarity generally on what the restrictions are. - In the short term I could set up a local development network (that would probably be the best idea anyway) but it would still need access to the internet - is that allowed? Eg. Can I put multiple servers behind a router/switch, and then either tunnel all of their connection through a VPN or else have them banned from connecting to other computers on the broader network, whatever IT needs? I'd really need to have reimaging the machines not be a problem to do this kind of work, because being able to control the entirety of the environment is pretty critical to being able to develop system-level software - it sounds like that's already the norm, but since these will be pretty loudly connecting to the network I just wanted to check that that wouldn't be a problem. - Related to https://git.jon-e.net/work/postdoc/issues/7, I'd like to hear more about efforts at a broader department-level push towards more reasonable IT restrictions, because eventually I'd like to start experimenting with connecting multiple labs data systems together.
jonny added the
concern
label 2022-10-10 23:51:37 +00:00
jonny added this to the Project Details project 2022-10-10 23:51:37 +00:00
jonny added a new dependency 2022-10-11 02:23:50 +00:00
Collaborator

This is definitely a concern of mine as well. I think the short answer is, if we have to, we will just setup everything outside the reach of the Med School IT Department. I am not sure what this would look like but some options would be:

  1. Setting up equipment within a department in the Engineering School or regular academic campus. Other than working with slowish ethernet cabling in our building, there shouldn't be an issue with streaming data to equipment somewhere on campus or local.
  2. Rent a space in Westwood and house everything there.
  3. I'm sure there are other options too.

More likely though, we can work with IT to find a solution that works for everyone. There is a process for IT to grant exemptions from their normal restrictions which we can pursue even before you arrive at UCLA. I am confident we will have the backing of at least my department, and likely a few others, which will help. It probably would be a good idea for you and me to talk soon and flesh out what we would need. Then I can set up a meeting with you, me, and IT.

As I mentioned when you were visiting, there is a growing pushback against IT by basic research labs within the Med School. I think there is a lot of momentum here for us to ride.

This is definitely a concern of mine as well. I think the short answer is, if we have to, we will just setup everything outside the reach of the Med School IT Department. I am not sure what this would look like but some options would be: 1. Setting up equipment within a department in the Engineering School or regular academic campus. Other than working with slowish ethernet cabling in our building, there shouldn't be an issue with streaming data to equipment somewhere on campus or local. 2. Rent a space in Westwood and house everything there. 3. I'm sure there are other options too. More likely though, we can work with IT to find a solution that works for everyone. There is a process for IT to grant exemptions from their normal restrictions which we can pursue even before you arrive at UCLA. I am confident we will have the backing of at least my department, and likely a few others, which will help. It probably would be a good idea for you and me to talk soon and flesh out what we would need. Then I can set up a meeting with you, me, and IT. As I mentioned when you were visiting, there is a growing pushback against IT by basic research labs within the Med School. I think there is a lot of momentum here for us to ride.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Blocks
#1 Scope of Work
work/postdoc
Reference: work/postdoc#8
No description provided.