All right, guys, good afternoon. We'll wait for one more person. Good afternoon, everyone. My name is Manuel Silvera. And with me today presenting are going to be Sean Murakami. We're both senior cloud architects in the Cloud Labs team. And we have Andrew Haley, who's our distinguished engineer and CTO for Cloud Labs. And today, we want to talk to you about OpenStack in the financial services sector. And really, with an example from the insurance industry. We just wanted to give you some of the lessons that we've learned working with these customers. And we wanted to also talk about some of the issues and recommendations that we have that we think OpenStack can really thrive in this industry and how we can do that. So I'll start off with the introduction. Then I'll hand it off to Sean. And he'll do an insurance industry customer use case. And then he'll give us some of the impressions and some of the feedback that we've received from the customers. And then we'll hand it over to Andrew. And he'll do a lessons learned and a conclusion. And since it's a really small audience, if you guys have any questions at any time, we'll be happy to answer them. So in IBM, the financial services sector, FSS, is the largest of our six industry sectors. It includes banking, financial markets, and insurance industries. And there are really two things that when you look at the customers that make them unique. On the one hand, you have the reality that it's one of the most regulated sectors. So you have, for example, Sarbanes-Oxley, PCI-DSS, HIPAA, and insurance. And then on the other hand, these are really very large customers.  So you have these two big factors pulling against each other. But the good news is that really a lot of opportunities exist for cloud computing, and specifically for OpenStack. Recently, IBM conducted a survey of 1,500 of the world's CIOs. And what they found is that in the financial services sector, firms are adopting cloud computing platforms faster than any other industries. And half of these respondents reported that they're already using private clouds. And more than half are planning to use public clouds within the next year. They really see cloud. They don't see it just as a new IT delivery method. They really see it as a key enabler for business model innovation. And basically, what they're seeing is that cloud, one in three of the respondents, really see cloud as an opportunity to drive new revenue streams. And in a recent Gartner survey, what they reported is that they're predicting that the insurance industry is going to see a compound annual growth rate of 36% through 2016. So the fact is that the good news is that opportunity really does exist for OpenStack in the financial services sector. So a quick introduction to our team, the Cloud Labs team. We've been working in cloud technologies for over a decade. We started with high performance on-demand websites. We started doing data center automation. And we've been moving up the stack towards private and public cloud engagements. And our main mission really is to drive customers to realize the potential of cloud computing. So as a result, we've been working for the last couple of years on these OpenStack and newer technology opportunities. And that's the whole idea of this presentation. We want to be able to share back all the feedback and all the information we receive from these customers. And we'd really like you guys to leverage this. And hopefully, we won't let this opportunity pass. So let's talk about a use case. And here's Sean. I'm Sean Murakami, colleague with Manuel on the Cloud Labs team. In my section, I'll talk to you a little bit about what we've done with this particular customer. A customer that we worked with is a large American insurance company. They're really looking at ways to grow their businesses in new areas and really to look at cloud computing and realize the benefits of it. They were doing the traditional data center operations. Folks would come in, request hardware. They would have a build team. They'll deploy that stuff. And it'll take a few weeks to get the compute resources that they required for their applications. And they're really looking to revitalize that, look at bringing things faster to market and to improve the productivity of their operations teams as well as their customers. So like any insurance company, as Manuel was saying, they have a lot of concern around these compliance regulations, things like HIPAA, SOX, PCI, being able to audit, log, track information, track who uses those resources, how they're using it, and really concern about securing the data and encrypting the data on the cloud systems.  So they're looking to be able to take a solution and tie it in with their own, in this case, active directory, enterprise directory systems to be able to provide that mechanism and to provide that level of tracking of who did what and what times. So that was very important to them. They're also looking at new network technologies. So Quantum at the time was something that they were really looking into, looking at new software-defined networks. And they also wanted to use some of their script automation they have built over the years and be able to reuse that. And OpenSAC has made it available for them to actually help with that automation. So this is a typical OpenSAC deployment design. So what we did for one of the pilots was take a few nodes. We had a dedicated network node with a Quantum L3 agent and the HTTP server, sorry, the HTTP agent, a single controller node with the majority of the OpenSAC score services. And then a couple of compute nodes that were used for the virtual machine testing, running Quantum plugins. And so what you see at the bottom in the data network, they also wanted to look at leveraging, as I said, the software-defined networking, being able to utilize GRE tunnels that Quantum provides to provide a multi-tenant network capabilities for their customers. So what were their impressions and feedback from this pilot? They really liked the APIs that OpenSAC provided. It really allowed them to integrate into their existing scripts and system services. They were using, I think, Foreman and Puppet to help drive some of that post-configuration automation on those virtual machine resources. I think at the time, they're also using VMware, and they're looking at other opportunities for hypervisors. And during this pilot, we introduced them to KVM, so they're really interested in what kind of capabilities that provided and the performance that came with it. And from a networking side, they also liked the notion of being able to pin multiple floating IPs. Some of their use cases across some requirements require them to be able to have multiple interfaces where some of their applications running those systems may take in different types of track from different end users. So what could be improved from, I guess, what came out of that pilot? At the time, we were using OpenSAC Folsom. Grizzly wasn't released yet. And as we know, Quantum was a bit immature at that point. And so they were really looking to improve some of those capabilities, like scalability in HA for things like, at the network node, being able to provide mechanisms where HA's sort of out of the box. So these are some of their kind of feedback from what they saw from a standard installation. There's no built-in backup of recovery systems, being a large enterprise, and being able to keep and track data, and keeping that data secure, and being able to look back in time in case they get audited. It was very important. And so backing up that data in turn becomes very important to them. And then the customer was using Active Directory. And at this point in time, Active Directory integration with Keystone wasn't, say, rich in feature or function. And we had to go through a lot of hoops to integrate Active Directory. Some of the interesting points with this particular feedback was the way that Active Directory and Keystone was integrated, and the way their end users were using OpenStack in the end required them to replicate users into their corporate directory, which doesn't make sense for a service provider model. And that's something that we're hoping that changes. And then finally, looking at monitoring capabilities, I know with the latest release, with Solometer and being able to meter those things is very important. So I see the community doing a lot of good work to tackle some of these problems that they're looking at. So I'm just going to go over some of the lessons learned we had with the customer. Thanks, John. So there's probably two reasons we wanted to share this view with you today. So one is a bit of a selfish reason. Are there any OpenStack developers in the room here? OK. I guess my first reason won't hold then. So part of this was actually to share with the community what drives some of our involvement, IBM's involvement, in OpenStack. And this is coming from a private cloud perspective, people who are figuring out how to use cloud technology in industries that a lot of people actually think would be slow to adopt cloud because they're regulated, because if you read that early cloud material about the kinds of things and the kinds of workloads you should take to cloud, a lot of the analysts and a lot of the consultants would actually say, do not take a regulated workload to cloud. And what we've seen in the past two years is that has completely changed. It has become almost normal for a number of enterprises to put any kind of workload on cloud. So what we have to do when we look at OpenStack is really get aggressive around closing the gap between cloud implementation and the processes that these companies have been using to run their business. One interesting story, I actually spent a couple of years working in South Africa. And there was a major bank at the time that had a number of IT challenges. And there's a quote that stuck with me from one of these projects. And he said, think of a bank really as just an information technology company. And I thought that was a little strange. You think of capital and you think of going to the bank and getting money and going to the bank branch and that experience and the ATM network and all that stuff. And he said, so we asked him why he thought of the bank as an information technology company and that it should be an aggressive adopter of IT. He said, well, if we lose a branch building, some people will be upset. They'll go to a different bank building. If we lose two buildings, that's OK. We can rebuild them. If I lose all my buildings, that's fine. We can rebuild them. We can bring in temporary ATMs. If I lose my data center, I'm out of business. So their number one concern is being an excellent IT provider. So it's kind of interesting for us to get really deeply engaged working on cloud computing and figure out if these are people who are striving to be, in some cases, the best at information technology, what can we learn from them that would apply not just to the banking and insurance industry, but that applies generally to people using cloud. So a lot of their experience is, OK, how do I look at my information technology assets as potential new businesses? How do I extend, essentially, the internet into my data center was a lot of the thinking here. They're not just looking at this as an example of, I want to be cheaper. A lot of this, as Manuel was pointing out, was actually about accelerating their business and really taking new businesses out to the market. What that means is they've got to look at what they already have and the processes that made them great as a company and figure out, how do I leverage these to do something new? And they aren't necessarily thinking that to do something great, they have to take their back end transaction systems and put them on a public cloud. They're looking at the systems they have in place today and the processes that they have in place running those systems and figure out how to extend new customers in and almost extend the idea of a public cloud or extend the internet. So their data center is just a way of delivering new services out to new customers. Now, when you tie into these existing systems, as you can imagine, and Sean was pointing out some of these things, is you're tying into something that runs the core of their business. You're tying into their customer records. You're tying into a transaction system. You're tying into CRM systems. So there's paranoia. And there should be paranoia about tying into these systems.  That's your health insurance information. So the top things on their list were about protecting them. It's about protecting those assets. So when you come to them with something, and at the time it was OpenStack Folsom, you say, I don't exactly have best of breed integration into user authentication and authorization systems. It's a non-starter. You just can't deploy a cloud solution that doesn't tie in properly to an enterprise and authentication authorization system. So that was kind of expected, but the importance of it, and the focus on it, and the amount of time we spent just on that one problem getting that right. Now, you think, OK, well, but that's not the transaction system looking for user data or customer data. It's just a cloud system. But why does that matter so much? Well, the regulations they have to live by to keep their licenses to run their businesses, they have to prove that they are in control of their systems, that they know who changed what when. And the first part of that is the who part. So if you are a cloud administrator and you deploy a new system, and it has a negative impact on the system next to it, you have to know who triggered that. All laws that regulate these industries are written about people doing things or organizations doing things. They're not written about what autonomic agent did something. It has to be accountable to the company and the person. So it is critical, critical, that they can actually tie into a system they trust that identifies the people who do things. And once you get past that, everything else is just fancy technology. So that was just one of the key things. And it was interesting to see how much of their business and how much of the way they run IT is tied into just identifying who did what when. And when you really dig into some of those things, like SOX compliance and best practices for running a data center, a lot of it is just keeping track of what happened when so that you can prove, should something go wrong, that you made a best and reasonable effort to keep your IT systems in control. So these people are happy to adopt cloud, which was kind of interesting. I mean, we actually thought regulated workloads, they wouldn't go near this. What they were bringing to us weren't dev test use cases. They were bringing new business-based extensions of their company that required them to extend out to the internet, reach new markets, connect with new partners, connect with new developers or external parties, building new systems. So they're building ecosystems around insurance, but they had to start from a solid base. So integrating into the existing network and storage, I mean, a lot of this was just, you need to unleash from what we have, right? We're not gonna spend $20 million to build the best cloud in the world. We need you to tie into what we have. Leveraging existing procedures and script and code libraries. And that was the other thing. They figured out quite a bit of automation over the years, right?  So going in and telling them, cloud will help you automate things. They'll just come back and say, I am 99% automated already. So cloud isn't about just automation to me. You have to tell me how I tie in to those existing scripts, those existing automation frameworks. So it's great that you can deploy a VM, but I've got this whole other automation library I need to leverage. And the last thing here, if I haven't said enough, security, security, security, security, right? It really is not just the authentication authorization part, but we got into some horribly deep discussions about every hypervisor technology we bring in, every network technology. And one thing that would really accelerate is to pick certified technologies. Things like FIP certification and things like that. So every time you introduce something into a regulated organization, they kind of have to do a bit of a threat analysis on it. So it actually helps if you can build from proven technologies. So the more that we treat OpenStack as a proven technology to build on, that many other companies have built on and even maybe take it that next step to certification, which is something that, at the end of this, if anybody has some feedback on that, I'd love to hear it. But to some extent, we probably will have to go and OpenStack that next, through that next boundary at some point and think about actually certifying some of the code to the standards that help them stay in compliance in their industry. So again, another thing that we just kind of learned, we did a lot of, I think we've been doing cloud engagements. I think we called it request-driven provisioning before we called it cloud. A good part of that we did was always about the return on investment for dev test was the classic business case, right? People can reuse systems, you get 700, 800, 900, 1,000% return. The cost story around cloud is not what was driving these clients anymore. It's not what was exciting their business stakeholders. It was, I need to reach a new business and come up with a new business model and I need IT infrastructure that helps me do that. I can't build end tiers of network perimeter security and still expect to be able to do something innovative like buy a new company or partner with a new business and actually deliver a new service that none of my competitors have. So the kinds of things that get a little surprising is when we talk to a lot of the CIOs of finance companies now, they will say my goal is to turn my IT organization into a service provider and do things like white-labeled banking, insurance marketplaces. Those are a bit famous in the US. If anybody's from the US right now, the insurance marketplaces, cloud should help you do those right.  You want, anybody here from the US? Okay, so the healthcare.gov thing resonates with people. There's a better way to do this, right? And so they actually look at cloud as an architecture that scales well that helps them extend out, connect to new business partners. There's no way that a health marketplace works, except for it to almost be an extension of your data center to the internet, right? So if your architecture doesn't help you define a network that securely connects to your partners, it doesn't help you grow your business. And one other thing that was needed was they really needed to meter this, right? They wanted to go to a shared model and internally it's always a struggle. We've actually done a lot of financial studies with customers and one of the biggest problems they have is how do I actually convince my accountants that doing a cloud model internally is gonna work? So externally they have no problem buying cloud from the internet. For those who use accounting, that's an operational or OPEX budget, right? I just use a credit card or I use a purchase order and I buy X amount a month. Internal accounting systems for capital acquisition of software hardware and assets do not work that way. So internally to become a service provider, they almost have to flip their accounting models around and to do that, they're building a new model internally that has metering and things like that as well. So they actually, if you don't provide them that instrumentation, they can't build the accounting model to actually make it work internally. So actually the very first cloud engagement we did with a health provider in the US, the single longest part of our implementation was actually upgrading their accounting system. It wasn't had nothing to do with cloud or virtualization or technology or any of that kind of thing. So the thing we're kind of excited about now is the metering has gotten kind of baked into the architecture. So when metering gets baked into the architecture, at least on the IT or the cloud side that problem's taken care of, you may still have to wait for the accounting upgrade, but when we were first doing this, we had to do both sides of the problem. We had to come up with a metering architecture for private cloud and then go work with the accounting system people and figure out how to make those things match. Because the existing accounting systems looked at every piece of the cloud as a physical asset that had to be depreciated not something that was metered out to individual services. And we didn't even have the metering framework at the time. Okay, so go through a few kind of high level things we've learned, a couple calls to action for the people in the audience here and then we should have time for some questions. So insurance industry, I don't know how much I believe analyst papers and the stuff we get sometimes, but this one kind of bent my head a little the first time I read this. The industry that's expected to use the most cloud was insurance, and at first it didn't make sense, but this was about a year ago and this was before the idea of insurance marketplaces happened. And this was before we started realizing that healthcare is a worldwide issue and insurance in the growth markets that the growth rates of those being up around 30%, it just means that those are businesses under extraordinary growth pressure, right? So the dominant architecture for onboarding new businesses, cloud just kind of the math works out that insurance becomes one of the leading consumers of cloud over time, which actually means all that nasty regulation stuff like HIPAA and PCI compliance, because there's a lot of payments involved that those certifications of cloud infrastructure become quite important to the business that's going to consume the most cloud. So it's kind of an interesting wake-up call for some of us that the problems we needed to focus on in cloud were industry aligned, right? They were business aligned, they were aligned to stuff that we used to harden into mainframes. Just another part of this, I mean the way we're now kind of looking at some of the things we do in OpenStack, our use cases are shifting a little. For the past few years, it's been just focusing on hardening OpenStack as a technology, right? Looking at what does OpenStack need to do so it's better for storage? What does it need to do so it's very flexible with respect to software-defined networks? Yeah, all that stuff is gonna continue, but there's another set of use cases that we need to spend some time on, and some of those have come quite a long way. If we look at what we were doing in these pilots when we were first trying to convince IBM customers that it was the time to look at OpenStack, I mean we were doing that on the fulsome basis from well over a year ago now. And a lot of these things that were real inhibitors like proper authentication and authorization, proper logging techniques. One thing I probably didn't talk about enough was the challenge of doing proper auditing and logging, because again, the record keeping is a critical part of these. If you look at what's really behind some of these regulations, it isn't just being able to prove who accessed it when, but you have to keep those records in a reasonable form that you can interpret, that an external auditor can interpret for up to three years. So sometimes it's five years, sometimes it's six months. It just depends on the industry and the procedure, but there is definitely this common theme around having a standard way to look at your system logs and to look at system logs for distributed systems. So that was actually something we were quite proud of was working together with the community to bring in the cloud, C-A-D-F, cloud auditing. I always forget the acronym, but it was the DMTF format for helping make sense of auditing and logging records, helping register certain triggers like login events or critical resource access and things like that. Just improving and testing as a basis. I was actually a little disappointed in one of the panels I attended this week. The panelist, I think, was the CTOs. Three of them gave, in my opinion, the right answer to this question. The question was, is cloud ready for production? For business. And three of them said, yes. I would say those are the three companies that probably had the most mature technology implementations. And one said, oh, maybe. I think that was a bit of defensive maneuver from where they were in their own product cycle with using OpenStack, but OpenStack has clearly become the basis for a lot of companies to do business. And moving on to Grizzly and moving on to Havana, that will become even easier with that, focus on testing, focus on stability. If you're running patient records, transactions, insurance claims, and you're doing that in a cloud infrastructure, this stuff just has to work. So the focus on testing in OpenStack is absolutely fantastic. We're thrilled about it. The idea that a change is made in the source or 700 changes results in 700 builds, it halts in 700 test cycles, and that happens in one day. I mean, there are very, very, very few enterprise application and software products that are tested as much as OpenStack. And that actually really does resonate with enterprise customers. The idea of extraordinary focus on testing. And the last one, it's a subtle one. I don't think we're 100% of the way there in the community, the zero outage window business. This is something that will require continued focus, but the kinds of businesses we're talking about here, is anybody like going to an ATM on a Saturday night and it says it's down for maintenance? I mean, it's just not acceptable. So if we're running business channels, external channels, if we're running real life transactions, we're in a zero outage business. So what we're doing here with respect to continuous upgrade, that's critical stuff. And you know, these industry requirements, I actually think we're kind of where we're starting to head. And this is my soapbox and this is my view and people in the room may have a different opinion, but software defined networking, that's gonna happen. Software defined storage, it'll happen. Enhancements to availability and hypervisor and all that stuff, that'll happen. But understanding what people need to run on OpenStack and making sure that we're closing those gaps on things like auditing, things that probably don't excite all the developers. But those let people run their business on OpenStack and that's a big deal to us. So with that, we did leave about five minutes for questions. So us, Sean and Manuel, they come back up here. If you wanna read more, so a lot of what we do is not always industry focused. We have a little blog on the internet. Sometimes we post videos up there just short demos of OpenStack, stuff like that. We have our YouTube. We also post it so you can download them online. Yeah, so these charts are, yeah. So it's cool that you're taking pictures. If you want the higher fidelity, you can keep taking them. We like being famous, don't get me wrong. So take as many pictures as you want, but the charts are actually already available in PDF form online and then the, sometimes when we do something cool, we post a video of it, a one minute video of a technology. I didn't know until this morning that we had a Twitter account. You think I would, but, so we do have a, we have a Twitter account where we post ingenious things, 140 characters at a time. With that, if there are any questions, we can go ahead and answer them. Let me say a company, a company like IBM. Yeah, so the question, as I understood it was, where we're going is about software defined data centers, software defined environments. Yeah, OpenStack is about. Right, software defined everything. And what does IBM think about that? Cause we make lots of hardware and we do, we make cool hardware. Actually, I've been in the software business with IBM for about 14 years. It was probably about 10 years into my career before I ever plugged in a machine. And then I realized, the hardware still matters, right? Yes, it's software defined anything, but there is still a base capacity that makes sense. That makes sense. There is still a set of workloads that when you actually get into really analyzing the workload, you can probably run them more efficiently on one platform or another. So there's still optimizations, right? And there are still things, there are workloads. So we used to say, don't move regulated workloads. So now what I tell people is, don't move your most optimized workloads, right? Because you'll actually struggle to reproduce that optimization right now. The next turn of the crank for software defined is actually how we express these optimizations we did in things like power infrastructure, mainframe infrastructure, and actually express those as policies, right? So there are certain things, maybe it's a firewall, for example, that don't make sense to package into hardware anymore because you can deliver those just as efficiently and perhaps in a more scalable way by moving them on to standard workhorse kind of units in a cloud. And we're all for that. And the last thing is we're a company that's done okay as far as going between technology waves. The office I started working at at IBM actually made typewriter balls, right? Now they weren't making them anymore when I worked there, but this is a company that's gone through actually one of the most humbling experiences of my career was going to some of the original IBM offices and realizing how many carpenters we had on payroll 100 years ago because we built beautiful wood cabinets for some of the early tabulating machines. So if you actually want to think about where we've gone as a company and how many technology waves we've gone through, but cloud is a massively disruptive technology wave, right? Which is why it's really, really important for us to not only be here and participate in this, but also to lead our customers to get through that. Because we want to get people off the electric typewriter balls, we love them, they're really cool, but we have to get them onto cloud and what comes beyond that. So I don't see it as a conflict, I just see we still optimize certain workloads and over time we will express those optimizations as policies that can be used by a software to find an environment. I think that is a today's statement, right? I think that's today, today there are still some highly optimized workloads that are still hard to move to cloud because you will not get the same performance. But I think that's a today's statement and one of the things we're doing is looking at those platforms as good places to become software to find environments. There is no reason actually some of our most successful cloud implementations are cloud on mainframe. Because we've started to figure out how to express the capabilities and qualities of service offered by the platform up through standardized interfaces. And those platforms become, whether it's quality of service, whether it's transactionality, whether it's redundancy, whether it's resiliency, those are policies we can express in a software to find way. And not all platforms are gonna be equal. So not all clouds will be equal. They will have different policies that the workloads can leverage from the underlying software to find environment. So great question. I should have paid you for that one. You had to change the accounting process of a customer in order to make the open stack capability available because traditional accounting looks at the each cloud as a separate depreciating item. I didn't quite get it. Can you explain that further more for us? Sure, do you want me to take that one? Okay. All right, so what I meant was not so much that cloud is a separate, but the pieces that make up cloud, right? So if a business unit wanted to do something with IT historically, they would go through a design cycle, right? The way that a project got kicked off, they would say, well, how much is the project in a cost, right? And then they would go do an information technology acquisition. And the way that they actually implement their budget cycle for a project would involve an acquisition cycle, which would result in them getting capital assets, servers, hardware, storage, networks, cables, and so on. And the system that actually figured out how that IT project budget was doing was built around the idea of there being assets, physical assets tied to each IT project. So if you actually looked at their accounting system for IT projects, it was a capital accounting system. So internally, if two departments wanted to run two IT projects and share a capital asset, the accounting system wouldn't let them do it. So one group or one business line on the asset, not two. So it was actually just kind of an interesting, when you actually really dig into what are the barriers for adoption, it just blew our minds that in one of our engagements, it was actually the way that the accounting system treated internal private clouds and the assets to build them as capital assets that had to be charged to one business unit. So it was actually, we had to actually figure out how to produce the right level of information out of the cloud environment so that it could match the different departments and on the flip side, they had to figure out how to adapt their accounting system to actually look at internal systems almost as operational expenditure or regular expense as opposed to you own a bunch of servers. Does that answer the question? Okay. All right. So we've actually hit the end. If you've got really tough technical questions, both Manuel and Sean are here and I always like to give them really tough, meaty technical questions, but we're happy to stay around. We'll be in the hallway if we're running over in the next session. So guys, we're gonna be around all week in hours there. So if you guys ever see us, all right? Thank you. Thank you again.


