8.3 Deep Dive: Platform Updates

Speakers

Carl Gould

Chief Technology Officer

Inductive Automation

Andrew Miller

Product Manager II

Inductive Automation

There’s so much going into 8.3 that we need a few sessions to talk about it all! Join us in this first of two sessions where we look closer at a few exciting changes happening at the platform level, and what it means for deployments in the future. In this session, we’ll focus on changes to the platform, such as the file system, API access, and secret management.

Transcript: 

00:07
Carl Gould: Hello, again, everybody. In case you forgot from half an hour ago, I'm still Carl Gould, Chief Technology Officer at Inductive Automation.

00:15
Drew Miller: And my name is Drew Miller, Product Manager for Ignition Applications.

00:20
Carl Gould: So we covered a lot in the keynote about these new features of 8.3, but at a pretty high level. So in this session, what we're going to be doing is digging a bit deeper specifically into some of the updates to the platform, hopefully explaining in some more depth and detail about how these things work. And then, in this session, we're gonna be able to open it up for an open Q&A after we're done, so you can all ask any questions you might have.

00:46
Drew Miller: That's right. With Ignition 8.3, it's a major release that we feel has something for everybody. From small, single gateway implementations to enterprise-wide, multi-gateway, deployment and coordination, there are just so many features that we've packed into this release to help you take Ignition further.

01:05
Carl Gould: Yeah, so many different features that we sort of struggled with how to structure these talks without it seeming like we were just going through this giant basket of features. So, a literal basket of features to go through. Because, you know, we are not above a cheesy prop-driven joke.

01:28
Carl Gould: Whatever, we're just going to roll with it here. So we are thrilled to share with you today this bushel basket of features that will be available with Ignition 8.3. Alright. Let's see what's up first.

01:38
Drew Miller: I got something here.

01:40
Carl Gould: A painting. What could that be symbolic of?

01:44
Drew Miller: Yes.

01:48
Drew Miller: So the first thing we're excited to share today is the brand-new Ignition 8.3 gateway UI. And what a beautiful sight it is. I thought it resembled more of a Van Gogh than a Picasso, but I think this one was cheaper on Amazon, so we'll stick with this one.

02:03
Carl Gould: So we started with a blank canvas, and we have painted an entirely new user interface for the gateway web UI. This fresh new UI was also designed primarily to just help you get things done more quickly. We rebuilt it from the ground up, as I've said, using new, modern web development technologies, which really makes the UI much snappier and more responsive. This was a pretty massive modernization overhaul, which has also allowed us to introduce some pretty key updates to the overall experience.

02:35
Drew Miller: So let's cover some of those updates. The first one to highlight here is that we've completely reinvented the gateway navigation. The entire architecture of the gateway has been renovated and reorganized to be more intuitive. We've introduced well-thought-out sections and categories so that every page within the gateway has a fitting home. Device connections, navigate to connections, devices. Need to update security settings? Try Platform Security. But if you really can't remember where something is at on the gateway, you can now search for it.

03:08
Carl Gould: Yeah, we've really worked to significantly improve the global search functionality and put it front and center in this UI. It allows you to search through everything on your gateway. So it'll search through all the pages in the navigation structure, but it'll also search through all the items that you have configured so that once you've found what you're looking for, click on it, and it'll just navigate you right to the section of the gateway for that item.

03:32
Drew Miller: Another new element to make the gateway more efficient is this merger of status and configuration. Now, when you navigate to a page, you'll be presented with both aggregated and itemized metrics while also having the capability to create, edit, delete, or diagnose related items, all without leaving the page. No more toggling back and forth between the status and configuration sections as they exist in 8.1. Complete all your related tasks in one spot.

04:00
Carl Gould: We really understand that so many of you deploy Ignition at really impressively massive scale. So, a huge part of this was to design a UI that just works gracefully as your Ignition systems grow. So all of the items in the tables are presented in a paged manner so that the UI's responsiveness doesn't degrade as the number of items increases. All the tables are filterable and searchable and sortable, and they allow for multi-selection with bulk editing so you can quickly take actions on many items at once.

04:35
Drew Miller: And then, lastly, with the new gateway, you see we have Ignition, but now we have launch. So like the gateway itself, we've once again reimagined how users can launch software directly from the web UI. With the new deep link launchers, users can open the Designer, launch Vision clients, and Perspective sessions or Workstations, all with the click of a button. So this saves time by skipping the step of opening the appropriate launcher and then finding the application that you're trying to run.

