Adding support for deploying ASDK with MSLab

[ohault]

Based on the key principle of simplicity and low profile hardware requirements of MSLab, the purpose of this issue is to be able to deploy ASDK systems using rapid lab deployment scripts

https://learn.microsoft.com/en-us/azure-stack/asdk/asdk-release-notes

[jaromirk]

Hey, yeah, but Azure Stack HUB is different beast and it deploys quite some infrastructure by itself. So it's beefy!

[ohault]

Hey, yeah, but Azure Stack HUB is different beast and it deploys quite some infrastructure by itself. So it's beefy!

Perhaps one of the most challenging beast according the the new sustainability commitment of Microsoft.

To help, it would be interesting to have a tool to use from a given deployed VM image able to generate the recipe to rebuild the same image based on their components (minimalist approach)

[jaromirk]

Well, I don't understand now. What do you want to achieve?

[jaromirk]

Maybe this is what you are looking for? https://github.com/mattmcspirit/azurestack

[ohault]

Maybe this is what you are looking for? https://github.com/mattmcspirit/azurestack
@mattmcspirit wonderful script is about to automate as much as possible, the post-deployment tasks for the Azure Stack Development Kit (ASDK). It has also to be updated to support the latest version of ASDK (
mattmcspirit/azurestack#141).

The goal here is about to being able to deploy ASDK using the key principle of simplicity and low profile hardware requirements of MSLab, but how ?

Yesterday, when I mentioned a tool to generate a recipe with ingredients (components), I was thinking to the following process :

• firstly assuming to start with an already deployed ASDK system meeting the ASDK minimal hardware requirements
• secondly, from that point, using this tool on each of the 13 infrastructure VMs of this ASDK system to generate the 13 recipes with their respectives ingredients
• and finality create a MSLab scenario for ASDK and components based on the 13 recipes and ingredients

Such a tool, could perhaps already exist, and would also be very useful to create new MSLab scenarios in general.

[mattmcspirit]

Hey Olivier - sorry for the delay here.

I'm not sure I fully understand the goal here either - so, you're saying that you start with an ASDK that's gone through the deployment, and you're ready to deploy additional services, marketplace images etc, and from there, you want to run something on the infra VMs that captures recipes, but what would you want to do with these recipes?

The ASDK itself is a collection of PowerShell DSC scripts that automates the deployment of all of the interdependent parts, so I'm not clear on what could be achieved when you capture these 13 individual pieces and what you could create from them.

[ohault]

Hi @mattmcspirit, the main goal here is to apply to ASDK infra the same exact principles of MSLab, aka simplicity and low-profile hardware requirements. In short, it will provide a way to deploy rapidly a minimalist ASDK system.

In this comment, I’m using “ASDK” as a difficult use case, but the concepts I would like to share hereunder are not specific to ASDK.

I agree 100% because there is an additional challenge for MSLab according to the interdependency between parts.
MSLab has already demonstrated very wonderful results being able to deploy many scenarios of systems in what I call a Desired State of a minimal Configuration (DSmC).
Several paths could exist to reach such a minimal state of a system. I can see it as an optimisation problem in terms of sustainability.

If we take the assumption that target systems are empty and not yet deployed, I can see two main approaches for deploying a system:
a) the classical forward setup (with pre and/or post optimizations at installation time to reduce setup requirements)
b) snapshot/image rollout (optimizations at pre-installation time if designed correctly)

About forward approach, I can list as examples:

• ASDK deployment procedure
• some initiatives like http://www.mritsurgeon.co.za/2020/01/nested-asdk-in-vm.html, with pre-optimization
  Once a system is successfully deployed, yet some optimizations could be performed trying to reduce the resources used by the system (e.g. using https://www.ntlite.com/ or others tools).

This approach can eventually reach a minimal state after several iterations using trials and errors, a lot of waste resources. At the end, it is not in a direct path to the optimum.

About snapshot/image rollout, I thing about DISM, container,... principles but at a components/parts level of a system (but with a semantic)
Here, the starting point is the spec of the desired system to be minimalised. It can be designed to be minimum by design and without iteration if deployed using image based component technics. It could avoid almost completely the peak and waste of resource consumptions during deployment in comparison with a forward setup approach (like when deploying the beast using the "ASDK deployment")

About the interdependency between parts, if we know the target system state in advance (like a static system), I guess these interdependencies could be determined during either design-time, during deployment and/or post-deployment, perhaps using some knowledge of an already deployed system in the same state or very close.

I can see that this approach is already partially being used by Containers, but why to be limited to Containers, as it could also be used with VMs too(*). It could also open a way to containerization approach.

Conclusion:
Before considering this approach towards more sustainability, ADSK as a whole is probably too complex at once, but it is also a very great target with a huge potential of improvement. As ASDK is composed of 13 infra VMs, the good news is that some experiments could be performed one VM at a time.

I would find particularly exciting to compare a benchmarked in terms of resources used during deployment time and once deployed (idle state without user loads) between an ASDL infra VM deployed using the normal procedure and the “same” VM using a minimalist approach.

(*) Sideload Apps with DISM or deploying offline an app/NT service to a given known offline VM using HCS (injecting a snapshot/layer with the required files) + adding Windows Registry required entries.

[ohault]

In the while, an intermediary solution could consist of deploying the 13 ADSK infra VMs on top of a Azure Stack HCI cluster. In short, by replacing the current SafeOS with a Azure Stack HCI cluster. This will also provide a clean way to split the ADSK hardware requirements on several nodes (with less RAM).