Welcome everyone to Google summer of code office hours. It's the 31st of March, 2021. So are there open questions, open topics that you have that you'd like to ask about. Grateful to have Gareth Evans with us. He's one of the agreed mentors or proposed mentors for several of the project ideas. Hi, everybody. Hi. Hi, I'm Akira cutie. I have a question. So I'm here. I'm, this is my first time to join this meeting and I'm very interested in the project code. Sorry. Jenkins remotely monitoring. I have several questions about this. It's okay. It, it is though Kiyuchi son, if, if you would prefer, well, why don't you go ahead and ask your questions. And we may some of them we may defer the likely mentor for that project will be a few minutes later arriving so go ahead and ask your questions and if we, if we cannot immediately answer them we may ask you to ask them again later on in the meeting when Oleg joins us. Okay. So, now, the project, the project goal is to correct the metrics from the agent nodes like CPU usage or memory consumption and expose the metrics in the four in the format, which can be used from it from this or graph. And I think the end point should be exposed on the master side, not in the agent side because it is a lot easier to access them. So, is this right? Is this correct? Is this correct? What, what, how do you think? Yeah. I think we are both pros and cons of this idea because exposing on the agent nodes can be, is very, is very good because when exposing them on the node side, we may correct the metrics even if the connection between master and node are closed. So, but I think it is not a good idea because the agent side is not designed to run the script while the master and node is the connection between the master node is done. So, what, what is the opinion of you, of your. I suspect that the reason Oleg originally described placing an endpoint on the agent was for greater diagnosis, not that typical users would actually have access to that endpoint on the agent. I assume that the endpoint on the agent would probably be consumed by the controller and use the controller would also use that to assist, rather than rather than assuming that an endpoint would be inaccessible for, for any generic user because in many installations kubernetes for instance, the endpoint, or the agent is completely dis is completely inaccessible to most users the only thing they can access is in fact the controller. I would guess that I think it's intentional when I, when I look at the description there, where it says, allow exposing monitoring endpoints on agents. And the reason the rationale is because on the controller side, there's not enough data so I assume what that would mean is the agent adds additional monitoring endpoints that are typically only accessible to the controller or to someone who's opened that network access to that agent. Then that would allow querying of more information about the agent as needed. Now, this is one really let's let's bring it to Oleg when he arrives because I think it's an excellent question I've given you my best guess. I'll let Oleg answer it when he, when he arrives, just to be sure, Gareth, do you have any, any other insights that you would offer on that. Yeah, I'm going to defer to Oleg on that one. Okay, I don't know enough about that area to comment. Shisan, do you have other questions about remoting monitoring as a project idea. Yes, I have. And yeah, I think, in my understanding, the, we cannot have a way to distribute the server road of the Jenkins master node, right. I mean, and we have a, we have, we can distribute the road on the agent side using criminal use or something like that. But the Jenkins master side is not, we cannot distribute the server road on the master side. Is that right. I think what you're asking is, is there a way for a Jenkins controller to or a master to be to be spread across more than one node more than one pod and Kubernetes or more than one computer. And the answer is no. So it was that did I answer your question or am I answering the wrong question. Yeah, that's what I want to ask. Yeah. And then the correcting the agents metrics on the master side can be near high. High road on the master on the control node and can, can it be the critical problem. Ah, so my assumption was that the choice to collect the metrics or not is something that would be made as needed to do diagnosis that it might not be an always collect the metrics kind of thing. Now I could be wrong though so that's that's again a good place where we'll ask will invite Oleg to answer when he arrives. Good, good, good question and yes you're right we know that the Jenkins controller is, as you noted, not a horizontally scalable thing right we cannot create multiple copies of it concurrently, working for the same on the same jobs. Okay, thank you very much. And the other questions on remoting monitoring. Now, I don't have. Great, well then let's, let's be sure that we, when when Oleg arrives, I'm going to bring you bring you back and ask you again to, to ask your questions again because I would love to have Oleg's corrections to my poor attempts at answers. Thank you very much. Other questions. Yeah, I have actually a question regarding the, like these are proposal submission process. Can I ask it over here? Sure. You're, you're welcome to ask. I can't promise that we'll do more than a great answer, but please ask. Okay. So like an application proposal period that the students can now submit the applications like for the proposal. So there's one thing which like, there's one document that they are asking Google, which is proof of enrollment for the Institute, like for Institute. So, like, the issue is, I like, add this like we are since online and we haven't like received any kind of when it was offline or college, we used to get like a signature like they want something which has signature from the authority of the Institute like that. So we used to get the identification card with the signature on that on it and the year of enrollment, like if I'm enrolling this year, I get that. But since it's online, so there's nothing like that, but we are like, is there an alternative? Like, can I send a bona fide certificate to Google for proof of enrollment? Like, if do you have any experience or idea about that? I don't have experience. That's a very good question. And I think it given COVID-19 it's a great question to ask in the in the general Google Summer of Code question line because I'm sure I'm sure if you have that question, there are probably thousands of people in the world who have the same question. What what is acceptable as a proof of enrollment, especially given your experience, you said that in the past when you were physically on at the university, you would receive official paperwork and it would have a signature on it. Whereas.  But now it's not there. Right. So, which, which I think if, if your university is doing that, if your educational institute is doing that, I am confident there are others who are doing the same thing. And therefore, it's very much a good question. I'm not sure what they would accept or not accept. Himanshu, is that what we need to do when we are submitting on Google's website. Yeah, yeah, yeah, we need that. I haven't. And what we need, what we need any agreement, do we need signature from university? So sorry to interrupt you, but I'm not wrong. You need a proof of admission to show that you're a bona fide student of a registered university. So there has to be some documentation, either in the form of your mark sheets or transcripts, or an ID card, or a letter of admission to the university which says that you are a student as of 2021, may of 2021. So that's all which they need to validate your academic status. That's about it. Do you have any sample image like how it looks? Right, so, right, so actually I did it for GSOC the other day and they are going to load a few samples on the GSOC website soon. They haven't put up examples as of now. So maybe like wait for a day or two. Let them update it on the GSOC website and then you could look at the example. Yeah, thank you. Thank you so much. We can wait for a week. Yeah, save a lot of time. Okay, so, right. Mark, so I had a question. So the other day I was trying to create a multi branch freestyle project. But it seems that since 2017 it's been deprecated. Right, but I mean I've been very new to Jenkins right and I'm still someone who uses Jenkins and I'm not developing. So I would want to understand if it's possible because I really see a situation where I have I want to use freestyle projects but at the same time make them in a multi branch format and I do not have the expertise right now to write a Jenkins file for all of my repositories and branches separately. So maybe if you could help me understand that a little that would be really cool. Sure, happy to so the simple answer is no you can't use and you shouldn't use I know you don't like that answer but that's the simple answer. You can't use and you shouldn't use multi branch with freestyle, you will be much happier and much, much better off.  The reality is, most of us after we, we made the transition, particularly to declarative pipeline it's, it's pretty simple to express. So long as you're not doing. Well, if you're doing terribly exotic things in freestyle projects you really want pipeline. If you're doing simple things in freestyle projects you want pipeline because it's simple to understand. Thank you Mark. Yeah, and good luck that's having been through that transition and having, having grieved myself at the deprecation of that particular thing. It was, Oh, no, but I love my freestyle projects. That's what it's so much easier. Well, well, I mean, I was, I like my web pages right there just they were they were nice and click and point. Don't forget the snippet generator, be sure you use the pipeline syntax snippet generator I cannot tell tell that story nearly enough people need to use the snippet generator more and more and more. So don't miss out on the snippet generator. That's that's the magic for transition from freestyle the pipeline. Okay, let me look into it. Thanks again Mark. Any other questions. Actually, honestly, I did the point is I can't find that proposal anymore so few. So I have seen that there isn't so that there are two problems have actually come across and since nobody else seems to have any questions. We have a lot of plugins which are up for adoption, but they are never really claim. First of all, like I've seen a lot of plugins that which are which are not up for adoption in a second. So we don't really have good plugins for like gcloud and AWS and let's face it, even if somebody's not deploying these runners directly on Google cloud or AWS, and they're using their own infrastructure for some reason or the other maybe security practices, maybe ease of use or something. There are plugins which are broken, which are not maintained anymore, and there's no, there's no way out if somebody doesn't know Java or Hudson properly.  So maybe, you know, if we have some kind of a terminal based access allowed, I know execute shell works, but like for example in my organization itself Jenkins is installed via Kubernetes. It's installed as a head and shot, or as a directly as a Kubernetes part. I do not have the Jenkins password available with me which is something which is only available during installation. I could not install gcloud I had to ultimately go ahead and learn GitHub actions and set it up using GitHub actions since I could not do it using Jenkins with something I prefer myself. So I mean, do you guys not face such issues or is it like, like you guys already have other ways out to this. I mean I don't know this is a very weird experience but since these are office hours I mean why not ask and share. Fair, fair question so I think what you're asking is, if you don't have permission on the controller to install a plug in. How can you work around that is that what you're saying. No, a little bit of a change it's more like if I do not have access to the node directly, the node, the gen, the nodes on which Jenkins is running directly. So, while I can install plugins but if these plugins are broken. Then what do I do. Okay, so, so I'm not sure I'm understanding the question still so I'm going to keep asking you questions until we until we understand each other so. So it is that that there is the, you need some permissions on the computer that's executing the Jenkins controller that you don't have those permissions is that correct. I do not have permissions on the pod itself I do not have users on the pod I do not have permissions on the part is any way to get about it besides you know maybe running a dummy project and then using execute shell on that dummy project to do it. And that's, that's certainly actually a healthy way to do it if you, if an agent then can do the work for you and so have the agent do the work for you is very good. But I do not have to do this on it. So that's where the entire and it comes to full circle. But isn't that where then you need to negotiate for the capability, either inside the controller or at add on an agent that you can use to do your work. True. Okay, so like has joined us all like we and so sit down. I'm going to pause our questions on Jenkins administration for just a minute. Thank you for joining. I can hear Okiuchi had some questions on the remote and monitoring project idea. He asked them, I gave really poor answers, and we would much prefer that to allow you to give good answers than my really poor answers. Thank you to sound would you like to ask your questions. Yes. Hi, I'm a hero. Nice to meet you and I have a question about the remote monitoring. And yeah, first, I think the purpose of the nose should be corrected on the master side and expose it on on the end point at master node. And that's because the axis to the node is not available can be a cannot be is not available in general so even if we correct the matrix from node. Be a be a master node. We don't have to establish any correction direct connection to the agent node and very easily correct the matrix from master node. You can access matrix from the master from the controller only when the node is connected. I'm sure I'm sorry I can't hear you. Notable. Okay, thank you very much. So, yes, there is a connection between agent and the controller. And when this connection is active, you can connect the metrics from the controller side. But it's not always a case. So for example, when agent loses connection to the controller. And then, yeah, controller won't be able to provide any metrics. It's not reasonable in this case. Plus, we have some agent types, for example, a agent operating cover Apache Kafka, which is not continuously connect the controller is being connected on demand. Every time there is an instance, which is running continuously, which has remote in, and which could be exposed to many torrent. Why we did that is support multiple controllers. So, you mean, you should expose the metrics on nodes arise. So, exposing metrics on the controller side isn't enough for complex setups. In this case, what is the best practice to run the script on the node side agent side. Even if the connection between the master and agent controller and agent is lost. There are multiple ways. So the easiest way that Jenkins controller when connected can install additional many tools on the agent side. So basically launching additional threads to expose metrics there. This way is doable, but this way isn't very reliable. And it requires first connection. There are relative ways to just have a standalone agent or just a part of remoting. I mean, I mean Java agent, which basically exposes the remote instance and its metrics, even if it has never connected to the controller. Thank you. And I understand the advantages of exposing the metrics on the agent side but I think it is very valuable if we expose on the master side because very easy to set up for the system admins, I think. For example, when use the community, when we use the Kubernetes on the OTS, OTS carries the agent nodes. And when we want to correct the metrics from agents and using like Prometheus, we need to set up the service discoveries and set up the configuration on the Prometheus and it can be a hard task for system admins. And so, if we correct the master side, the system admins do not have to establish any extra connection between nodes and the monitoring servers. So just tell the master endpoint to the metrics to the Prometheus. I think, I understand the advantages of establishing the endpoint on the agent side but I want to, I love to create the plug-in to expose the metrics of agents on the master side and I think it's very high variable. And what do you think of this? Well, you could do that. At the same time, we all have metrics plug-in and this metrics plug-in already exposes considerable amount of data from agents. Oh, very. Yes. So if you explore Prometheus plug-in with permanent agents, then you should be able to see the data being returned. But it has many limitations, for example, for cloud APIs, because, well, I think that it would still expose agent metrics for ephemeral nodes, but I'm not sure about that. Sorry. Sorry. The metrics plug-in are now correcting some metrics like CPU usage on the node side. Yeah. There is also plug-in called support core plug-in. Ah, that one. Yeah. So if you look at the support plug-in, I saw the plug-in and the plug-in corrects the metrics at one not continuously, right? Just continuously. Well, there are only a few tools which correct metrics continuously. This is not really needed if you want to stop Prometheus, because Prometheus is a pool-based service. So once a while, it will connect to your instances, request the data, and you need to provide the data. And on your side, it has to be updated periodically, but not for any request. Oh, okay. Maybe for any request, but I don't think that all metrics would be collected in that way, because some metrics are really heavy when we talk about support core plug-in. Can I again ask my idea to correct the master, correct the agent metrics on the master side? Yeah. I think it's definitely something doable. My recommendation would be to explore what's already available, to see the gaps there, and to build your proposal based on this research. Because if you want to create a new engine for agent monitoring from scratch, then it will be like another head for the implementation. Thank you. Thank you very much. Oh, like I think I missed a phrase there. Okay, so it's, you were saying that if you were attempting to create an agent monitoring system from scratch, it would be overhead? Yeah, most likely there will be a lot of duplication, because how current metrics plug-in periods basically collects various data from the system using, for example, GMX and points, using already existing endpoints for collecting agent metrics, and then it exposes everything basically in a three structure where you can have a lot of information. And these three structure could be exposed to parameters. So if you look into the parameters plug-in, it basically wraps metrics to expose them up on request. And yeah, you could do the same for adding new metrics, but you wouldn't need to write a new engine from scratch. It's a bit more different for support core plug-in, because support core plug-in also uses metrics to collect some metadata, but for some other reports, it just does calculation by itself, and if there is something you would like to expose to monitoring systems, you would like me to move this code this way. Do I make any sense? Sorry, I cannot understand about the part of what you say. I do more further research. Thank you. Yeah, that's fine. And if you have any questions, please don't hesitate to ask in the chat, so no need to wait until the next meeting. Okay, thank you very much. Yeah, and the chat channels are quite effective as a way for us to use do question and answer when we're not when we're not in a in this meeting so that's good. Do you have, do you have the URL to the chat channels? Do you have the URL to the chat channels? I'll just post it here. That way you've you've got it. I don't need to. I didn't even ask the question. Let me just put links on each project page where you can find the channels which are specific to this project ID or jsoc6 channel. Right, good point. So let's let's point to the one for the for this specific remoting monitoring project. Let me go find that. So, I'm going to share my screen so that you can see the navigation. I don't want to do anyone any harm and other questions can proceed while while I'm on guitar. Other questions. Well, I have no one coming. So, hello, like, like, I submitted my draft for the proposal. I wanted to discuss about the add support for generating a new plugin file based on the current Jenkins for like I asked this same issue in the last meeting as well. Where you told me like the original plan was to get the list of the plugin files so as to provide it to the configuration for the configuration as code plugin. Right. That this is what I like thought or have understood. So, my question is basically I have also commented it so I thought maybe I go ahead. So, like, what I'm thinking is giving a giving out a YAML file but in the issue with Tim Tim created and the GitHub issue tracker. He said like he provided like all the three alternatives so standard output text file and as well as YAML. So I was thinking of like all the three, like, is it okay or is it fair to go ahead with that? Like, what do you say? Yeah, I don't think that complementing three outputs is a big overhead because once you can create a data model you can export this model in any format. It shouldn't be a big deal. Okay, okay. It's probably worth pointing out where those, so where those three different data formats would be used. So the standard out is probably going to be used for just debugging what plugins are there and what's what needs to be done. The text file format is to create a plugins.txt file that can be used for generating a like a custom .rimmage with all those plugins in there. And the YAML format is for the helm chart. So one of the things you can do is list plugins to be installed on startup inside the helm chart for Jenkins. That's the use case for those. So just to give you a bit more context on why there's three different formats. Thanks. And like, can I ask like for the, like if I have, I had posted my draft for the proposal, like I don't want to make this meeting about me, but I'll go ahead and say like ask this question. Like what do you think? Like is there any feedback from you guys? Like I saw, but there were not many comments as much as I expected for my proposal for my draft. Like any comments as such by the mentors and the community members? I think we should really take it offline and handle it synchronously, because in my case I just started looking in proposals. If you want, I can send a few dozen technical questions and clarification requests there. But keep in mind that there is no objective to create a full specification at this phase. So the idea is to have a proposal which can be related by mentors. But it means it has to have clear deliverables. It should be possible to estimate time for this deliverable. So to understand whether the proposal is feasible and mentors should be able to see basically what's your way of thinking and decide whether they want to work with you on this project or not. So that's the main objective. There is no objective to create a full description of what you will do. And most probably it's not possible at this stage anyway. But for the mentors to see what I'm thinking, I should describe it. It is kind of contradicting each other. If I want the mentors to understand what I'm thinking, I should probably describe it. What I understood from my research or whatever I did. So isn't it contradicting? You also said that it shouldn't be too much technical for the draft. So mentors make a decision based on overall impression. So they meet with you. Let's say this meeting is in the charts, etc. They got some permission from there. If you create some pull requests, etc. They also got information from there. And proposal is only a part of that. And your proposal will be also only a part of this decision making. If you have never talked to your mentors during the application period, of course, proposal is the only way to convey your idea. But for the majority of us, it's not the case. So you just focus on following the GSOC guidelines and make sure that you have all the required information there. You will like to get more feedback. We still have two weeks before the application deadline. And if you don't get enough feedback, if you're concerned about particular topics, don't hesitate to ask me in the chat. And yeah, okay. So now Oleg, you guided towards potentially a less precise definition. When we did the get plugin exercise last year, that project we felt in about middle of it, we felt like, oh, we should have thought about this before. So my experience was the other direction that gee, I should have, we should have had more asked more questions in the beginning. It's okay that the project during its execution changes its definition somewhat. But can you give some hints there? Yeah, there are three phases. First is application period. Second is community bonding and 30 is coding. So our expectation that by the time the coding begins, you have clear understanding what to code and how to basically deliver on the changes plan for the first phase. For that, it's not on the application period, there will be a community bonding phase. And community bonding phase is when you meet with your mentors discuss what would be the project deliverable and it's also an opportunity to adjust your project. So, yeah, because anyone has different starting points, sometimes you just need knowledge transfers, sometimes you need to study particular technologies, and you can write the proposal and specification without studying it. But you are not expected to study all the things before you get accepted. Yeah, it's understandable. So we basically expect mentors and students to work during the community bonding to scope the project, to do the evaluation, basically do some reality check and they, when we discover together you can make adjustments in the project. Okay, and I think that was one of the weaknesses. I'm glad you pointed that out that was one of the weaknesses we had is, I'm not sure we were as effective during the community bonding phase as we should have been in doing that kind of deep detailing of what the next phases would look like so we were getting familiar with each other but I'm not sure we did nearly enough specifying and final design during community bonding last year. Good insight. Yeah, to be final design, because for many projects, first phase is actually a discovery. Yeah, now it's a bit different because in the previous years, so in 2016, there were two phases, but there were two long phases, then there were three phases, and now we have two phases but they're also short. So probably it's, if you will dedicate the first phase to discovery, then you will have almost no time to do the whole thing. So please be cautious about that when you plan your work with mentors. But at the same time, I still find to firstly do prototyping and to see whether the ideas work or not and to adjust as you go. Okay, you just need to have a clear plan. So on June 7 or when the recording begins, you are not locked by anything. So you have the required infrastructure you need, you have the required knowledge, and you have a plan on what you would do. Because the worst thing which can happen in that coding period starts and you cannot really focus on implementing your project. This is what mentors and students expect to handle during community bonding. So when you were describing the difference between two phases and three phase in that case those are, they used to be three coding phases, and now it's two coding phases, did I understand correctly. Yes. Okay. There are two variations in this year. Got it. So, while in principle, it doesn't change too much because just subject for the planning, but before, basically, if even during the first coding phase, there was no final deliverable produce. So for example, yeah, there was a prototype, but nothing we should go to production. There were two phases to basically learn from the prototyping and to implement something final and many projects actually follow this way. Yeah, this year, it's unlikely an option. So just when you plan your project, if you see that you need some prototyping before you can do design and final implementation, it's perfectly fine. You can put it in the schedule. That's okay. So deliverables and deliverables, but yes, you cannot predict everything. Yeah, I don't know any JSOC project, which would go 100% smoothly in terms of delivering coverage in case it was planned. Actually, I have one more question. It's regarding the like office hours only. You had mentioned like you guys keep a meeting for configuration as code. I also put up a message regarding like this question. Is there any meeting but there was no response. Is there any meeting like that I'm not aware of because I went to see the events calendar and there was no mention of. Yeah, there is a configuration as code project meeting every two weeks. But we've been skipping it for the law since the new year because there was no much interest. So sometimes it's only me in team available and we're in a good sync without project. So we basically decided that if there are no other contributors interested to participate in, we want to host them for now. There is one time agreement that we would create the configuration as code infrastructure is called special interest group. We'll just make configuration as code again installation manager and other components are part of this seek and probably expand the scope so that there are more contributors invited. But yeah, right now we haven't done that. So for like for actually since the project is very much related with as you also mentioned with configuration as code and I would like like but since you are also saying that no, there are not many contributors, but I would like if it is possible to have these meetings like if you can or if the community can. We can do that. So, yeah, one of our responsibilities of mentors during the community bonding is to ensure that the community bonding happens. It means that the GSoc students get introduced the community to the stakeholders and that the connections with the community are not limited to mentors themselves. So there are special interest groups. Yes, some of them are rather dormant at the moment, but it's not like we don't have contributors working in this space. Because, for example, what had this configuration as code plugin, it reached a certain station, it addressed the most of the demands. It became stable enough. And basically the focus of the development switched to other areas. So for example, plugin installation manager, I wouldn't call it stable now. It definitely improved since we introduced into southern thinking, but there are still bugs that are still a major features that are many interested users and contributors in this space. And basically host meetings just for that. But for configurations code plugin development. Yes, at some point that there was just no interest as is to host it on a regular basis. Don't worry, we have a lot of contributors around. Yeah, I'm looking forward to those meetings. Thank you. Okay, so was there any confusion, possibly a separate SIG or like had the configurations code team considered just bundling into like the platform SIG. We were talking about three options. So currently, so configuration is called the plugin was started under the umbrella of cloud native SIG. The reason was mostly because of your configuration is called the essential part for that. The main time configuration is called isn't limited to cloud native for deployments. It's actually much more relevant for class configuration management use cases. And yeah, so there are many areas where it will be applied. We were discussing making a part of platform SIG, but at the same time platform SIG was pretty packed. So we decided that it would rather be better to have a separate SIG, but it's something which could be revisited. Option. Great. Thank you. So we've, we've reached our time. Are there other questions before we conclude. All right. Thanks very much. See us in the chat channels. Conversations are good there to start those and continue them looking forward to pull requests looking forward to yes we'll get more reviews out for for proposals that are out there. Thank you for your proposals. Much appreciated. Thank you so much. Thank you for the chance. Thanks.


We're back with Jerome West, Product Management Security Lead for HCI at Dell Technologies, Hyper-Converged Infrastructure. Jerome, welcome. Thank you, Dave. Hey, Jerome, in this series, a blueprint for trusted infrastructure. We've been digging into the different parts of the infrastructure stack, including storage, servers, and networking. And now we want to cover hyper-converged infrastructure. So my first question is, what's unique about HCI that presents specific security challenges? What do we need to know? So what's unique about hyper-converged infrastructure is the breadth of the security challenge. We can't simply focus on a single type of IT system. So like a server or a storage system or a virtualization of use of software.  So luckily, we have excellent partners, like VMware, Microsoft, and internal partners, like the Dell PowerEdge team, the Dell Storage team, the Dell Networking team, and on and on. These partnerships and these collaborations are what make us successful from a security standpoint. So let me give you an example to illustrate. In the recent past, we're seeing growing scope and sophistication in supply chain attacks. This mean an attacker is going to attack your software supply chain upstream so that hopefully a piece of code, malicious code, that wasn't identified early in the software supply chain is distributed like a large player, like a VMware or Microsoft or a Dell. So to confront this kind of sophisticated, hard to defeat problem, we need short-term solutions and we need long-term solutions as well. So for the short-term solution, the obvious thing to do is to patch the vulnerability. The complexity is for our HCI portfolio, we build our software on VMware. So we would have to consume a patch that VMware would produce and provide it to our customers in a timely manner. Luckily, VxRail's engineering team has co-engineered a release process with VMware that significantly shortens our development life cycle so that VMware will produce a patch and within 14 days, we will integrate our own code with the VMware release. We will have tested and validated the update and we will give an update to our customers within 14 days of that VMware release. That as a result of this kind of rapid development process, VxRail had over 40 releases of software updates last year. For a longer-term solution, we're partnering with VMware and others to develop a software bill of materials. We work with VMware to consume their software manifest, including their upstream vendors and their open source providers to have a comprehensive list of software components. Then we aren't caught off guard by an unforeseen vulnerability and we're more able to easily detect where the software problem lies so that we can quickly address it. So these are the kind of relationships and solutions that we can co-engineer with effective collaborations with our partners. Great, thank you for that description. So if I had to define what cybersecurity resilience means to HCI or converged infrastructure, it to me, my takeaway was you got to have a short-term instant patch solution and then you got to do an integration in a very short time, two weeks, to then have that integration done and then longer-term, you have to have a software bill of materials so that you can ensure the provenance of all the components. Help us, is that a right way to think about cybersecurity resilience? Do you have additives to that definition? I do. I really think that cybersecurity and resilience for HCI, because like I said, it has sort of unprecedented breadth across our portfolio. It's not a single thing. It's a bit of everything. So really the strength or the secret sauce is to combine all the solutions that our partner develops while integrating them with our own layer. So let me give you an example. So HCI, it's basically taking a software abstraction of hardware functionality and implementing it into something called a virtualized layer. It's basically the virtual, virtualizing hardware functionality like say a storage controller. You could implement it in hardware, but for HCI, for example, in our VxRail portfolio, we, our VxRail product, we integrated into a product called vSAN, which is provided by our partner VMware. So that portfolio strength is still through our partnerships. So what we do, we integrate these security functionality and features into our product. So our partnership grows to our ecosystem through products like VMware products like NSX, Horizon, Carbon Black and vSphere. All of them integrate seamlessly with VMware. And we also leverage VMware software partnerships on top of that. So for example, VxRail supports multi-factor authentication through vSphere's integration with something called Active Directory Federation Services or ADFS. So there's a lot of providers that support ADFS, including Microsoft Azure. So now we can support a wide array of identity providers such as Auth0 or like I mentioned, Azure or Active Directory through that partnership. So we can leverage all of our partners, partnerships as well. So there's sort of a second layer. So being able to secure all of that, that provides a lot of options and flexibility for our customers. So basically to summarize my answer, we consume all of the security advantages of our partners, but we also expand on them to make a product that is comprehensively secured at multiple layers from the hardware layer that's provided by Dell through PowerEdge to the hyper-converged software that we build ourselves to the virtualization layer that we get through our partnerships with Microsoft and VMware. Great, I mean, that's super helpful. You've mentioned NSX, Horizon, Carbon Black, all the VMware component, Auth0, which the developers are going to love. You got Azure identity, so it's really an ecosystem. So you may have actually answered my next question, but I'm going to ask it anyway because you've got this software-defined environment and you're managing servers and networking and storage with this software-led approach. How do you ensure that the entire system is secure end-to-end? That's a really great question. So the answer is we do testing and validation as part of the engineering process. It's not just bolted on at the end. So when we do, for example, the X-Rail is the market's only co-engineered solution with VMware. Other vendors sell VMware as a hyper-converged solution, but we actually include security as part of the co-engineering process with VMware. So it's considered when VMware builds their code and their process dovetails with ours because we have a secure development lifecycle, which other products might talk about in their discussions with you, that we integrate into our engineering lifecycle. So because we follow the same framework, all of the code should interoperate from a security standpoint. And so when we do our final validation testing, when we do a software release, we're already halfway there in ensuring that all these features will give the customers what we promised. That's great. Let's close, pitch me. What would you say is the strong suit? Summarize the strengths of the Dell hyper-converged infrastructure and converged infrastructure portfolio, specifically from a security perspective, Jerome. So I talked about how hyper-converged infrastructure simplifies security management. Because basically you're gonna take all of these features that are abstracted in hardware, they're now abstracted in the virtualization layer. Now you can manage them from a single point of view, whether it would be say, for VxRail it would be vCenter, for example. So by abstracting all of this, you make it very easy to manage security and highly flexible because now you don't have limitations around a single vendor. You have a multiple array of choices and partnerships to select. So I would say that is the key to making it to HCI. Now what makes Dell the market leader in HCI is not only do we have that functionality, but we also make it exceptionally useful to you because it's co-engineered. It's not bolted on. So I gave the example of S-bomb. I gave the example of how we modify our software release process with VMware to make it very responsive. A couple of other features that we have specific just to HCI are digitally signed LCM updates. This is an example of a feature that we have that's only exclusive to Dell, that's not done through a partnership. So we digitally sign our software updates so the user can be sure that the update that they're installing into their system is an authentic and unmodified product. So we give it a Dell signature that's invalidated prior to installation. So not only do we consume the features that others develop in a seamless and fully validated way, but we also bolt on our own specific HCI security features that work with all the other partnerships and give the user an exceptional security experience. So for example, the benefit to the customer is you don't have to create a complicated security framework that's hard for your users to use and it's hard for your system administrators to manage. It all comes in a package. So it can be all managed through vCenter, for example. And then the specific hyper-converged functions can be managed through VxRail manager or through STDC manager. So there's very few panes of glass that the administrator or user ever has to worry about. It's all self-contained and manageable. That makes a lot of sense. So you got your own infrastructure, you're applying your best practices to that, like the digital signatures, you've got your ecosystem, you're doing co-engineering with the ecosystems, delivering security in a package, minimizing the complexity at the infrastructure level. The reason you're on this is so important is because SecOps teams, they got to deal with cloud security, they got to deal with multiple clouds. Now they have their shared responsibility model going across multiple, they got all this other stuff that they have to worry. They got to secure the containers and the runtime and the platform and so forth. So they're being asked to do other things. If they have to worry about all the things that you just mentioned, they'll never get, the security is going to get worse. So my takeaway is you're removing that infrastructure piece and saying, okay guys, you now can focus on those other things that is not necessarily Dell's domain, but you can work with other partners and your own teams to really nail that. Is that a fair summary? I think that is a fair summary because absolutely the worst thing you can do from a security perspective is provide a feature that's so unusable that the administrator disables it or other key security features. So when I work with my partners to define and develop a new security feature, the thing I keep foremost in mind is will this be something our users want to use and our administrators want to administer? Because if it's not, if it's something that's too difficult or onerous or complex, then I try to find ways to make it more user friendly and practical. And this is a challenge sometimes because our products operate in highly regulated environments and sometimes they have to have certain rules and certain configurations that aren't the most user friendly or management friendly. So I put a lot of effort into thinking about how can we make this feature useful while still complying with all the regulations that we have to comply with? And by the way, we're very successful in a highly regulated space. We sell a lot of VxRail, for example, into the Department of Defense and banks and other highly regulated environments and we're very successful there. Excellent, okay, Jerome, thanks. We're gonna leave it there for now. I'd love to have you back to talk about the progress that you're making down the road. Things always advance in the tech industry and so we would appreciate that. I would look forward to it. Thank you very much, Dave. You're really welcome. In a moment, I'll be back to summarize the program and offer some resources that can help you on your journey to secure your enterprise infrastructure. I want to thank our guests for their contributions and helping us understand how investments by a company like Dell can both reduce the need for DevSecOps teams to worry about some of the more fundamental security issues around infrastructure and have greater confidence in the quality, provenance and data protection designed in to core infrastructure like servers, storage, networking, and hyper-converged systems. You know, at the end of the day, whether your workloads are in the cloud, on-prem, or at the edge, you are responsible for your own security. But vendor R&D and vendor process must play an important role in easing the burden faced by security, devs, and operation teams. And on behalf of theCUBE, production, content, and social teams, as well as Dell Technologies, we want to thank you for watching a blueprint for trusted infrastructure. Remember, at part one of this series, as well as all the videos associated with this program, and of course, today's program are available on demand at thecube.net with additional coverage at siliconangle.com. And you can go to dell.com slash security solutions, dell.com slash security solutions to learn more about Dell's approach to securing infrastructure. There's tons of additional resources that can help you on your journey. This is Dave Vellante for theCUBE, your leader in enterprise and emerging tech coverage. We'll see you next time.


I work at this fast food spot right and dog. I tell you these customers, bro These customers be tripping bro. First of all first of all, uh, can I have a? Why are you with my job? Huh? Why are you here? Why are you here making me do the job? I applied to do that's one, okay? Second of all second of all Second of all I see some of these people roll through the drive-thru these niggas roll through the drive-thru spend like $40 $40 in cash on some fast food On some fat like bro Yaman didn't teach you to cook or something, huh, right? I just want a burger throughout the day Throughout the day we deal with over a couple hundred customers and it chips away at our moral integrity You know it chips wet our moral integrity slowly by slowly each repetitive process It drives us into the corner of our brains until even even the even the smallest request seems like a hassle Can I can I split on two orders, please? That makes me want to split you into two orders, okay? That makes me want to split you into two orders. You know, we actually don't mind We actually don't mind handing people extra sauce packets I don't know where that myth comes from or where it came from you ask for some extra sauce We don't really care that much. We don't right, but there's always just that one guy That one guy. Hey, can I get a Can I get 50 sauce packets? Oh even that doesn't seem so bad. He didn't let me finish. He didn't let me finish Can I get 50 sauce packets of each sauce? But sir, all you got was two items.  Okay one by one nigga What really gets me though What really gets me are the customers that go ballistic when they find out Even just one item is missing from the bag and don't get me wrong.  That's it That's it other times though other times People make it seem like the world's gonna end. They make it seem like the rapture is about to get initiated Just because we forgot to put their fries in the bag or we didn't fill up a certain container of food for them All the way some people even do this thing. They even do this thing where they'll spend an extra 15 seconds 15 seconds in the drive-through line sifting through their bag Just to see if we got an item wrong and I get it bro I get it. Sometimes people forget stuff. Sometimes we forget stuff. I completely get it, right? But why are you taking so long? Why are you taking so hey? Listen if I was a customer if I was a customer I I could check that bag in under two and a half milliseconds.  Okay You know when I go to fast food spots when I go to fast food spots I don't even check the back. I don't and every one out of maybe 50 times I go They might end up handing me something completely different Sometimes I'll be driving home from the spot open up the bag to take a bite of my food And I see I got someone else's order and I'm just like oh well Oh well, you just take what's given to you.  Okay. Um, all right I I guess I'm a little bitch then, you know, I honestly don't care I honestly don't care if I order a number three and end up getting a number four Or if I if I order a number seven and end up getting a number two It's all made by the same blend same cholesterol raising arteries blocking ingredients It's all gonna take a couple years off my life and that that's all I'm really looking for. Yeah