05:05
Carl Gould: Those of you like me who mourned the loss of Web Start, it's finally back. Yay. Okay, so we're just sort of scratching the surface here. There's really a lot to see in this redesign. It's packed with a bunch of clever features that support a lot of the advanced features of 8.3. It's better looking, it's more intuitive, easier to use, and should really help you just do things quicker, diagnose issues more efficiently.

05:31
Drew Miller: But there is more than what meets the eye with the new interface, and that's because Ignition 8.3 comes built in with a complete RESTful web API to configure the gateway. But we're gonna touch more on that later.

05:43
Carl Gould: Yeah, but on the topic of APIs, I'm dying to know what else is in this basket.

05:47
Drew Miller: I have something. Oh, let's see. Oh, we got a little history book here. Ooh.

05:56
Drew Miller: A history on the history API.

06:00
Drew Miller: That sounds really boring. Do you have the Cliff Notes for us here?

06:01
Carl Gould: Yeah, you got it.

06:02
Drew Miller: Okay.

06:02
Carl Gould: Let's talk about that Tag Historian API. So the Tag Historian API is the interface in Ignition that all history must conform to, all history and implementations. And it was introduced in the very first version of Ignition, version 7.0, nearly 15 years ago. And at the time it was introduced, the tag system was relatively new. And at the time, all history was being stored to databases using transaction groups. And little did we know how transformative and successful this API would really be. So today, the vast majority of historical storage and querying in Ignition goes through this original Tag Historian API.

06:43
Drew Miller: Now, with 15 years of experience under our belt, we took this opportunity with 8.3 to make some important and fundamental improvements to the design of the API to support today's ecosystem of time-series technology. Let's name a few highlights. So before 8.3, aggregations and calculations were performed in the platform using raw data from the historian engine. Now, historians can implement custom aggregations and can handle the processing of the aggregations themselves. This means that the calculations can be done within the engine itself, saving massive amounts of data transfer into the gateway, saving CPU, and most importantly, memory and time.

07:27
Carl Gould: In the previous API, all the historical data was packaged up at the source like a tag and then put through the store-and-forward system and then given to the historian engine on the other side of store-and-forward. And this made it difficult for historians to be able to capture important context about where the data came from, like modeling information or state transitions about that data. So, this new API corrects this issue by allowing historians to plug directly into the source of the data and not have to have the data be transferred through the store-and-forward system, which will allow historians to understand more context about the tags and the tag model. And that context can then be used to interpret state transitions correctly, as well as to store modeling information and context with the data, which should allow us to develop a richer contextual query model.

08:29
Drew Miller: And lastly, the historian uses a path model to identify data sources. Of course, when we think about history, we think mostly about tags. But there are actually lots of kinds of data in Ignition that could be historized, alarm data and model definition data, to name a few. The new API allows for many kinds of data to participate. And as an added bonus, engines can now handle when the path to a data source changes. So, if you rename your tag, your history can be mapped to the new name.

09:07
Drew Miller: Well, that's good. I thought we were going to lose them on the history lesson here, but let's pluck another item out of the basket.

09:12
Carl Gould: Let's do it.

09:13
Drew Miller: What's next? Oh, check this out. Sound the alarms, everybody. And this one's not a nuisance either.

09:22
Carl Gould: We don't have much prop budget.

09:27
Carl Gould: Alright. So, we want to share an important update with you about alarm management and alarm notification. So, in 8.3, we introduced an important new concept in the alarm model called alarm aggregations. And what this does is allows you to get at a first-class solution for aggregating alarm statistics at the tag folder level and at the UDT instance level.

09:53
Drew Miller: That's right. So now, you can quickly count the number of alarms in a critical state, display the highest active priority within a group, or sum the number of unacknowledged alarms for a specific area. With alarm aggregation, you no longer need scripting to derive or calculate these numbers. Instead, they're now properties exposed at the folder level that can be directly subscribed to.

10:16
Drew Miller: Yeah.

10:19
Carl Gould: Yeah. That's going to be real nice. Alright. And so staying on the topic of alarms, we want to share some features that will make notification seem as outdated as sending them through carrier pigeon.

10:32
Drew Miller: Fly out of here, little buddy. There you go.

10:36
Drew Miller: Alright. In Ignition 8.3, we've introduced Twilio voice notification and WhatsApp messaging. Expanding Twilio capabilities within Ignition is a great example of how we at Inductive Automation like to first make it simple and then make it easy. Or make it possible, then easy.

10:52
Carl Gould: Simple and easy. Yeah, same thing.

10:55
Drew Miller: By leveraging more of the Twilio platform, you no longer need to procure your own SIP server to implement voice notifications from Ignition. So now you can create custom call scripts, text-to-speech, broadcast calls, and implement pin authentication alarm acknowledgement, all while Twilio Voice does the heavy lifting.

11:12
Carl Gould: And you can also reach a wider audience because we've also integrated the use of WhatsApp into the Twilio Module. So WhatsApp is probably the world's most popular messaging platform and now we can utilize it for alarm notification. So, these additional alarm notification channels using the Twilio Module should make it a lot easier to build sophisticated notification systems because it eliminates the need to deal with physical cellular modems or manage your own telephony infrastructure, which can be kind of burdensome.

11:43
Drew Miller: Speaking of sending messages, I think our next feature might be somewhat related here. Oh, boy. A box of cereal. Tell me this isn't a cheesy serialization pun.

11:55
Carl Gould: You know it is.

12:00
Carl Gould: I literally pulled this out of my pantry this morning.

12:05
Carl Gould: There's a lot of places in Ignition where we have to send messages across the network, right? So, for example, between Ignition gateways, we have the gateway network. And here we send dozens of different kinds of messages to support all the various things the gateway network is used for, remote services and the EAM. And when we have to send these messages, they have to be serialized, right? We have message objects and they need to be serialized, put on the wire, and sent across.

12:32
Drew Miller: Similarly, between the Designer or Vision client and the gateway, there is tons of active communication to support both of those applications. Since the beginning of Ignition all the way up until 8.3, the messages sent on both of those channels were encoded for transport using a technique called Java serialization.

12:51
Carl Gould: Yeah, unfortunately, this is a technology choice which didn't age very well. You know, I talked a little bit in the keynote about technical debt. This is a good example of what technical debt is, right? Any software that lasts long enough will have some kind of technical debt. You make some sort of technology choice. It doesn't age all that well. This would be one of those. Because it has been shown that this Java serialization technique is susceptible to a certain class of security vulnerability. Now, I wanna make it clear that there are no known vulnerabilities of this category in Ignition. We do protect against this type of vulnerability using secure channels and using a mitigation technique called object whitelists.

13:33
Drew Miller: But in 8.3, we decided to do the work required to rid the platform entirely of Java serialization just as a precautionary measure. In 8.3, all messages are encoded using protobufs instead. This technique is fundamentally secure and it actually happens to be more efficient too.

13:51
Carl Gould: So, while we were doing this work in the network channels of Ignition, we also added an important upgrade to the Vision Module. The Vision Module now communicates... Phil's happy. The Vision Module now communicates using persistent web socket connection, which means that you don't have to pull for tag changes anymore. They can just be delivered unsolicited from the gateway when a tag changes, resulting in a lot less network traffic and faster update rates as well for the Vision Module.

14:22
Drew Miller: Okay, let's take another peek at what's in the basket here. I've got some manila envelopes. Take a guess at what could be in there. Configuration, of course.

14:33
Carl Gould: File folders. In 8.3, all the configuration of the gateway is stored in a logical file structure in human-readable JSON files. So, as we said in the tech keynote, 100% of the configuration top to bottom is now compatible with Git.

14:51
Drew Miller: Which these files are designed to be easy to interpret and encoded so that they are friendly to these diff tools. Source control systems like Git unlock the capability to develop, branch, merge, track changes, and strategically deploy using a centralized configuration repository. So, what we're going to do is we're going to break things down and take a look at how this configuration is stored on disk.

15:14
Carl Gould: Okay. So, we're going to get into some detail here. So, the configuration is stored in a structure that is going to look really familiar to any of you who've peeked into our project storage system that we introduced in 8.0. So, let's take a look at an example of just a single configured resource, in this example, it's a device connection. So, the resource is stored as a folder with configuration files in it. Most configuration resources store their settings in a JSON text file called config.json, but resources have the opportunity to store other configuration files in addition if it's appropriate for that resource type. So, for example, a Modbus device might also store your address mapping in a CSV file, for example.

16:02
Drew Miller: Above the resource layer, resources are grouped by resource type. So, all of your devices will be together, all of your database connections, etc. And above that layer, the grouping separates the configuration of different modules and the platform. And then, lastly, above that is what we call the resource collection layer.

16:23
Carl Gould: There are multiple collections of resources, and this is where things get kind of interesting. So, your configuration is organized into different collections that have different specific purposes. So, we're gonna go through each collection so you can understand how they all fit together and how you might make the most use out of them. So, most of your configuration is going to live in a collection called Core. This is where if you just go through the web interface and make a new resource, it shows up in Core. Above Core is a collection called External. External is where you can mount configuration from an external source like an orchestration operator. So, if you wanted to inject configuration into a gateway by mounting shared files from somewhere else, you would put them inside of External.

