Closed ashcrow closed 5 years ago
Just going to dump some info from perusing the documentation.
add support in coreos-assembler to buildextend images for this platform
Looks like qcow2 is supported and recommended, so this should be more or less the same thing as cosa buildextend-openstack
.
check if we have some metadata endpoint (or hypervisor back-channel) available for Ignition to use
Looks like a vanilla user-data endpoint. From the docs:
You can use user data of an ECS instance to customize its startup behavior and to pass data into the instance. ... For Linux, run
curl http://100.100.100.200/latest/user-data
to view the user data.
add support for ore to upload images
Seems to follow the AWS model of uploading the image into their storage service, then calling to the compute service to import from there (docs).
add support for afterburn if needed
SSH keys are supported. The docs don't say at what endpoint they're available, but cloud-init has:
class DataSourceAliYun(EC2.DataSourceEc2):
...
metadata_urls = ['http://100.100.100.200']
...
def get_hostname(self, fqdn=False, resolve_ip=False, metadata_only=False):
return self.metadata.get('hostname', 'localhost.localdomain')
def get_public_ssh_keys(self):
return parse_public_keys(self.metadata.get('public-keys', {}))
Do we need to discuss this in a community meeting re. whether we want to support it in FCOS? RHCOS definitely will; it would be good for FCOS to lead.
Do we need to discuss this in a community meeting re. whether we want to support it in FCOS?
I don't think so. Maybe we can FYI everyone on it but IMO the more platforms the better.
Do we need to discuss this in a community meeting re. whether we want to support it in FCOS?
I don't think so. Maybe we can FYI everyone on it but IMO the more platforms the better.
That's my thought as well. Unless there is a reason to not support it I think supporting it in FCOS would be great!
For Afterburn purposes, the metadata endpoint and content is documented at https://www.alibabacloud.com/help/doc-detail/49122.htm.
For reference, terraform supports this cloud platform under the provider name alicloud
: https://www.terraform.io/docs/providers/alicloud/index.html. I think we can align ourselves to that as the platform label.
@lucab: We normally avoid having noise like "cloud" in our platform names, and we don't actually need to align with Terraform.
@bgilbert Would alibaba
make more sense?
Maybe. I guess the thing that seems odd is abbreviating Alibaba but also adding in cloud
. If it's commonly called Alicloud and people will recognize that name, then that's likely the name we should use. But it's not clear to me how common that usage is?
It's not as simple as just naming the platform after the vendor, since we're not fully consistent here; we have digitalocean
and packet
but also aws
and gcp
.
@bgilbert Got it. I did some searching to see if I could find a proper short name for Alibaba's Cloud but nothing came up. Most seem to call it "Alibaba Cloud".
FWIW, cloud-init uses AliYun
. Not that we need to align there too, but (1) the initial implementation (and hence naming) was done by someone who works there it seems, and (2) if there's ever another "platform" on Alibaba, cloud-init would likely have to add a new ID too.
FWIW their go sdk is Alibaba Cloud SDK for Go
with aliyun
being the org.
From Wikipedia and from poking around a bit on their website, I think the situation is: Ālǐyún is the pinyin for the Chinese name, Ali Cloud is the literal translation, and Alibaba Cloud is the English branding.
The official CLI is named aliyun
.
aliyun
:+1:
aliyun
http://100.100.100.200/latest/meta-data/
reserve and document a platform ID for this environment
Is there a current location we keep track of the platformid
's?
@ashcrow I have this currently in flight https://github.com/coreos/fedora-coreos-docs/pull/11.
@ashcrow I have this currently in flight coreos/fedora-coreos-docs#11.
Perfect!!
Misc self-notes from my exploration of the API so far:
instance/instance-type
)OK, we got all the prereqs in place. If we want to get FCOS there, we need to work out the legal stuff to get a Fedora account there.
We could also just publish the artifacts for now so at least folks can upload to their own accounts.
We could also just publish the artifacts for now so at least folks can upload to their own accounts.
That would be a good starting point for FCOS artifacts.
Just to recap, is the final goal of this ticket to "upload artifacts to FCOS bucket" or to "upload artifacts to Alibaba cloud"? (Is that decided yet?)
In both cases, should we add one last task in here to write a "Booting on Alibaba Cloud" doc?
This card is for the tools in place for the OS teams to utilize. In terms of uploading to $LOCATION
, those would be other issues/cards IMHO.
In order to properly support this, we should:
/cc @imcleod