On my channel, I tend to steer away from covering things that might be considered controversial in nature, at least in regards to something that could, you know, tend to go over into the political side of things because I don't like making political statements, I don't like taking sides, I know it's a slippery slope and it just leads to some very intense conversations that tend to get nobody nowhere as everyone tries to force their own political opinions down each other's throats and that usually never works and you never really convince anyone to change sides, so it is what it is. I'm here to tell you how to vote this upcoming November, I'm here to tell you what to do with your lives, but Sony and PlayStation 5, they have some interesting terminology happening in their end-user license agreement and the reason this end-user license agreement is even me it looked into is because of other things that Sony is doing with not just the PlayStation 5, it technically exists on PlayStation 4, but some of this back to the PlayStation 3 as well, but nobody really realized it because we all just click accept and don't really look back and think twice. One thing that Sony's been under fire for heading into PlayStation 5 launch is they did announce that they will be recording people's conversations, like private conversations on PlayStation 5 in particular and the reason that they're doing this they say is to protect users, so they kind of went back and said well we're only recording like 30 seconds of conversation, like 10 seconds before 10 seconds after, this is for people who are going to report other users, it's a rolling thing, they're not going to keep conversations, this is just what Sony claims, we don't actually know what's happening behind the scenes, it's kind of one of those things like if you remember some stuff, I'm not going to go too deep into this, but when Edward Snowden unveiled a bunch of things the government was doing, it's kind of one of those situations where do you really trust Sony when they say they're not going to keep conversations and when you're going to determine if you're going to ban people based off recorded conversations, it's one of those situations that if you're only going to listen to 30 seconds, are we going to lose context? Because in theory, I could report someone and submit a clip or whatever, right? Because like they're only going to do like five minute snippets and you could take like 30 seconds out of that snippet and report it. Well, if I report a 30 second snippet of someone cussing me out and it conveniently leaves out the part where I might have started the cussing out of that person, someone could get banned without the context of really I started it and they responded, I should be the one that's banned, right? Like it's a it's a context thing. And it's one of those situations where I understand that Sony is trying to protect its users. Members Sony kind of gave those old excuses in the past about why they couldn't have cross play because they had to protect the children. So it's another one of those situations where I feel like they're maybe overstepping their bounds a little. I get wanting to protect people, but it's just kind of like with discord or Skype or anything else. The measures to protect people are already in place. If you know, you can block people, you can mute people like the measures are already there for users to take care of this themselves. Sony doesn't really need to step in and be the voice police. That's just my opinion. I'm going to stick with that opinion because I think that it is wrong for any company to record private conversations on any platform. Just give the tools necessary for users to handle it on their end, which already exists, you know, with the mute features, the blocking features, all that jazz, there's all you know, parents can go on there and literally, you know, block voice chat altogether on some games and stuff like that. So parental controls to prevent kids from even dealing with this situation. So yeah, to be honest, I think that the power should be in the users, the tool should be in the user's hand. And we shouldn't be relying on companies doing any of this stuff. But, but it gets a little bit worse. And it gets a little bit worse because because Sony is recording, people decided to look at the end user license agreement, and you'll see the usual harassment and policies and all that jazz, which need to exist and are good. But what you'll also run into is some interesting things that deal with China in particular. Now, if you live outside of China, you can say who cares? And I can completely understand the sentiment. But PlayStation does not allow you to use your account or your PlayStation network in any way to create, reproduce or publish or disseminate any information, which opposes the basic principles of the Constitution of the People's Republic of China, endangers the security of the people's public over China, they've all just people of Republic of China's state records or secrets jeopardizes the sovereignty or unification of the people of the People's Republic of China damages the honor and interest of the PRC violates PRC policies on religion or propaganda, heresies or superstition, disseminates rumors disrupts social order or undermines social stability, disseminates obscenity, pornography, gambling, violence, instigates others to commit crimes is prohibited by PRC laws, administration regulations and other provisions. Now, on the surface, this doesn't sound like anything out of the ordinary. Why would they have this Chinese specific law?  But if you actually look at what this is specifically dealing with, it's dealing with a political situation in China. And these rules that exist in the end user license agreement are targeting Hong Kong, which it's a whole mess of stuff. Again, I said this gets a little political I hate getting political, but it gets into a whole mess of things where the People's Republic of China are trying to enforce and the overall law of China onto Hong Kong. And for those who don't know, Hong Kong is kind of independent of China, even though it's part of the country. It's it's a really sticky situation. Basically, Hong Kong is a more free area, more democratic area, a more, you know, in line with kind of how, you know, United States and other places run. And the People's Republic of China is definitely not that. And they are trying to suppress it and force Hong Kong to conform to the rest of Chinese law. And the thing is, the People's Republic of China are the exact people that are enacting slavery and moving certain people to making, you know, working in factories, including at Foxconn. This has been a controversy we've briefly touched on in the past, in regards to electronics manufacturing, because there is technically slave labor involved in it. And this is because of the People's Republic of China, even though they are denying it. Obviously, we can talk about the COVID-19 stuff, and how they doctored numbers. And it's just crazy, right? I'm not here to get into conspiracy theories. The pandemic is real. Wear masks, be safe out there. I'm just saying that China does a lot of really bad things. Hong Kong has always been kind of the exception to this. You've actually been able to buy switches in China long before China allowed, you know, electronic devices to be sold there. Because again, Hong Kong operated in a bubble. Well, the People's Republic of China is trying to burst that bubble, use their military and suppress people who are trying to speak out against the government. Imagine if in the United States, you know, we weren't allowed to speak our opinions one way or another on the president or the policies or anything. We didn't have the freedom of speech. They are trying to suppress freedom of speech. And Sony is being complicit in that suppression with their device. Now again, outside of China, you know, who really cares? This rule only applies to people that live in China. But the thing is, is this means that PlayStation is placating China. They are you know, I went to the end user license agreement for switch, which also exists in China. And they do not have specific rules like this in their end users license agreement. I went through Microsoft's end users license agreement. And they too do not have any specific rules specific to the People's Republic of China. And their devices are all also available in China. So these aren't rules that need to exist for the platforms to be sold in China. This is likely a back doors behind scenes handshake between the People's Republic of China and Sony that maybe lets them get cheaper manufacturing, maybe lets them, you know, which again, does affect things, maybe lets them get certain perks and benefits in the retail space, whatever the case might be. And I'm not saying that like Nintendo and all these companies are innocent. I mean, Nintendo works with 10 cents and does some crappy things in China. It is what it is. China is all sorts of messed up in many different ways. But yeah, it's very interesting that Sony here is basically bowing down to the government of China. And when they don't need to to sell their products. And everyone just kind of didn't notice because nobody ever reads these license agreements. And you might be like, Well, you know, who cares, people don't read license agreements all the time, you know, we're already on social media, we're on YouTube, did you really read YouTube's end user license agreement before you made an account here and like, no, I didn't. Most people haven't. And but but it is concerning when this is a company that's recording voice conversations, actively admitting they're recording, you know, five minutes of voice recordings, but only 30 seconds, it's a rolling thing.  So again, I don't know what this means. There are those out there saying that we should boycott Sony and the PlayStation five. I don't know. It's tough for me as someone who covers these platforms to consider boycotting. I still am excited for PlayStation five and the games like, you know, this this thing doesn't affect me in the US because I'm not necessarily agreeing to it in the US because we could talk about whatever we want on PlayStation.  But it I don't know what Sony is doing. Okay, I'm not trying to get political. I just don't know what they're doing. They've been making these really funky decisions now. I don't know. Like the last five or so years. It's really weird. These things where Sony feels like they need to be the government basically. It's weird. Remember, I mean, we already talked about the weird situation where they wouldn't allow cross play for a while because they needed to protect the children as if other companies aren't doing that and protecting the children in a game owned by another company. Hello Minecraft like it. I didn't. It's just such a weird situation to me to be completely honest. I don't know what's happening. Sony did move their headquarters technically from Japan to California at one point. So there is that I just don't know that this is a really weird situation. And I want to know your guys' thoughts on it because I think this is just like the latest in a line of things that Sony is doing behind the scenes that they're hoping people don't notice. And when they make public comments on it, it never comes off that well. I don't know. I just don't know. It makes me feel uncomfortable. I guess is the best way to put it. It makes me feel uncomfortable about buying a PlayStation 5. I'm probably still gonna buy one. Call me a hypocrite. I'm still gonna play the games. Call me a hypocrite. I'm still excited. Call me a hypocrite. That's fine. I'll open the Amen.  I just I'm a lot more uncomfortable now and I'm and if nothing else, I'm probably gonna end up playing all my multi-platform games on on the Xbox and the Switch. I just I just I don't know, guys. I don't know. You guys let me know what you think about this.  Like I I'm legitimately excited for PlayStation 5 but I'm also I can't ignore some of these things that Sony keeps doing behind the scenes that just I don't know guys. Like it doesn't make me feel good. I guess is the like something just feels off at Sony. So something's just not right. I don't know what it is. I don't know if they're just getting you know big paychecks behind the scenes from from places that I make them make these decisions. I don't know but I something just doesn't feel right. I don't know. You guys don't know what you think. Maybe I'm overreacting. Maybe this is a big nothing burger to you. I am with Andrew Robert Jansson from The Tender Prime. I'll have links in the description to the sources on the voice chat stuff and obviously the unusual license agreement that has this China stuff in it. Thank you guys so much for tuning in and I'll catch you guys in the next video.