17:13
Drew Miller: And above that is a collection called System. And this is where module authors have a chance to inject configuration. This can be useful for providing configuration that is always present or for using the module system to encapsulate an entire application so that it isn't editable once it's been deployed.

17:31
Carl Gould: Now, below Core, we have a system called Deployment Modes, which we're going to get into in some detail in just a few minutes, so we'll skip that one for now. And below that, we have a collection called Local. And Local is a place where you can put configuration that is specific to your host machine. So, there's some kinds of configuration that basically you don't want synchronized to a backup node in a redundant pair. And that's really what Local is for. So, if you imagine something like a certificate that has the host name embedded in it, you don't want that. You want different certificates in your primary and your backup node. Local gives you a place to put configuration that won't be replicated.

18:15
Drew Miller: This stack of configuration collections all inherit from one another, combining to create a cohesive set of configuration for your gateway. So, now we're gonna look at these various collections and how you might use them together.

18:28
Carl Gould: Okay, let's look at some examples of what might go where. So, you might get your JDBC Driver configuration from our new JDBC Driver Modules. In 8.3, we're able to now package up the JDBC Drivers we ship with Ignition as modules, which makes it easier for us to keep them up to date. You could have, as I explained before, some centrally managed configuration that got mounted into external by mapping a volume in a container orchestrator, your normal configuration that you configured through the web interface shows up in Core. And then again, you might have certificates inside of Local.

19:06
Drew Miller: The gateway then automatically combines the configuration from these collections into one set of configuration. This combination is what your gateway actually runs. Because of the way that the collections inherit from one another, you can also override configuration provided by another layer.

19:22
Carl Gould: So for example, say you don't like the version of the JDBC Driver that we shipped with Ignition, no problem. Just define your own configuration for JDBC Drivers in Core and it will override the version from System. And this works for any kind of resource. You can override any reconfigured resource in a lower level. So, hopefully, you're starting to see how this design offers a really incredible amount of flexibility and power for fine-tuning and really specifically managing how the configuration of your gateway works and is organized, and can be packaged and deployed across various gateways and between redundant pairs. So some of you might be thinking though, with all of this configuration in nice human-readable files on the file system, aren't there things in my configuration that might be a little bit sensitive that I don't want everybody looking at?

20:21
Drew Miller: That's right. We have something for that.

20:22
Carl Gould: Yeah, I think we do.

20:23
Drew Miller: I'll just take another look in the basket here. Well, check this out, a cryptex.

20:28
Carl Gould: What is that? It's so small.

20:31
Drew Miller: It's a clever little device that holds a secret message inside. Oh, I can open it here. And what does it say? It says, "Don't store your passwords in plain text, silly."

20:42
Carl Gould: Sage advice. So, yes, your configuration is often full of secrets. What's a secret? Things like an encryption key or a private certificate or a password. Those are all secrets. And with your configuration being so readily exposed to so many people who, you know, the various engineers working on your system or people managing the source control repository that you may be checking configuration into, or even if you package up configuration and send it to our support team, you start really having to think about not exposing the secrets that are inside of your configuration.

21:22
Drew Miller: Of course, this isn't just a problem facing Ignition. All software shares this challenge, and that's why there's an entire ecosystem of IT solutions to help manage this problem. The most popular solution is a product from HashiCorp called Vault. Secrets managers like Vault can send your secrets securely and only provide them on demand to systems such as Ignition through secure validated connections.

21:47
Carl Gould: So, in 8.3, secret managers are now an extension point of the platform. So we have two implementations and one of them is an internal implementation that right out of the box makes sure that the secrets that are embedded in your configuration are encrypted securely. The encryption uses a key that you can provide to the gateway and it's encoded in such a way that it supports a graceful key rotation mechanism. Or of course, the other implementation is the HashiCorp Vault implementation, where your secrets are not stored in your configuration at all. They're just references to a name secret stored inside a vault. This way when Ignition is running, it's able to grab the secret from HashiCorp Vault and use it and then throw it away when it's not needed anymore. So it's not persistent at all.

22:38
Drew Miller: This way you could share your configuration and put it in source control with a lot less worry about this sensitive information being leaked. But what if you need to configure different credentials in different environments? For example, what if you want your development server to connect to your database using a less privileged user than your production gateway, so that your development server only has read access, for example. I think we have something for that as well, right?

