Hi, we're here from Argo and Tecton to talk about pushing the boundaries of what's possible on Kubernetes. So, who are we? Well, I'm Alex, I work it into it. I specialize in Kubernetes and kind of OLTP stuff and the lead engineer on Argo workflows, Argo events and Argo labs data flow. And I like coffee and cycling. Ideally, a bike ride to a nice coffee shop is my kind of ideal Sunday. Yeah, and I'm Jason Hall, I work at Red Hat. I've been involved with various developer tools for nine on eight years now. I helped co-found the Tecton project and I like pizza and sitting and ideally sitting while eating pizza. And what do we do? Like Alex said, he works on Argo workflows. Argo workflows is a general purpose workflow execution engine. Steps in Argo run sequentially and tasks in Argo run in a DAG or a directed acyclic graph. It's built on Kubernetes and it has a cute logo. Tecton is also a continuous delivery-focused workflow engine. Steps run sequentially, tasks run in a DAG. It's built on Kubernetes and we also have a cute logo, they're friends. Why did we decide to build on Kubernetes? When building a workflow service, there are two, well, there are a lot of problems. Two of the biggest ones are node management, just managing the resources that will be doing the work and another is workload scheduling. So when a user's request comes in, I wanna do this work, putting that on one of those nodes to do the work. Well, if you are at KubeCon and know anything about Kubernetes, Kubernetes is very good at these and so by building on Kubernetes, we don't ever have to, well, we do have to deal with it sometimes, but mainly we just get to upload that and make it Kubernetes's problem. Kubernetes also has a great resource and custom resources. This lets us build flexible, extensible APIs inside the Kubernetes API server and ecosystem and we basically get RBAC for free. RBAC is another huge source of work if you don't have one already built for you and Kubernetes built that for us, so we love it. And then there is the long tail of just community stuff. That's all of you, that's everyone outside, that's everyone watching all of this later. There's a huge community around Kubernetes that provide people to look out for the security of the platform and the performance of the platform and observing the platform and portability across different architectures and platforms, client tooling for all of these things and multi-tenancy concerns and policy enforcement and tons and tons and tons more. All of these things are things that if we didn't build on Kubernetes, we would have to build ourselves and that would be a massive amount of work and largely pretty wasteful and instead we get to sit back and work on features while Kubernetes improves underneath us every day thanks to all of you. However, Kubernetes was not really designed for this. It was more designed for long running, serving workloads, things like deployments and services and ingress, the usual suspects. These things assume long running pods. Well, we have relatively short running pods and they assume long running containers and we have fairly short running containers and they assume no control over the life cycle of the containers starting and stopping. They just sort of assume they run forever. Well, we need to start and stop these things a lot and they have no convention for passing data from one pod to another. Pods are pretty isolated on purpose in the Kubernetes ecosystem. Well, we need to pass data between these things a lot. So these are the sort of four main points we're gonna talk about, container life cycle, starting and stopping, especially with regards to how sidecars are involved. Container IPC, inter-process communication, talking between containers and a pod. Cross-pod communication, talking between pods in a workflow and custom resource proliferation, which turns out to be a gigantic pain and with that I will hand it off to Alex to talk about container life cycles. Thank you, Jason. I just asked Jason if we could do something. Oh, I've completely forgotten. No, it's fine. Okay, so put your hands up if you're an Argo workflows user.  Tecton user, let the record reflect they had the exact same number of people. All right. Yeah, the great thing about this talk is we get to talk about things that we have in common, which is brilliant. And one thing that we have in common is a container life cycle. Now, both Argo and Tecton execute processes in graphs in a directed acyclic graph and that's not something that Kubernetes supports out of the box. And to make things more complicated we actually can do things like modifying the graphs at runtime. So in a way that you specify in your pod spec what containers that you want to run in that pod without our workflows and our graphs we don't necessarily even know what the containers are gonna be when we start it. And we have some nice simple ones but we also have some pretty big graphs that we run 20, 30,000 pod graphs sometimes and this is an example from the community. I can't even make out how many there are there. So what does Kubernetes provide out of the box for startup? Well, it kind of provides two options. The first option is init containers. It's pretty simple but it actually does fulfill some pretty simple and useful use cases that allows you to start a whole group of containers and they have to run to completion before you then run your main containers. And the other option is effectively run one container in a pods and then you use the Kubernetes API to order the pods execution which is expensive because pod creation isn't actually that as cheap as you might imagine. And then the other thing we need to do for lifecycle management is ordered container shutdown. So what we wanna do is shut down the containers in a specific controlled order, stopping container B before stopping container A and when they stop, when they're shut down they need to be able to do some graceful termination, clean up, flushing their buffers, that kind of stuff. And that shutdown really needs to work with standard Kubernetes shutdown. And so the way that Kubernetes shuts down a pod is firstly you get a SIG term to the root process, then you get 30 seconds, configurable, yes I know, followed by a SIG kill, a hard shutdown. So you need to work nicely with SIG term. So the way that we do this, the primary way that we do this is what we have termed the command look pattern which we termed Wednesday last week. That's why you've not heard of it. But you probably know this better in tecton as the entry point rewriting or in Argo workflows as the MS area executor which is very heavily influenced by tecton. How does this work? Well, it's actually pretty simple. It's actually described completely by this YAML on the right hand side but let me walk you through it first. What we wanna do is we wanna replace the user's command with our own command that forks the user's command as a sub-process. And the way that we do that is we'll have an init container and both the init container and the main container will share an empty directory volume and the init container will just copy that binary onto that volume and then that's made available to us in the main container. So they don't need to be baked into the image of the container. This doesn't mean this is really handy. Actually just loads of things that are really useful for us. So it allows us to do that ordered startup because the entry point, our new command can wait for some condition before the sub-process is started. That we can use that as a way to signal the sub-process. So to send sig terms and sig kills when we want to send them to it. We can actually capture the sub-processes standard in, standard out and exit code and you can actually do things like remap the exit code to a different exit code if you want to. We can also wait for a condition before shutdown which is pretty neat for debugging. So the user's main process can finish that sub-process finishes and then that container is held open still running while you can connect with kube exec to do some debugging. And the great thing is it that it's very difficult with two containers in the pod is they can access the same file system. So you can get access to any files on the user's file system because actually your process is running in their file system. Has a couple of caveats, couple of downsides. If you're gonna delay the start of that sub-process based on some condition, then that container's still gonna be running and it's gonna be consuming memory and it's gonna be costing you money as a result of that. Now it'll be set by your resource requests. And typically this kind of commandlet doesn't need very many resources at all. It can be pretty skinny, pretty lightweight. But your main container may be doing some really heavy lifting and might have some high CPU memory GPU requirements. So that could be costly. And you can mitigate that by working with resource requests. And the other thing it doesn't really allow us to do is we're still tied to pod specs so we can't dynamically add containers to the graph. Originally our title list title just shut down but it's really shut down in sigterm, I think. So how can you ask a process to gracefully exit? What you need to do with the sigterm and there are two ways to send that signal today. One is to delete the pod which is a pretty, it has the downsides that the pod is deleted so you can't inspect the pod afterwards, can't look at status afterwards once it's deleted and unless you've archived the logs you lose access to the logs. And the other one is to use kubectl exec kill one. But I hope some people can realize the problems with that.  Most pods don't have a kill binary on them. They might be a scratch or distreless images because security is more important now I think for many people than a year ago. And so those images are much more common. Or it could be something like Debian where the kill isn't a binary, it's a built-in, shell built-in. It doesn't necessarily work with shell scripts.  And finally, if you're running this non-root, your root process won't be started with PID number one. So kill one, I mean, won't do anything at all in those containers or I think a return and exit code. So here are a couple of mitigations for that. One is to use dominant. So there are, I think there are two or 300 mutations of this. The one I know is by Yelp. And that provides an init process which handles those symptoms correctly and that can fix your shell script forking and get those guys to shut down correctly. Like we did for the entry point and you can have your init container copy a kill binary onto the image, onto that shed directory and then you can actually just invoke that directory and you'll know the path to that. And actually you can write kill in about 20 lines of go.  Well, and to mitigate the PID one issue, you can use the PID of command to figure out which PIDs to do it and there are various other ways to do that. Now I can't talk about this with just saying if you wanna find out more about this, Jason and Christie Wilson spoke about this in depth at KubeCon 2019, which feels like a very long time ago. And there's a link there in the slides if you wanna find out like a load more depth about it. It's hard to talk about writing your own controller and creating pods I think without talking a little bit about sidecars. So a little bit of revision for anybody who doesn't know what a sidecar is. A sidecar is just a container that runs next to your main container provides some kind of facility. It's usually some kind of cross cutting concern. This example is straight out of Kubernetes documentation and it shows a log collection sidecar. Pretty standard stuff. Now the problems with sidecars is we don't control them and they can become quite unruly. You know, we don't know how they behave. We don't know if they're going to accept sigterm correctly and run it. We don't even know if they have an init process. They're a bit of a black box to us. And it gets kind of even worse when we talk about injected sidecars like those that come with Istio and Vulse. So an injected sidecar is a term we use to describe a container that's added to the pod spec after creation by a mutating webhook controller. And because it's added by that mutating webhook controller we just don't, we don't have any information about it. We can't intercept it or change it. We can't rewrite the entry point. Now Istio does provide a quick, quick, quick endpoint. I think that's how you pronounce it, quick, quick, quick. But it's not really a standard. And our solution today, certainly for workflows, is if people have Istio Vault running, we say, well, disable it. And that's a shame because people want to use those technologies for really good reasons. And we'd really love to be able to support them doing that. Container IPC, or if I've termed it, CIPC. Again, I made up last Wednesday. It was a big day. It was a big day. It was a productive day of making up new terms. So why would we want to do container IPC? What's our use cases for it? Well, it's typically about sharing data between two containers. So for example, you want to download a file from S3 or some other kind of bucket storage and make it available for that main container. Or you might want to do some kind of remote procedure calls between the two containers. Or you might want to do some kind of streaming data. Get messages from Kafka and provide those to the main container amongst quite a few different use cases, I would say. Now, container IPC is just Nick's IPC. And there are about five to seven to nine different ways of doing Nick's IPC. And I'm going to talk about a couple of them that we've found that work really well with our systems. The first one that both Argo and Tecton use is this ubiquitous shared empty volume. Alex, how do I solve this problem? Well, I think it's pretty solved by a shared empty directory. But any Argo workflows users know that it's not too far from the truth. So the shared empty directory allows you to communicate between two processes, typically using some kind of marker file. So one of the two processors will write a marker file into that directory. And the other process will let sit there polling for changes to that file. And when that file has changed, it's going to read the contents and perform some kind of option. Obviously, in a shared empty directory, you can mount a FIFO using MKFIFO or whatever your language's FIFO creation API is. And that's quite fast if you want to just do read and write of bytes. But it's not particularly proven. If you look out there, there's not too much documentation on that. But the nice thing about shared empty directory volumes is that they're really simple. I mean, just so simple. They're super secure and they're really robust. So they're great for what I would call a slow IPC where you don't have a lot of data going through. And those messages don't change a lot. But if you want something faster, then there's another really great tool in the toolkit to use. And that's just HTTP. HTTP has these great benefits of being well known and easy to implement. Most programming languages come with HTTP server and HTTP client built into them. So you don't have to worry about checking your dependency tree for those problematic security issues. It's just part of the core SDK. You need to define an API contract. Not particularly difficult. The nice thing about this is it's actually relatively secure. You actually don't need HTTPS between two containers within the pod because they have own network namespace. You can just use HTTP. And it's actually pretty fast. It's pretty fast. Especially if you are using HTTP Keep Alive, so you don't have the socket establishment cost. And you're using Unix domain sockets as well. You can get a pretty nice performance and throughput benefit from using those. And when we rehearsed this earlier on, I was telling Jason how Java 16 now supports Unix domain sockets. And it turns out I should have also been talking about Java 17, that's out recently as well. So yeah, widely supported Unix domain sockets. And this is great for fast IPC, if you've got a lot of throughput. Now are there other ways of doing container IPC? So these are some of the examples of the kind of TPS messages per second you can get with some of the other technologies out there. So things like pipes, message queues, POSIX and SysPy message queues, shared memory and memory map files. And if you just take a look at this graph, you can see that the throughput you can get from memory map files is, what is that, 20 times? 20 times faster. So there's like, there are other ways, much, much faster than TCP. But these are kind of unproven and in the kind of research that I've done on this topic, it has been a bit heavy dragons on the internet. And I'd love to hear from anybody who has looked at memory map files between containers and be fascinated to know what their results were. Mechta, my colleague, Jason. Thank you. So like with containers, we also need to pass data from one pod to another pod efficiently. For example, the canonical use cases for this are, if a task does it get clone of some revision of some repository, it might need to pass the commit that was actually checked out to the next task in the pipeline. Or if it built a container image, it would need to pass the digest to the next task that signs it or scans it or does something else with it. We also need to expose that information up to the user that's looking through the API or the UI or CLI. And these are all short-lived containers that we don't necessarily control. So we don't have a lot of options for having users request HTTP endpoints directly on those containers to get that information. And so in Tecdon, at least, we've found a fun little work around using little new technology called termination messages. Not a lot of people know about this, or I don't think they do, but if you write to this magical path in your container slash dev slash termination dash log by default, it will magically get collected by the Kublet and written up to the pod status for that container. So this is a little way to ferry information out of your pod, out of your container through the pod up to the API server. And it's configurable with the container's termination message path. So yeah, the more you know. So the way that Tecdon uses this is if a container, if a step container writes to slash Tecdon slash results slash something, the injected entry point that Alex talked about before will, after the step is complete, it will scan all of Tecdon results and see if there's anything in there. It will collect that information. It will stuff it into a JSON string and write it to its termination message path that gets collected by Kublet, written up to the API server. The controller watching that pod pulls out that JSON and then puts it into the task run status where it goes. And this lets us pass that data on to other tasks and show it to end users. We also use this to report the actual start time for the containers. So like Alex said, all the containers start at once and then only the first sub process starts and then only the second step sub process starts when that's done. So we lose the actual start time of each of these containers but we write it to the termination message path as well. So there are some limits with this though that we have started to hit. And that's that the Kublet will only write, will only collect 4K of data to pass up per container and only 12K of data across all the containers in the pod. This is mostly enough to get the job done if we're talking about Git commit shas and container image digests and timestamps and relatively small bits of information but it will start to break down if you do anything more crazy than that. And it's really only a matter of time before people come and ask if they can do something more crazy than that. To poorly paraphrase Steve Jobs, 4K should be enough for anybody is not actually true as it turns out. And we've talked about compressing this data, compressing the data better than JSON or encoding it in something better than JSON but ultimately if the 4K limit is there you're gonna hit it one way or another eventually. So something we started to look into is instead of writing to that termination message path we will have that injected entry point contact the API server and write to a config map. The config map max size is much, much larger than 12K. And so for every task run that will run we'll create a config map to hold its results. The entry point will write that data to the config map and we can tightly narrowly scope the RBAC to that results object to so that the entry point is only allowed to write to it and the controller is the only one allowed to read from it so you can't have cross task contamination in the results. And that's basically exactly what Argo Workforce does. So it's nice to have proof that that works. There are however some disadvantages. If we want to use config maps we can use config maps. If we wanted to use our own type that we define we now have to define that type and manage that type and version and upgrade and validate that type. And the sort of bigger concern is the additional load on the API server. So instead of just writing to the pod that we already use and update all the time we're also making frequent writes to this config map or another custom resource. And we have to create RBAC for that on every new task and every new execution and manage it and delete things when they're done so they don't leak and it can get difficult. That also leads me to my next issue that we have started to hit which is custom resource proliferation. As I said before, custom resources are great. Texon wouldn't exist without it. Argo wouldn't exist without it. Plenty of other things in the ecosystem would not exist if Kubernetes didn't provide an extensible API server but fundamentally they're not magic. At the end of the day CRDs are just writing to etcd and etcd while also really great is not magic. It's not the key to unlocking free infinite scalable storage.  You will start to experience pain in a few dimensions. One way you can mess up at CD is to write too many bytes. Like I said, it's not an infinite storage. You will eventually hit some limit and etcd will start to fall over.  And if you're just constantly writing requests to etcd through the API server and constantly updating etcd you won't like it and will fall over. De-stabilizing etcd is really, really, really bad. The cluster just sort of starts to act funny and things don't work and requests start to time out. And what's up, yeah, pagers go off and you get angry calls from SREs. And the worst thing is that you can't debug it because you're using the system that's destabilized to debug it.  We have discovered some mitigations for this. One really easy one is don't use jobs when you really just want pods. If you create a job, it will just create a pod for you and now you've created double the resources and double the QPS because when the pod updates it'll update the job and then you read the job. So that was an easy one. That's like 50% off right there. Avoid unnecessary updates to your objects if you can in your reconciled loop instead of making 10 requests to update the status of something, batch those until the end and make one update at the end.  So Tecton actually doesn't do this well today. When a task run status is actually copied and aggregated into the pipeline run status for ease of the user but that means that we have to make two updates every time anything changes. Also avoid these monolithic mega objects like the pipeline run because you will update them more often and they start to hit those size limits that we talked about.  Argo actually has a really interesting feature that I didn't know about until earlier until we were working on this talk which is that if the status of an Argo object gets too big, the controller will offload it to another database and just give it a pointer to that.  So that's really interesting. Other mitigations we've had for custom resource proliferation are just resource quota. In a namespace, you can say this namespace is not allowed to have more than 1,000 task runs ever and if you try to create 1,000 in first, it will fail. You might also want to prune old resources. We do this in Tecton a lot today but the question there is always like do you want to prune by age? Do you wanna say something I only wanna keep the last week of history or do you wanna prune by number of resources? I only wanna keep the last 10,000 requests whether or not however old they are but fundamentally users don't wanna lose this data especially if it's security sensitive like what did we deploy three months ago? Well, sorry, we needed that space so we deleted all record of that deployment ever happening is not a good answer for users. So Tecton and Argo have also solved this in a similar way or planning to solve it in a similar way. In Tecton, we have a Tecton results project and in Argo, they have Argo workflow archive which effectively runs another controller to watch for these executions. When they finish, it copies that data to another relational database and then prunes that object from the Kubernetes API server. This also gives us an opportunity to have better indexing and searching and you can search for failed task runs that took more than 30 minutes in the last 20 days which is not something as far as I know you can do with the Kubernetes field selector today. But unfortunately this means like we lose all of the, some of the nice ecosystem stuff of like kube control doesn't work and all of these things need to be sort of custom built to support that. So are we gonna do this? Yeah, we're gonna do it. We're gonna do it. So what can we do about this? Well, we could do nothing which is my first option. I always present everybody in my organization. What is doing nothing mean? Keep working around it. Yeah, we just keep working around it. It's kind of value add for both Tecton and Argo because Kubernetes doesn't support this out of the box. We get to add that value to it and if it was supported, we wouldn't get to that but we could do... Boop, boop, boop, boop, boop, boop. Caps! That was the thing. We enjoyed that. I did. You did, okay, we won't do it again. We'll never do that again. So, we were great to go out and add some additional features to Kubernetes. So one of the things would be an API to start and stop containers. That would be fantastic, like a container sub-resource or something along those sort of lines where you can say, stop the container, start the container, don't start this container just yet. It would be nice to be able to declare the daggers a dependency tree with inside the container spec. So say container two is dependent on container one. We could have that, that would be pretty neat. We've talked a bit about standardizing the commandlet pattern. So maybe providing a library that people could use that is kind of well-tested and robust that you could just use that and that commandlet would expose some kind of API that people could use that would allow you to use kubectl-exec or curl to just invoke commands on it and it would deal with it for you. And for resource quotas, so people use resource quotas to limit the number of custom resources in a namespace, typically used for limiting the number of pods but you can use it for custom resources. But it'd be nice if in that we could specify what to do when there are too many, you know. Some kind of strategy saying, for example, delete the oldest one of these custom resources and kind of clean up afterwards. I think that would be pretty neat. I guess we've freestyle a lot of these ideas, don't we? Yeah. Yeah, so I think it's kind of like an interesting space to kind of think around in it. Yeah, so with that in mind, do we have any questions from the audience? Yeah. So the question was given, a common use case for tecton at least is clone some source from a repo and then build it, run tests, do other stuff, scan it, do, you know, let's say five other things in parallel. Currently today we would ask you to make a PVC to have one task write that data to a PVC and then share that PVC read only to the other ones. There's some, and obviously there are downsides to that of now you have this PVC you have to clean up or at least have around and it can limit your schedule ability of those things. There's some interesting work going on in being able to run all of a pipeline in one pod. So effectively that would, you would have one big pod that does all the resources of all of those things and they would run in one shared on the same node, but in that way you wouldn't have to write the persistent data outside of the execution of that pod. There's, if you find me afterwards I will send you a link to the actual proposal for that, but I think that's an exciting sort of area, a frontier of solving that problem. Yeah, so you can also do the, sorry, the follow-up was instead of using PVCs could you write to some external object store S3, JCS, whatever? Absolutely, that's absolutely an option. It has more or less all the same problems as PVCs. You have to write this data somewhere and it costs money while it sits there and costs money to delete it and it costs money to, you know, it's management overhead. I really think the fundamental problem is you don't want that data to exist longer than it's being operated on. And in that case, if it just was isolated to the pod it would just disappear when the pod disappears. A code of this is that we actually do something like this in Argo. You can share data between the steps in your workflow by using S3. And it's sometimes cheaper than PVCs and sometimes faster and sometimes more expensive. Kind of depends on what your use case is. Okay, next question. Okay, so the question was, did you look at Kubernetes events as a way to message between pods? I'm gonna say no from Argo's side. I don't, I think we did. I mean, it has all of the same API server scalability problems, right? Like if that's your message bus, what's the way you communicate between containers in a pod or pods in a workflow? It's sort of, you might be able to get by with it, but it's going to be plagued by all the problems we've described here, which is it's not built for this, it's not designed for that scale. So maybe, like by all means, we can experiment and see what falls over, but I don't know if it's better than what we have today. Okay, any questions from the middle? From the back, the middle? So the question was, with Vault and Istio, is there an alternative of Vault by using the CSI injector ahead of time? Yeah, yeah, yeah, you could do that. It's the fact that they use a new setting webhook that makes it difficult to work with. And specifically to inject new containers that we don't know about? Yeah, yeah.  Volumes would be fine, yeah. Yeah. Yeah. I'll take this one. Sure. So the question was, you want to understand what I'm laughing in a second is when you're running a DAG and you have a container in it, believe it or not, it's shot in the head. I'm going to terminate it. Terminate it because Kubernetes might want the resources.   And it's a really hard problem to solve because we're trying to one really reliable, robust workloads on Kubernetes. And those two things are a diametric opposition. Yeah, they are fighting against one another. And there are kind of mitigating actions. You can take like a pod disruption budget, for example. In workflows, the main thing we do is allow you to just retry those steps automatically. And things like retry them on a different node within your cluster, change, change where it gets ruined. That's the main thing that we do. And the good thing to do, and I don't know if this is the case for Tecton, is don't have very long running processes which take an hour to run, cost an absolute fortune. And if they get 55 minutes into that, being terminated gracefully, you have to do all that work again because that can happen over again. It's better to have some kind of memorization going on in the process. So the question is, do pre-stop hooks help? We don't use them, but yes, I think they can, yes. I mean, the fundamental, so this points to another way in which Kubernetes was not designed for this. Kubernetes is designed for replicated serving workloads where if somebody unplugged a node, it should be fine, right? We very much need that pod to finish for the next one to start and things to work. So it's sort of a difference of assumptions between what Kubernetes assumes and what we assume, yeah. Do we have, she's giving me a thumbs up. We're good. We're good, we're good. Okay, any more questions? All right. So just one more thing. If you want to find out more, oh, has the size gone a bit strange on this? Yes, it has, never mind. I don't know why that text is so small. I'm at the Intuit booth today, we're in zone stage. I'll be on the booth from 3.30 if you want to talk about Argo kind of related stuff, or you can obviously go to the Argo booth to speak to some of the engineers there as well. Will you be on the Red Hat booth? I'll be around, yeah. Cool, cool. Sorry, that's why you can find out more. Yeah, thank you. Thank you very much. Thank you.


