A More Dynamic Imagr

131 views
Skip to first unread message

Nate

unread,
Jun 3, 2015, 5:24:21 PM6/3/15
to imag...@googlegroups.com
I was talking with some cohorts and we discussed Imagr as well as a feature that could be extremely useful for the project.

One thing about Imagr that makes it super useful is that all the workflows are dynamic. You feed it a config file and it runs the workflow as per the config file.

What if this functionality was taken a little further? Why not download the code necessary to run the steps as well as the specific settings to use in the step.

Example:
  • Imagr pulls down the config
  • partitionDisk step is in config
  • Imagr pulls down the module (code) for partitionDisk
  • Imagr runs the partitionDisk code using the data in the config
The Imagr.app that lives on the NBI would have the bare minimum amount of code to download the workflow modules/configs from the server and execute them. It would essentially be a stub app that sets up the netboot environment with only the steps necessary to image/bootstrap a machine.

This would provide a few very useful things:
  1. Less NBI builds. No need to rebuild the .nbi to change Imagr workflow steps and functionality.
  2. Better/faster testing. It would be possible to test new workflow modules with quick rollback if something doesn't work as expected. If you had 5 locations, you could test a new module at one location, confirm it works well and then roll it out to additional locations.
  3. More flexible. Just like with dynamic workflows which are configured dynamically, the code itself would only be pulled down if appropriate for the given Netboot set/location.

To facilitate this, you could split imagr into two parts:

Imagr Core (the .app)
Image Standard Modules (all the 'supported' workflow modules)

The only things that would need to be supported by the project would be Imagr Core and Imagr Standard Modules. If someone wanted to write a workflow module that queries AD and does all types of other crazy things, then they could feel free to provide that to the community and support it outside of the main Imagr project. This would help keep Imagr focused on doing the standard functionality well...Imaging and bootstrapping machines).

I think this may be slightly painful to implement at first, but once done, it would make doing further improvements easier and faster.

Nate

Graham Gilbert

unread,
Jun 4, 2015, 6:50:25 AM6/4/15
to imag...@googlegroups.com
I've given this some thought overnight and I'm going to stick with my gut reaction: I really dislike this approach.

My reasoning:

- I've seen what has happened with AutoPkg and the confusion on who supports what.
- I've been toying with allowing scripts to be pulled from a URL (a trivial change, one that I might work on during my next flight if the wife falls asleep!) and to take it further, I'm thinking of arbitrary input variables (either delivered to the script as positional arguments or environment variables - happy to take suggestions or reasons for either). I think this would alleviate most of the need for external modules and have the bonus of allowing languages other than python to be used.
- Imagr is designed to be super simple - this adds more complexity on the server end
- How is UI handled? This would require a significant rewrite to not use interface builder (unless I'm missing something).

Graham Gilbert




--
You received this message because you are subscribed to the Google Groups "imagr-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to imagr-dev+...@googlegroups.com.
To post to this group, send email to imag...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/imagr-dev/CAK6xLgJS%2BbBH21iae-iiVg7F5X2qsDM%2B%2B%2BFuwc3-rWy7dPuodA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Nate

unread,
Jun 4, 2015, 11:15:44 AM6/4/15
to imag...@googlegroups.com
Totally understandable. I thought I'd throw the idea out there and see if it was interesting enough to pursue. 

Grabbing scripts off the webserver would be helpful. So it would be core functionality baked into the NBI, then all other functionality you can add via scripts which are downloaded. I think that is a good compromise ;)

Nate

To view this discussion on the web visit https://groups.google.com/d/msgid/imagr-dev/66840460D6116442.7D016275-9DE3-4F78-BB41-C889B544FE1E%40mail.outlook.com.

Erik Gomez

unread,
Jun 4, 2015, 12:41:54 PM6/4/15
to imag...@googlegroups.com
I have a script currently in my workflow that curls a package that Imagr doesn't natively support and it works well. If this was added natively it would be great. 

Sent from my iPhone

Graham Gilbert

unread,
Jun 4, 2015, 12:51:11 PM6/4/15
to imag...@googlegroups.com
A package that imagr doesn't support? It should support everything. If it's a bundle package, wrap it in a dmg. 

Graham Gilbert




Erik Gomez

unread,
Jun 4, 2015, 12:54:04 PM6/4/15
to imag...@googlegroups.com
Wasn't clear. It's a package (application) that needs to run in the imaging context for my technicians to select the proper location the device belongs in. 

Graham Gilbert

unread,
Jun 4, 2015, 1:18:54 PM6/4/15
to imag...@googlegroups.com
Ah, yes. That's unlikely to ever be built in. External scripts would probably be easiest here. 

I'm still looking for opinions on whether to pass input variables to scripts via environment variables or positional arguments. Either are as easy as one another to out into imagr, so it comes down to using them with scripts. I get the feeling that environment variables would be easier and would allow for default / optional values as well. 

Graham Gilbert




Erik Gomez

unread,
Jun 4, 2015, 1:29:00 PM6/4/15
to imag...@googlegroups.com
I would say environmental variables only because there are some defaults and (hopefully) people are used to them. 

It would be interesting to see what scripts would be written for positional arguments. I can't think off the top of my head what I could/would use them for. 

Sent from my iPhone

Vaughn Miller

unread,
Jun 4, 2015, 1:50:18 PM6/4/15
to imag...@googlegroups.com
I like the idea of being able to download external scripts, should make it easier to maintain larger scripts vs having to embed them in the config plist.

My gut says environment variables, though I'm not sure I can articulate why...

To view this discussion on the web visit https://groups.google.com/d/msgid/imagr-dev/66840460D6116442.0D55C5AB-8941-4302-8FB5-41A6B7752650%40mail.outlook.com.

Ben Toms

unread,
Jun 4, 2015, 2:00:52 PM6/4/15
to imag...@googlegroups.com
External script support would be nice. So another +1 on that. :)

Regards,

Ben. 

Tim Sutton

unread,
Jun 4, 2015, 2:37:48 PM6/4/15
to imag...@googlegroups.com
Another vote for environment variables over positional args :)

Tim
> https://groups.google.com/d/msgid/imagr-dev/0C6C684E-21FD-4F37-8181-0BA8D8B75465%40btopenworld.com.
Reply all
Reply to author
Forward
0 new messages