23:04
Carl Gould: Oh my. A giant chameleon.

23:06
Carl Gould: A creature that can change its colors to adapt to any environment. Here, the pigeon needs a friend.

23:12
Carl Gould: There you go, buddy. There we go. That's nice. They can be buddies. Alright. So yeah, in 8.3 we have this fun new concept called deployment modes. And that is gonna really help you solve this challenge of dealing with multiple deployment environments.

23:28
Drew Miller: Many of you are building sophisticated deployment pipelines for your Ignition applications where development, testing, and production are all done on separate systems. Managing the deployment transition between these environments can be tricky because there are often subtle differences between each one.

23:45
Carl Gould: Okay. So, the idea always sounds simple enough, right? Make development changes in isolation and then test them and then push the changes to production. Sounds great on a whiteboard. In practice, this is pretty tricky to pull off gracefully. So, one of the big complications is that each of these environments might have different configuration from the other one, and then you're in trouble when you need to deploy from one environment to the other. So, in production, you've got production assets, but you don't wanna connect to those production assets in the other environments, maybe you wanna have different security settings in your dev environment than your production environment, because of the rapid change of innovation happening in dev, maybe the security's getting in the way. There's all kinds of reasons why these different environments have different configuration and then it makes deployment really challenging.

24:43
Drew Miller: Deployment modes helps to solve all of these challenges. So let's explore how it works. You remember the diagram from earlier. This is where deployment modes fits into the configuration system. With deployment modes, you can define any number of modes. To keep things simple though, we're gonna define two: development and production. Now, you have the opportunity to define alternate settings for any configured resource within these modes. You could have a device defined with different settings for each mode. For example, in development, this device could be a simulator, but in production, that device would actually be a Modbus device, a production asset.

25:21
Carl Gould: The thing to really understand here is that these are alternate configurations for the same resource, and the gateway will then automatically load the different settings based on whichever production mode, I'm sorry, deployment mode that it's in. So if you're running in dev, it'll be a simulator. If you're running in production, it'll be an actual connection to the Modbus device. But to the rest of the system, like the tags that may be referencing that device, it's the same device, same device name, etc. It looks like one logical entity that just behaves differently in different environments. And devices are just one example. But this is a fundamental platform-level feature of the entire configuration management system. So, it works with any kind of resource that you want it to. So if you wanted those different security settings, no problem. Security settings are just another kind of resource, so you can define different security settings for the different deployment modes. You wanna use different certificates in different environments. Now again, that's just a resource. So you can define different settings for different modes. So everything works really gracefully with the system.

26:27
Drew Miller: The beauty of this design is that all of the configuration, both the settings for development and the settings for production, they're all contained within one cohesive configuration set, which means one gateway backup. In development, you can review and change the settings for production even though those settings aren't active. This way, the deployment from one environment to the next can be an atomic migration of all the configuration, instead of surgically moving specific resources between servers, which is a very risky maneuver.

26:58
Carl Gould: And of course, the idea is fully integrated into the new web UI, since we were rebuilding it from scratch anyways, which means that even though that might have sounded kind of complicated, in the UI it's really pretty simple, right? You go into a resource and you just have the opportunity to define overrides that are active in different modes. It's really pretty straightforward. So, speaking of migrating configuration from one environment to the next, how might you actually pull that off? Let's see what is next in the basket of goodies?

27:32
Drew Miller: Oh, I have something for you here.

27:33
Carl Gould: Oh my, a conductor's wand, I can finally fulfill my musical ambitions. No, of course, we're talking about orchestrating the gateway, not an orchestra.

27:49
Drew Miller: Let's circle back to that topic of APIs. I mentioned Ignition 8.3 comes with a built-in RESTful web API to configure the gateway itself. This API can be accessed through secure API tokens that you can generate. And best of all, it's fully documented using a standard OpenAPI-compliant specification file. This spec is fully embedded within the gateway and it's dynamic based on which modules are installed. So, it's always accurate. One of the great things about OpenAPI is the ecosystem of tooling and support that exists for it as well. So if you're trying to interact with this API in an external system, chances are you'll be able to generate a client API library in that system's language using this OpenAPI specification file. And it also comes with a UI so that you can browse and search through all the endpoints and see exactly how to use them with detailed information about the schema and the payload.

28:44
Carl Gould: Yep, APIs are way better when they're documented.