Mike says, I have a SharePoint list I need to archive to reduce the number of items in the list. I need to be able to recall the data on demand as it contains employee performance data that must be compiled and averaged at the end of the year. Any ideas? I love the list. Again, this is, we just kind of answered one of these previously, but in changing your views and using that magical little today option in your filters. If you look in the descriptions of the filters, there's two dynamic fields that one of them looks at me, it's in square brackets. So it looks at the logged in user. The other one looks at today and using that date as a dynamic date. So you don't have to constantly go in, you know, 30 days later and change the day it's referring to. So you can say, I need everything from today, mine it, something like everything greater than today minus or 365 or something like that. And it gives you everything within the last year. I did that just yesterday for some things. Any other ideas? No, the only other thing that I've really seen is having a column that's very specific. As you said, you can filter it that you can be archive. You can call it archive and then tick off everything that's archive as an actual, whether it's a radio button or a tick box or whatever you kind of create there and then that can just be filtered out of the list and then you can bring it back when you need to. So yeah, creating that kind of extra metadata. Yeah, I mean, the only thing I was going to add is like, again, going back to my the old school, you know, the 25 years ago, building out looking at data and having this, this issue. Was making sure that all we captured that we left within it was for us, it was like that 13 months. So you can look at January of 2022 against January of 2021 and that rolling cycle. Anything older than that automatically got archive got pulled back out of there. So making sure that you're only keeping what you need to keep. If you're still hitting the limitations. Sherry, I think you nailed it. It's, it's the create the views. Yeah, you can store the data, but you just, what do you really need to access on a daily basis? I mean, I also see where, you know, is it a year by year that you're keeping and that you can actually then export that data maybe to Excel have it there in a folder that's archive SharePoint, you know, kind of something like that where you get information you can still go back to it. Although it's not part of your main list anymore because you've kind of got rid of it and you've started it. But I have seen it where he got a year on year. We create a new list so that we haven't got a massive list. And then, you know, it's part of an, you know, a part of the archive process. If you need to be able to then go back to it at some point. The hardest part about that is pulling it back together because it looks like he's trying to do some data analysis on performance. So now you got to put it back together. It's a rolling, it's a rolling calendar. Yeah. And you could potentially then have, you know, multiple old repositories. How do you bring all of it together to see the, the history and then I, you know, for me, then I go is lists actually the right technology for you to use should you be using another system and like a proper, you know, system when it comes to performance. There's a lot of different awesome, you know, HR reporting performance type stuff that you could be using that's going to give you what you need. And it may be that list is not the technology for you for what you want to do. Well, there's a discussion. There's now right. Let's use the data. So pre dataverse. Right.  SharePoint workflow when it was still a SharePoint workflow. Now it's power out of me created a clone list move them over and then what I had to go. For me, it would have Microsoft access to bring them back together and do a joint table and SQL query and blah, blah, blah. We don't have to do that anymore. Microsoft makes it very easy, especially with the dataverse. You know, you can now store that and it's it's meant for that SharePoint lists like, you know, can you build a database? Well, it goes back to the SharePoint is not a database. Yeah, if you're doing database things with it. Then that's exactly your point. Dataverse is there for that. It's an Azure discussion. Move it out of the list. Yeah.  Yes, could we. Yeah. Not necessarily. I think you might need something a little extra potentially. For sure. It's Azure.  Azure goes to 11 SharePoint. You're all the way up all the way up. Where are you going to go? Azure to 11.


