12 Replies Latest reply on Sep 10, 2013 10:08 AM by Gregor

    Whatever happened to "PI Agent"?

      I remember some chatter about PI Agent, a method for distributing and updating PI Software, on vCampus and from various other avenues. It has been quiet on this topic for a while. What are OSIsoft's current plans or thinking on this topic? I can imagine some scares of liability in the event the auto update goes wrong, but how much has OSIsoft explored such a method for delivering updates?

        • Re: Whatever happened to "PI Agent"?

          Hello Rhys,

           

          PI Agent is in production with managed PI Systems. There is some information available at OSIsoft Technical Support web i.e. here. What I don't know is if PI Agent is already used for update rollouts.

            • Re: Whatever happened to "PI Agent"?
              mhalhead

              Hi Rhys,

               

              As Gregor pointed out the PI Agent is here; it is the piece of software that communicate with the NOC. Hint, its part of managed PI so only EA customers at the moment. We had a discussion regarding the software updates earlier this year. As you rightly pointed out the consequences of get a bad update are quite high. What I gather is being looked at is similar to the Windows download but not install option; so the PI Agent will download the relevant piece and a person will have to push the install now button.

               

              Maybe someone on the Managed PI side could provide some more info.

                • Re: Whatever happened to "PI Agent"?

                  Thanks Gregor, Michael.

                   

                  One of the EA clients I work with has Managed PI, but there have been numerous deployment issues (another story). So I can imagine confidence to have automatic installations would not be too high right now. However, I have worked on and implementing (next week) a PowerShell alternative to automatic software updates for a system upgrade. It will receive the raw OSIsoft packages, un-package/extract them, apply the silent installation, configure the installation and then check the consuming system/applications. This is in a well defined environment with lots of implementations of the "same system" so it works well but I would be hesitant, although not against, to do the same on a multi-tenant type environment.

                   

                  The one thing that I think is lacking from OSIsoft software is an accurate (and likely highly complex) upgrade path with multiple other OSIsoft software & Operating System variations. We should have a table that clearly states dependencies, shared resources, upgrade paths and known effects (such as stops/starts PI Network Manager, or even code effects like the LINQ changes between AF SDK 2.4 & 2.5). That intelligence should be part of the software update element of PI Agent, so installs categorised as "low risk" or "low impact" can be set to automatically install, other installations would still require "authorisation" due to complexity/known effects/regulatory requirements.

                   

                  The PI Agent system could even have a Virtual Environment where the "to be deployed" system is replicated, the updates applied, a system verification performed, and then updates pushed to the production environment. If the deployed environments are virtual then roll back plans like VM snapshots can be used...automatically.

                    • Re: Whatever happened to "PI Agent"?
                      andreas

                      Hi Rhys - please keep in mind that these systems are monitored by the NOC. If you work on these systems, the EPM and the NOC should be aware.

                        • Re: Whatever happened to "PI Agent"?
                          fgasparro

                          Hello All,

                           

                          The PI Agent is alive and well. We have a large install base in across our EA customers. The PI Agent's primary purpose is to securely transfer data from the customers site to the OSIsoft NOC. One of the key design features of the agent is the ability for the agent to "maintain" itself. At times we do use this ability to help customers update their agents. Since the PI Agent does not have any dependency on the PI Infrastructure this is a relatively easy task to execute without breaking anything. One issue that we have run across operating systems that aren't patched. As you can imagine we, strive to be secure as possible and we do have requirements for high encryption levels which require specific patches for older operating systems like XP or 2003.  

                           

                          Rhys pointed out correctly that it really isn't that easy to properly orchestrate an upgrade with the number of dependencies that are found in the typical PI System. Most customers prefer to upgrade manually because of this and because beyond the install there are typically validation steps post install to ensure the upgrade went well.

                           

                          What is on the horizon for mPI and PI Agent? Well, we are working hard to improve the PI Agent and Managed PI maintenance experience through this technology. In 2014 we'll have an all new Managed PI with the ability to maintain itself, maintain its monitoring definitions and maintain the PI Agent. The experience will be similar to what you'd find in a virus scanner or Windows Update. A key change in the workflow will be that it will be completely driven by the customer and their preferences.

                           

                          Frank Gasparro

                           

                          OSIsoft Engineering Group Leader, Managed PI

                            • Re: Whatever happened to "PI Agent"?
                              Roger Palmen

                              Taking the ideas from Rhys forward, i can imagine a 'private cloud' variation of PI that is deployed and managed by OSIsoft, where the client only provides the rackspace or a number of vSphere resources.

                               

                              In the end, all i want from a PI Server, is that it is there all the time, waiting for me on port 5450. I don't really care about the OS, the version, or if it's HA or not. It just has to run, and i presume OSIsoft can do that cheaper on an enterprise level than most clients can themselves. That's what's cloud is all about, not?

                               

                              I could see this working for the major 'core' or a PI system: the PI and AF Servers, Notifications, Abacus (yes, we need abacus! Yesterday! :-). All the clients and connectivity is where the integration and customisation takes place, thus i typically see any work there as very client- and solution-specific.

                               

                              Offcourse, a public cloud for PI is also an option but that might not be an option for all customers and applications for a number of reasons, being security, privacy, latency, regulatory or any other technical (or emotional...) reason.

                               

                              And my apologies if i hijack this thread, but Rhys' got me thinking about this subject.

                            • Re: Whatever happened to "PI Agent"?
                              mhalhead

                              For others info (I'm sure that you know this Andreas) you can schedule NOC maintenance via the PI Agent. There is a tab on the PI Agent UI where the maintenance period can be schedule and the reason. I don't believe that this can be done programmatically.

                                • Re: Whatever happened to "PI Agent"?

                                  Frank, what if PI Agent was extended to allow client specific pre & post installation scripts to handle scenarios for the client consuming applications. Post installation scripts could initiate a roll back if they fail to validate the installation, or validate the consuming applications. This would be of particular interest for servers built from a template, i.e. one server is built and configured as the next multipled by 10s to 100s.

                                   

                                  Michael, what are your thoughts as an end user to an approach like this (automated installations)?

                                    • Re: Whatever happened to "PI Agent"?
                                      fgasparro

                                      We have a work item to look at this type of use case for mPI 3. We're thinking of silent installation (which we can do already) and then configuration by powershell scripts. There are a few challenges  in your scenario that we will need to resolve. One problem is that the installation needs to be validated i.e. we need to know it's working properly in the NOC and that there are no alarms before it's released for monitoring, we call that commissioning. Today we depend on our FSE's for this and they have a process that they use to ensure its ready for monitoring. Second, we need to figure out how to solve the authentication and unique registration for each agent in your scenario.  

                                        • Re: Whatever happened to "PI Agent"?

                                          Now that is interesting as that is what we've done to date but with a manual/human element to it (for now).

                                           

                                          We push OSIsoft software (and a lot of custom software) to remote systems. Then via PowerShell do the decompressing & extraction of files (self-extracting exe varies depending on the age of the exe), switch the OSIsoft installers to silent (switch setup.ini and silent.ini), set some of the default parameters, then initiate the installation. When the installation finishes we have PowerShell scripts that check if the update has installed as expected, then performs some sanity tests on what was installed; like making a connections to the PI Server upgraded, connection to AF, instantiate AF SDK, ... (via the OSIsoft PowerShell Tools). We then have some more scripts that do the "start up" of the servers, like starting up PI System services (AFService, ...) and starting up custom connected applications to the PI System.

                                           

                                          I'm just finishing some data validation scripts that check data is being produced in the same manner as pre-installation, obviously it will vary depending on the update. Currently this is purely manual.

                                           

                                          We have the luxury of performing this in a known environment built from a "cookie cutter". I could imagine your scope is massive in comparison albeit the same principle. 

                                           

                                          Our timeline for the next phase is aggressive, in the next few months (okay, probably end of the year) I would want the whole process automated where humans are involved by exception. We'll have a mechanism to notify centrally if an automated release has run into issues, most likely piggybacking on PI to PI to send some tag blob data containing a report/status.

                                            • Re: Whatever happened to "PI Agent"?

                                              Does mPI use BITS for package distribution (or going to use it in mPI v3+)? I'm looking at a mechanism for background transfers from PowerShell and BITS seems to fit the bill...but wondered what mechanism is on the cards for mPI.

                                                • Re: Whatever happened to "PI Agent"?

                                                  Hello Rhys,

                                                   

                                                  BITS is not used in the current design of the mPI agent. The primary issue with BITS was compatibility with operating systems used by our EA customers, as well as being less than robust in some cases. At this point, development suspects it is a more mature and robust platform, and our customers generally have newer OS's so the advantages could very well outweigh the disadvantages in the past..

                                                   

                                                  mPI development will most likely revisit the use of BITS in the next generation of the mPI Agent. A technology study will be necessary in preparation of a decision.