1 01:00:00,133 --> 01:00:02,266 Hello and welcome to another 2 01:00:02,266 --> 01:00:06,533 wonderful episode of the VCD Roundtable. 3 01:00:06,866 --> 01:00:09,966 This is episode 48, and I atleast have full control of 4 01:00:09,966 --> 01:00:11,733 my computer, microphone, and camera. 5 01:00:12,199 --> 01:00:13,800 Unlike some other people (in the chat), I 6 01:00:13,800 --> 01:00:16,000 just actually solved it on my own. 7 01:00:17,000 --> 01:00:20,433 So with this episode, we are going to look into 8 01:00:20,433 --> 01:00:22,900 Orchestration and Automation, 9 01:00:23,266 --> 01:00:26,666 which is at least when it comes to Cloud 10 01:00:26,666 --> 01:00:29,466 Director, far more a topic for Matthias. 11 01:00:29,733 --> 01:00:32,666 So before we get to Matthias, Toby, any opening words? 12 01:00:33,333 --> 01:00:35,466 No, absolutely not from my side. 13 01:00:35,466 --> 01:00:37,433 Hello and welcome to episode 48. 14 01:00:38,266 --> 01:00:39,633 Yeah, let's hand it over to Matthias 15 01:00:39,633 --> 01:00:42,766 and listen what he is referring to. 16 01:00:43,366 --> 01:00:44,533 Hi guys, this is Matthias. 17 01:00:45,433 --> 01:00:48,766 Yeah, I'm not in control of my mic anymore, because my 18 01:00:48,766 --> 01:00:52,633 MacBook Pro refuses to accept the microphone I configured. 19 01:00:53,566 --> 01:00:57,033 It insists of using my iPhone for whatever reason. 20 01:00:59,033 --> 01:01:01,633 But yeah, nothing I can automate. 21 01:01:02,966 --> 01:01:05,833 Cloud Director Orchestrator and Automation. 22 01:01:09,866 --> 01:01:11,800 Automation has multiple approaches. 23 01:01:12,866 --> 01:01:16,366 For example, we use automation to onboard new customers. 24 01:01:18,333 --> 01:01:20,633 Onboard new customers, for example, is not like a... 25 01:01:21,099 --> 01:01:22,766 We're not automating it to have it 26 01:01:22,766 --> 01:01:25,666 more or to have it onboarded faster. 27 01:01:26,433 --> 01:01:27,866 So from my point of view, 28 01:01:28,400 --> 01:01:31,966 Automation is not always to speed things up. 29 01:01:32,766 --> 01:01:34,933 On the other hand, a big part of 30 01:01:34,933 --> 01:01:38,633 Automation is to have configuration consistency 31 01:01:39,666 --> 01:01:42,466 and there's standardized implementation of something. 32 01:01:43,666 --> 01:01:46,333 We all are human beings, so we are pretty 33 01:01:46,333 --> 01:01:48,766 aware that you just fat finger something. 34 01:01:49,066 --> 01:01:52,933 Maybe you select the wrong allocation model for the OVDC 35 01:01:52,933 --> 01:01:54,099 and then you configure everything. 36 01:01:54,466 --> 01:01:57,166 And then it's like, "Oh, I selected the wrong one." 37 01:01:57,800 --> 01:01:58,766 So delete everything. 38 01:01:59,866 --> 01:02:01,599 So that's a big part of Automation as 39 01:02:01,599 --> 01:02:04,566 well, to have standardized configuration. 40 01:02:06,766 --> 01:02:09,199 I don't know how many guys of you have already played with 41 01:02:09,199 --> 01:02:11,033 Automation on Cloud Director. 42 01:02:11,766 --> 01:02:15,866 So we have two main pillars to automate Cloud Director. 43 01:02:16,933 --> 01:02:22,433 First, we can just use the APIs and build a workflow to do 44 01:02:22,433 --> 01:02:26,133 certain steps, one after the other, 45 01:02:26,666 --> 01:02:27,566 to achieve a goal. 46 01:02:28,633 --> 01:02:30,300 On the other hand, we can use 47 01:02:30,300 --> 01:02:33,333 Cloud Director Event Broker Services 48 01:02:34,166 --> 01:02:39,500 to trigger based on certain events and external systems to 49 01:02:39,500 --> 01:02:41,566 kick off an automation process. 50 01:02:41,566 --> 01:02:43,966 So these are the two main pillars we have. 51 01:02:45,233 --> 01:02:48,966 From my point of view, and I have a big grin on my face 52 01:02:48,966 --> 01:02:51,599 because Yves and Toby both told me, 53 01:02:51,599 --> 01:02:55,066 "Orchestrator is dead" years ago. It's still there. 54 01:02:55,800 --> 01:02:59,933 And it will be there in the future and forever. 55 01:03:05,466 --> 01:03:07,066 So I'm a big "Orchestrator" fan. 56 01:03:08,066 --> 01:03:11,266 On the other hand, I have to admit there is a great PowerCLI 57 01:03:11,266 --> 01:03:15,266 implementation or a cmdlet 58 01:03:16,033 --> 01:03:18,166 for the Cloud Director API as well. 59 01:03:19,766 --> 01:03:22,633 So everybody, feel free to use PowerCLI as well. 60 01:03:23,166 --> 01:03:24,566 I'm more the "Orchestrator" guy, 61 01:03:24,566 --> 01:03:26,566 but that's just my personal opinion. 62 01:03:28,133 --> 01:03:30,066 Most important thing is to automate stuff. 63 01:03:30,066 --> 01:03:31,699 So PowerCLI and Orchestrator can both 64 01:03:31,699 --> 01:03:35,400 be used to access the Cloud Director API 65 01:03:36,133 --> 01:03:38,533 and automate things. 66 01:03:39,533 --> 01:03:43,766 I still stick with the example: tenant onboarding. 67 01:03:44,400 --> 01:03:45,833 Why am I using this example? 68 01:03:46,566 --> 01:03:50,199 Because tenant onboarding includes many, many steps. 69 01:03:51,533 --> 01:03:52,833 So first, guys, what do we need? 70 01:03:52,833 --> 01:03:54,500 We need to select the PVDC. 71 01:03:55,133 --> 01:03:57,033 We need to create an OVDC, select an 72 01:03:57,033 --> 01:03:59,000 allocation model, choose resources. 73 01:04:00,599 --> 01:04:02,366 We deploy an Edge gateway. 74 01:04:03,266 --> 01:04:05,366 We need an OVDC network. 75 01:04:05,833 --> 01:04:10,066 We need IP space allocation, maybe some 76 01:04:10,066 --> 01:04:12,466 default firewall rules in the Edge gateway. 77 01:04:12,866 --> 01:04:17,400 Some users create things like this. 78 01:04:17,733 --> 01:04:18,966 So a ton of stuff which needs 79 01:04:18,966 --> 01:04:21,400 to be done to onboard a new tenant. 80 01:04:23,000 --> 01:04:25,466 That can be done in an automated fashion. 81 01:04:25,833 --> 01:04:30,199 So all these steps I've mentioned can 82 01:04:30,199 --> 01:04:34,733 either be built in PowerCLI or Orchestrator. 83 01:04:36,266 --> 01:04:42,166 Before we dig more into that topic, I need 84 01:04:42,166 --> 01:04:45,966 to make you guys aware that Cloud Director 85 01:04:46,133 --> 01:04:48,633 currently offers two APIs. 86 01:04:49,166 --> 01:04:52,766 We still have the old standard REST-based API. 87 01:04:53,599 --> 01:04:56,633 We still have the old standard REST API. 88 01:04:56,866 --> 01:04:59,500 And the new one is called the Cloud API. 89 01:05:02,800 --> 01:05:05,766 I have to admit, the Cloud API 90 01:05:05,766 --> 01:05:08,233 is the new stuff, its cooler. 91 01:05:09,666 --> 01:05:13,166 I'm refusing to say the better API. 92 01:05:13,966 --> 01:05:16,466 It's an easier API compared to the standard one. 93 01:05:17,433 --> 01:05:20,766 But the Cloud API still misses a lot of important stuff. 94 01:05:23,133 --> 01:05:27,133 Everything about automating and managing virtual machines 95 01:05:27,133 --> 01:05:29,933 and vApps is still not in the Cloud API. 96 01:05:31,433 --> 01:05:35,933 And I don't know when it will be part of the Cloud API. 97 01:05:38,666 --> 01:05:43,699 So what we need to think, if we cover automation, we have 98 01:05:43,699 --> 01:05:45,433 the two main aspects I think we're 99 01:05:45,433 --> 01:05:47,566 going to cover is PowerCLI and Orchestrator. 100 01:05:48,900 --> 01:05:52,833 Power CLI is shipped with its cmdlets for Cloud 101 01:05:52,833 --> 01:05:55,466 Director, and they can be used if 102 01:05:55,866 --> 01:05:59,133 you need to implement something and you don't have a 103 01:05:59,133 --> 01:06:02,133 cmdlet, use PowerShell to implement 104 01:06:02,133 --> 01:06:03,366 the REST API call. 105 01:06:04,933 --> 01:06:07,933 And on the Orchestrator side, it's the exact same thing. 106 01:06:08,466 --> 01:06:10,833 So you could implement the plugin 107 01:06:10,833 --> 01:06:14,933 in Orchestrator and use the plugin. 108 01:06:17,000 --> 01:06:20,333 Honestly, it is nice, though. 109 01:06:20,333 --> 01:06:22,266 I have to admit, it's helpful. 110 01:06:22,566 --> 01:06:23,133 It's nice. 111 01:06:23,733 --> 01:06:26,033 You can solve a few very basic 112 01:06:26,033 --> 01:06:28,066 tasks really fast with the plugin. 113 01:06:28,866 --> 01:06:30,866 It has an implicit authentication, 114 01:06:30,866 --> 01:06:33,233 which you can use in JavaScript code. 115 01:06:33,233 --> 01:06:34,599 So that's pretty nice and straightforward. 116 01:06:37,166 --> 01:06:40,500 But I honestly tend to implement 117 01:06:40,500 --> 01:06:43,833 all the Cloud Director calls via REST. 118 01:06:45,833 --> 01:06:49,333 The plugin has not all the methods and API calls 119 01:06:49,333 --> 01:06:51,599 implemented, so you are dependent on 120 01:06:52,133 --> 01:06:54,666 the development team of the plugin if a 121 01:06:54,666 --> 01:06:57,233 certain feature is available via the plugin. 122 01:06:58,566 --> 01:07:01,133 If not, you need to build it in REST anyway. 123 01:07:02,266 --> 01:07:04,266 So that's the reason I prefer 124 01:07:04,266 --> 01:07:08,333 the REST approach in Orchestrator. 125 01:07:09,333 --> 01:07:16,199 And what I start with, I build a template. 126 01:07:19,133 --> 01:07:23,066 So a few templates that I can use over and over and over, 127 01:07:23,066 --> 01:07:25,333 because I don't want to build 128 01:07:25,333 --> 01:07:30,666 and structure every single workflow to rebuild every single 129 01:07:30,666 --> 01:07:32,466 REST API call over and over and 130 01:07:32,466 --> 01:07:32,733 over. 131 01:07:33,199 --> 01:07:36,466 So it's easy to just grab a template and change a few lines 132 01:07:36,466 --> 01:07:38,366 of code, the method, the URL, 133 01:07:38,833 --> 01:07:42,199 or some inputs, outputs needed, and then use the same 134 01:07:42,199 --> 01:07:43,666 workflow over and over and over. 135 01:07:44,033 --> 01:07:45,933 So it's also a very standardized approach 136 01:07:45,933 --> 01:07:49,666 how to build workflows for automating, in 137 01:07:49,666 --> 01:07:50,699 our case, Cloud Director. 138 01:07:51,066 --> 01:07:53,266 But I use the same mechanism if 139 01:07:53,266 --> 01:07:56,633 I automate NSX or other stuff. 140 01:07:59,133 --> 01:08:03,866 With Cloud Director, as long as we use the Cloud API, we 141 01:08:03,866 --> 01:08:05,633 have a great Swagger documentation 142 01:08:06,033 --> 01:08:08,933 of the API built into the Cloud Director product. 143 01:08:10,199 --> 01:08:11,966 On the top right, just click the 144 01:08:11,966 --> 01:08:13,666 question-- I think it's the question mark. 145 01:08:14,266 --> 01:08:17,233 And then you have a menu entry saying API Explorer. 146 01:08:18,000 --> 01:08:19,533 And then just navigate over there. 147 01:08:20,899 --> 01:08:23,133 Please be aware, Cloud Director 148 01:08:23,133 --> 01:08:24,766 is still a multi-tenant product. 149 01:08:24,766 --> 01:08:26,933 So you have an API documentation 150 01:08:26,933 --> 01:08:29,166 for the tenants and for the provider. 151 01:08:29,433 --> 01:08:30,266 And they are different. 152 01:08:30,733 --> 01:08:31,866 Always keep that in mind. 153 01:08:33,399 --> 01:08:35,500 Oh, what just pops up in my mind is: 154 01:08:36,166 --> 01:08:38,433 There is a very cool mechanism, guys. 155 01:08:39,266 --> 01:08:45,133 If you as a CSP would like to offer your tenants API access 156 01:08:45,133 --> 01:08:47,466 to Cloud Director, there is a new 157 01:08:47,466 --> 01:08:49,666 session to generate user tokens. 158 01:08:51,333 --> 01:08:53,433 So it's somewhere in the UI. 159 01:08:54,466 --> 01:08:57,166 On the top right, where the username is, 160 01:08:57,166 --> 01:08:59,766 you can go to User Preferences, I think. 161 01:09:00,566 --> 01:09:03,266 And there is a section or a menu 162 01:09:03,266 --> 01:09:06,666 entry saying "generate access tokens." 163 01:09:06,666 --> 01:09:08,133 So you can use that access-based 164 01:09:08,133 --> 01:09:11,100 mechanism for the API for your tenants as well. 165 01:09:11,100 --> 01:09:11,966 It's pretty nice. 166 01:09:13,399 --> 01:09:15,066 Also for service accounts and other stuff. 167 01:09:15,399 --> 01:09:17,866 So it gets even more secure. 168 01:09:19,133 --> 01:09:22,899 Nevertheless, so the Cloud API documentation is great. 169 01:09:22,899 --> 01:09:23,966 It's easy to use. 170 01:09:23,966 --> 01:09:25,166 It's built into the product. 171 01:09:25,466 --> 01:09:29,199 You have all the URLs and like a Swagger 172 01:09:29,199 --> 01:09:32,666 documentation is, you have all the tryout, 173 01:09:33,066 --> 01:09:36,600 functionality, copy, paste, etc., all that kind of stuff. 174 01:09:38,766 --> 01:09:42,633 If you have or if you need a REST API call, which is not 175 01:09:42,633 --> 01:09:44,933 part of the Cloud API, you need 176 01:09:44,933 --> 01:09:47,800 to move over to the standard API. 177 01:09:49,966 --> 01:09:51,433 Yes, there is a documentation. 178 01:09:54,233 --> 01:09:58,733 I would phrase it, it's not as easy to use 179 01:09:58,733 --> 01:10:02,133 as the Swagger documentation of the Cloud API. 180 01:10:03,166 --> 01:10:06,566 It's a website in VMware code 181 01:10:06,566 --> 01:10:09,733 and best of luck to find something. 182 01:10:11,000 --> 01:10:16,433 Honestly speaking, I prefer if I need to deal with the 183 01:10:16,433 --> 01:10:18,466 standard API and I have no clue how 184 01:10:19,000 --> 01:10:21,566 a certain API call works. 185 01:10:22,166 --> 01:10:24,833 I prefer using the developer tools of my 186 01:10:24,833 --> 01:10:28,699 favorite browser and just grab the call, the 187 01:10:29,133 --> 01:10:32,466 UI fires in the background against the API because the 188 01:10:32,466 --> 01:10:35,300 Cloud Director UI does or is just 189 01:10:36,133 --> 01:10:39,399 consuming the REST API in the background. 190 01:10:39,399 --> 01:10:41,566 So there is no secret behind that. 191 01:10:42,800 --> 01:10:46,633 Use developer tools, grab the REST API call from the 192 01:10:46,633 --> 01:10:48,133 backend, which is monitored by the 193 01:10:48,166 --> 01:10:49,166 developer tools and then you 194 01:10:49,166 --> 01:10:54,666 have the URL, maybe some data model. 195 01:10:55,199 --> 01:10:58,566 So you can go to the header section, validate which header 196 01:10:58,566 --> 01:11:01,899 it is, which API version it is 197 01:11:01,899 --> 01:11:03,566 and then check the payload. 198 01:11:03,766 --> 01:11:07,199 If it's a put or a post, grab the data model. 199 01:11:08,699 --> 01:11:17,166 Sometimes you will find some hidden options in the data 200 01:11:17,166 --> 01:11:18,866 model if you're using the developer 201 01:11:19,000 --> 01:11:19,366 tools. 202 01:11:19,699 --> 01:11:22,366 So even with the Cloud API, not every 203 01:11:22,366 --> 01:11:25,666 single parameter of the data model is specified. 204 01:11:26,233 --> 01:11:28,433 And then you just use this stuff, you 205 01:11:28,433 --> 01:11:32,566 have sniffed and used a different data model. 206 01:11:32,600 --> 01:11:36,899 It also helps which parameters are mandatory, which are 207 01:11:36,899 --> 01:11:39,133 optional because I, for example, 208 01:11:39,266 --> 01:11:44,033 sometimes struggle with, "oh, I need parameter ABC or where 209 01:11:44,033 --> 01:11:46,166 do I get this information from?" 210 01:11:46,166 --> 01:11:47,633 Maybe it might not be available. 211 01:11:48,000 --> 01:11:50,566 So it's easier to be like, "oh, it's just optional. 212 01:11:51,066 --> 01:11:55,233 I just leave it empty or remove 213 01:11:55,233 --> 01:11:57,600 it from the data model as well." 214 01:11:58,000 --> 01:11:59,366 And then you can do it by REST. 215 01:12:02,466 --> 01:12:04,733 I think that's a pretty straightforward approach for 216 01:12:04,733 --> 01:12:07,000 automating Cloud Director and also basic 217 01:12:07,133 --> 01:12:07,600 tasks. 218 01:12:07,600 --> 01:12:12,033 And then you just move on for NSX and other products. 219 01:12:12,533 --> 01:12:13,166 If you have Cloud Director, 220 01:12:13,433 --> 01:12:15,433 please automate NSX via Cloud Director. 221 01:12:16,566 --> 01:12:18,133 I think that's something very, 222 01:12:18,500 --> 01:12:20,133 it's always like, oh, yeah, thank you. 223 01:12:21,100 --> 01:12:22,766 I saw it in your face, right? 224 01:12:23,766 --> 01:12:27,033 So it is important to say, even if you 225 01:12:27,033 --> 01:12:29,699 automate stuff, stick with the rules. 226 01:12:30,333 --> 01:12:31,733 Cloud Director is the leading system. 227 01:12:32,399 --> 01:12:33,966 If you've Cloud Director and your tenants 228 01:12:33,966 --> 01:12:37,733 are consuming NSX, automate on an NSX via 229 01:12:37,733 --> 01:12:38,466 Cloud Director. 230 01:12:39,266 --> 01:12:44,600 Except, unless you're automating something in NSX, which is 231 01:12:44,600 --> 01:12:47,366 meant to be a managed service 232 01:12:47,366 --> 01:12:48,633 for your customers. 233 01:12:49,466 --> 01:12:53,233 So it would be configured in NSX manually anyway. 234 01:12:56,500 --> 01:12:58,333 One of the features which just comes up 235 01:12:58,333 --> 01:13:00,866 is, for example, Distributed IDS/IPS. 236 01:13:02,166 --> 01:13:04,733 That's a managed service from a CSP perspective. 237 01:13:07,600 --> 01:13:08,133 Okie doke. 238 01:13:08,566 --> 01:13:10,433 So that's basic automation. 239 01:13:12,866 --> 01:13:15,733 The even more interesting part is, 240 01:13:16,266 --> 01:13:18,399 yes, Yves, you want to share some thoughts. 241 01:13:18,399 --> 01:13:20,199 You need to unmute yourself. 242 01:13:20,433 --> 01:13:25,033 Yes, I think the big question for me is, on one end you 243 01:13:25,033 --> 01:13:28,366 said, you don't know when the 244 01:13:28,433 --> 01:13:30,566 Cloud API is going to be finished. 245 01:13:30,566 --> 01:13:33,433 I think the answer to that is very, very straightforward. 246 01:13:33,800 --> 01:13:36,166 It's never going to be finished, because that requires 247 01:13:36,166 --> 01:13:39,266 additional development investments into VCD. 248 01:13:40,233 --> 01:13:43,266 And VMware was very clear that besides patches or anything 249 01:13:43,266 --> 01:13:44,633 else, they are not going to invest 250 01:13:44,633 --> 01:13:45,666 a penny into VCD anymore. 251 01:13:46,399 --> 01:13:50,899 I would not, to be honest, expect anything really coming 252 01:13:50,899 --> 01:13:52,466 back into that one, especially 253 01:13:52,633 --> 01:13:54,666 looking at how long it took them to 254 01:13:54,666 --> 01:13:56,733 get the API to where it currently is. 255 01:13:59,000 --> 01:14:00,933 And I would not expect much to the other ones. 256 01:14:02,333 --> 01:14:12,433 They promised that we will get similar API in the new 257 01:14:12,433 --> 01:14:15,600 systems, but they did not say similar to what. 258 01:14:16,199 --> 01:14:20,366 So whether that is the old-old one, the Cloud API or the 259 01:14:20,366 --> 01:14:22,899 current Automation API, which they 260 01:14:22,966 --> 01:14:24,766 also sometimes refer to. 261 01:14:25,166 --> 01:14:30,933 So the question is, if someone didn't start so far on their 262 01:14:30,933 --> 01:14:32,366 automation journey, what would 263 01:14:32,366 --> 01:14:34,633 be your advice at the moment to 264 01:14:34,633 --> 01:14:37,266 automate anything around Cloud Director? 265 01:14:37,566 --> 01:14:40,399 Would you still advise them to go directly REST? 266 01:14:40,666 --> 01:14:43,966 Do you advise them to use any of the existing packages? 267 01:14:44,866 --> 01:14:46,433 Or maybe use something more like 268 01:14:46,433 --> 01:14:48,033 an infrastructure as code approach? 269 01:14:49,699 --> 01:14:49,899 Yeah. 270 01:14:50,433 --> 01:14:56,000 So I still think the plugin is great, but, 271 01:14:56,333 --> 01:14:59,666 and there's a big but, if you start using 272 01:14:59,666 --> 01:15:04,133 the REST approach, you're more flexible because all the 273 01:15:04,133 --> 01:15:06,333 other products support the REST API 274 01:15:06,333 --> 01:15:07,033 as well. 275 01:15:07,733 --> 01:15:13,833 NSX, the vCenter server, SDDC Manager, even Operations 276 01:15:13,833 --> 01:15:15,433 manager, Operations for Logs, 277 01:15:15,666 --> 01:15:19,833 or it's a bit more hidden, but they have a REST API and 278 01:15:19,833 --> 01:15:21,233 they all use the same mechanism. 279 01:15:21,500 --> 01:15:26,033 If you are familiar dealing with one REST API, you're 280 01:15:26,033 --> 01:15:27,866 familiar dealing with all the 281 01:15:27,866 --> 01:15:29,066 other REST APIs as well. 282 01:15:29,966 --> 01:15:32,966 The only big difference between all 283 01:15:32,966 --> 01:15:36,100 the APIs is authentication, right? 284 01:15:36,966 --> 01:15:39,333 So you once need to figure out how to build 285 01:15:39,333 --> 01:15:42,466 Cloud Director authentication via REST, or 286 01:15:43,033 --> 01:15:46,066 you need to figure out how to build the authentication for 287 01:15:46,066 --> 01:15:47,333 NSX because they're different. 288 01:15:48,933 --> 01:15:54,366 But at least speaking for VMware by Broadcom, the 289 01:15:54,366 --> 01:15:57,933 documentation, how to authenticate against 290 01:15:57,933 --> 01:16:00,833 the REST API is properly written for 291 01:16:00,833 --> 01:16:03,600 every single product I've dealt with so far. 292 01:16:06,733 --> 01:16:07,033 Toby? 293 01:16:07,566 --> 01:16:11,699 Just to add here one thing, especially for those who really 294 01:16:11,699 --> 01:16:13,933 begin to start now with Automation 295 01:16:14,033 --> 01:16:17,166 or playing around Automation, let's call it that way, 296 01:16:17,166 --> 01:16:18,433 because if you really have already 297 01:16:18,433 --> 01:16:21,966 a use case that you would like to automate something, then 298 01:16:21,966 --> 01:16:23,733 maybe it is not the best idea. 299 01:16:24,199 --> 01:16:27,566 But if you're really starting now from scratch and say, 300 01:16:27,566 --> 01:16:28,766 hey, I would like to have people 301 01:16:29,333 --> 01:16:32,933 inside and look and play around with it, I would heavily 302 01:16:32,933 --> 01:16:35,199 recommend to play around with 303 01:16:35,266 --> 01:16:41,399 the REST API of the Operations Manager, especially for the 304 01:16:41,399 --> 01:16:43,433 future, more and more becomes the 305 01:16:43,433 --> 01:16:46,533 centralized API for the whole VCF game. 306 01:16:47,766 --> 01:16:51,699 So if you now really start with the REST API, then I would 307 01:16:51,699 --> 01:16:53,300 highly recommend that you play 308 01:16:53,300 --> 01:16:56,199 around with the API of the Operations Manager. 309 01:16:58,366 --> 01:16:59,733 That's a good mentioning. 310 01:17:00,033 --> 01:17:01,733 Thank you. 311 01:17:03,500 --> 01:17:05,066 So if you're familiar with REST, 312 01:17:05,433 --> 01:17:07,399 you're good to go with all the products. 313 01:17:07,399 --> 01:17:10,300 And it's not related to only VMware by Broadcom. 314 01:17:10,966 --> 01:17:14,899 But I have to admit, I don't know anything about the 315 01:17:14,899 --> 01:17:17,566 documentation quality of REST APIs 316 01:17:17,566 --> 01:17:18,433 of other vendors. 317 01:17:18,833 --> 01:17:20,533 So I'm not commenting. 318 01:17:23,266 --> 01:17:25,033 So that's very useful. 319 01:17:25,066 --> 01:17:29,866 You can even add Orchestrator into the service library of 320 01:17:29,866 --> 01:17:31,533 Cloud Director, and then you can 321 01:17:31,533 --> 01:17:39,633 use a VCD UI to kick off or to start VRO... it's Aria 322 01:17:39,633 --> 01:17:42,133 Automation Orchestrator -- a VRO workflow. 323 01:17:42,866 --> 01:17:47,566 And if you build the input form properly in VRO, it's 324 01:17:47,566 --> 01:17:50,266 identically displayed in Cloud Director. 325 01:17:51,500 --> 01:17:56,333 And if you're really brave, you play a bit with the actions 326 01:17:56,333 --> 01:17:59,233 in Orchestrator to populate drop-down 327 01:17:59,233 --> 01:18:02,500 menus and stuff, and then you can add filters based on 328 01:18:02,500 --> 01:18:07,066 organization ID, which might make sense to have 329 01:18:07,066 --> 01:18:14,100 an input form of a workflow, a multi-tenant based on Cloud 330 01:18:14,100 --> 01:18:16,033 Director, because Cloud Director knows the 331 01:18:16,066 --> 01:18:20,066 organization ID, OVDC user ID, and stuff like this. 332 01:18:21,033 --> 01:18:26,566 And the combination with roles and rights enables the 333 01:18:26,566 --> 01:18:29,366 visibility of certain objects like an OVDC network. 334 01:18:29,699 --> 01:18:33,533 So that's this part. 335 01:18:34,666 --> 01:18:38,833 Let's move to the dark side of 336 01:18:38,833 --> 01:18:42,033 Automation -- event-based stuff. 337 01:18:42,066 --> 01:18:49,000 I think that's even a more challenging area to automate 338 01:18:49,000 --> 01:18:52,866 infrastructure behavior, because 339 01:18:52,866 --> 01:18:54,766 that's exactly what we're talking about. 340 01:18:55,933 --> 01:18:57,966 So within Cloud Director, if you 341 01:18:57,966 --> 01:19:00,533 go--so that's the provider context. 342 01:19:00,733 --> 01:19:04,033 Within the provider context in the administration section, 343 01:19:04,766 --> 01:19:07,033 there is a menu entry called Extensibility. 344 01:19:08,033 --> 01:19:11,266 That's where you add the message broker to the system. 345 01:19:11,933 --> 01:19:16,100 And on the second tab, you can enable events. 346 01:19:17,433 --> 01:19:24,333 And then you can select--you can either trigger that Cloud 347 01:19:24,333 --> 01:19:27,733 Director should send all events to the event bus, 348 01:19:28,566 --> 01:19:31,399 or messaging bus, or to certain events, and you can choose 349 01:19:31,399 --> 01:19:32,800 if it's blocking or non-blocking. 350 01:19:33,366 --> 01:19:37,133 So non-blocking means Cloud Director sends 351 01:19:37,133 --> 01:19:40,733 an event and continues with its workflow, 352 01:19:41,500 --> 01:19:45,866 or if it's blocking, Cloud Director fires the event, 353 01:19:45,866 --> 01:19:49,100 triggers the event, and waits for the response. 354 01:19:50,066 --> 01:19:54,133 So the response could be successful, failed, or cancelled. 355 01:19:55,133 --> 01:19:58,633 And it sits there until it reaches the default time out. 356 01:19:59,100 --> 01:20:00,033 And that's five days. 357 01:20:01,033 --> 01:20:03,666 So you can wait for an external system. 358 01:20:03,866 --> 01:20:06,066 That might make sense if you ramp up a new virtual machine, 359 01:20:06,600 --> 01:20:10,399 and you need to grab an IP address from an external IPAM. 360 01:20:11,233 --> 01:20:14,266 It might make sense to wait for it, because you need to 361 01:20:14,266 --> 01:20:18,133 inject it into the boot process of the guest... for example 362 01:20:19,466 --> 01:20:22,833 And of course, if you use the event-based automation, you 363 01:20:22,833 --> 01:20:27,233 need to implement a RabbitMQ message bus in the backend. 364 01:20:28,066 --> 01:20:32,433 There are some hacks to access the MQTT, 365 01:20:32,966 --> 01:20:35,366 so the internal Cloud Director message bus, 366 01:20:35,366 --> 01:20:37,533 but I'm not the biggest fan of 367 01:20:37,533 --> 01:20:40,066 it, because I didn't understand it. 368 01:20:41,033 --> 01:20:42,466 So it's a bit more of a hack. 369 01:20:42,733 --> 01:20:46,933 So I don't preferr that option, because I leave the 370 01:20:46,933 --> 01:20:50,866 appliances as they are, because from a support perspective. 371 01:20:51,366 --> 01:20:53,333 So I'm not changing anything in the appliance. 372 01:20:54,266 --> 01:20:57,466 Just attach the message bus system, and then you attach 373 01:20:57,466 --> 01:21:00,100 Orchestrator, on the other hand, to the message bus. 374 01:21:01,033 --> 01:21:03,233 Do some configurations to route messages. 375 01:21:03,966 --> 01:21:05,633 So I have a nice blog article out there. 376 01:21:05,633 --> 01:21:09,500 It's like zillions of years old, but still accurate. 377 01:21:10,266 --> 01:21:13,966 And then you just consume the messages, and based on the 378 01:21:13,966 --> 01:21:16,666 message, you start the workflow. 379 01:21:19,166 --> 01:21:22,000 Hint, or today I call it a pro tip. 380 01:21:23,033 --> 01:21:27,833 If you deal with messages, there is something out there 381 01:21:27,833 --> 01:21:32,600 called the VMware Cloud Director Notification Package. 382 01:21:34,766 --> 01:21:38,966 If I have it in my head correctly, I think it was built by 383 01:21:38,966 --> 01:21:41,466 Christophe Decanini initially. 384 01:21:42,766 --> 01:21:44,233 I think, so he's a great guy. 385 01:21:45,033 --> 01:21:51,466 So that notification package enables something very 386 01:21:51,466 --> 01:21:54,500 specific, which is, you can 387 01:21:54,500 --> 01:21:57,733 collect a message from the message bus. 388 01:21:58,699 --> 01:22:02,466 That's Orchestrator out of the box behavior. 389 01:22:03,633 --> 01:22:06,766 But you have a message runner workflow, and the message 390 01:22:06,766 --> 01:22:11,166 runner workflow converts the message 391 01:22:11,166 --> 01:22:16,166 body into Orchestrator usable objects. 392 01:22:18,100 --> 01:22:19,500 Which is very helpful, because 393 01:22:19,500 --> 01:22:22,033 otherwise you need to start dealing with XML. 394 01:22:23,033 --> 01:22:28,733 And dealing with XML in Orchestrator with the Rhino 395 01:22:28,733 --> 01:22:34,666 JavaScript engine is not even a nightmare. 396 01:22:34,899 --> 01:22:40,366 It's like, I don't know. No, it's not working. 397 01:22:44,033 --> 01:22:46,266 Yep, oh, Yves volunteers. 398 01:22:46,600 --> 01:22:49,033 So from now on Yves is doing all the XML stuff for you guys. 399 01:22:50,033 --> 01:22:51,500 I'm not touching Orchestrator 400 01:22:54,666 --> 01:22:56,800 So the notification package. 401 01:22:56,800 --> 01:22:58,833 I have something to write my code now. 402 01:23:00,033 --> 01:23:03,666 I tried it and it can't deal with it because the Rhino 403 01:23:03,666 --> 01:23:07,033 engine in the JavaScript engine 404 01:23:07,033 --> 01:23:10,466 version in Orchestrator is way too old. 405 01:23:10,833 --> 01:23:16,033 And does not understand the XML header fields and stuff. 406 01:23:16,066 --> 01:23:18,699 Which tells me a lot about the product. 407 01:23:19,699 --> 01:23:21,966 It's a great product. It's old. It works. 408 01:23:23,733 --> 01:23:27,766 But coming back to one sentence before, are we sure that 409 01:23:27,766 --> 01:23:31,800 AMQP still is supported in 10.6? 410 01:23:33,966 --> 01:23:38,133 Because MQTT should now be finalized and working. From what 411 01:23:38,133 --> 01:23:39,933 I have heard and what I have tested. 412 01:23:41,266 --> 01:23:42,833 I don't get the access method 413 01:23:42,833 --> 01:23:45,033 and RabbitMQ is still supported. 414 01:23:49,666 --> 01:23:53,500 Does Hock charge an extra license 415 01:23:53,500 --> 01:23:55,866 for RabbitMQ now that he owns it? 416 01:23:57,300 --> 01:23:58,033 Please not. 417 01:24:00,500 --> 01:24:01,699 Just asking. 418 01:24:03,300 --> 01:24:06,033 I don't know. I didn't read anything. 419 01:24:07,033 --> 01:24:13,300 So another very very common use case for the Cloud Director 420 01:24:13,300 --> 01:24:17,933 Notification package is or are the blocking tasks. 421 01:24:18,233 --> 01:24:21,100 If you're using blocking tasks, the 422 01:24:21,100 --> 01:24:25,399 message runner workflow converts automatically. 423 01:24:26,666 --> 01:24:28,266 Or no, let's phrase it differently. The 424 01:24:28,266 --> 01:24:30,033 message contains the blocking task ID. 425 01:24:31,033 --> 01:24:35,166 And the Cloud Direct Notification package, the message 426 01:24:35,166 --> 01:24:37,833 runner workflow converts that ID 427 01:24:37,833 --> 01:24:42,066 into a vCloud blocking task object. 428 01:24:42,633 --> 01:24:46,333 So that can be triggered via the plugin. 429 01:24:47,699 --> 01:24:50,533 So these are some rare cases which 430 01:24:50,533 --> 01:24:52,033 are just the plugin is so useful. 431 01:24:52,066 --> 01:24:57,966 I once built a whole rest mechanism with blocking task ID 432 01:24:57,966 --> 01:25:00,433 to resume or cancel whatever. 433 01:25:01,833 --> 01:25:04,666 But honestly with the plugin, it's just two lines of code. 434 01:25:05,199 --> 01:25:08,600 And then you just trigger the blocking task. It's 435 01:25:08,600 --> 01:25:11,399 successful, continue, it's failed, it's aborted. 436 01:25:12,166 --> 01:25:15,666 And you can also implement based on that behavior some 437 01:25:15,666 --> 01:25:17,033 error handling in the workflow. 438 01:25:17,066 --> 01:25:19,566 Some rollback or whatever is needed. 439 01:25:20,333 --> 01:25:22,399 So that's the event based 440 01:25:22,399 --> 01:25:25,466 automation approach out of Cloud Director. 441 01:25:27,000 --> 01:25:32,566 And the Notification package also enables you to filter the 442 01:25:32,566 --> 01:25:37,699 messages based on organizations, based on users, based on 443 01:25:37,699 --> 01:25:39,966 event types or whatever is needed. 444 01:25:40,766 --> 01:25:44,033 Is part of that notification package. 445 01:25:44,066 --> 01:25:48,966 The only thing is, the message runner workflow is not 446 01:25:48,966 --> 01:25:51,199 working anymore out of the box. 447 01:25:52,266 --> 01:25:53,166 Second pro tip. 448 01:25:54,633 --> 01:25:59,800 The methods of the date time object have changed. 449 01:26:00,466 --> 01:26:04,100 You just need to go into the code, it's around line 140, 450 01:26:04,866 --> 01:26:06,966 and just change three or four methods. 451 01:26:07,500 --> 01:26:09,333 And then it's all good. You just need to 452 01:26:09,333 --> 01:26:10,033 alter the workflow and then it's working again. 453 01:26:10,100 --> 01:26:12,933 It tells the error message tells 454 01:26:12,933 --> 01:26:14,433 you exactly what's not working. 455 01:26:15,166 --> 01:26:18,100 Just validate that the methods are wrong, use the correct 456 01:26:18,100 --> 01:26:19,566 methods and you're good to go. 457 01:26:22,699 --> 01:26:23,866 That's the second pro tip. 458 01:26:27,466 --> 01:26:29,833 Yeah, so that's... 459 01:26:30,833 --> 01:26:37,033 So maybe one last idea based on a statement of Toby. 460 01:26:37,066 --> 01:26:40,333 Because Toby said, and that's 461 01:26:40,333 --> 01:26:42,033 something you always should keep in mind. 462 01:26:43,133 --> 01:26:46,733 If you're new to the automation game and you want to start 463 01:26:46,733 --> 01:26:50,966 with automating stuff, I have two tips. 464 01:26:51,833 --> 01:26:57,533 First, never ever just sit in front of the computer and 465 01:26:57,533 --> 01:27:01,199 tell yourself, "I'm now going to automate something." 466 01:27:01,699 --> 01:27:02,033 It's not working. 467 01:27:02,500 --> 01:27:05,766 It's not working, because you don't have a goal. You cannot 468 01:27:05,766 --> 01:27:08,533 achieve the goal. You will never have a result. 469 01:27:09,800 --> 01:27:14,033 Always come up with the use case and implement the use case 470 01:27:14,033 --> 01:27:16,433 and please start with very simple ones. 471 01:27:17,399 --> 01:27:19,000 And that's my second point. 472 01:27:20,366 --> 01:27:26,466 Never ever start, if you're new to the game, start 473 01:27:26,466 --> 01:27:29,966 automating virtual machines or vApps in Cloud Director. 474 01:27:31,033 --> 01:27:34,666 That also refers back to the vCenter server. Please do not 475 01:27:34,666 --> 01:27:36,666 start automating virtual machines. 476 01:27:37,666 --> 01:27:44,733 Because these are from the amount of methods and properties 477 01:27:44,733 --> 01:27:47,933 they have, they are by far the most complex objects. 478 01:27:52,266 --> 01:27:54,666 Just start with simple tasks. Let's call it that way. 479 01:27:55,866 --> 01:27:59,033 Yes, exactly. Toby, you're completely right. 480 01:28:00,266 --> 01:28:05,199 If you're struggling in the beginning, what could be an 481 01:28:05,199 --> 01:28:08,266 easy thing to automate just to play around with it? 482 01:28:08,933 --> 01:28:14,000 Create an Edge Gateway in an existing org. 483 01:28:15,166 --> 01:28:18,366 The OVDC itself is a very complex object 484 01:28:18,366 --> 01:28:21,033 as well because of the allocation model. 485 01:28:22,833 --> 01:28:24,933 That's the only reason. And I have 486 01:28:24,933 --> 01:28:27,033 another, I today have a ton of pro clips. 487 01:28:28,033 --> 01:28:32,199 If you would like to build an OVDC with Flex as an 488 01:28:32,199 --> 01:28:38,100 allocation model, the REST API is the only way to go 489 01:28:38,100 --> 01:28:40,566 forward, because the plugin is 490 01:28:40,566 --> 01:28:42,333 not aware of that allocation model. 491 01:28:45,033 --> 01:28:45,666 It's that simple. 492 01:28:46,066 --> 01:28:48,500 It was just introduced about five years ago. 493 01:28:49,866 --> 01:28:53,033 Yeah, so it's like it never went to school. 494 01:28:57,866 --> 01:29:02,033 Good. I think that is a good starting 495 01:29:02,033 --> 01:29:04,566 summary around Automation Orchestration. 496 01:29:04,933 --> 01:29:08,633 If you have any questions in any of these areas, feel free 497 01:29:08,633 --> 01:29:13,733 to ping the master of old-school automation called Matthias. 498 01:29:14,533 --> 01:29:16,399 No, his name is Sascha. 499 01:29:19,066 --> 01:29:20,033 Well, Sascha does the fancy new stuff. 500 01:29:21,033 --> 01:29:28,333 And also, if you have any other topic suggestions, feel 501 01:29:28,333 --> 01:29:31,566 free to drop them somewhere in the show notes, no matter 502 01:29:31,566 --> 01:29:33,966 which platform you are using, so that we get that. 503 01:29:35,333 --> 01:29:36,833 Do we know already the topic for 504 01:29:36,833 --> 01:29:38,833 the next recording in two weeks? 505 01:29:40,033 --> 01:29:41,033 Okay, I see silence. 506 01:29:42,433 --> 01:29:45,733 Okay, I see silence. So that means you should better follow 507 01:29:45,733 --> 01:29:48,600 us on social media and see what we are going to announce, 508 01:29:48,600 --> 01:29:51,133 what is going to be Episode 49. 509 01:29:51,133 --> 01:29:52,066 And then we better have a good 510 01:29:52,066 --> 01:29:54,500 idea of what's going to be Episode 50. 511 01:29:56,866 --> 01:29:59,233 But nevertheless, I would say 512 01:29:59,233 --> 01:30:00,766 thank you all for listening in. 513 01:30:01,100 --> 01:30:03,566 You can find this also on any of the 514 01:30:03,566 --> 01:30:07,466 podcast platforms and subscribe over there. 515 01:30:08,033 --> 01:30:09,033 Any closing words, Toby? 516 01:30:10,033 --> 01:30:12,566 Not from my side. Start with automation 517 01:30:12,566 --> 01:30:16,399 as soon as possible and have a happy day. 518 01:30:18,533 --> 01:30:22,199 Yeah, guys, go into automation. It's just cool. It's better 519 01:30:22,199 --> 01:30:24,000 than just clicking and watching 520 01:30:24,000 --> 01:30:26,266 progress bars moving and stuff. 521 01:30:26,266 --> 01:30:31,033 And then you free up time to learn 522 01:30:31,033 --> 01:30:33,033 new topics and do even cooler stuff. 523 01:30:33,066 --> 01:30:35,699 The first steps are pretty hard to 524 01:30:35,699 --> 01:30:39,733 take, but get used to it, go into it. 525 01:30:39,733 --> 01:30:42,600 It's not that difficult once you get used to the mechanism. 526 01:30:44,433 --> 01:30:48,366 I think, and I will end with a side take, I think it was 527 01:30:48,366 --> 01:30:52,366 William Lam who said, "Before I do 528 01:30:52,366 --> 01:30:55,033 it once, manually, I automate it." 529 01:30:58,033 --> 01:31:00,033 A good man, a wise man. 530 01:31:02,366 --> 01:31:05,866 Thanks for that closing statement. See you all on one of 531 01:31:05,866 --> 01:31:09,666 the next episodes and automate the world. 532 01:31:10,666 --> 01:31:12,033 Thanks for tuning in, guys. Bye.