First I just wanted to thank the organisers for allowing us to present our data from a project that we're running in Uzbekistan. Some of the background to MDRTB treatment I think is very pertinent for those in the room that don't treat patients with that disease. The conventional treatment for MDRTB is up to two years long. It's very complex medically for doctors and nurses to manage patients on MDRTB treatment. The side effects are very significant with up to 10% developing hearing loss during the treatment and for programmes it's very expensive. Each patient we think costs around 3,000 euro for their treatment alone. Around 2010 a group in Bangladesh the Damien Foundation discovered a new regimen using conventional drugs so no new drugs but in a different combination which allowed treatment to be reduced from two years down to nine months, had lower toxicity levels and was significantly cheaper. At that stage there's very limited data about the role of this regimen and so in Uzbekistan we conducted a study to develop more data to hopefully lead to policy change. Uzbekistan for those that don't know is in Central Asia. It's a former Soviet Union country and it's on the list of the WHO list of high MDRTB countries. Amongst new cases of TB diagnosed 23% are diagnosed with MDRTB and amongst patients who've had treatment for TB before it's almost two thirds. I think importantly for the former Soviet Union which is sometimes different to other parts of the world there's very high levels of second line drug resistance so these are drugs that we kind of rely on for patients who have MDRTB with almost 8% having resistance probably the most effective drug at that time which is the fluoroquine loan group of drugs. So the analysis I'm going to present today is actually two analyses. It's comparing the shorter regimen that was discovered in Bangladesh with the conventional treatment that we were using at the time this two-year regimen and so what I'm presenting is data around the early effects of the two regiments so comparing people who had two months of the conventional treatment versus people who had two months the shorter treatment and also the end of treatment outcome to see was the shorter regimen as effective or more effective than the standard regimen in this context. So the original study was a single arm prospective study that we started in 2013. We restricted it to three districts for obviously for logistical and operational reasons in a in a program that MSF has run in collaboration with the Ministry of Health for many years. I think the program started in 1999. We started recruitment in September 2013 and this new regimen is shorter than the original so four months of this combination at the beginning with an injectable drug every day and five months following on from that with tablets. The inclusion criteria I think is essentially any patient with pulmonary MDRTB and we have an advanced laboratory there where we can use multiple tests to diagnose that and the exclusion criteria is to exclude patients we think have that second line drug resistance because when the study started we knew that they had a potentially worse outcome. So our comparison group it's important to know that this is an observational single arm study so the comparison is with is after the study finished. So for the short course regimen we have those recruited and involved in the in the short regimen so that prospective study and then the conventional care group is other patients within the same MSF Ministry of Health collaborative project but in different districts. We restricted them to the same time period to try and remove biases involved in changing of the program and that group received a protocolised WHO approved 20 or 24 month regimen based on the clinician's decision making. We looked at fairly standard outcomes for both for both analyses the first one being the effectiveness of the a measure of the effectiveness of the regimen at two months treatment and then the final one being the final outcomes at the end of treatment. Baseline characteristics across both groups were fairly similar. I think the key part from this slide is to notice that this is a region with with very very low HIV prevalence and in fact we included no patients who are HIV positive in this cohort. Unequally disease characteristics looking at the the burden of disease how how severe they're paid these patients where we looked at fairly standard TB aspects so things like cavities on the chest x-ray how much TB we discovered in patient sputum as well as some baseline resistance characteristics are all similar across the groups and so I think the the key part is coming to the results is the box in red so comparing the two two two groups of patients in their early treatment response we found that those receiving the short regimen had basically twice the effective response after adjusting for the reasonable confounders and in fact at the end of treatment outcomes we discovered that there was basically no difference between the groups. Obviously that's comparing a treatment of two years versus nine months and so actually we believe this to be quite a positive finding. Obviously the fact that our methodology was was observational the analysis that I'm presenting today was in fact retrospective raises a number of biases that I think we can't get away from. Obviously it's non-randomised but equally we felt that it was valid given that the program is the same the laboratories are the same the outcomes are the same and so we do feel that the biases although they are limited in some fashion. So in conclusion we think the short regimen shows that it has good early effects in this patient group we know that we found that the final outcomes at the end of treatment were quite similar although that's with a much shorter regimen and we think these are quite encouraging results from quite an established program and in fact last year the WHO agreed with us and other groups performing similar analyses around the world and change international guidelines to include the short regimen for some for certain groups of patients. So I think it's important to talk about the generalisability of our results. This is a context with high levels of second line drug resistance and very low HIV prevalence. We do believe across that region of former Soviet countries that that's quite similar to other countries and so maybe we can generalise to those countries. There's a question about whether this effect early on in treatment has an impact a positive impact on transmissibility. We believe that having a shorter treatment requires less work and less costs for programs and we're actually all looking forward to the randomised clinical trial that is occurring at the moment to give us valid scientific results. So just finally to thank all the patients and doctors and nurses who participated and obviously support patients with TB in this region as well as our collaboration in Uzbekistan and Kazakhstan, the region where we have this collaborative program. I'll leave it there.