28:50
Carl Gould: Far more useful. And yeah, this API is really going to enable external actors like those container orchestration systems, CI/CD systems, even just a simple scripting setup to be able to view, diagnose, and manipulate the configuration of a gateway from across the network. So, taken all together, all of these new features, the file-based configuration, the distributed source control compatibility, secrets management, deployment modes, and this RESTful web API. Taken together, they really create this compelling set of features that makes sure that Ignition is really poised to be able to be natively and gracefully integrated with the kinds of modern orchestrated IT-managed enterprise architectures that many of you are working with today.

29:41
Drew Miller: That's right. And what these technologies promise is really truly revolutionary compared to traditional systems management. Technologies like Kubernetes with Helm charts make our classic approach of first running the installer and then configuring look archaic. So, containerization not only allows you to install quickly, but rapidly stand up complex architectures, easily keep them patched, and keep your systems running smoothly with well-orchestrated deployment strategies.

30:11
Carl Gould: Yeah. We're really looking forward to building and releasing a lot of additional resources over the next year as we explore the promise of putting all of these technologies into action. We're working on deliverables like Helm charts, which are really amazingly compelling way to bring all these technologies together, as well as additional educational materials, new IU videos, etc., to make sure that we're all clear on what the best practices are as we put these systems into production.

30:42
Drew Miller: And more importantly, we cannot wait to get this release of Ignition into your hands. With 8.3, we feel that our platform has been modernized to the point it is now poised to deliver another wave of innovation really in any industry. And we know the community in this room is going to be the group that makes it happen. So, this will conclude the updates to the Ignition platform. Join us in the next session. You can still see we have some features left in the basket here that Matt Raybourne and Reese Tyson are gonna cover. But at this time we'll turn it over to questions.

31:14
Carl Gould: Yeah, questions. And I believe there's mic runners.

31:17
Drew Miller: Very eager question.

31:18
Carl Gould: Phil's very excited to ask a question.

31:22
Carl Gould: Who's gonna get to Phil fastest?

31:27
Drew Miller: He's also really excited about Vision updates.

31:32
Audience Member 1: So, you've not left me very many things to pick at here.

31:41
Audience Member 1: But I did notice the Historian API appears to be replacing the Tag Actor API, is that going away or being deprecated?

31:55
Carl Gould: I wouldn't say it's replacing it. I would say we just made the Tag Actor API better.

32:00
Audience Member 1: Okay.

32:01
Carl Gould: Does that make sense?

32:02
Audience Member 1: So, if I develop against it, it's relatively safe?

32:07
Carl Gould: Yeah. You may have some migration to do on your modules. Any module authors in the room, you got some work to do.

32:16
Carl Gould: The backwards compatibility promise does not apply to APIs over major versions. Right. But yeah, the capabilities absolutely still supported.

32:24
Audience Member 1: Okay. I got nothing else.

32:26
Carl Gould: Oh my God.

32:27
Carl Gould: We did it.

32:41
Audience Member 2: I started coming to the ICC about three years ago and what I found out is ICC is code word for hold my beer to the rest of the industry.

32:52
Audience Member 2: But are there any plans to expose, let's say you talk about event streams and whatnot, but events within the tag database, to expose them publicly such that you wouldn't need modules?

33:06
Carl Gould: Exposing tag events publicly. In what way? Like you wanna be able to subscribe to tag events?

33:14
Audience Member 2: Yeah. Think of the things like, you know, when somebody adds a tag or deletes a tag instead of having a full...

33:18
Carl Gould: Oh, oh, I see what you're saying.

33:20
Audience Member 2: Yeah.

33:21
Carl Gould: Like you want to be able to subscribe to changes natively through like a RESTful API or something?

33:28
Audience Member 2: Something like that. Like tag data, change that...

33:32
Carl Gould: Right. Tag configuration changes. Are there any plans for that? No. Concepts of plans.

33:42
Carl Gould: That was Drew's joke. I stole it from him. It's an interesting idea. I don't think it would be... What I would like to do for that, so one of the neat things is that tags are just configuration also. And so, what I would prefer to see for that idea is it not to be specific to tags, but I don't know exactly how we would pull it off, but it's an interesting idea that we'll think about. Yeah.

34:09
Audience Member 1: You can do the tag through module.

34:11
Carl Gould: Well, yeah, but he doesn't want to do it through a module, he wants to... Right?

34:15
Carl Gould: 'Cause you could do that as a module today, but...

34:26
Audience Member 2: Sorry. Like, what Sepasoft does with the MES events. When you create a new MES object, you can trigger an event and sit there and hook into things or whatever. Same sort of idea, like with tag creation, right?

