Allen Building Board Room
Note: ITAC meetings are digitally recorded for meeting minute generation; audio files for each topic are posted to an authentication-protected repository available on request to any ITAC member. Presenters are welcome to request to have their audio program excluded from the repository.
All times below include presentation and discussion time.
Agenda – May 23, 2019
4:00 – 4:05 – Announcements (5 minutes)
4:05 – 4:20 – ITAC Charter Discussion (15 minutes discussion)
What it is: ITAC supports the academic mission of the university through the appropriate use of information technology. The current charter is available on the ITAC website, and a draft revision was emailed to the council earlier this week for review. The ITAC Steering Committee invites council members to participate in a discussion to advise Duke IT leadership on these planned updates to the document.
Why it’s relevant: The current ITAC charter was penned at ITAC’s inception in 1995, with little update since its creation. As IT at Duke has evolved immensely since then, the charter is in need of an refresh to reflect ITAC’s role in Duke’s current IT landscape.
The ITAC charter has not been modified in 25 years. ITAC was formed as a successor to three previous committees to bring together the academic and administrative into one body. There is now recognition that information technology is a large concern of the university and there is a need for formal governance around information technology policy development, in conjunction with Academic Council and other university governance bodies. ITAC has been invited to become that body, necessitating a minor addition to its charter:
"Serve as the primary faculty-led body in advising and guiding consideration of technology-related and privacy-protecting policies; beyond the general advisory role,"
This is especially important around "privacy-protecting policies". ITAC is ideally suited to give faculty guidance about privacy-related policies given its informed and active faculty representation. The addition was crafted to provide guidance that would be considered, acknowledging that other groups also contribute to these issues.
Discussion:
The addition seems very reasonable. I initially thought "Does this mean we need a more formal relationship with the faculty council?" I realize now it is not eliminating the input from other parties.
This is similar but not as time-consuming as when edits were made to the "acceptable use policy", which took a year to complete. ITAC suggested changes but this was passed on to the body of every school, counsel, and finally to the Academic Council.
The faculty are formally charged by the Academic Council but perhaps we may want to re-formalize our relationship with these other committees, both more and less formal.
When we did the security camera policy, we did a similar process. We crafted a draft policy and brought it to ITAC but there were many other parties that were consulted.
I do question if there a need to include the word "academic" in our opening Purpose statement. We advise beyond academic matters and the text later does provide clarification.
As a reminder of process, we do not get to approve these changes to the ITAC Charter but to recommend them. Senior leadership is the approving body.
Regarding "membership", as we add this new language which arguably has more responsibility, we make sure we have a more deliberate process for representation of all the schools. There may be some that we are not reaching. The current language suggests this, but it is not explicit.
We can include "Faculty members nominated by the academic council and representing the breadth of the University".
The motion was made to accept the changes and submit this to senior leadership. The motion was seconded. Committee members present voted in the affirmative.
4:20 – 4:45 – OKD, Chris Collins (15 minutes presentation, 10 minutes discussion)
What it is: OKD is the next step in enterprise-class container orchestration for everyone at Duke. An open-source project maintained by thousands of contributors, OKD is now being used by OIT for container orchestration of all kinds: application development and hosting, large-scale on-demand infrastructure, compute job scheduling, external service provisioning, etc. Chris will discuss the internals of OKD, what it can do, and why it is a valuable new service for Duke.
Why it’s relevant: OKD is a powerful tool that is changing and streamlining how we work with web applications, Drupal websites, RestAPIs, and more. This summer, OKD will become a production service available to the entire university. It can support a huge variety of workloads currently, with future plans to accommodate even more.
Kubernetes has changed the information technology landscape in the past few years in a significant way. "OKD" (which uses Kubernetes) may have the same effect here at Duke. Kubernetes is a container organization platform that uses Docker and other components to run Docker containers. It orchestrates how these are configured and organized. It's declarative. It's coded regardless of where it's stored. Scaling plays a big part of Kubernetes.
Kubernetes is great for developer workflows. It removes the bottleneck of an operations task. Web developers are able to build the environment on demand. OKD is developer-centric tool that can deploy quickly and scale up and down while maintaining version control. What would have taken 2 weeks minimum can be completed in minutes. The reason why faculty would be interested in this is because of its multi-tenant hosting. You are able to put different workflows together but keep them separated from each other and have better hardware utilization.
Kubernetes by default is extremely difficult to configure. 90% of companies who attempt to stand up a Kubernetes cluster give up because of the complexity. We have been successful because we are a large institution compared to startups and small companies who lack these resources. In the end, these entities reach out to Amazon or Azure to run the clusters for them. We can run our own cluster because of OKD.
We have been working with faculty to help them "containerize" software for classes, building these containers with Gitlab and deploying these into OKD, including shutting them down when no longer needed. This can benefit other areas at Duke where you don't have to be a cluster administrator to provide services to others using OpenShift. The classic example is that database administrators can write an operator in Kubernetes language to request a database that is fully administrated, patched, updated, and removed. These complex things are beneficial in a security sense, too. The desired state is stored. Logs can be uploaded for analysis and environments can be monitored for security. A hacked website on a standard VM may not be discovered in a timely fashion but with OKD, there are two possible outcomes. First, we can immediately track down where the site was hacked, when it was hacked, what the vulnerability was, and who owned the site. Second, we can prevent it from being hacked in the first place because we can see what is being deployed and intercept it. So not only is OKD efficient, it is more secure.
Q: What does OKD stand for?
A: It doesn't stand for anything in particular. It represents the OpenShift Kubernetes distribution.
Q: Why would faculty care?
A: It's a flexible environment that supports what would otherwise be very complex.
Q: Is this more relevant to the system administration side? I already direct my students towards using containers. This sounds like meta-containers.
A: You can run the entire suite of your calculation in a more consistent way. It's more than what is running in the container. If your workflow is characterized by having a lot of components that need to assemble over more than one container, then Kubernetes is very interesting. Standing up multiple containers and connecting them together using automation is what OKD does.
I advise my students to run containers so that we can use services like the Open Science Grid or NERSK where we don't have to worry about the technical details for utilizing these facilities.
Kubernetes provides a language that is translatable to these other systems with widespread adoption. There are templates available that facilitate this flexibility. It can be utilized by people who aren't aware it's being used. For research computing, I think OKD is especially beneficial and even complicated projects can be replicated.
Q: Will you be offering training?
A: The reality is that it is difficult to on-board users. There is a learning curve but once you've passed this, OKD begins to make sense. OIT provides office hours and anyone is welcome to attend. We also work with the OpenShift user group. We want to build a community around this platform. We are writing documentation as well.
Q: When we have the new version of Kits, is this something utilizing OKD? At a recent presentation of Kits, we saw a dashboard-like experience. Are these in containers?
A: Yes. Kits is based on containers.
The difficulty is identifying what faculty want us to run. If we can find out this information at least a week before the class is scheduled to start, we may be able to provide this for them.
There are environments set up for faculty with continuous integration where they have full control to change the libraries or change the problems directed to the students. The faculty member can make changes even the day of classes.
Q: Most faculty are not familiar with the concept of a "container" or how to utilize them.
A: There are classes that are run at the Technology Engagement Center on containers. This does require some familiarity with the terminology.
We almost need "lunch and learn" sessions that are aimed at faculty and are given by faculty describing how they are using containers.
The way we have been on-boarding faculty in OKD is to set up a template with basic actions and show them where and how to make changes. However, we need at least a week before classes because this is labor-intensive.
But even this requires a faculty member to know this is called a "container" and it's useful.
A single container is a good way to package simple, run-once applications. OKD allows you to package an entire distributed computation environment in a reproducible way even though it was a complex multi-machine environment. These can also be signed to attest they are real.
4:45 – 5:05 – ParkDuke Application, Hugh Thomas (10 minutes presentation, 10 minutes discussion)
What it is: First introduced to ITAC as a Code+ project and collaboration with DTech Scholars in summer 2018, the ParkDuke mobile application is about to become a reality. This presentation will provide an introduction to the app and outline the planned project schedule – including an upcoming beta testing period for end user feedback.
Why it’s relevant: Parking on campus is a recurring pain point for faculty, students, staff, and visitors alike. ParkDuke, a convenient, easy-to-use, and powerful mobile app, is an important step toward improving the parking experience.
Last summer, six undergraduates worked to write or "code" a parking app. The students presented an overview of this app to ITAC and continued to work part-time during the school year with assistance from OIT for the payment component. There is now a version of this app on the Apple test flight store and an invitation will be sent out by email to around 50 participants. The app will be available for download on the public store by the end of June. Those with a night permit from Duke parking will participate as beta testers.
The app was designed for three different use cases, with permit holders being the primary focus. The other targets are campus visitors and hospital visitors. There are background features like dynamically allocating spaces in real-time as well as support for "push" notifications from Duke Parking (examples include important game day parking in the blue zone or traffic affected by construction). If there are problems purchasing permits, Duke Parking has the ability to push a permit to the user from within the app.
The process for purchasing a permit starts with a map of the parking lots. Alerts and spaces available in a particular lot are indicated on the map. A user can click on an icon where a "P" indicates short-term permits can be purchased. A color system is used to indicate capacity, green showing the most spaces available and red the least. Users will be presented with a list of the vehicles on record with Duke Parking. They can select the vehicle and purchase a temporary permit using Apple pay. The permit is pushed in the form of a QR code which can be scanned at the gate. There is also reporting and logging of purchases made from the app.
The app should be released by the end of this summer. There are discussions for integrating this into the Duke mobile app. Because of the special requirements for hospital guests, there is a need to have a standalone app.
The work that the students did last summer and continued through the school year with assistance from OIT have driven home that developing these apps and projects for "production" use takes a lot of effort. We have about 7 projects with Code+ this summer. While not all teams will produce a production app, this particular experiment has been very valuable in helping us determine what it takes to turn these into professional-grade code.
Q: Does this app know which lot is associated with the user's permit?
A: After you login, your permits are displayed including lots. Having a permit gives you the ability to access these other lots for temporary access.
There are some cases where we know that for students on East Campus, they are limited to six lots.
That is correct. All permits have restrictions on them that may not be well published or understood. For example, some permits have additional lots available to the permit holder after 5 PM.
Q: Will the parking map show all the lots where I can park that are included with my permit?
A: Wherever there is a "P" on the map, this indicates a place where a permit holder can pay to park.
This means that you will charge someone money to park in a lot where they already have privileges. This map is not reflecting places the user is already permitted to park. Is this correct?
That is correct. The locations where you can park are indicated on your physical parking permit, but this is not noted on the map. This may be because our test users were "Night" permit holders which are free. The app is still in beta but differentiating lots already available to the permit holder is certainly something that could be added as the app is improved.
It would be helpful for the app to display to the user all lots where the user can currently park for free keeping in mind that this can change depending on the time of day. During work hours, there are more restrictions than in the evening or the weekends or for special events like football games. This would be an attractive feature to users and could help drive adoption of the app.
Q: Is there any logic that prevents users from purchasing temporary permits early in the morning where the lot may not currently be full, but will be later as regular permit holders park in the lot? Is anyone looking at trends for each lot?
A: There is trend information inside the app but the data we are using for space availability is hard-coded because the parking department has allocated the spaces.
Q: A similar situation is where you are bringing a guest speaker and you would like to pay for the permit. Will the app permit me to park with my own permit and pay for admission for another driver or will it deny access for the second parking instance given that the entrance and exit is being tracked for the lot?
A: The permit is specifically associated with the app for one day parking privileges. It would be necessary for you to show your device in order for the guest to enter the lot. Perhaps in the future, there will no longer be a need for the physical permit and all parking management will be done from an app.
Discussion
I may be driving in a different car that is not on file with the parking office or I may forget my physical permit. It would be helpful if the app could display my existing permit so that I could use this to gain access to my regular lot.
We did have that as a feature but removed it. It introduced a situation where the permit could be used twice.
As a person who pays monthly for parking, this does make me consider whether it might be better to pay for a daily permit instead when I need to park.
There is a green initiative on this issue. People would be more likely to use alternate transportation if they were not paying a monthly parking fee.
Q: Does the app still have notices such as lots being closed on particular days after 5:00 for athletic events?
A: Yes. This is also tied into the Duke Parking website so that notices that are listed there are pushed to the app.
5:05 – 5:20 – TechExpo 2019 Review, Jack D’Ardenne, Carol Reaves (10 minutes presentation, 5 minutes discussion)
What it is: Duke TechExpo is an annual one-day conference for Duke IT staff – from both the health system and university sides of Duke – to foster professionalism, share expertise, and look into the future. Now in its 11th year, Jack and Carol will look back at April 2019’s Back to the Future-themed event, and solicit ITAC feedback for future TechExpos.
Why it’s relevant: A gathering of Duke IT people, by Duke IT people, and for Duke IT people, TechExpo provides opportunities to learn about IT contributions at Duke, enhance your skills, and connect with friends and colleagues across the university and health system.
TechExpo was held on April 12, 2019 with a theme of "Back to the Future" and a focus on the past and present of information technologies. The event was hosted at the Washington Duke Inn as it has been for the past several years due to its facilities and great location near campus. We are reaching maximum capacity with our attendance for this location. There were 829 registrants with 645 attendees, our largest ever with almost 100 more than we had last year. Our capacity at Washington Duke is around 650. We have been using Cvent for the event registration.
We ran 2 prize wheels and 359 spun the wheel. Those who won prizes were given a ticket which they redeemed at a vendor table. We implemented this last year as a way to increase visits at vendor tables. We had 32 presentations from Duke participants and 6 from vendors. Something we are exploring for next year is using lightning sessions. These would be sessions much shorter than the standard 45 minutes (around 20 minutes). There were 9 Duke posters and 34 from vendors. We used the Science Drive parking garage and two other lots with a running shuttle between these and the conference. We have received positive feedback on the parking solutions.
We were tasked with no increase in funding for 2019 and we were able to stay within our budget. We had one increase in our expenses with the Washington Duke in that last year's event was able to take advantage of a tent installed for alumni weekend. We paid for the tent this year as a precaution against inclement weather and it did rain. To offset the cost of the tent, we increased the cost of the vendor tables.
Something new for 2019 was a dedicated website of techexpo.duke.edu. Previously, our information moved from location to location. OIT Duke Web Services helped configure this as a Wordpress site. Our focus now is populating the site with information from this year and previous events.
Issues that we had during the event included a delay with badge printing for attendees who arrived at 8:00 AM. After about 15 minutes, we fixed the issue and badge printing went smoothly after that. We would have liked better audio during the keynote. And our logo could not be imprinted on items such as T-shirts and prizes due to copyright concerns. We also heard concerns from some vendors located in the tent area with poster sessions who didn't have the traffic that they would have liked. We are revisiting this for next year.
We do believe this was a smooth event and we had the largest attendance ever. We stayed within budget even with the inclement weather. We anticipate for future TechExpo events to continue reserving a tent to address possible poor weather conditions and to accommodate the attendee experience by locating buffet tables and snacks outside.
One of our committee members reached out to members of a DeLorean club and we were able to have to have 2 cars available for pictures. People were outside taking photos in the rain and see the inside of the car. This is also our second time handling on-site check-in and badge printing for our event without hiring a company to come on site (a significant savings). Our keynote was on machine learning and artificial intelligence and went well. The format was an open discussion and most of our feedback was very positive. One of the suggestions for doing things differently was to include a moderator.
We sent a survey after the event to the attendees and received over 150 responses. Survey respondents were asked what was most valuable to them. The interaction with colleagues as well as the Duke presentations were very popular. Most respondents felt that TechExpo was informative and helpful to them in their jobs.
A committee helps plan TechExpo and is made up of staff from Duke University and Duke Health and is advised by leadership from both Duke University and Duke Health. To improve the committee, we plan to document the roles and responsibilities of each subcommittee and we are trying to recruit new members including those who have never served. Other members remain on the committee in order to maintain continuity. We also plan to update our website and advertise poster sessions better and increase vendor traffic. The co-chair responsibility is a two-year commitment with overlap, meaning one chair steps aside and a new co-chair is selected.
Q: How do you choose the vendors?
A: The vendors reach out to us. We've been doing this conference for a while and have a list of vendors that participate year after year.
Feedback
We would like to thank those who organized the committee as well as IT staff and managers who allow and encourage this participation, both in planning the event and attending on the day. The fact that this is completely volunteer-driven is impressive.
In addition to the committee, there are many volunteers to help out on the day the event. We also did lose a few committee members because they were not aware of the amount of work that was involved. That is why we hope to document the roles and responsibilities so that the level of commitment required is not a surprise.
5:20 – 5:30 – Common Solutions Group, John Board, Tracy Futhey, Gagan Kaur, Charley Kneifel, Mark McCahill (5 minutes presentation, 5 minutes discussion)
What it is: The Common Solutions Group (CSG) works by inviting a small set of research universities to participate regularly in meetings and project work. These universities are the CSG members; they are characterized by strategic technical vision, strong leadership, and the ability and willingness to adopt common solutions on their campuses.
Why it’s relevant: CSG meetings comprise leading technical and senior administrative staff from its members, and they are organized to encourage detailed, interactive discussions of strategic technical and policy issues affecting research-university IT across time. We would like to share our experiences from the recent Spring 2019 meetings.
All of the attendees had a similar background and were very collaborative on topics like governance, security, and privacy. As we build up on our analytics team, the experiences of the other participants can really help us.
Duke ran a workshop on "The Continuous Cloud and Mobility", talking about containerization going back five years. One point that was raised was the lack of reliable IP numbers from cloud providers unless IPv6 used, a good motivator to migrate to this technology. Duke also talked about Bitfusion with FlexDirect, which connects jobs to the GPUs which can be on a different machine from the processors. We talked about this in the workshop and we are trying to get this running at Duke.
Another university is doing a massive replacement of enterprise systems to cloud services, ("cloud native"). They wanted to be able to move between cloud providers without being committed to a single vendor.
There were also discussions on supporting multi-campus research collaboration which turned into discussions on InCommon federated attributes shared across institutions and how this is moving slowly but there is progress toward common sets of attributes from the services.
There was a session on the "Immersive University", code for virtual reality or VR with a focus on identifying the educational value. There were some compelling experiential learning environments such as an ebola hot zone. Many of the schools pursuing this are looking for talent in the gaming industry with conversations about the trade-offs between fun and accuracy in some of the simulations and how engaging these experiences should be.
The "Balancing Modern Needs and Privacy Concerns" session discussed researchers accessing monitoring data using queries against aggregated data, not an individual's. One of our peer institutions now has educational analytics that can predict within a half letter grade at 87% accuracy how a student will perform in a class before it has started. This is a game changer for better or for worse.
"Strategic Network Design" covered schools that are doing network redesigns and spending a lot of money. This is driven by aging hardware unable to move large amounts of data needed for research. Security concerns are also a factor to easily segment traffic and keep "Internet of Things" devices separate from researchers.