Hello, everyone. Can you hear me? Hi. Hi, how are you? I'm well you look stunning today. Thank you. It's Friday right after this. I'm going out so that's why Awesome. Oh my god. Yeah. I'm jealous of your plans. What do you have to tonight? No idea. I mean my friends have plans. I'm just going along with it That's that's what's up. Hopefully it ends like it didn't flock with music Showdown and some drinks. I hope the company is not as good as that. Well, it's awesome to see you. Thank you for coming to Fedora Women's Day and Presenting, I know you have, you know, some experience with Fedora, but you have even more to share about Other communities that you're involved with so I'm super excited to hear your story I'm gonna let you go ahead and jump off and then when you're wrapping things up I'll come back on and help moderate any questions I have prepared some slides here about journey in tech, as Marie said this is specifically for Fedora and my involvement with Fedora, it's basically how I started in tech and how I branched out to other stores and then to Fedora and then to client So I can cover them all and the writing and the history and what I would like to have with you is a big question on how I can share this with you I can share it all with you So we have something to come My journey in tech Can you all hear it? I don't want to share it like this No So we're we can hear it we can see the screen. Oh my gosh, I love this Here, this is gorgeous. The audio is a little bit choppy Okay, it's actually better right when you did that Okay, let me try this one. Can you hear me now? Yeah, that's that's much better. Yep If this doesn't work, too, I can put my headphones on Okay, if it doesn't, I'll jump back on. All right, I'm gonna leave it The first one, I do presentation myself I'm back again because it's really fuzzy Okay Okay, so this is my journey in tech prepare for some nostalgia here This was a very it was very fun fun to put together for me because I have been in tech for quite some time but I Stopped to think how I got here. So this was very fun To put these slides together. So here's also the nostalgia part Okay, so this was the first time I got introduced to tech This was our first computer. This is how it looked like because I don't have any pictures It was a Pentium 4 I think And it was actually my brother's computer. So I Had very restrictive access to it But when I first saw it, I was immediately drawn to it. I wanted to know how it worked What can I do with it? What are the possibilities? And the first thing that my brother taught me it was about Wikipedia And yeah, and when I learned about Wikipedia, I was mind blown I thought okay. I can search about anything and know anything I want So I would spend literally hours on Wikipedia and I had a notebook That I would keep near myself and then whatever I would read and wanted to remember it I would just write it down and This is how my journey tech started after this After this it was this is the beginning chapter after this came So that was in primary school. I was in the eighth or ninth grade And then came high school, which is this chapter the second one I wasn't sure what I wanted to do next But I really thought during my primary school I thought that I really don't like learning theory I didn't like just sitting and listening to the teachers and I didn't see any Applicable lessons there. So I thought that was very boring to me and I wanted some more practical learning So I found out about a school a high school that was electrical engineering high school Supposed to be for guys but for some reason in my country they also accept women although a few very few So I decided to go there and see how it looked like And I went to a tour and then saw the labs and I loved it I thought okay. I can explore more computers, which I really liked There was practical learning because it wasn't just theory We would actually learn about every piece of the computer about electrical How the electricity works and stuff like that I really really liked it and I can say I really enjoyed high school although I made a good friends although we were very few women there like we were four women and 35 male Oh, you can see me. Oh my god. I'm sorry. I can't look at the chat because I'm looking at the slides Can you see me now? I'm not sure. Okay. Cool. Cool. Sorry. I can't I can't look at both at the same time I will take a look at the chat later Okay, cool So this was high school The second chapter and then the third chapter which is university. I finished high school and I was Having some thoughts on what I could do next. I knew I wanted to study, but I wasn't sure what I wanted to pick So there were two main things that I really enjoyed which is computer science and Psychology I was always also interested in psychology and enjoyed reading books About psychology and I was also had this creative side of me that I could never apply To my school my high school because it was so focused on engineering So to pick between this two I thought Maybe I can just you know Combine creativity with computer science and that works Psychology is also I can learn more if I want to but I don't see myself practicing it So I went with computer science. This sounds a very easy decision Maybe right now, but at the time I had a lot of thinking about this Okay, the next chapter is The chapter of open source this was The first year of university when I first got introduced to open source Some people on my Where I live I live by the way in Kosovo and Pristina which is a very small and young country They were building a hacker space And I wanted to see what was going on there and I have some friends That were involved in open source and were building the hacker space So I went and saw what it was happening there because I was very curious And this is what I saw basically I went to the hacker space I was the only girl there and There was a lot of terminals And I just didn't know if I fit in there I was I was very curious of what they were doing But since I was in the first year so I didn't have any programming experience So what did I do? I did some exploration I did some exploration So not in front of everyone in the hacker space But I got introduced to the world of Linux through those guys So when I came back home I wanted to explore what open source is about what Linux is And I watched YouTube videos and I also decided to give a try Some Linux distros Which are called flavors or And to me that sounded like so interesting like ice cream flavors or something And so I decided to try some of them I put some digital machines on my computer And the first one fun fact the first distro I tried was popular Linux And then Linux Mint I think Debian and then I had OpenSUSE and then Fedora which I ended up keeping Yeah, this was that I now knew which I didn't know before And I thought okay I can read that I have the opportunity to contribute and change things And propose about new things But how do I do that? I have no idea At that time I was Through my friends from Obeña They had Fedora community And still have And I they invited me with a link on telegram And one day they shared a link for Outreachy I clicked on it randomly and saw what Outreachy is about And it was the perfect thing I was looking for Because for those of you who don't know Outreachy is just like Google Summer of Code Basically approaching new contributors And helping them get involved for the first time contributors But since they saw that on Google Summer of Code There were no participation from underrepresented folks They decided to do Outreachy Which is focused only on underrepresented folks And another problem that I had on Outreachy I thought it was a great idea And I went through every project they had listed on their website But the problem was I didn't know to coding Because I was still on my first year ending my first year I'm not sure of university So I found out that Outreachy also had some non-technical Contributions which is really nice So I took a look at them and found the perfect one for me I found Grom which was looking for usability testing I had no idea at the time what usability testing was And I thought at the beginning like why do we even need it But later I found out that we do need it a lot And there's actually a whole career that it's built upon The user experience of applications So anyways I looked at what usability is And how to apply it to software And then I ended up doing some contributions for Grom And I did my internship on Outreachy for three months Which was a great experience There I found out about design part of the open source Basically how much open source software needed good design And usability and user experience improvements I got exposed to that And I also got exposed to other communities Like open source design, Fedora, Debian So I saw a lot more variety on open source During my internship and during this chapter The other chapter which is the fun one It's this one This is when I have finished my internship And as I said I saw the need for good design work In open source software And the need especially for user experience improvements On open source software So that it would be easier to use And that way in my mind more people can use it So my strategy was I thought let's do a workshop or talk Or something like that So I can reach out to more communities And explain them that improvements of user experience It doesn't have to be hard or a lot of work I wanted to simplify for them in a few steps And how they can, everyone actually can contribute To their open source project By doing improving user experience With a very simple way And I did that in a few conferences And one of them was also Flock Which I ended up having a great time And what I learned also during this time Was the non-tech side of open source Which was the community part Because even before I had kept in touch with the communities But mainly through written format Which is not the same as meeting them in person And seeing them that they are not just a nickname They have faces, they have personalities And that was so much fun And to see all the communities For example at Flock Like how they were very connected to each other And they knew each other for years sometimes But still were very welcoming to new people I felt very nice there So yeah, I did this for some places And during the events I would also do, for example, usability testing To help, as I said Open source software project To improve the user experience So I would do usability testing on the halls With some participants And then whatever they would need to test most I would do that, for example On Flock, I remember doing a usability test For the badges website And then I made sure to compile all my findings And give them back to the community So that they can take action on them Okay, let's see if so far everyone is hearing me And I'm good Okay, I think so Just checking Okay Next chapter The next chapter for me was working on open source I was approached by a small company That does design on open source to work for them And to do basically what I was doing until now Trying to improve user experience And doing user research, some UX design And I really, since I really enjoy that I immediately accepted it And I had the opportunity during this time To work for a lot of open source projects Which feels very good And to know that I could help to improve them I have here some examples Just a few of them So I can show you what user experience is about Or for non-designed folks here Just to get an idea of what I do So for example, this one is I have worked with Thunderbird Which if you don't know is an open source email client Lately they have been integrating PGP encryption As a built in feature So I've been helping to do the design And the research part of the design Just to make sure that everything is The user experience is smooth You can see here is the On the right side is the research part And then you can see the mock-ups here And the heat maps that you see In the bottom with the colors They are from the usability testings Because I talked to a few users That had used any email before And compared it to the user experience Of Thunderbird with PGP integrated And I wanted to see how they are comparing it How is the user experience So you can see everything is detailed And also had been written down by me In very detail with screenshots And how to improve it in suggestions And all of that The next one is for example I2P which I don't know if So I'm just here I don't know how much you all know About the application So I'm just going to quickly introduce them I2P is basically like Tor They had a browser extension before Which looked like this Like the before And then we did user research I talked to users and to the community there To see what they needed And started building the design Doing the fidelity of wireframes And this is how the design ended up looking Which I think it's nicer than it used to be So this was basically every design After this we got Briar Briar is an application for again open source Which is based on security They had a much complicated approach To connecting with users Connecting with each other Then traditional applications Like for example what's happened Viber and stuff like that So we worked with them I did a few testings To see how it goes And they are still in the beginning But we are improving each iteration So this is basically my work I'm always open to seeing And finding out other ways How to help open source software Improve its user experience I'm always open to that But this is basically my journey And how it looks In the last slide I just wanted for If anyone here is very new to open source Or they are not sure why they should do it You saw my journey And maybe my reason So I just wanted to maybe quickly Highlight some other reasons And there is a lot I wrote here just a few of them But now reading it I can imagine other ones Coming from my own For the first one is Getting real world experience I think that's very important And open source allows you that If you are in the beginning of your career For example it doesn't matter Design or whatever Coding You have the opportunity To not do just some work Based on a homework That you were given in a course But here you can just apply Everything you know And learn everything in real time With real problems Which is very important I know in the design But I'm sure for every other area And the second one is Connect with people from Of the same interests For me I live in a As I said in a very small country Basically in my country There is no one that does UX research Which is what I do for a job So I felt very lonely at times Not having someone to share my ideas And what I'm thinking about My profession And in open source You have a lot of people working Who have other UX researchers In my case That I could talk to And they have communities And I can discuss more About my profession And I'm sure this applies To everything else The other reason is Working on large scale What I mean by this is I'm not talking about every software But mainly in open source The software, the projects And the software is huge So you have the opportunity To collaborate with a lot of people And that's something You cannot learn in practice If you're just working On your country With a smaller group of people Here you have the opportunity To connect to a lot of people Also you have the opportunity To learn how to work remotely I think this is now more accurate than ever Because everything has gone remotely these days So I think this is even more appreciated About open source now Because you can basically Everything, almost everything Is done remotely So you can learn how to Approach the remote working part Through contributing on open source software The other thing which You can see here I have mentioned three times Community and friends Just because I think it's very important And on open source communities You have this sense of belonging To a community And also when there are People that accept you And they are friendly Here I'm talking specifically about Dora Because I remember How they accepted me And immediately I made a lot of friends Just by attending one conference So when you want to Join an open source group Just make sure you see How they are connected And if you fit in there But this is why I would recommend Joining Dora Because I'm sure that they are And they have done a lot of efforts Actually to make the community more diverse And also make a lot of friends As I said again Dora emphasizes the friends part Which I like and it's really important You will make a lot of friends And if you are an introverted person Or shy or reserved Like I know I am This is a great way to open up Because people will approach you And ask about what you do And that way you will learn How to talk to people And how to make friends Yeah, this is it I don't have any more slides You can find me at Dora On Twitter or anywhere If you want to talk more Okay Awesome Yeah, can you hear me? Okay, cool, thank you for that story I really enjoyed how you took us Back to the start And I was having memories Of my first computer Remember when we had the family computer In the middle of the house And we all had to share it And all that's so funny I was also getting nostalgia in there Yeah, thank you for that story I love that you're doing You're not doing coding, right? Did I understand? Yeah I'm a similar person Here in the open source world Doing design for many years And now I do community work But it's definitely I don't know, it's interesting But at the same time You have this entire background You know how computers work And you went to an engineering school So I'm just super impressed with your story So cool to learn all of that stuff for you So Natasha is asking What can a newbie do in Fedora? I knew it So first, I'm just talking here On my experience I mean, maybe other people Can share also their first experiences Because I attended an event That was organized by the Fedora ambassadors And they do a great job On explaining what the options are Because in the beginning It's very hard to know Because Fedora is a very big project So you can't know everything You can possibly do And then they will help you And guide you in a way Where do you fit in? For example, in my case I did in being more of a people's person Or maybe something more creative In design And that's why I ended up Joining the diversity and inclusion team And also the design team But this is how you get started Other ways, if you are not Able to approach an event like that I would suggest either virtual events like this Where you can ask specific people more Or maybe even joining on telegram groups Or just visiting Fedora Wiki pages There you have set-by-step guides On how to join everything And if you have questions You can just think specific people And they can help you I hope that answers your question Yeah, I'm just going to follow up with We will be thrilled to have you Basically, if you show up in a channel And say, hey, I'm new here There will be like five people who say Oh my gosh, hi, welcome What can we do for you? So it's definitely a very welcome place I would say, yeah, connecting with humans Right? That's the way to get Into open source in a more meaningful way More connected to like your personhood So any other questions? I'm just going to give a chance to do the chat I don't know if you were in the opening Or the intro remarks, but We are working on making A cool video based off the content That we're recording here So I have a script If you're comfortable reading it So part of it is in your native language And part of it will be in English So if you could stop sharing your screen I will copy and paste I just wanted to say If you had any other Albanian speakers here You've probably got the Albanian part So if you don't want to double that Because I think we just had I think we just had someone do Greek Okay, yeah But it's not about doubling It's about having your part Okay So we will have you part of the video Give me one sec Let me copy and paste Should I stop sharing the screen? Okay So Nick, put it into the chat So I'll do mine to show an example So in your native language you'll say My name is Renata I am from Kosovo I am a woman and I speak Albanian In Albanian and then you'll say We are from different countries But we'll put it in English Sound good? Okay, so the second part is in English Let me highlight the second part So I don't mix it up Can I try it right now? Okay, cool So my name is Renata I am from Kosovo I am from Kosovo We are from different countries We speak different languages We are different cultures But Fedora announced us with open source Awesome You did great Very cool Oh, we have another question Have you done UX for Fedora? So to explain my This is To explain my role, my job It's UX research Which means I don't actually Do the high fidelity design The detailed work I do the research part Which is doing the testing To see if something is easy to use And then report those findings And maybe do even little Mockups on low fidelity So to answer Your question I did UX research For Fedora badges During flock 2019 Where I did usability testing With a few people from Fedora And I did a report Which I think very shared here That is basically the UX part of me Doing for Fedora A really cool update For the people who are here We actually opened By Masha We actually opened A bunch of tickets For some new Outreachy applicants To try to tackle some of these badges Things, right? Some of these usability issues Meanwhile We had an outreach intern over the summer Working on the back end of it To move it to Badger Away from Terrier So hopefully It's kind of like all going to come together But as we all kind of know These kinds of projects They take time and they take passion And people really put some time in there So we hope to see All the fruits of this labor Eventually But the report is so Like detailed And you can tell it's just great There's a lot there To make the badges site so much better Yes, thank you For the update I already saw The work that someone did I think from Outreachy For the design I didn't have time to check everything in details yet Which I plan to do I would like to keep up with my report And everything that goes through the badges And see how it goes Yeah, that's like You're planting seed To watch the tree grow All right Well, I hope you have An awesome night out Coming up at our Women's Day And chatting with us And we'll see you soon Thank you and thank you everyone For joining and for Leaving questions and comments here Thank you so much Can't wait to see you in person Bye


