[LAD] CoreOS support

[colrack]

Hi all

I successfully installed LinuxAzureDiagnostic from the new Portal and from azurecli on ubuntu.
When installed I can see that python scripts are licensed under Apache 2.0 and that extension version is 2.0.92.
However I can't find a place where the source is public accessible.
Can anyone point me to the code? I googled a lot but I couldn't find anything.
Is it possible to publish the extension source code here?

Also, I am a CoreOS user and I would like to have the ability to enable the extension under this os.

Thanks

[karataliu]

@colrack
The diagnostic extension code is now available here:
https://github.com/Azure/azure-linux-extensions/tree/master/Diagnostic

[colrack]

@karataliu Thank you
Any chance to get this working on CoreOS?
They currently ship (WALinuxAgent-2.0.14) and the installation of LinuxAzureDiagnostic is failing.
CoreOS is a Azure-Endorsed Distributions (https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-endorsed-distributions/).

I got the extension working with a dockerize waagent image based on ubuntu; however this is a workaround since I have to:

1. boot the machine
2. stop systemd waagent service
3. wait for docker daemon to start
4. pull my custom image
5. start the container with embedded waagent + LinuxAzureDiagnostic

/cc @crawford
Thanks!

[karataliu]

Thanks for the information and the interesting experiment with docker.

@hosungsmsft Do you have any idea whether the CoreOS can be supported? Thanks.

[sepiroth887]

Bump. We would like this as well here @yammer :)

[crawford]

CoreOS does not ship Python. This script will need to be wrapped up into an ACI along with the appropriate version of Python, and the actual extension will then need to run sudo rkt run azure.com:LinuxAzureDiagnostic.aci (it might additionally need --stage1-name=coreos.com/rkt/stage1-fly to allow it full access to the system). It should be pretty straight forward (famous last words).

[sepiroth887]

Afaik the waagent on coreos ships with a static linked python version. It's currently broken for script extensions though as it tries to use ssl without libssl.

However as long as the extension can run in RKT via ACI that would be fantastic :)

[colrack]

@sepiroth887 @crawford thanks for the interest.

Let me point out the importance of this.
Last year VMSS (Virtual Machine Scale Set) were introduced see blog and docs. The new ACS (Azure Container Service) is based on VMSS and it is basically swarm or mesos running on top of ubuntu (no choice for kubernetes as of now :( ).
With VMSS you can manually scale in and out a group of vm in the same scale set. However, if you want to scale automatically based on metrics you have to configure alert rules and use this extension (you can of course rely on other tools and services, but waagent + linuxdiag would be the one azure integrated/supported).

Last year I studied how this diag extension works because I wanted it to work on coreos and I even submitted this PR. I spent a lot of time because the source was not easily to find, no docs available and I even had to do some reverse engineering. Furthermore only MS partners are allowed to develop and publish extensions so I couldn't do much more than open this issue.

My solution was the one reported above: I replace the shipped waagent and I have a fleet unit with my image. Today I share the docker image I used at that time, stable waagent was at 2.0.15 and diag extension at 2.2. It is here in coreoswaagentdiag. It still works, automatic VMSS scale in/out just works. I will make some tests with updated stuff and report updates.

Unfortunately it is not only about a python script, that would be easier for sure. There is also some stuff like omi and scx that I grabbed after a successful installation on ubuntu. There is a lot of shitty binary stuff that is downloaded during the installation of the extension (MS guys cmon, what's that?! Where are sources?! Please clarify how things work and provide docs!)

This is not an optimal solution, it just works but I not recommend anyone to use it other than testing.

I look forward to see official support on coreos images.

Thanks!

[boumenot]

cc: @hosungsmsft

[turowicz]

+1

I can see CPU, Network and Disk diagnostics, but nothing for Memory. Having read this issue I suspect the readings I get aren't accurate.

[crawford]

CoreOS is working with Microsoft to get this operational. We don't have anything to announce yet, but we are getting closer. The plan is to ship the waagent and all of its dependencies in a rkt container.

[fadenb]

@crawford cool. Will this include dependencies required by the mdsd binary that will be downloaded and executed by the agent? (required to use autoscaling with Azure VMSS)

[turowicz]

It's been almost 5 months now, anything new?

[fadenb]

@crawford: Any news on this issue?

[jasonzio]

Full source for the mdsd binary has been added to this repo, along with a Dockerfile that builds the environment needed to build it. All of the dependencies are, themselves, open source (including OMI, SCX, fluentd, CPPREST, and the Azure Storage SDK); however, the mdsd build script does not build those components from source.

We'd welcome a PR for this repo with any changes LAD needs to run within CoreOS.

[HighwayofLife]

6 months since the last update, is there any news on CoreOS support? Thanks!

[crawford]

It looks like extensions will largely not work on Container Linux. This is due to the fact that every extension seems to maintained separately and hard-codes which distros are supported. Many of these extensions additionally assume they will have access to a package manager and have absolute control over the machine. This notion is at odds with the intended use case for Container Linux, which is intended to be immutable and driven by containers.

On a personal note, I'd like to see the Azure agent removed from Container Linux (there are some technical hurdles to overcome before this can be done) and the environment between cloud providers leveled. It shouldn't matter where you run Container Linux, administration should always be the same.

[vrdmr]

Closing this issue due to inactivity.