34:39
Carl Gould: Yeah. No, I get it. It's a fun idea. And the system is really well suited now to be able to do that in a consistent way across any type of resource. Because you're interested in tag configuration changes, but someone else might be really interested in certificate changes. I know they are. So it would be, I think, best to do it at the resource layer, which is now nicely consistent across all kinds of resources. So, it's a fun idea. Thank you.

35:08
Audience Member 3: Hi. So, I saw an Ansible logo in the keynote, but in the deep dive, we didn't mention Ansible. So I get with the API, it's easy to do, but it's still a lot more work. Are you actually planning to do like a community module for Ansible to make configuring a gateway kind of first class for Ansible specifically?

35:27
Carl Gould: That's a good question that I don't have a great answer to off the top of my head. I don't think it would be an Ansible module. We're playing with all kinds of things in this space. Helm charts is one of the most interesting. We're also looking at publishing a Kubernetes operator. Oh, I got a thumbs up on that one. I'm gonna take it and let that be the end of that answer before I get into trouble.

36:00
Audience Member 4: Yeah. I noticed in the beginning in the screens that at the bottom, it said "gateway restart required." Could you go into what triggers that and the effects of it? And the other question is you said the tag historian does the tag, sends the tag model, does that include like the engineering units, the last time the tag changed, the quality, all of that stuff at that time when it sends it?

36:37
Carl Gould: Okay. Two good questions. Do you wanna take the restart one?

36:40
Drew Miller: So the first is the, the module lifecycle itself has been refactored for 8.3. So what would trigger that restart event? Module installations would be a big one. There are a few, I think, settings throughout the gateway. Just a very small.

36:56
Carl Gould: Deployment modes would be one. You can't change deployment modes without restarting.

37:00
Drew Miller: Right. So those, those types of configuration changes would require a gateway restart.

37:05
Carl Gould: Yeah. That probably showed up in that screenshot because we're testing the notification bar API, while we're taking the screenshots. But the second question is about, okay, we have, again, here we're talking about the Historian API. In the next deep dive session, Matt and Reese are actually gonna be talking a little bit more about the historian implementation we're adding, the Power Historian. Because what's important to differentiate is, the Historian API creates the opportunities or capabilities for a bunch of interesting things to be true. As in, if you were writing a historian implementation, you would now theoretically be able to do a bunch of interesting things, but we aren't at the place right now where we have that plurality of interesting and compelling historian implementations that take full advantage of all the APIs as capabilities. And I realize that is, probably sounds a little weaselly. But, so the answer is an optimistic yes that is now possible, with an asterisk of the Power Historian today, I don't believe is storing the full UDT definition or tag definition. But that is the idea that we're trying to get toward.

38:38
Audience Member 5: New gateway interface. Are we able to export the tags without having to go into the Designer?

38:51
Carl Gould: I think so, but I'm not a hundred percent sure. But if not, it would be trivial to add. I will say that in the... On the topic of exporting, so there's... What's in 8.3.0, and then there's what might not make the .0 release and what might be added in the next few point releases. Right? And one of the things I'm really excited about, but probably won't make the .0 release, is so we have gateway imports and exports right now with the GWBK file, which has like everything about your gateway. Cool. I also wanna add a new import/export format, which would be really similar to how in the Designer you can import and export projects and just pick and choose the resources. And then, when you import them, they just like zipper into the project you already have open. Now, we can do the exact same thing in the gateway, which will be really nice.

39:42
Carl Gould: So, there's two things here. One is like exporting the tags as like a tag JSON file. If it's not in there right now, it could be added trivially. So, the answer should just be an unequivocal yes. But then, also there should be a platform-level import/export function so that you can more easily export a set of configuration. And that could include tags, but it could be say, you know, I need the tags and I need the devices. And then, those would all be able to be exported as one file and then imported into a gateway without causing a restart requirement.

40:25
Audience Member 6: Yep. So, another question on the Power Historian. So since the host is gonna actually be storing the historian data by default, I'm curious like what does that look like under the hood? You kind of danced around it that it was a more modern like time-series based. So, that's one, like what is it under the hood, is that gonna be externally accessible or accessible through the platform without having to stand up something like that, external?

40:58
Carl Gould: You're talking specifically about the Power Historian?

41:00
Audience Member 6: Yeah. Specifically with the Power Historian.

41:02
Carl Gould: Okay. So yeah, the platform is one piece, the Power Historian is contained within the Tag Historian Module. And the answer of what it is under the hood is it's a time-series database technology called QuestDB. And QuestDB is an open-source project. You can use existing tooling for QuestDB and open the file. We're not trying to keep it secret or anything. So, I think that's the answer to that question.