Welcome to season three of stable talk. We got woman soccer and with us today We got Meg Meyer and Jess Bizzacco both New Jersey relatives. If you guys just want to Tell us about yourselves your major What position you play now? Maybe what position you used to play growing up? I'm Meg. I Am from Howell, New Jersey. I'm a rising junior But I'm like a red-shirted sophomore because I was out my freshman year I played midfields like center mid. That's like my home. I've always loved playing center mid That's usually like where I play but I can really like play anywhere. Oh elementary ed nice I'm Jess. I have been super voting Jersey, which is like South Jersey. Um, I'm a rising sophomore and I'm majoring in graphic design And yeah, my main my position now is like center back defender I actually used to play goalie for a long time, but yeah, well, yeah, so now I'm a center back So you guys are both from New Jersey What's what are like the main things that are different about living in New Jersey? And then both you going to college in Maryland. What's different a hundred percent the bagels and pizza like The people are wait are the bagels bad here. They're just like not You know, the bagels here. They're just like crusty like Jersey like they're just like perfect. It's just no other, you know Sisters live in South Carolina and like I went down there and I tried to get like a fresh bagel and that's like they don't exist Bagel shops like aren't a thing like it's just so weird to me even like fresh bagels That's the grocery store. Like they're just not a thing and I didn't realize that Where are you from Jersey too? No from Maryland, but But I like For me that I noticed when I came to Maryland is you guys are kind of like obsessed with the Maryland flag And like I don't even know what the Jersey flag is like it's really to me. Yeah, like it's just like everywhere It all started with Route 1 apparel Do you guys know what that is? No, like this girl who's actually like from where me and Jay are from in Bel Air Started this company called Route 1 apparel and she literally just started out with like a pair of socks and like a shirt With like the Maryland flag on it and it's like blew up and now it's like this whole and I think that's when the whole thing started About people just like wearing the flag everywhere Through I feel like not a lot of states like do that. You know what I mean? Like the only state flags I know are like us Texas and California, yeah, it's so weird. That is also like Maryland people just love Maryland You know what I mean like ravens crabs like they're so like in love with Maryland. It's so funny, dude No, you guys ever had crabs before not like that. I mean I Remember last year I lived in Wooded Way and I like all most of my roommates were like from Maryland And I walk in one time and all I see is like these like crabs like actual crabs You know what I mean?  I'm not a seafood fan. Yeah, I see food fan All right, burger cookies. Have you guys had burger cookies? I don't need to have them. J. Have you had this? No, we should we should tell our YouTube subscribers to comment below Comment below. They had burger cookies Next up. Are there any hobbies or I was already pointed out I grew out my hair there anything that you've done in quarantine that you typically not normally do or any like fun things that We're like spur of the moment I'm gonna do this because I have nothing else to do because of a pandemic um From I've been watching a lot of baking shows and it gets me really inspired. So I tried to recreate anything. Yeah, what do you mean? I haven't tried to recreate anything because I'm not that good. So like I can't go, you know Crazy, but I started making scones, which are actually really good. Are you a gordon ramsey or um a guy friary? Which one? Oh Oh Yeah, I got so good in the hairstyle then Yeah I'm trying I like have been working like ever since Like quarantine like I work at a daycare for like essential employees kids. So like that was like always open So I was like always working. So I kind of just like flopping out. Yeah, it kind of just like felt like every other day Yeah, I've really just been showing I just moved into my apartment in Maryland. So Kind of taking it day by day, you know packing All right, we're gonna do some team superlatives First one most likely to spend the most time on their phone probably melbourne cut Yeah, I can see that Tell us why She's like loves taking pictures like loves Taking pictures or in like and then she'll take pictures and then she'll like edit them for like an hour, dude. Like she's just like My god, dude, like it's so funny But she's not like the type of person where Like you're trying to tell them a story and they're like, you know what I mean? Like she's not like that It's just like she loves like doing doing stuff on her. She loves the gram. Yeah, she does. She does big grand All right, who's most likely to host a talk show I say Cassie Butler I don't even say Cassie or Lowe. Yeah, both of them on the same show would be something but yeah Cassie really co-hosts. So yeah I can totally see that. Yeah, she could just go on and tell you stories and stuff. So Yeah, Cassie always has a story to tell. Yeah Best person to be stranded on an island with Bridget Heist 100% 100 why? Because she's just with it. Like she knows like things that like normal people don't know Who do you think Jess? Um from I mean, I I'm I live with Lowe. She's my roommate So like I can't really imagine like not going or being someone with her But I also feel like she's also like she makes me laugh all the time. So I'm like, I want to at least pass the fun I'm stuck on someone who can keep you entertained. Yeah, for sure Bridget will keep us alive. Lowe will keep us entertained. There you go. Yes All right, who's most likely to get married in Vegas? Could it be like an alumni or not? I was thinking too. Yeah The same person who you think Lena? Why She's just like she's the she's very like lovey, you know what I mean? Like she just like Has so much love coming out of her and like she's very like impulsive. So I could totally see her doing it Might do it like next year like type of thing like honestly always that for good times.  I feel like get married just to have like a party. You know what I mean? All right, last one coach Joelle's big passed out in the front seat. Who's messing with him or pranking him? Vegas prankster I mean, I'm definitely pranking him I heard like Tati would like get everyone to do it probably would be like 100% like everyone's gonna like get in on that. Were there any pranks this past year? Yeah, we did So I don't know why but we thought it would be so funny if we Like because coaches so we get in the locker room like 15 20 minutes before practice And the coaches come out like the time of practice So if we have we had practice at like four we have to be in locker room like 330 out on the field like 345 They come out at four So we thought it would be so funny to like hide. You know what I mean? Just like not show up Like where is everybody? So we like got up on this the ledge thing like outside on the turf We like got up on it and hid behind the bushes and we they like came out and they like They were like where is everyone like they looked in the locker room everything and then we were like I thought it was so funny, but like talking about it like it really Like we were because there was like this wall and it was like right next to the stage Hop over the wall and like we were all like having trouble getting over it. Like I cut my leg open I have like 35 girls who got I don't think it was funny. They were just confused.  Like they're trying to make But like they knew it was funny like We have to prank them more honestly Yeah No, I'm thinking about it. We only pranked them once the whole season. Yeah, I want to come back for Another episode and see what you guys have done on joel We're going to do a special edition episode called prank Yeah, call it just pranking joel I All right, we're gonna do some q&a How long would either of you last in a zombie apocalypse? I feel like I would last a long time just because of the fact that I've watched like all the walking dead and like I know everything that happens and I'm like, I think I got it planned out, but I don't know if I can I think I'm the opposite like I'm really like straight up if like that was happening right now. I am not prepared. I have nothing, you know what I mean? That was happening right now. I had my niece on ultimate in my apartment. Like what am I doing? Time for the top of my building that's about it. Like I I never watched walking dead. Like I always thought like zombies were so scary I tried watching walking dead, but there's like how many seasons now like 12 or something a lot of seasons now Yeah, I watched uh until they what's the old dude? I I stopped watching when glenn died honestly. Yeah Always remember like looking through twitter when like walking dead was like the thing If the stevens and woman soccer Was a sitcom. What would the theme song be? Question. Oh my god It could be just like your guys's go-to hype song or whatever Or a locker room jam. Okay If it's like explicit probably like plain jane I MTV Favorite memory from the 2019 season playoffs, oh my god like just like um October like the month of october in general like We literally were just winning like every game. You just like we were that team. You know what I mean like we After september because we lost almost like every game in september And then coach steward talked to us on the bass men's basketball team He just gave us this pep talk and like you could ask anyone on our team about this like they remember that talk Like you know what I mean that that talk we were just like yeah, like yeah, like It just got us going then after that talk we Almost won like every game and made it to playoffs and it was crazy.  You know what I mean Exciting Joel Joel would come in the office and be like yeah, he took October we haven't lost the game since I got here Yeah, that's true.  It was like so satisfying Playing arcade. It was always like a big big game for us big games, especially the last two times.  Like yeah, I just want to play them again You know, yeah, and you're not even in our conference anymore our side is right We're never gonna get to play them yet. Yeah, like I want to play them again Yeah, I don't really do Well, maybe Right. Yeah, I mean sometimes you guys still like cross between freedom and um Commonwealth Yeah, that's just make it to NCAAs though Or maybe conference we play them like in the beginning We're gonna go into this or that you only get one forever Super sandwich for the rest of your life. You get other things in your life, but you just lose Okay, so what's the question soup or sandwich? Super sandwich. Yeah Um, it was like super sandwich sounds good I say soup I say sandwich For sure. They're just I'm a sandwich girl too. Yeah, I'd love a good sandwich What about you Jay? sandwich Oh Ocean or mountains ocean you can never go to the other ever again. What kind of question is that? I'm from Jersey Right by the dirty shore. Yeah, I'm 15 minutes.  Elmar I go to city Phone or computer phone You could just do so much on a computer and so easy, you know I would say phone though. Just because you can take it Yeah um Netflix or youtube Netflix all the way I'm like never on youtube I want to say youtube just because i'm on i'm on it more like there's more like to watch But I do be watching Netflix a lot I've recently gone into like watching random youtube videos All right, what if it was Netflix or Hulu? Yeah Yeah More options. Yeah Here we go trivia This is where you're real Stevenson woman soccer trivia. Yeah Okay, how many NCAA appearances does the Stevenson woman soccer team have? Three About you just what do you think like five? I don't know Four four I said three or four. Okay like Four just to say other you're close. Okay. All right. That's reasonable Two-part question. What state is head coach toddy from? Okay, and what city is she a native of? We oh, hi. Oh, is she really from Ohio? I don't even know that She does not say anything ever talks about it In what city? Well Wait, what was the city question? What city? You know what city in Ohio? In Ohio, Cleveland She was from Ohio Wooster, yeah, apparently it's a wooster. Yeah, I'm gonna roast her about that. I've been there once We can do a high hour booster What's it like? It's kind of like really suburbian It's really it's honestly a poly just like anywhere else in Maryland really suburb. I mean toddy correct me I'm just gonna email you and be like actually like it's not like I remember there being like a lot of tj max's and buffle wall way So everywhere else in the world Makes sense, but I was I was near the college of mooster. I'm pretty sure so it's gone What are the names of coach joelle's three kids? But oh no I feel bad that I don't know this. Yeah, he's definitely watching this. I know I'm sorry joelle. I'm sorry. He couldn't I don't fall in I can describe them. He has like two three-year-old sons. They're twins and he just had a newborn baby Yes, okay, and it's a girl We got a p name and m name and an h name harker no m name They're like Preston Maxwell and henry. Oh, they're all boys.  What is all girls? Henry. Don't listen Preston Maxwell and what was the other one Henry Henry. I'm gonna remember that He tells us all the time. I had a text on the day. I can only remember Preston Okay, what number this is just regular soccer trivia. What number did me a ham wire? 15 11 Single digit six one Number nine me and Jess were literally like the trivia I don't even think I was like alive when she was playing so She was on the night. Yeah, we weren't well. We were just like starting starting out All right now in the world just someone more recent then We're gonna do a little bonus questions. See if you guys can get it right Okay, don't make it too long Okay, what number did abby wambach wear 20? There you go Yes You're one for four We always tell people if you want to let people know where to follow you Where instagram You can look me up if you want to I'm not signing me and just up for this. Yeah, thank you. Tati The best Mr. I have Thanks for all for not joining us today. Yeah, thanks.  I hope you got I hope you got your work done because we really missed you on the zoom call Thank you for sure. I don't know who this be upset that we didn't know his kid's names Thank you Thanks, we had fun


