providers: add an AzureStack stub

[darkmuggle]

Stub out AzureStack wire-framing in anticipation of working on AzureStack in the near future. This stub out should allow exploration on the AzureStack platform.

As a platform AzureStack does not provide either a meta-data service nor does it provide a useful OVF XML the utility of Afterburn is a pretty much a noop for AzureStack.

Signed-off-by: Ben Howard ben.howard@redhat.com

[darkmuggle]

Here is an OVF-XML file from AzureStack. You'll notice that today it treats Linux VM's as Windows.

<?xml version="1.0" encoding="utf-8"?>
<Environment xmlns="http://schemas.dmtf.org/ovf/environment/1" xmlns:oe="http://schemas.dmtf.org/ovf/environment/1" xmlns:wa="http://schemas.microsoft.com/windowsazure" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <wa:ProvisioningSection><wa:Version>1.0</wa:Version><WindowsProvisioningConfigurationSet xmlns="http://schemas.microsoft.com/windowsazure" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><ConfigurationSetType>WindowsProvisioningConfiguration</ConfigurationSetType><ComputerName>prf000000</ComputerName><AdminPassword>!!123abc</AdminPassword><EnableAutomaticUpdates>true</EnableAutomaticUpdates><AdminUsername>tenantuser</AdminUsername></WindowsProvisioningConfigurationSet></wa:ProvisioningSection>

  <wa:PlatformSettingsSection><wa:Version>1.0</wa:Version><PlatformSettings xmlns="http://schemas.microsoft.com/windowsazure" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><KmsServerHostname i:nil="true" /><ProvisionGuestAgent>true</ProvisionGuestAgent><GuestAgentPackageName>WindowsGuestAgent.zip</GuestAgentPackageName><UseAVMA>true</UseAVMA></PlatformSettings></wa:PlatformSettingsSection>
</Environment>

The ISO also includes an unattend.xml:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="generalize">
[REDACTED]
         <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <TimeZone>UTC</TimeZone>
            <ComputerName>prf000000</ComputerName>
        </component>
[REDACTED]

I would need word from Microsoft or API documentation, but the example ovf-env.xml and unattend.xml include references to the <ComputerName> which could be used. Regardless the purpose of the stub is simple: provide the wire-framing.

[darkmuggle]

FWIW, I'm am happy to leave this a WIP if the Afterburn overseers would prefer a "complete" provider pending information from MS.

[ashcrow]

@darkmuggle thanks for starting this! You noted this is kind of a noop and, that makes sense. It's primarily scaffolding and boilerplate to match the trait. I'm curious what folks think about these ideas (which shouldn't block this PR! -- just thinking out loud):

• having a literal noop MetadataProvider for reuse in these types of instances (avoiding copy/paste implementations with the same boilerplate)?
• moving these noop function implementations into the trait and move to overriding default implementations?

/cc @lucab

[darkmuggle]

In regards to the noop provider, https://github.com/darkmuggle/afterburn/commit/6369339b3fd7ebe44e1bbeb8e30f1c45fdf7b6a5 is a novice take on the idea. And using traits https://github.com/darkmuggle/afterburn/commit/8f77a41ff2337ae1d99a94e0251d9d3d103fe352

[lucab]

@ashcrow @darkmuggle yes we can add default implementation for trait methods, that would help de-duplicating the same empty logic in a bunch of places. I'm not very convinced about a noop platform though.

[lucab]

I would need word from Microsoft or API documentation, but the example ovf-env.xml and unattend.xml include references to the which could be used.

Just for clarity, does the ComputerName in there "prf000000" match the name of the instance?

[darkmuggle]

I would need word from Microsoft or API documentation, but the example ovf-env.xml and unattend.xml include references to the which could be used.

Just for clarity, does the ComputerName in there "prf000000" match the name of the instance?

TBH, I think that is the case, but I'm not sure. The snippets came via Microsoft. In fact, when I did a deep dive on the XML, I have serious questions about whether it was provisioned as Windows or Linux virtual machine; the ISO contains windows PowerShell commandlets.

@ashcrow @darkmuggle yes we can add default implementation for trait methods, that would help de-duplicating the same empty logic in a bunch of places. I'm not very convinced about a noop platform though.

Yeah, I've not convinced myself. I was learning me some Rust as my Hack-day, and thought that I would do something potentially useful; hence this PR. After filing the PR, I realized that noop is kind of pointless given that in CoreOS SystemD units are used.

I'll update the PR to:

• use traits
• drop the noop provider

[lucab]

@darkmuggle did you close this by mistake or in preparation for a further step?

[darkmuggle]

I was going to rebase and submit as two sperate PRs:

• Metadata trait refactor
• follow up stub

The diff was pretty ugly, IMHO.