Updates to modules showing in repo but not modules toolbox

Audit in UIv3 will be going away in 194. This is to avoid further divergence with UIv4’s skipped modules.

We recommend using the “Skip” functionality in the Toolbox to replace the older Audit functionality.

There’s no plan to provide API endpoints for module counts by state, but we can reevaluate this based on feedback.

194 will also see the rollout of “in use / not in use” counts and status for some LogicModules (others coming in later releases).

Can we please resolve the large number of modules that appear to need updates but when installing the update it says there are no differences? Can we do that before we pull the rug out from under the existing working workflows at least?

@Stuart Weenig I’ve got the backend team looking into the update “no differences” issue. I see us getting this fixed before the old stuff goes away.

I understand the fear of “having the rug pulled out”. The LMX team understands how important these flows are for LogicMonitor customers, and we want them to be solid before they become your only option. Some of these changes are very difficult to make/maintain in parallel (Audit/Skip being one, and RBAC being another), which is why we pulled Audit out earlier. We haven’t seen any issues with “Skip” functionality in the Modules section.
 

I think what might help would be to know how to construct filters in the module toolbox that help classify the modules according to the level of attention required. In my case these classifications also map to:

• Up to date - no attention required
• New - cursory attention required (ability to back out needed)
• Updated Not in Use - cursory attention required (ability to back out needed)
• Updated In Use - that hasn’t been customized by me, moderate attention required
• Updated In Use - that has been customized by me, heavy attention required

I currently tell the difference between the last two using some custom software I’ve built that parses out and identifies the differences between the repo and the currently installed modules. It also displays the update history, which easily identifies a module that has been customized vs. updated from repo. @Michael Rodrigues, I know you and i have talked about the ability for the toolbox to track this not just on a module level, but on an attribute level. That should help.

Here’s my workflow. If this workflow breaks, i can either build a new workflow or abandon doing the work. 

1. New
   1. make a note of the date/time (my script preps this list so i can bulk copy/paste into my changelog system)
   2. pull them in
2. Updated not in use
   1. make a note of the date/time and the old version of the DS in JSON (so i can roll back if needed) (my script preps this list so i can bulk copy/paste into my changelog system)
   2. pull them in
3. Updated In use - not customized:
   1. make a note of the date/time and the old version of the DS in JSON (so i can roll back if needed)
   2. check if any changes would cause instances to disappear, new alerts to open, or customizations to be overwritten (decide go/no-go)
   3. pull them in
4. Updated in use - customized:
   1. make a note of the date/time and the old version of the DS in JSON (so i can roll back if needed)
   2. check if any changes would cause instances to disappear, new alerts to open, or customizations to be overwritten (decide go/no-go)
   3. pull into sandbox. Copy script(s) to DS editor in prod and test extensively (decide go/no-go)
   4. copy changes from sandbox to prod without overriding prod customizations (most often not fields yet preservable in module toolbox sadly)
   5. mark prod DS as audited so it no longer shows up as having an update

Elsewhere here we’ve asked for the ability to download tables in CSV format. Keeping my change log up to date is easy today because my script fetches all the data from the api and formats it in a way that’s easy for me to pull into my changelog. I can’t do that once the functionality is only available in the module toolbox. Having the ability to download the table from the module toolbox would alleviate that issue, especially if i can figure out the filters to replicate the four classifications above.

If a new interface is being designed and it makes a workflow harder or impossible, what’s the point of the update? I get that ease of manufacture is a goal of UIv4, but that can’t be at the expense of usability. Otherwise you’re making an upgrade that costs the customer without providing a corresponding value.

@Stuart Weenig 

Here’s how those filters map to those conditions (just click Clear and enter the relevant filters for Toolbox or Exchange):

• Up to Date 
  • Toolbox
    • Status: Up to Date
  • Exchange
    • Installed & Up-to-Date
• New
  • Toolbox
    • You won’t see modules you don’t have in the Toolbox, so the Exchange is the only place to see new (uninstalled) modules.
  • Exchange
    • Status: Not Installed
• Updated
  • Toolbox
    • Status: Outdated
  • Exchange
    • Status: Installed & Update Available
       

You may want to supplement these by looking only at Official modules, but if you have Community modules and those have updates, they’re probably worth looking at too.
 

Currently, there is no way to differentiate in use from not in use, or to see which side customizations were made on (you vs us) with in the diff. We do have all this data though. 195 will see the rollout of the “In Use / Not in Use” column for some modules types, and it’s more advanced than the old school AppliesTo check that Import from Repository uses (and which you technically can tediously recreate by testing AppliesTo on each module). There will be a filter for this as well (and you can sort by how in use it is).

 You can see “Customized” status today to know that you customized a given module from our defaults, but again, that doesn’t extend to the field by field diff (though we have that info and hope to show it in the UI).

It’s going to be difficult for my team to allow access to thew new APIs (we don’t control API access, but we do build the LMX APIs), but if you’re cool with something like a CSV export, I’m pretty confident we’ll be able to create something you can use to get back to a similar (if not better) flow.

Last week (in the context of the API difficulties), one of the BE engineers actually recommended just providing a simple export for power users who wanted the info but didn’t want to deal with our tooling/ui/flow.

You won’t see modules you don’t have in the Toolbox, so the Exchange is the only place to see new (uninstalled) modules.

TIL. I never really understood why there should be a separate toolbox from the exchange. Would rather have one searchable/filterable list to rule them all. Even your own filtering options for the same kind of thing have different names depending on whether you’re in the exchange or the toolbox. I have not been on the exchange page in over a year. Do you have usage stats on it? Do people actually use it? Why does the exchange even list the installed modules? 

You may want to supplement these by looking only at Official modules, but if you have Community modules and those have updates, they’re probably worth looking at too.

Community stuff cannot be trusted to receive updates, so I never use it. The exception is if there’s a github repo that i can follow.

Currently, there is no way to differentiate in use from not in use, or to see which side customizations were made on (you vs us) with in the diff. We do have all this data though. 195 will see the rollout of the “In Use / Not in Use” column for some modules types, and it’s more advanced than the old school AppliesTo check that Import from Repository uses (and which you technically can tediously recreate by testing AppliesTo on each module). There will be a filter for this as well (and you can sort by how in use it is).

Is that going to happen simultaneous to losing the audit module functionality? What will the in use/not in use be based on? Actual instance counts? Could we just get the instance counts and resource counts in columns? Is the ability to run an adhoc “test appliesto” and/or “test discovery” still on the roadmap?

 You can see “Customized” status today to know that you customized a given module from our defaults, but again, that doesn’t extend to the field by field diff (though we have that info and hope to show it in the UI).

This will help immensely with the actual heavy lifting of merging in updates. Currently I just look at the diffs in my tool (which diffs all fields not just preservable ones and decodes the code and diffs line by line). Understanding the decisions the ME team makes without any context can sometimes be difficult.

It’s going to be difficult for my team to allow access to thew new APIs (we don’t control API access, but we do build the LMX APIs), but if you’re cool with something like a CSV export, I’m pretty confident we’ll be able to create something you can use to get back to a similar (if not better) flow.

Obviously today, I built my own module toolbox to help me analyze the diffs. Having a CSV/JSON endpoint i can hit in a script will allow me to still update my changelog. Once all this mess is actually working, I’d love to talk about enhancing the change log so i don’t have to maintain my own.

Last week (in the context of the API difficulties), one of the BE engineers actually recommended just providing a simple export for power users who wanted the info but didn’t want to deal with our tooling/ui/flow.

Yes, that would help ease the transition until the kinks are worked out of the module toolbox workflow.