|
Replies:
17
-
Pages:
2
[
1
2
| Next
]
-
Last Post:
Feb 13, 2009 8:22 PM
by: rob_campbell@ce...
|
|
|
Posts:
1,151
Registered:
12/1/06
|
|
|
|
PowerPack editing - your input required
Posted:
Jan 11, 2009 11:07 AM
|
|
|
We are currently working on the new PowerPack architecture to turn them into real add-ons with automated upgrades and so on, and we would like to learn more about how you use or plan to use PowerPacks to make sure we design the system that satisfies your needs.
Here's the key question that we'd like you to comment upon:
When you use someone else's PowerPack, do you ever need to modify it, and if so how?
The obvious reason for the question is that the more you modify a pack, the harder it is to automatically upgrade it to a newer version, when the pack owner releases one.
So my personal inclination is to say: for tree nodes no changes are permitted if the node is a part of a PowerPack. You cannot delete any nodes or folders, edit any code, change parameters for cmdlet nodes, rename anything, change order, create your own subnodes - nothing. The only thing allowed is selecting the columns you need in the grid.
If you need to change things - you select the nodes you need (or a subtree with the nodes) and Ctrl-drag them to another folder in the tree to create your own copy. You can then do anything you like to these copied items. However, these are indeed one time copies which will not get upgraded when the original PowerPack creator makes any changes to his/her product and publishes the upgrade.
Does this sound fair or too harsh? If this is too limiting please share your scenarios.
|
|
|
Posts:
9
Registered:
6/26/08
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 11, 2009 11:53 AM
in response to: Dmitry Sotnikov
|
|
|
Hi Dmitry,
This hasn't got much to do with your specific question but since you guys seem to be looking at a new PowerPack architecture I thought I'd mention it.
I mainly use PowerGUI for script editing. Still there's a good bit of useful stuff out there in PowerPacks. What I'd like to see is some sort of alignment between PowerPacks and PowerShell modules. There's obviously a lot of good stuff out there in various PowerPacks. I wish I could simply write a script that leverages a PowerPack (basically: import a PowerPack and start calling various functions within it). Having all the niceities that PowerGUI script editor gives you switch completion and so forth would be very helpful as well.
The other direction is handled nicely in the current PowerGUI but I don't find myself using it that often. The other advantage this could bring is that the code generated would be a lot more transparent than the code we get today. This may even help a bit with the problem that prompted your question, the changes you make to the PowerPack would not necessarily get duplicated into generated scripts.
|
|
|
Posts:
1,151
Registered:
12/1/06
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 11, 2009 12:58 PM
in response to: Carter Shanklin
|
|
|
Carter,
Yeah, these are kind of offtopic but quite valuable.
For PowerPacks to PowerShell libraries, let me think this over... Maybe I can come up with a script to do a conversion. I wonder how I would generate function names from labels... Just leave as is or have some kind of heuristics, e.g. nodenames go into Get-nodename, links to Get-Linkname, actions... Hm... Actionname-ObjectTypename?
I am not sure I am getting the code generation issue that you mention... Do you mean some of the code-generation you do can be better? Could you start a new thread with some specific examples?
Dmitry
|
|
|
Posts:
414
Registered:
12/15/08
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 11, 2009 7:40 PM
in response to: Dmitry Sotnikov
|
|
|
Hi Dmitry,
(Sorry for the novel ;-)
This is a very similar problem to what Microsoft has with Operations Manager. OpsMgr has Management Packs (MPs) which are analogous to Power Packs. MPs contain monitoring rules, views, reports, etc. Frequently, admins want to tweak the rules in one of the MPs to better match their environment.
In versions of OpsMgr prior to OpsMgr 2007 (aka SCOM), users could modify any aspect of an MP. For instance, they could change the threshold for a performance monitoring rule from 75% to 90%. However, when the next version of the MP was released customers who failed to document all of their changes would go through the “tuning” process again. To mitigate the problem, Microsoft advised admins to create custom MPs, copy the rule they wanted to change into the custom MP, then disable the rule in the packaged MP. This prevented new version of the MP from stomping on customizations, but had its own issues because often the new version of a rule – especially a rule with a script – fixed some issues with the previous version. However, admins who created a copy of the original rule would not benefit from the improvements. All of these issues lead some of the product teams that built MPs to release updates very slowly to prevent stress on customers.
In Ops Mgr 2007 Microsoft introduced the concept of an “immutable” MP. Essentially the MP is locked and admins cannot modify anything. Instead, they can apply overrides to rules. An override lets the admin change the an aspect of a rule such as a threshold as before and even apply the change to only a subset of computers. Then, when a new version of the MP is released the rule is updated, but the override is unchanged.
That said, given the current architecture of PowerGUI I see a couple of issues with your “immutable” Power Pack approach. The biggest problem I see is that if I want to take someone else’s Power Pack and modify just one node so it works better for my helpdesk folks then I’m caught between a rock and a hard place. If I create a copy of a node and customize it then the copy lives outside the Power Pack and I degrade the usability and discoverability of the Power Pack. I know where the modified node lives, but I have to train my helpdesk folks to look there. Also, I can’t redistribute it as a single Power Pack, now I have to distribute two Power Packs. The alternative is to copy the entire Power Pack which means extra work for me up front and now I lose any bug fixes or other enhancements in future versions.
There are a couple of ways I see to mitigate these issues. First, allow me to override nodes. In the current PowerGUI architecture this would mean hiding the original node and allowing me to put my customized copy in its place. Then, allow me to re-export the PowerPack including my overrides as a single, new Power Pack that I could distribute to my helpdesk. When a new version of the original Power Pack is released I should be able to import it and everything except my custom node would be updated.
An alternative (or better yet an addition to the suggestion above) to minimize the need to modify a script is to add a layer of abstraction on top of the script. Automatically, extract the parameters in the Params block and display them in a window similar to the New User Action on the Browse Active Directory node. This would especially useful for things like domain names, SQL connection strings, etc. With this in place you can capture my parameter changes as overrides that can be redistributed along with the Power Pack. Now, my more of my customized nodes can remain in the Power Pack and I don’t miss out on any of the improvements – even to the nodes that I’ve overridden.
Hope this helps,
Chris
Pasted original from Word and it lost the line breaks.
Message was edited by: seaJhawk
|
|
|
Posts:
1,151
Registered:
12/1/06
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 12, 2009 4:31 AM
in response to: seaJhawk
|
|
|
Chris,
So you basically are saying:
Do not let change anything but:
1. Column selection/order, and
2. Node parameters.
Plus, externalize parameters for script nodes/links/actions as we currently do with regular ones.
Correct?
(Thanks for the MOM story! Very useful!)
Dmitry
|
|
|
Posts:
414
Registered:
12/15/08
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 12, 2009 5:30 AM
in response to: Dmitry Sotnikov
|
|
|
Hi Dmitry,
Essentially, yes. However, I think you need to let the Power Pack author decide if the Power Pack should be locked or not. The reason for this is that if I share a Power Pack with some coworkers or here on the forum I may want them to be able to edit it for their own use, or edit it to enahance it or fix something and return it to me. In that case I defnintely don't want it locked.
(Note: none of what I've mentioned is designed to protect intellectual property. Some folks may feel this is important, but currently it's not a high priority for me.)
A couple of other things I forgot to mention that make working with multiple versions much easier.
1. Version #. Allow me to specify a custom version number when I export the Power Pack through PowerGUI. This also allows you to add a feature to PowerGUI where user's can check for newer versions of a Power Pack that have been posted to PowerGUI.org.
2. Command line tool for exporting the Power Pack. Given the nature of PowerGUI this should just be a script. This allows me to edit the Power Pack in PowerGUI and then kick off a process to export it then check it in to souce control, deploy it to destination computers, etc. It would also be cool if you let me add an option to the context menu based on a script or function such that when I right-click on a node I can choose something like "Export and deploy to test servers."
3. Store the Power Pack in clear text. I know you already do this, but please don't switch to a binary format because developers can't store their their source in source control and take advantage of all of the source control features that rely on files being in clear text.
4. There's probably some more, but I need to take the kids to see the Dr. :-)
(Correction to my MOM story - I believe the term Microsoft uses for the "immutable" MP is "Sealed" instead. I don't think they use immutable in public.)
-Chris
|
|
|
Posts:
1,151
Registered:
12/1/06
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 12, 2009 8:52 AM
in response to: seaJhawk
|
|
|
Chris,
This leads to even more questions from me. 
If you allow people to modify packs, how do you upgrade when the new version becomes available? Do you just leave the option to skip or roll back the items that were modified or try to somehow merge the versions?
Merging may be a real headache:
* How would you merge code change?
* If PowerPack creator deleted a node, for which user added a subnode, what do you do?
* If user moved a node outside the pack do you still update it?
* If user deleted a node do you restore it?
For other features you suggest:
1. Version # and auto-upgrade - absolutely. This is why we are having this discussion here.
2. Command-line export for automation. Just the export or full APIs to manage any elements in PowerGUI: create/delete/modify/move nodes/links/actions?
3. Keep PowerPacks in clear text as we do today... How about using zipped xml instead (kind of Office 2007 and Firefox addon approach)? The reason I am asking is that the clear text we have for some reason is currently causing IE to open the file as XML right inside the browser (or change the file extension to XML when saving to disk) instead of treating it as a file to be opened by an external application (PowerGUI) as it should which is a headache for some of our users.
4. Keep them coming!
Dmitry
|
|
|
Posts:
7
Registered:
9/26/08
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 12, 2009 10:13 AM
in response to: Dmitry Sotnikov
|
|
|
I have a few requests.
- PowerGUI should remember what PowerPack (if any) a node/link/action came from. I find it very annoying to track down my links and actions while exporting when I want to connect to other PowerPacks (have to browse through the list of objects and dig through many levels).
- Ability to uninstall a PowerPack (related to above).
- Folders should be treated like paths (don't give them unique IDs). Right now each folder node has a unique ID, so it is possible to create many folders on one level with the same name. I would like to set up folder structures based on function, not PowerPack.
One option for handling upgrade conflicts, if you allow replacement of nodes, would be to upgrade the original node and notify the user. That way the user's custimizations would not be lost and they would know if there was a change. They could then compare the new original to their version and edit as they see fit. I don't see a good way to automate all of it.
|
|
|
Posts:
414
Registered:
12/15/08
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 12, 2009 10:21 AM
in response to: Dmitry Sotnikov
|
|
|
>> This leads to even more questions from me.
I love design discussions! I don't get nearly enough of them in my current job. >> * How would you merge code change?
When a vendor releases a pack to the public they should lock it to prevent customers from shooting themselves in the foot by modifying it. When updates are released they always overwrite the current version. It's up to the vendor to ensure that new versions don't break backward-compatibility for parameters so overrides will continue to work. Radical changes in organization or functionality should install side-by-side with previous versions. For unlocked packs, if I've customized a pack and then get a new version (or decide to import the original version or even a previous version) here is what I would want: P1 - have PowerGUI compare the packs and pop-up a warning if there are any changes. Then, give me the option to import the new pack side-by-side with the current one, appending the version number to the top node. P2 - Give me the option to see the changes- even if it involves something as simple as using compare-object. P3 - Show me the nodes that are different (and the actual change) and give me the option to accept or reject each change (at the node level) with reject being the default. One issue that is present in PowerGUI that something like MOM doesn't have to contend with is multiple users with their own configuration. In MOM, all users share the same data store containing management packs, rules, etc. If a new version is installed the update affects everyone. If a rule is modified it affects everyone. ( New items) In PowerGUI, because there is no central configuration store the process of importing a pack is going to be repeated on each workstation and for each user. To ensure a smooth upgrade process, I should have the ability to import a pack, apply some overrides and the export it. I should also have the ability to configure PowerGUI installations in my environment to look for updates on an internal share in addition to or instead of checking PowerGUI.org. I should also be able to configure PowerGUI so that when it finds an update it downloads and imports it automatically without involving the user. And finally, I'd like to have these settings available via Group Policy so I can modify them as necessary without touching every workstation. >> * If PowerPack creator deleted a node, for which user added a subnode, what do you do?
Deletes in minor updates (as opposed to a new major version) are tough. The vendor may want to clean up some "junk" that was missed by QA or they may decide that they know best and that the user doesn't need a particular node any more. However, that node may be the only one that the user uses. Either way, I think that P2 and even more P3 above handle this, giving the user the ability to choose not to delete something. >> * If user moved a node outside the pack do you still update it?
No >> * If user deleted a node do you restore it?
Good question - I think I would still defer to P2 and P3 above. >> 2. Command-line export for automation. Just the export or full APIs to manage any elements in PowerGUI: create/delete/modify/move nodes/links/actions?
Export is P1, but full APIs would be a high P2. Full APIs would give me the ability to architect the code for my pack in a manner that best suits development, developers and my source control system, yet convert it into something that can be consumed by PowerGUI at build time. This would enable things like easily building multiple versions of a pack with differeing levels of functionality (a lightweight free version and a full-featured fee version), sharing code between nodes such as in the case where I have a function that I want available in all of my scripts I can have one source and then just include it in each script node, and it would also allow me to more easily localize my pack. >> 3. Keep PowerPacks in clear text as we do today... How about using zipped xml instead (kind of Office 2007 and Firefox addon approach)? The reason I am asking is that the clear text we have for some reason is currently causing IE to open the file as XML right inside the browser (or change the file extension to XML when saving to disk) instead of treating it as a file to be opened by an external application (PowerGUI) as it should which is a headache for some of our users.Giving me full APIs would potentially eliminate the need to store packs in text because I could build them programatically and store my own source code in clear text, but this is only going to help the most advanced pack authors. Most authors are going to do all of their editing in PowerGUI and export their new version so they can check it in. If the file is in binary then it's pretty much useless in source control other than as a backup. I can't compare versions to determine what has changed and I can't easily write scripts to automatically report on information in the pack or modify portions of the pack. However, I think you could solve this pretty easily by providing two standard export options (Export as XML and Export as binary) then leave it up to the author to do the right thing. If you give me a way to convert from one format to the other from the command line then I can easily edit in PowerGUI, export as XML, check in to source control, then at build time I can make all the changes I need to the XML version and finally "compile" it by zipping the xml. New Stuff
4. PowerGUI compatible version - Pack authors should have the ability to specify a minimum and maximum PowerGUI version to indicate compatibility at the pack level or perhaps for individual items within packs. If I know that some function I'm calling in a script will only work with PowerGUI 2.1 and not 2.0, then I want it hidden or grayed out in versions of PowerGUI prior to 2.1 to prevent errors. I'd prefer not to have to add all the extra error handling to every one of my scripts. Maybe once this is all said and done I could get a free copy of PowerGUI?  -Chris
|
|
|
Posts:
414
Registered:
12/15/08
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 12, 2009 12:41 PM
in response to: Darin Pendergra...
|
|
|
Oooh Goodie! I love getting free copies of free software!
Comments:
>> 1. PowerPacks are shipped locked and will have version numbers
Authors should have the ability to decide if the pack is locked or not.
>> 2. Locked PowerPack nodes are updated - even if they have been moved
Nodes in locked packs shouldn't be able to be moved, only copied to a location outside the locked pack. I'm not sure I understand what you mean with this one.
>> 3. Users can unlock nodes to edit and/or rename and/or move them
Interesting idea, but I would lean towards making the user copy a node outside the pack before they can edit anything.
>> 4. Unlocked orphan nodes are preserved if the end user deletes/uninstalls the PowerPack
Based on the way I'm thinking about it I would rephrase as "modified nodes in an unlocked pack are preserved if the end user deletes/uninstalls the pack"
>> What about empty (deleted) nodes? Should they be considered locked or unlocked?
This goes back to whether or not individual nodes in a locked pack can be unlocked. If you do that I think you're looking for trouble because different users are going to have different expectations about what happens during upgrade, uninstall, etc.
>> I liked the alternate grouping idea - if you rearrange the nodes and relock them, the grouping would be preserved during upgrade.
See response immediately above.
>> Have I missed any use cases?
Maybe a couple. 
5. When a PowerPack is uninstalled it should leave nothing behind (other than overrides).
6. externalize parameters for script nodes/links/actions as we currently do with regular ones.
7. Allow parameters of nodes, links, etc. to be overridden.
8. Allow overrides to be exported and deployed in conjunction with new or updated packs
9. Allow me to export and modify packs without using the GUI
10. Allow painless upgrades. See ">> * How would you merge code change?" in my previous post.
-Chris
|
|
|
Posts:
414
Registered:
12/15/08
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 15, 2009 11:44 AM
in response to: seaJhawk
|
|
|
Two more requests:
I would love to have a way to programatically define the columns that are visible in a script node. (as well as their order and width)
I have one script that has a different behavior based on the name of its node. When I modify the script I update it in all of the appropriate nodes. Unfortunately, when I do this the columns are all reset and I have to update each node with the correct set of columns manually.
"Global" Functions - it would sure be nice to be able to define a function in one node of a powerpack and be able to call it from any subnode, link or action.
Thanks,
Chris
|
|
|
Posts:
414
Registered:
12/15/08
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 15, 2009 2:07 PM
in response to: seaJhawk
|
|
|
And a couple more requests...
1. Icons - I'm creating my own New User... Action. Can I use the Icons I see in the Active Directory pack?
2. Icons part deux - when I click on the New User... action in the AD pack, it pops up the dialog box, but the icon in the box is the old script icon. It should inherit the icon from the Action that called it.
|
|
|
Posts:
663
Registered:
6/30/06
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 15, 2009 4:15 PM
in response to: seaJhawk
|
|
|
all good suggestions - we are busily working away dividing this issue into bite-sized chunks so we can start getting stuff into the next relelase. Not sure what's going to make it - but we are moving forward with more powerpack management capaiblities.
|
|
|
Posts:
1,151
Registered:
12/1/06
|
|
|
|
Re: PowerPack editing - your input required
Posted:
Jan 16, 2009 4:37 AM
in response to: seaJhawk
|
|
|
> 1. Icons - I'm creating my own New User... Action. Can I use the Icons I see in the Active Directory pack?
Kind of offtopic for this thread but here you go :)
To change node/link/action icon from PowerGUI UI, open the item's properties dialog box, and click the icon there - this will open a dialog box for you to browse to an ico file.
If you want to copy an icon from another node, the easiest way that I can think of is copying over the section in the xml file. ;)
|
|
|
|
Legend
|
|
MVP: 2501
+
pts
|
|
Guru: 2001
- 2500
pts
|
|
Expert: 751
- 2000
pts
|
|
Enthusiast: 31
- 750
pts
|
|
Novice: 0
- 30
pts
|
|
Moderators
|
|
Helpful answer
(5 pts)
|
|
Answered
(10 pts)
|
|