41:33
Audience Member 6: Yeah. Thanks.

41:34
Carl Gould: Cool.

41:35
DM: One more.

41:37
Carl Gould: Oh, that made a lot of people have more questions.

41:39
Audience Member 7: So quick question with now we're gonna be able to use external repositories pretty easy. So what is that gonna do for audit trail? And along those lines, when I do push something from external repository, am I gonna be able to see it in the audit trail that something was pushed and what those changes were?

41:57
Carl Gould: Okay. So, an audit trail for configuration changes is in some sense what Git is. Right? And I wanna make it clear that we haven't like embedded a Git client into the platform. There's some ideas, and so the the point being there that any integration with Git is sort of on you to do, as in you've gotta create the repo and send it up to, you know, whatever, if you can use GitHub or GitLab or whatever you want to use, those details are left to you. And we're doing that. I don't know how many of you have a lot of familiarity with Git? I use Git every single day. I don't really want the support department having to walk you through your own merges.

42:54
Carl Gould: Git's great, but you kind of need to know how it works. So, I guess the answer to the question is just Git just does that out of the box. It becomes that audit trail for configuration. Now, I do think that we need to add better hooks, so that when configuration changes are made through the web UI, you have a chance to do something like an auto commit into the repo. But that's still a little bit TBD about exactly how that works.

43:32
Audience Member 8: Can I ask about the Event Stream and Kafka Module? Are those gonna make their way down into the Edge version of Ignition product? And I think traditionally, like document-type tags have not been historizable. Is that going to change basically with the Power Historian or are we gonna be able to like buffer events offline to go into like the Event Stream?

43:58
Carl Gould: Okay. So Event Streams are not gonna be on Edge. And then, the question about document tags becoming historizable, I want to just say yes, but I would need to phone a friend to be a hundred percent confident about that answer. Do you have a confident answer to that one?

44:16
Drew Miller: I do not.

44:18
Carl Gould: That fun game of stump the chump, I almost made it. We only got 15 seconds left for that.

44:23
Drew Miller: You pulled me outta applications for a platform. That's great.

44:28
Carl Gould: Good questions.

44:33
Drew Miller: Probably time for the last one.

44:34
Audience Member 9: So with Historian API and also the Power Historian coming up, are there any plans for migrating all historian data that is currently in the SQL database into the new historian?

44:44
Carl Gould: Yes. Plans but not for dot zero. We won't have it ready. But that I think is gonna be a big piece of kind of how we move forward. On top of this new historian infrastructure is building better tools to migrate data in a number of different contexts. So, between those layers that I was talking about in the keynote, as well as between different historian storage implementations themselves, exactly when that's gonna get delivered, I couldn't say right now.

45:17
Audience Member 9: So, there will be going to the Power Historian but also the Historian API will be able to migrate to...

45:25
Audience Member 9: For instance, a cloud solution?

45:27
Carl Gould: What I'm saying is that in order to migrate data from one engine to another, we're gonna have to add some sort of data migration tooling that we don't currently have in there. So that's not really the... There's nothing about the API that would preclude us from doing that. We just haven't built that piece of it yet on top of the API.

45:45
Audience Member 9: So in the beginning, that would be custom made by ourselves for instance?

45:49
Carl Gould: That's right.

45:50
Audience Member 9: Alright. Thanks.

45:54
Carl Gould: Okay. It's gotta be the last one. I see I'm getting waved at by a light up there. That works 'cause it's blinding up there. So, last one, unfortunately. After that, you can just find me when I'm wandering out in the halls.

46:05
Audience Member 10: So you talked about alarm aggregation briefly there. Are you giving us totals and counts within like a particular folder? What does that look like? Can you talk about that a little bit? And then, how does like suppressing lower priority alarms work with the higher priorities?

46:24
Carl Gould: You wanna take that one?

46:25
Drew Miller: This is what happens when we pull the product manager outta the application and into the core. Wait, the data model should look the same as the existing alarm underneath that...

46:35
Carl Gould: Yeah. Yeah. It does counts by priorities and things like that. It's basically just a set of new bindable properties that is exposed at the folder and instance level. The question about filter, specific filtering, I'm afraid I don't know the answer to it off the top of my head, but it's an interesting question. Oh man, ending it on a low note. That's a bummer.

46:57
Carl Gould: Good thing I've got my furry friends here to keep me company. Okay. So, we're gonna have to end it there, unfortunately, but I'm around all week, so grab any of us and continue to ask hard questions. We love this part of it. It's super fun for us. Thank you so much, and stay tuned for the next one.