From our studios, in the heart of Silicon Valley, Palo Alto, California, this is a CUBE Conversation. Hi, I'm Peter Burris and welcome to another CUBE Conversation from our wonderful studios in beautiful Palo Alto, California. One of the biggest challenges that every enterprises face is how to attend to the volumes of data that are being generated by applications, but more importantly, that the business is now requiring because they want to find new derivative sources of value in their digital business transformations. This is going to require a significant retooling and rethinking of how we use data as an asset and the directions that infrastructure, data management and business are going to move together over the course of the next few years. Now to have that conversation, we've got a couple of great guests here. Jyothi Swaroop is a VP of Marketing at Veritas. Welcome to the CUBE, or back to the CUBE, Jyothi. Yeah, thanks, Peter. And Rick Clark is the CEO of Optar. Rick, welcome to the CUBE for the first time. Great to be here. So let me start here, Jyothi. Why don't we start with you? Give us a quick update on Veritas and where your customers are indicating the direction needs to go. We've just had a record breaking financial year for us, which ended in end of March. So since divestiture from Symantec, as you know, Veritas has been through a transformation and then on a path to growth. So our core businesses are humming. We've just, like I said, the second half of the year specifically was great for us. What we're hearing from customers, Peter, is that they want to elevate their business problems away from infrastructure to business outcomes. What they ask Veritas to do is, can you abstract away some of those infrastructure plumbing problems, storage, security, data protection, and focus on what the applications can give us? That's number one. Number two is, can we standardize? I mean, the example of Southwest comes to mind, right? They have the same plane, so they can reroute those planes anytime they have the same pilots flying those planes. So they can just standardize so they can abstract better. And then lastly, to your point, value of data over volume. Everybody talks about the volume. What about the value of data? What does Veritas do for me as a customer in order to extract value of that data, which is growing day by day? Well, one of the most interesting things about this challenge that businesses face as they try to attend to these things is that data is often characterized as the new oil. And we push back against that because data is a new kind of asset. It's an asset that's easily copied. It's an asset that's easily shared. You can easily integrate it. You can apply it to multiple uses with zero loss of fidelity in what it does currently. And so the whole notion of creating new options and the value of data is intrinsic to the questions of digital business. So that suggests that we need to start thinking more about data protection, not just from the standpoint of protecting data once it's been created and is sitting there so that we can recover it, but new types of utilization, new ways of thinking about data, data as it's going to be used, understanding more about data and protecting that. Rick, would you kind of, does that resonate with you? Yeah, absolutely. One of the things that we've sort of seen in the marketplace is certainly over the last 10 years the data center has become so complex. There's this massive fragmentation of data across highly virtualized infrastructures. And then when public clouds came along, customers didn't really know what workloads they should move up into those clouds. And so what we saw as a huge problem is areas of cost inefficiencies, massive problems of risk, and then obviously the amount of money that companies are spending on compliance. And so what we were really focusing on is the gaps. What do you not know about? And so we would really measure- About your data. About your data, exactly. So we'd really measure the heartbeat of the data protection environment. And from that, we could actually see where are your risk, where are your exposure, where are you spending too much money? And where's your opportunities? Where's your opportunities? So we've got a notion of the solution that folks are looking for is something that provides greater visibility into their end-to-end data from a risk exposure, opportunity, new sources of utilization standpoint. Now talk a little bit about how Aptar rounds out the Veritas portfolio as it pertains to these things that you're seeing customers ask for. Taking data closer to outcomes and away from a device orientation. Absolutely. So Veritas has always been known to be a leader in data protection. We've done that for over 20 years. We also were the first pioneers in software-defined storage and we are number one in market share according to IDC and Gardner as well. But again, to my earlier point, customers have been asking, so what? Yeah, we've done the plumbing really well and you've scaled. How do you take this to the next level and extract value from all that data you're sitting on top of and you're protecting? And that's where Aptar comes into the picture. We've built some tools natively within Veritas of the last three or four years where we try to go and classify the data on ingest, identify things like PII information, sensitive data, rock data, redundant, obsolete, trivial data that we can delete. There was a customer who recently deleted 30 million files. Just press the delete button and this is in a highly regulated environment. I bet you they were still pretty darn anxious when you pressed that button. They definitely were, but we were able to give them that visualization and information that they required. Now the question those customers are asking us or were asking us before Aptar came into the picture was at the infrastructure level, how do I know how much I'm spending on my data protection environments? Do I know where the growth is? Is it all in the traditional workloads of Oracle SAP or is it in virtual or is it in the cloud? Am I putting too much data on tape? Is it costing me enough? Can I extract the value from that data? So they were asking us infrastructure, visualization and IT analytics questions which only Aptar could answer and we have some joint customers that were actually using Aptar already not just to monitor the Veritas ecosystem but even some of our competitors and the broader IT ecosystem on a single plane of glass and that's where I think Aptar really shines is the agnostic approach they take beyond just Veritas or beyond just another storage vendor. Well, so we certainly subscribe to this notion that data protection is going to, and it's going to be extended, but it's going to become a strategic digital business capability that does have to be rethunk around the concept of data value and sounds like that's the direction you're taking and you guys have clearly seen that as well but obviously some of your customers have seen it. So talk to us a little bit about how customers helped knit you two guys together. Rick? Yeah, that's a great question. It was interesting actually we had some of the largest companies in the globe actually using our software. Many of the Fortune 10 are using our software JP Morgan Chase, Qualcomm, Western Digital and they came to us with these very precise problems around how to optimize my risk within the environment and how to streamline obviously the costs and compliance and we found that they were very common questions and so we actually created this agnostic intelligence built into the software, a rules engine that would be able to correlate data from all of these disparate data sources whether it's on-prem or in the cloud tying that together would provide impactful insights to our customers that could solve real world problems and we do it with kind of what we call the easy button. One of the big problems with a lot of software products out there today is there are point solutions to manage parts of the infrastructure. So companies wanted a single pane of glass where I could see everything across all of my storage, all of my data protection on-prem and cloud and that's really what we bring to the table that single pane of glass and we do it very simply at scale for the largest customers and that's in many ways was the synergy obviously with the partnership with Veritas. So give us some sense of how customers will see the benefits of this from a rollout standpoint over the next six to 18 months. Right, so step one in this journey for us is to ensure that our customers understand that we're going to continue to have that open and agnostic approach. Aptar suddenly is not going to become a proprietary Veritas product. It's going to continue on its mission to be agnostic across various storage, data protection and cloud environments. That's number one. Number two is we're going to bring the artificial intelligence and machine learning capabilities that we have in-house with Veritas, combine that with some of the things that Rick just talked about with the AI capabilities that Aptar has, combine it so our customers can gain added value, the one plus one equals three approach there as well. So those are like the two key pillars for us going forward and eventually we'll extend Aptar to an end to end data analytics platform, not just ID analytics, where we're looking at infrastructure, but an end to end data plus IT analytics platform that spans Veritas as well as the proprietary IT ecosystem. Well, so it's good to hear that you're going to let Aptar continue to focus on data value as opposed to Veritas value. But talk to me a little bit about what does that analytics piece really mean? How are customers going to use it? How are they using it today? How are they going to use it? Yeah, let me count that. There's roughly 30,000 unique metrics that we actually gather across the whole IT infrastructure. And we'll look at a classic use case as one of exposure. A lot of companies spend an enormous amount of money on their data protection infrastructure. They're using disparate tools and technologies. They don't always go with one platform like NetBackup as an example rate. And so with that come challenges because there's going to be gaps. They might be backing up a Windows server where the backup policy says they're just backing up the C drive. We'll interrogate VMware or the hypervisor. We'll look at the network and see that there's a D drive attached to that volume as well. And there's no backup data protection policy. So enormous amount of exposure if they try to do a restore obviously from the D drive where there's no protection, right? From a cost perspective, there's an enormous amount of white space problem in the storage industry. More and more companies are moving from spinning disk to all flash arrays. A lot of companies are struggling with how do I protect those all flash arrays? They're using snapshots. They're using cloud. They're tearing to the cloud. They're using different backup products. Obviously, we'd prefer that they use NetBackup. But with our software, we can provide that insight across the entire data protection framework and storage and show you where is your risk? Where is your inefficiency? Where are you double protecting things and spending too much money? This whole notion of data protection is transactional. A lot of people do what's called disk to disk to take, still being vaulted offsite. How do you know that all those transactions are successful? How do you know you can restore based on those SLAs and tying that into your CMDB? That's what Aptar does. So I'm going to throw a little bit of a curve ball here. So having worked within an IT or worked within IT organizations, it can be, IT historically has been relatively compartmentalized and segmented. You had administrators for servers, administrators for storage, people who were administrating applications and subsystems. And the cloud is munging a fair amount of that together. But one of the places that has always required coordination, collaboration, and even more important, practice, has been in the area of restore. Firms or shops that did not practice how they would restore, hopefully they never had a problem, but if they did have a problem, if they hadn't practiced that process, they would likely were not going to be successful at bringing the business up. It gets even more important in digital business. Can you give us a little bit of visibility into how this combination, taking the metadata, the metrics, the visibility, taking the high quality services, bringing them together is going to streamline, restore within enterprises. So first let me address the first point you made, which is what I call the rise of the versatile list. So there are no more specialists in certain jobs. The versatile list in the cloud or in virtual tend to do three or four jobs, whether it's backup or storage or virtualization itself. And what these versatile list want is to respond an easy button to restore their VM environment or their big data environment or their Hadoop environment. They're not really worried as a central IT team that hey, what am I going to do with the entire data estate and how do I restore that? So that's the first step. Second step, as the world of IT gets more and more complicated and the rise of the versatile list continues to happen, these folks want to be able to have a resiliency plan. They want to be able to rehearse these restores, right? And if they don't have a resiliency plan built in, if the data protection is so siloed and does not help them build a resiliency plan end to end, that restore is not going to be successful, likely, right? And that's where Veritas and companies like Veritas come in to help them build those resiliency plans end to end. But let me take you back to, so the financial industry, for example, there are rules about how fast you have to be able to restore. I got to believe that visibility into data as a value level can help set priorities because sometimes you want to bring up this application or this class of applications or this class of users or functions before you bring up those. So does Aptar, is Aptar going to provide even greater clarity in the crucial restore, set of practices and that kind of thing? One of the biggest challenges for a lot of companies with restores is actually finding the data. We had a classic use case with a large Fortune 10 company where they had a bunch of servers that were being backed up, they were bolted off to tape, and then it was obviously a different backup product they were using, they actually lost their catalog. The data was still there on tape. They had millions of tapes in their vaults and they used Aptar to identify the barcodes and recover that data literally within a matter of hours. And so not only can we find you your freshest copy, your most recent copy if that's what you want, but we can find where is your data, because in a lot of cases there's multiple replications, multiple copies of the data across all sorts of assets within your infrastructure. Interesting. So last thoughts, when we have you back in theCUBE in a year, where are you guys going to be? Hey listen, the two things that I talked about, we're going to continue to expand the support of the ecosystem, the world of IT, whether it's on-prem, virtual, or in the cloud with Aptar, we're going to continue to invest in the artificial intelligence and ML capabilities, so not just Aptar, but all of Veritas's ecosystem, and you'll see a more integrated approach and a platform-based approach around standardization when we come here next. Guys, thank you very much. Great conversation. Thanks for being here on theCUBE to talk about this important relationship between data, tooling, and sources of business value. Rick Clark is the vice president of the Aptar business unit. Used to be the CEO of Aptar, but now the vice president of the Aptar business unit at Veritas. Jyothi Swaroop is the vice president of marketing at Veritas. Once again, guys, thanks very much for being here. Thank you so much, Pete. Thanks for having us. And once again, I'm Peter Burris. You've been listening to another CUBE conversation. Until next time.