Integrating all Your Tools With Chef - And How we Did it at HPE
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Title of Series | ||
Number of Parts | 50 | |
Author | ||
License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
Identifiers | 10.5446/34636 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
ChefConf 201619 / 50
4
6
9
10
11
12
14
15
22
29
34
35
40
42
43
45
46
47
48
00:00
CodeData managementInformationMathematicsOrder (biology)Programming languageLibrary (computing)Type theoryProduct (business)INTEGRALSoftware testingIntegrated development environmentTask (computing)BitLine (geometry)Power (physics)MereologyMultiplicationPhysical systemVirtual machineQuicksortSystem callConfiguration spaceServer (computing)PlanningCASE <Informatik>Process (computing)Connectivity (graph theory)AbstractionSystem administratorComplete metric spaceAdditionSocial classSet (mathematics)Data storage deviceDirection (geometry)Internet service providerElectronic mailing listSoftware frameworkGreatest elementWorkstation <Musikinstrument>Video game consoleComputer fileClient (computing)Open sourcePasswordKey (cryptography)Different (Kate Ryan album)Fitness functionContext awarenessMultiplication signStandard deviationRight angleSuite (music)Representational state transfer1 (number)Software development kitCodeData managementMathematicsSoftwareComputer programmingLibrary (computing)Product (business)INTEGRALTask (computing)DeterminantMathematical optimizationFunctional (mathematics)Line (geometry)Power (physics)MultiplicationPhysical systemProjective planeAutomationDevice driverVirtual machineScaling (geometry)Configuration spaceServer (computing)Process (computing)Connectivity (graph theory)AbstractionSystem administratorMusical ensembleComplete metric spaceAdditionSocial classData storage deviceInternet service providerSoftware frameworkWorkstation <Musikinstrument>IdempotentIdentifiabilityEnterprise architectureComputer animation
09:43
Attribute grammarCodeVideo gameData managementFormal languageProgramming languageData centerSelf-organizationExpert systemLibrary (computing)Type theoryCategory of beingINTEGRALIntegrated development environmentTask (computing)Line (geometry)MultiplicationProjective planeSampling (statistics)NumberConfiguration spaceServer (computing)Operator (mathematics)MassCASE <Informatik>System administratorSCSIData storage deviceCartesian coordinate systemVideo game consoleFlash memoryOpen sourceKey (cryptography)MiniDiscBlogWeb serviceCycle (graph theory)Common Language InfrastructureMultiplication signSpacetimeSoftware development kitWorkloadData managementBarcodesTask (computing)Mathematical optimizationGroup actionMaxima and minimaMultiplicationPhysical systemAutomationDevice driverVirtual machineSystem callConfiguration spaceDependent and independent variablesPredictabilityComplete metric spaceData storage deviceFlash memoryClient (computing)Channel capacityView (database)Block (periodic table)Multitier architectureMultiplication signAutonomic computingCache (computing)Volume (thermodynamics)Mobile WebSoftware developer
19:20
Attribute grammarCodeDiagramImplementationData centerSoftwareCategory of beingINTEGRALSoftware testingSystems engineeringConnected spaceLine (geometry)Group actionStructural loadDevice driverSystem callConfiguration spaceSimilarity (geometry)Server (computing)Operator (mathematics)Template (C++)Set (mathematics)Data storage deviceCAN busCartesian coordinate systemOnline chatClient (computing)PasswordBlock (periodic table)HTTP cookieCommon Language InfrastructureInstant MessagingDemo (music)Interface (computing)Representational state transferSoftware development kitCodeVideo gameData managementOrder (biology)SoftwareProduct (business)INTEGRALIntegrated development environmentTask (computing)Computer configurationLine (geometry)Group actionExecution unitDevice driverVirtual machineMenu (computing)System callConfiguration spaceOperator (mathematics)Template (C++)Musical ensembleComplete metric spaceSocial classData storage deviceCartesian coordinate systemInternet service providerWorkstation <Musikinstrument>Computer fileClient (computing)View (database)NeuroinformatikIdempotentDefault (computer science)Software developerSoftware development kitComputer animationLecture/Conference
27:19
WorkloadCodeVelocityInformationPerspective (visual)Self-organizationSoftwareTelecommunicationComputer programmingType theoryProduct (business)Profil (magazine)Wave packetElectric generatorUser interfaceINTEGRALEntire functionMathematical optimizationBitConnected spaceMereologyPhysical systemSlide ruleVirtual machineNumberQuicksortConfiguration spaceRevision controlSimilarity (geometry)Server (computing)InternetworkingParameter (computer programming)CoprocessorException handlingSystem administratorTemplate (C++)NamespaceInformation securityBridging (networking)Data storage deviceRoundness (object)Latent heatAcoustic shadowStability theoryTraffic reportingSurjective functionOpen sourceView (database)Key (cryptography)Different (Kate Ryan album)Object (grammar)IdempotentMultiplication signPublic key certificateSpacetimeRight angleService (economics)VirtualizationWeb 2.0Operating systemContinuous integrationWorkloadData managementSoftwareCodeSemiconductor memoryProduct (business)Profil (magazine)INTEGRALMIDIMathematical optimizationAnalytic continuationBinary codeSeries (mathematics)Connected spaceIntelMaxima and minimaExtension (kinesiology)Metric systemPhysical systemData recoveryScheduling (computing)Core dumpConfiguration spaceRevision controlServer (computing)Operator (mathematics)Human migrationConnectivity (graph theory)Information securityData storage devicePC CardOnline helpDirection (geometry)Internet service providerStability theoryBackupPoint cloudChannel capacityOpen sourceWhiteboardComputing platformOracleCollaborationismService (economics)Suite (music)Computer animation
Transcript: English(auto-generated)
00:05
Yeah, so how's it going everybody? As he said, my name is Bic. I'm here with Hewlett Packard Enterprise, and I'm on the infrastructure automation team at HPE, along with Vivek, also on the same team, and Thiago on the composable infrastructure team. So today we're going to be talking about
00:21
integrating our IT infrastructure and your IT infrastructure with Chef. So a quick agenda. So we'll start off with our integrations with HPE technologies, which include server configuration, storage configuration, complete infrastructure provisioning, and then we'll move into HPE UX
00:44
support for Chef compliance, as well as a little information about our team. So integrating tools with Chef. We're all here avid users of Chef, and we've all seen the types of things that Chef provides to us. There's a lot of benefits, a lot of reasons why you would want to use Chef
01:01
in your environment, and now we're going to see the reasons why we want to combine your custom tools with Chef as well. So the power of automation. By integrating your tools with Chef, you get provided with a unified framework to interact with everything and to use these different tools.
01:21
So the benefits your customers will see is that it provides a lot more acceleration to your IT provisioning. It makes your tools easier to use as well. So we at HPE decided to take a few of our different tools and combine them with Chef to make them more powerful,
01:42
to make them easier to use for our customers. So in order to do this, we had a four-step process to getting to these different integrations. We started off by first identifying our different automation needs, where our customers may see fit that Chef would provide them acceleration inside of their data center, would provide them with other greater benefits,
02:04
and then we determine which components of Chef provided our use case. So for example, you can have resources, a provisioning driver, a cookbook, or even OS support for your custom operating system brought into Chef. So we'll take a deeper look into these pretty soon.
02:25
And then following that, we constructed helper libraries. So HPE has quite a few different technologies, and the plan going forward is to bring them together with different open source tools to make them more powerful. So we decided that the best possible way to do this would be
02:46
able to build libraries that we can leverage in multiple places to make them more reusable and versionable for multiple tools, including Chef and outside of Chef. And then finally, we went ahead and created those components. So yeah, as we just went over, we've created
03:07
these easy-to-use tools, and all these automation tools work seamlessly together through Chef, and they provide rapid configuration of your infrastructure. The first tool we have deals with server configuration. So specifically, this includes HPE proprietary technology called
03:29
the iLO. This is the integrated lights out, which is a server configuration tool we have at our company. So a little bit about that. Integrated lights out is used for efficiency,
03:43
simplicity, and uptime when it comes to managing your server infrastructure. So it's built-in intelligence and automation for increased server admin productivity. This is a very popular tool that our customers use, and we really wanted to enable them to be able to use this tool at scale, give them the power of Chef and then the power of being
04:05
able to automate this within your data environment to turn even something as popular as, I mean, complicated tool into code as well. So we structured this into two different projects,
04:24
both based off of an industry standard Redfish API. HPE has been moving towards building a standard API for a lot of our products to make it a lot easier for these tools to be used with our customers. And then on top of this API, we built our iLO SDK Ruby project, which is a helper
04:45
library which gives us all of the API calls abstracted out and easy to use for the resource providers and easy to integrate into a programming language. And then we also built an iLO resource provider. So moving on, we take a look at an example SDK configuration of your iLO,
05:08
of your integrated lights out console. So this is written in pure Ruby and uses a gem, which is called the iLO SDK to configure all of your resources configuration for your integrated
05:21
lights app. So it steps through, written in pure Ruby, creates two different clients for iLO 1 and iLO 2, and then does a few different things in them. On both of these two, it builds a user called test with a password of 123. It changes that password on that user, sets the time zone,
05:40
sets NTP, and then resets both of these servers. And it does this all through pure Ruby code, nothing to do with Chef, just pure Ruby based off of a gem, which calls APIs. So the benefits of this, it can be leveraged by any technology that uses Ruby to build integrations. So currently we have it built out for Chef, but this can be leveraged by Puppet,
06:04
any sort of other tool that uses a Ruby library to run its commands. And it hides all the API calls by creating really human readable resources. And it uses far less lines of code than manually making API calls through other classes. Here at the bottom you can see an example of how this
06:24
works. You run a Ruby executable on your workstation, which is built using the iLO SDK Ruby, which then makes the REST API calls to your iLO. So going beyond this is when we get into the really interesting part. So using this iLO SDK that we built, this gem that we've created,
06:45
we were able to put this into Chef resources and create a whole suite of different Chef resources to configure your iLO server management console. So this code right here does the exact same thing that we just saw in that Ruby file. Does everything we just saw, sets the users,
07:05
changes NTP, sets the time zone, resets the server, does all that stuff but in the context of Chef this time. So this is written in Chef DSL and it abstracts out all those iLO SDK gem methods. And you can basically run it on as many iLOs as you see fit. We have a list of two
07:25
different iLOs, same ones we saw earlier, and they're being run on each one of these resources. One interesting thing to notice, no, so it does it through an API call. So you would run,
07:41
how we do all these things, we don't have anything running Chef client natively. We have it call the API out from a workstation. And then it also goes ahead and gathers the information and places that back in the Chef server, either using data bags or using pure files that just store this different information. So there's no native Chef client
08:01
being run on these servers, which we see as an advantage because you can easily run it on any person's workstation. So this can be run multiple times, what we just saw, without breaking any configuration. So we've designed the Chef resources to be item potent,
08:23
a key concept within Chef, so that they can be run multiple times and they only bring you back to one end state, rather than diverging into different directions. So it hides all the API calls using that iLO SDK as well, and it executes the configuration task on multiple machines with no additional lines of code. And by this we mean,
08:45
as you can see, we have a list of iLOs provided to your resource. So both of these two iLOs will be executed against for each one of these resources. It's just provided by a simple Ruby array. And below you can see an example of how it does, goes through, uses a Chef client,
09:06
and then, to answer your question, uses the API calls and makes separate API calls to each one of these iLOs. And it also ensures that, let's say we want to add a username test. It'll ensure that the test user does not already exist, and if it does exist,
09:22
it won't do anything. You'll see zero out of one resource is updated, but if it doesn't exist, it'll go ahead and create that test user. And now I'll hand it over to Vivek to talk about server configuration. Thanks, Vic. All right, okay. So as Vic spoke about iLO integration
09:47
with Chef, all right, okay. So basically we started this project because a lot of our customers, they have sometimes more than 100 or more than 10,000 or even more
10:01
than that number of blades in their environment. And when they have to manage their iLOs, it becomes really very difficult. And when they have to do a mass configuration change, it is something which is very manual and very tedious. So we decided that we'll create this automation and just make it open source so that most of our customers who are using
10:24
iLOs, they can just leverage our automation and start doing it in their environment. And as we see, a lot of customers are already using Chef. So for them, it becomes very, very easy to automate their iLO management. So based on going after that, what we also
10:45
realized that one of our key storage product, which is 3PAR, which is number two hot selling storage in the market right now in the mid-drain space. So we thought we'd create similar automation
11:02
for 3PAR as well. So I'll quickly take you through some of the key features of 3PAR. So 3PAR basically is so autonomic that it basically understands the iO requirements of a particular application based on that. It has the intelligence to take care of the
11:25
workloads, how it has to be managed, how the internally it has to give the iO ops to a particular application or to a particular server. And also it is very efficient because
11:40
it has a lot of new features in the storage. It has thin provisioning. It has inline deduplication due to which storage performance becomes really good. And then it provides 99.9 percent data availability. So most of the customers who are using it, they really see a lot of
12:01
value in 3PAR storage because it's highly available. Even if one disk goes down, nothing really happens because it's fully highly available storage. And last but not the least, the federated feature is a very, very important feature because a lot of customers, they have SATA disk, they have SCSI disk, and they have
12:24
a lot of flash disk as well in their environment. So when they have their workloads, which are not really requiring flash storages, data automatically moves to the lower and the slower disk devices. So that happens automatically inside 3PAR, which takes care of your efficiency
12:47
in storage. All right. So this is a typical 3PAR management life cycle. So if any customer who buys 3PAR storage, they have to basically do a lot of initial configuration where they have to set up CPGs. So I'm not sure if you guys are aware of 3PAR storages,
13:05
but these are most of the configuration tasks which are performed by the storage admin in any organization if they have 3PAR storage. Okay. So right now, the integration that we have done with Chef, you can actually do the initial configuration, ongoing management,
13:24
and the decommissioning management of the 3PAR storage. So I'll quickly go through the use cases that we have automated. All right. Okay. So this is typically if a storage admin who have to perform a task manually in their environment, then it typically takes
13:45
close to seven hours for 10 tasks on three 3PARs. But if you use automation that which we have created, then it may take two to three minutes to complete the same 100 tasks on all the storages. It's parallel, and it can do the configuration in a faster
14:06
way. Yeah. So if one person has to perform those 100 tasks on 10 different storages, so that takes a lot of time. Sure. All right. Okay. So these are some of the sample
14:29
configuration tasks which you can perform using the automation. So as you can see from the first example, this is for creating number of hosts onto a particular 3PAR. So let's
14:43
say you have a 3PAR in your environment, and you have this is very new in your environment, so you want to add all your hosts which would require LUNs from your storage. Then in that case, you have to add those hosts. So as you can see, it's very simple, very
15:01
English readable language where you just have to use 3PAR host resource, and you just have to specify the host names that you want to add. And you can also specify a lot of other attributes like WWPN numbers and what type of host it is, whether it is Solaris, HP, OAX, AIX, or Linux. And then from the second example, you can see that if you
15:23
want to modify any particular property for a host, you can just use this five line of code to perform that task. And if you want to perform it on multiple 3PARs, let's say you have 10 3PARs or 20 3PARs in your environment, you can use that. And you just have to use this five line of code. So similarly, this is another example where
15:45
you want to create a new CPG. So customer, when they buy new 3PARs storage, they have to create new CPGs. And it is always better to have just one recipe which performs all the tasks for them because whatever standard configuration they normally do manually, they
16:05
can actually automate it and just put it in one single recipe. And it does that for you. All right. So this is on the very similar lines on what you have seen in ILO. So we had a similar project. We followed the same approach. And we created
16:24
two separate things in it. So one is the 3PAR cookbook example which you have just seen. And we have a 3PAR SDK Ruby which basically has the entire library and the wrapper around the APIs which has to be called. So normally the storage admins, they don't really know how to use the APIs because they are from the system admin
16:44
background and it is really difficult for them to use the APIs because they don't know the programming languages. So just to make it simple for them, we have written this whole 3PAR SDK. So when they call resources from 3PAR cookbook, they don't really have to understand the APIs because everything
17:03
happens in the background. And then as all the new 3PARs starting from 7400 model, they all come with web service APIs. So when you execute your Chef client, it talks to the WS APIs of all the 3PARs and perform the tasks.
17:25
All right. I'll hand it over to Thiago. He's our expert on OneView and Chef. Thank you everyone. So his question is that we have a 3PAR management tool as
17:52
well as we have 3PAR CLI. So why do we really need this automation? So thing is if you want to perform a task on a single storage or on
18:03
multiple storage, you either have to connect to a management console and you have to go to each 3PAR and perform the same task. Or if you want to use CLI for that also, you have to connect to the CLI of each 3PAR and then run that particular command. But using this, you don't even have to do that.
18:22
In this case, you just put everything inside one recipe and you execute it. It talks to all the 3PARs and perform the task for you. So you don't have to manually connect to any of the 3PARs to perform any of the tasks.
18:42
Yes. So we'll talk about it. Actually, Bik is going to show you the sources, but it is coming soon. We already have it ready. We are just doing fine-tuning in it and we'll make it open source very soon. And we'll also have a blog and the video on it. You're welcome. All right, handing over to Thiago. Okay, so thanks Vivek. If we're talking about a complete infrastructure
19:06
provisioning, we assume that we are going from the bare-metal data center to a fully operational one, right? So here, we made some chat integrations with HPE OneView that some of you may not be so familiar with it.
19:24
So I can quickly say that the HPE OneView software is a infrastructure automation engine and also infrastructure manager, okay? So basically, HPE OneView has a software-defined intelligence that makes your data center
19:43
interactive, it's more simple and more fast, okay? So with it, you can deploy your infrastructure faster, as I said, because it has a template-based, technology-based that you can configure your compute, your storage and fabric as you want based on your templates, okay?
20:05
And also, it can simplify some lifecycle operations of your data center because with the HPE OneView, you have some agent-less monitoring, have online female updates, and with this, you simplify all these operations
20:23
you want to do in your data center, all right? And at last, it provides an API-driven interface. So basically, the IT can make any integration they want because with this, you can connect with HPE OneView to your
20:46
tools and internal software and services, all right? So now that you know a little about the HPE OneView, the work that we are really doing is to create more readable interfaces and similar as the HILO, we have a Ruby SDK interface
21:05
for HPE OneView, all right? So it's basically the same attributes that we had on the HILO SDK. And with this, we can integrate with another software, as it was already said, that's Jeff, Puppet, or any other Ruby application
21:26
your IT wants to use. And also, we can deploy simple infrastructures because of the REST API, it's hidden with the SDK. And also,
21:43
we can use far less lines of code to make this integration possible. So here's a diagram to example how you can use it. So basically, you create your Ruby application that uses the OneView SDK gem and it does all the call, the REST calls to the OneView appliance, all right?
22:03
So here's an example. Using the Ruby SDK, you can define the OneView appliance you are using. So here in the first block of code, you're defining what's your OneView that wants to use. Here you define
22:22
some settings. Please don't put the user in password this way, which is just an example, all right? And this code basically creates some networks for your OneView appliance and after that, it connects to the virtual connect of your HPE hardware, okay? So this can be done using the HPE
22:44
OneView interface, but it's done here using the HPE OneView Ruby SDK interface, all right? So let's get to the point, the chat OneView integration. So after this, we have three layers, the layer of the REST API
23:04
of OneView, the layer of the Ruby SDK, and the last one, we created this implementation of the chat integration. So basically, as you can see here, the chat, this OneView cookie book integration uses the OneView SDK and you
23:24
can create your cookbook that depends on this cookbook we're creating to make your calls to the OneView. So why did we do this? Because with chat, we can make some more high-level integrate, more high-level templates.
23:46
So with this, we get even more human readable code and also, you can execute tests faster, you can...well, you know about the chat, all right? So also, we keep this idempotent property. And after this,
24:06
we have some example here of...it's far more simple than the last one. So here, you can see that we can...that's similar when we define our clients to connect with the OneView API. And...but after that,
24:24
here in this use case, we just need...we want to create these enclosure groups that we will...that we need, for example, to support a seasonal load. And here, we define that this enclosure group will get this virtual connect
24:43
templates that support heavy loads. And then we, in the last block of code, say that this enclosure that we defined there, we want to be in this enclosure group. So when you run this with the CLI...sorry,
25:03
you can do this all automatically and with one line of code, all right? So it's...as you can see, it's really template-based like the OneView, but it's more high-level templates. So after that, we configured all of our
25:24
infrastructure in our data center. And now, what we want to get our servers that are inside the enclosures and configure the software on them. So basically, we also have this chat driver with OneView that after we define some templates in OneView of what you want in our software,
25:47
we get these templates and then put some other configurations like settings of the security, settings of some connections. And we do this,
26:01
and after that, we get the chat templates that want to provision our server. And when we run, it's all done. So basically, an overview of what Farah said, you go...the customer, you go to the OneView.
26:25
And after that, you define your templates. After you define your templates, you define your software stack. And after you define your software, you can also define the additional infrastructure you may need.
26:41
And after you define all of this using the chat templates, you run the chat client and everything is done. So basically, you can start from an empty one...sorry, from an empty data center, very metal data center, and with all the servers running and functional, sorry.
27:10
So here, we have a demo of the chat driver. So basically here,
27:21
we already configured our infrastructure and we used some templates to... applying the templates, you can see chatweb01, chatweb02, chatweb03. And with these templates, we are applying them on some servers.
27:41
And here, you can see that the servers are powered on. And after that, we run some chat recipes. And these chat recipes configure all the software you may need inside your server. And after that, you can see that the servers are already on the web template,
28:04
the web interface. All right. So right now, Vivek will talk about the HP UX compliance. Thanks, Thiago.
28:30
Sorry, you can repeat. Oh, this integration just works with one view.
28:48
But because it's happening on the HP hardware, okay? So, all right. So this can be portable, but as we've done there,
29:13
we are using just the HP one view one, but it can be done with another tools too.
29:24
Yeah, they can definitely move on to different types of provisioning things. Because when it comes down to it, you're provisioning quite a few different servers. And it really doesn't, not in the sense it doesn't matter which driver you're using, but you still get the same velocity no matter which VMware,
29:42
whether one view. It just depends on how you're trying to abstract that data. So I would definitely say use these different things with VMware, whether they're tool. We specifically did one view because it didn't have any sort of Chef integrations prior. It didn't have a really quick way to spin up these servers automatically.
30:02
Because VMware has the knife VMware. There's different tools in those spaces for those other tools. But this was one that was missing that we thought would be very valuable. Yeah, yeah, yeah, yeah.
30:39
So HP one view can provision bare-metal machines with VMware ESX.
30:44
So you can use Chef provisioning driver, which we have written for one view. And it can talk to the one view APIs and provision a bare-metal machine. Exactly, there is nothing on it, to the VMware hypervisor. So you can do that, yeah. Any other questions?
31:06
All right, so we can move to HP UX. So how many of you know about HP UX? All right, so people have heard about it. That's great. Okay, so I used to be a system admin on HP UX quite a number of years ago.
31:28
And one of the key things which I saw with HP UX was that most of the financial customers and the telecom customers are using HP UX. And even now, I still see a lot of customers
31:40
are using HP UX. And we had one of the biggest banks in India who wanted to use Chef, but they did not see any support for Chef compliance. So as you know, compliance is one of the key important things for financial customers because all the financial data is at stake if their systems are not compliant.
32:05
So what we did was we tried to... So let me quickly talk about some of the things on HP UX. I'm sure you might be knowing about it. So HP UX, nowadays it comes on integrity. Before, we had BRS systems which used to have HP UX.
32:26
And we have new version of Service Guard which supports Oracle. We also have a similar hypervisor technology in HP UX using which you can have virtual machines running on it. And I'm sure if people have used HP UX, then they might be knowing VPAR virtualization was there
32:47
very long ago as well. And then it has high efficiency. Right now, we are extending support with other security solutions.
33:00
And some of them are HP products and some of them are open source products and Chef is one of those. And in future, on HP UX, we want to have HP UX running on the new generation Itanium processors.
33:20
And as you know, HP UX was one of the stable operating systems. So it has reduced downtime and we will try to do more innovations to have lesser downtime. So I'll quickly move on to the next slide because this is something which you already know and this is what will be there in the future. So I'll talk from the compliance perspective on what we have done.
33:43
So Chef compliance generally comes with two gems. So your entire Chef compliance, I don't know how many of you have used it so far, but it is driven by these two gems. And as you can see from the first gem, which is train gem,
34:04
which is for making an SSH connection to the particular operating system. So what we did was we added the support onto the train gem so that it can connect to the HP UX box, identify which operating system it is, whether it is 11.11, 11.23, or 11.31,
34:25
and then identify that part of operating system and then give it to InSpec. Now InSpec basically has all the resources written in it. So if you want to find out any particular thing or a particular parameter
34:44
or you want to check particular user onto HP UX, you can write the resources inside InSpec. So that is what we have already done. There are resources which are already available. And currently Chef compliance is shipped with CIS HP UX profiles.
35:04
I think you might have seen in the keynote today that we had the HP UX support, which was done by our team. So this is open source. Anybody can use it. And if you have any issues, please report onto InSpec,
35:22
and our contributors will definitely try to fix that. All right, so I'll hand it over to Bic. He'll talk about all these resources and these open source codes, where you can find those, and he'll give you the links as well. Thank you, Bic.
35:41
Thanks. Yeah, so all of these different resources can be found in all the same place. So they're all open sourced, all available right now with exception to 3PAR, which will be available very shortly for those of you who are asking, and all under the Hewlett Packard namespace of GitHub. So if you're on your laptop, go ahead, check it out.
36:00
It's up there. You have the gems as well as the actual Chef resources. And then for more information about our team and the composable program, you can hit hpe.com slash info slash composable program. So a little bit about our team. We provide a lot of these services towards understanding these tools
36:20
and helping you leverage these tools in your environment as well. We operate in four different spaces, which includes infrastructure automation, continuous integration and delivery, infrastructure monitoring and compliance, and workload optimization. So thank you. We're here at booth 101 right through the front of the door.
36:41
Was there any questions before we go ahead and do the raffle for the sweet barbecues? Okay. Yeah. So the question was, if we integrate this into Chef, do we leave the other tools in there and or were they obsolete? Um, with the way this works is that other tools are still there. There wasn't, we really didn't have an actual tool for when it comes to infrastructure automation.
37:01
So integrating them with Chef provided us with that tool. See, these were already tools that are used to, um, for server configuration, for internet configuration. So Chef was kind of that bridge that brought us to the, to leveraging these tools in a much more automated fashion. And, and Chef also helped us automate a lot of the tasks,
37:23
which was not possible before. So in your storage provisioning team, whatever team, right? Um, what sort of Chef, um, you know, knowledge
37:40
or whatever is needed to do their day to day tasks? So after you finished your integration and all that. So right now, uh, if any storage administrator in any organization who had three part, they just need to download our cookbook, which has all the examples in it. They can just start using the simple English like code.
38:02
They don't even have to know about the API's. They don't need to understand how they will pass on the object, Jason objects and the parameters to the API's. They can just use a simple recipe and just anybody can write it. Um, following onto that, are your cookbooks general
38:20
and the recipe that you're doing, are they generally run once or do they get constantly run to make sure that the system continually converges to it? And what happens when you have administrators who are not cooperative with Chef and go behind its back and do things the old way that they're used to?
38:40
Yeah, so, so they are, they are continually run, which is why we have them running idempotently. You would want to ensure that they stay in that configuration and converge back to that configuration. With, um, with talking about people who really aren't buying into Chef and do not want to do that kind of stuff, maybe doing stuff in the background, changing the configuration,
39:00
that Chef will pretty much automatically correct that. So if you don't buy in and these things are being run continuously, like say in an hour basis, on a daily basis, all that configuration you're doing, just in the back, Shadow IT is going to be overrun with these as well. Yeah, so, so in this case, we can run the same recipe again,
39:22
but let's say we are trying to create something which is already there. So let's say I'm creating a LUN with specific details, with a specific number, and if the LUN already exists, then it will not create that LUN. Or if you're trying to, if you're trying to delete something through our recipe. So we make sure that our storage admin,
39:42
when they are executing this, they understand what is going inside the recipe, because recipes can be, I mean, you can write a code which can destroy something, right? So they should understand and be aware before they use it. So we train them enough to be able to understand.
40:00
And as you can see here, I mean, typically Chef can be learned by a system admin and not a storage admin in two days. It's not a very difficult thing to learn. Yes, we had the whole partner certification. The question was if their team went through formal training. Yeah, so Bic and I are certified Chef trainers as well.
40:23
On behalf of the Chef community, thank you for your time. Can we give them a round of applause? And now we'll move into the raffle as well.