Munki2 - Item added during installation/removal is not processed in similar fashion to first item

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Select a package to install - wait for status to say "Installing"
    OR
   Select a package to uninstall - wait for status to say "Removing"
2. Select secondary package to install/uninstall

What is the expected output? What do you see instead?
Munki should process user's request (like MAS) to add/remove software 
immediately just as it does when a user attempts to add/remove the first item.

Currently, it will be added to pending updates, waiting for the user to 
manually update, add/remove another item, or for msu to be ran as --auto at a 
later time. 

Original issue reported on code.google.com by eriknico...@gmail.com on 23 Mar 2014 at 4:47

[GoogleCodeExporter]

I also have a use case for this issue:

User receives new machine and looks at the software available. User selects a 
small installer (say Firefox) first and it begins to install. User then selects 
a larger package(s) and is awk, expecting software to install. Large package(s) 
do not install until a later time or when user returns, increasing wait time to 
use said software.

While one could argue this is a minor issue, I still think it's a valid one. :)

Original comment by eriknico...@gmail.com on 23 Mar 2014 at 4:52

[GoogleCodeExporter]

The intended behavior is that any user selections made while either a 
managedsoftwareupdate check or install session is occurring will be queued and 
then performed after the managedsoftwareupdate completes. It's very possible 
this does not always occur -- specifically I'm not at all certain it will 
happen if the user selection happens during an install/removal session as you 
describe.

Do note:

1) In the worst case, (like an Adobe CS6 Master Collection install), an install 
session could take an hour or more. It would not be until that install 
completed that a new selection would be processed.

2) As currently architected, MSC.app would need to remain running the entire 
time, otherwise there is nothing to initiate the subsequent check+install 
session.

3) It's possible to imagine managedsoftwareupdate being modified to check and 
install even after the user has exited MSC.app; would it be unexpected if 
MSC.app relaunched for user confirmation if additional items are found to 
install? There are many user interaction/user experience issues to think about 
here; this is not as simple and straightforward as the App Store, where you 
select a single app and it is installed. What Munki is doing in the background 
is more complicated and not always easy to map to the simple App Store-type 
interface.

Original comment by gregnea...@mac.com on 23 Mar 2014 at 7:24

[GoogleCodeExporter]

1. I may to do more testing with a situation like this then. Selecting a bigger 
package could be even more confusing, because the user could look through the 
repo and "queue" things and have a large list to process through later. In my 
situation, the package was small, so a 3rd item would immediately invoke item 
2. In this case, it probably won't.

2. Right.

3. At what point would the relaunch occur? Once msu --auto is ran? If so, isn't 
that technically what happens now with Munki1 when updates are found without 
user interaction?

I agree that Munki is not MAS, however this specific use case can be confusing. 
It took me quite a while to even find this particular issue. 

These issues don't really exist in munki1 - I guess it's y(our) job to figure 
out how big of an issue this really is.

Original comment by eriknico...@gmail.com on 23 Mar 2014 at 8:57

[GoogleCodeExporter]

"At what point would the relaunch occur? Once msu --auto is ran? If so, isn't 
that technically what happens now with Munki1 when updates are found without 
user interaction?"

Sometimes. Currently, managesoftwareupdate runs around once an hour in the 
background. If there are pending updates that need user interaction/approval, 
MSU.app is launched if it's been about a day since it last notified. IOW, 
MSU,app (by default) does not launch every time there are pending updates, or 
it would then potentially launch several times a day if a use kept deferring 
updates.

Original comment by gregnea...@mac.com on 24 Mar 2014 at 12:51

[GoogleCodeExporter]

"I agree that Munki is not MAS, however this specific use case can be 
confusing. It took me quite a while to even find this particular issue. 

These issues don't really exist in munki1 - I guess it's y(our) job to figure 
out how big of an issue this really is."

We can't ape the App Store behavior 100%.

In very early testing of MSC.app, clicking "Install" from the Software view 
_only_ added the item to the pending list. A user then needed to visit the 
Updates page and click "Install all" to actually initiate the installation. 
This maps better to how Munki actually operates, but was possibly confusing, 
since clicking "Install" on the Software page did not actually install.

I've also considered something closer to "Add to cart", and then a "Checkout" 
function. This again would better map to how Munki operates.

I think this will take some iteration to end up with a user interaction 
experience that is clear and consistent, since how Munki operates does not 
directly map to how the App Store operates.

The Apple Software Update model was a closer match.

Original comment by gregnea...@mac.com on 24 Mar 2014 at 12:56

[GoogleCodeExporter]

I agree. I've wondered about queue functionality as well. Most of the issues 
I've found are directly related to the "instant"-install.

I also take it you are working on this issue with the latest git revisions 
though [cache in MunkiItems.py]

Original comment by eriknico...@gmail.com on 25 Mar 2014 at 8:46

[GoogleCodeExporter]

Nope. Unrelated.

Original comment by gregnea...@mac.com on 25 Mar 2014 at 8:54

[GoogleCodeExporter]

In my testing tonight it seems as if you've fixed this issue. I still need to 
test larger packages though.

Original comment by eriknico...@gmail.com on 8 Apr 2014 at 12:40

[GoogleCodeExporter]

We're going to consider this fixed.

Original comment by gregnea...@mac.com on 16 Apr 2014 at 3:52

• Changed state: Fixed