-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
platforms: investigate support for Azure Stack Hub (azurestack) #476
Comments
Thanks for the report. A bunch of things to unpack here:
|
As far as I know we haven't done any investigation of Azure Stack; we have #148 which is for the "main" Azure but we should probably break out a separate tracker for Azure Stack. |
@cfBrianMiller per https://docs.microsoft.com/en-us/azure-stack/operator/azure-stack-linux?view=azs-2002#step-2-reference-cloud-inittxt-during-the-linux-vm-deployment it would appear that this is a question of how you are deploying the image I tested the 4.3 and 4.5 image Azure proper and it worked. To @lucab:
Per https://docs.microsoft.com/en-us/azure/virtual-machines/custom-data:
I concur with @lucab @cfBrianMiller if you have indeed deployed the VM with custom data properly, we would need at the very least:
On Azure proper I see the Virtual CD-ROM come up in the console logs:
If there is no VirtualCD showing up then question for Azure Stack is how do we access it and, more importantly where is it documented? I did a deep dive into the documentation and the WALinuxAgent code and from what I was able to glean the device should be there. |
From the Azure Documentation, an image prepared for Azure proper should work. Microsoft, in an email thread, had indicated that Azure proper images should work on Azure Stack: |
Over at https://bugzilla.redhat.com/attachment.cgi?id=1696551 a console log was provided that gave a whole lot more information:
These error messages are NOT found on Azure proper. Based on the UDF source [1] the kernel is NOT locating the UDF VRS (Volume Recognition Sequence) and so the mount is returning EINVAL. In other words, the kernel is saying that Ignition asked for a UDF mount but whatever is on There are three potential cases:
Can you attach a copy of the UDF? Looking at how WALinuxAgent does the mount [3], it does a blind mount without specifying the filesystem; Ignition is more precise [4]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git/tree/fs/udf/super.c#n1970 |
We have confirmation from Microsoft that the UDF volume is, in fact, not a UDF volume: it's a generic iso9660. I have draft fix proposed in Ignition that should allow Ignition to work on either Azure or Azure Stack. |
Any chance they'll fix the documentation now? |
We can ask. |
A complete different issue in Afterburn has come up:
And then:
And ending with:
Both the Ignition issue and now Afterburn raises two distinct differences that raise the questions of what other differences exist. In my opinion, we should consider whether Azure and AzureStack should be considered the same. |
@darkmuggle - maybe a new issue for the afterburn bits? or if you want to go wide - an issue to discuss our approach to Azure vs AzureStack |
The problem child is definitely this line:
Azure stack has different API versions, for compute it is 2017-12-01 |
Things we have discovered so far on Azure Stack:
Things still to discover:
|
Should coreos/ignition#1007 be reverted for the time being? |
I'd say so, yes. |
Is there any harm in leaving the code? We know the code works. And having this code will make the enablement easier. Conceivably, enabling AzureStack as a separate platform from the Ignition side would look something akin to:
The difficulties with AzureStack in Afterburn may be handled differently. Also, the code now checks to see if the volume is either a UDF or ISO9660 before blindly attempting to mount it as a UDF volume. |
If we release the code and later roll it back, we'll be making shipped code stricter, which in principle could break someone. Why not just go ahead and add the separate platform ID to Ignition now? It should be straightforward to add a wrapper which enables ISO9660 only on Azure Stack. |
This moves the iso9660 support out of Azure's provider and introduces a new provider for AzureStack. Per [1], we found that AzureStack should be treated as its own platform. The Azure provider now is configurable for the filesystem types. [1] coreos/fedora-coreos-tracker#476 Signed-off-by: Ben Howard <ben.howard@redhat.com>
AzureStack is now a distinct platform for both Ignition and COSA. The word from back-channels is that might have what we need towards August/September on the Afterburn side. |
"Azure Stack" is a whole product family, which spans a few verticals. My understanding is that here we are targeting "Azure Stack Hub" only for its computing on-demand capabilities. Re-titled accordingly. |
This is done now in coreos/afterburn#561 which is part of the v5.0.0 release. |
Hello,
When trying to boot this image, it fails with the following boot diagnostics.
I am deploying to azure stack with this custom data string, (with a valid URL)
eyJpZ25pdGlvbiI6eyJ2ZXJzaW9uIjoiMi4yLjAiLCJjb25maWciOnsicmVwbGFjZSI6eyJzb3VyY2UiOiI8dmFsaWRfdXJsPiJ9fX19Cg==
I am unable to exec into the box to determine the exact error however this is what Microsoft support believes is the issue after troubleshooting CoreOS issues.
I am capable of testing fixes to this problem against an up to date azure stack.
Thank you.
The text was updated successfully, but these errors were encountered: