Surface nubis account creation input values somehow

[gene1wood]

Is there a place in a nubis account that the inputs used to create the nubis account can be surfaced so they can be read?

The use case that I have is

How can I programatically determine the nubis version of a given nubis AWS account?

The version is made available in a DNS TXT record, but to fetch that record you need to know the vars.account_name for that account.

[tinnightcap]

@gene1wood You can get at this information from any host running mig by executing this command:

dig +noall +answer +short txt version.nubis.$(nubis-metadata NUBIS_ACCOUNT).$(nubis-metadata NUBIS_DOMAIN)

Will this work for your needs?

[tinnightcap]

FWIW, nubis-metadata QUERY currently supports the following QUERIES (showing values from my dev account):

• NUBIS_PROJECT=jumphost
• NUBIS_ARENA=core
• NUBIS_ACCOUNT=nubis-jd
• NUBIS_DOMAIN=nubis.allizom.org
• NUBIS_JUMPHOST_EIP=eipalloc-7d55aa41
• NUBIS_SUDO_GROUPS="nubis_global_admins"
• NUBIS_USER_GROUPS="nubis_users"

In the release that is currently building and will be deployed to the accounts over the next few days I added the following QUERIES (again showing values from my dev account):

• INSTANCE_IDENTITY_PRIVATEIP="172.16.39.177"
• INSTANCE_IDENTITY_INSTANCEID="i-05b04f6da23e257be"
• INSTANCE_IDENTITY_INSTANCETYPE="t2.nano"
• INSTANCE_IDENTITY_AVAILABILITYZONE="us-west-2b"
• INSTANCE_IDENTITY_ACCOUNTID="095732026120"
• INSTANCE_IDENTITY_ARCHITECTURE="x86_64"
• INSTANCE_IDENTITY_IMAGEID="ami-371c7a4f"
• INSTANCE_IDENTITY_PENDINGTIME="2018-07-18T20:02:51Z"
• INSTANCE_IDENTITY_REGION="us-west-2"

I understood your team was asking for the ami_id to be output somewhere and this is why I added the identity document information.

Also. The current metadata is in bash format located here:
/var/cache/nubis/userdata

The new information, in bash format, will be located here:
/var/cache/nubis/instance-identity
and in json format here:
/var/cache/nubis/instance-identity.json

[tinnightcap]

ref: nubisproject/nubis-base#818
ref: https://github.com/mozilla-itcloud/maintenance-project/issues/34

[tinnightcap]

Additionally you can determine what version any particular host was built against thusly:
cat /etc/nubis-$(nubis-metadata NUBIS_PROJECT)-release

Which gives you something like:
"nubis-jumphost v2.2.0 ee483d3a-d237-f4e2-2de5-67434b639df5"

So for just the version:
cat /etc/nubis-$(nubis-metadata NUBIS_PROJECT)-release | cut -d' ' -f 2

Would giive you:
v2.2.0

in this case

[gene1wood]

@tinnightcap That's awesome, I didn't know about that tool on the systems. Is there any way to read this kind of information from the AWS level (as opposed to from within an ec2 instance)? The way that one used to be able to determine the version of an installed nubis by querying for the security group. Ed pointed me to the DNS record in the nubis route53 DNS zone for each account, but we couldn't figure out a way to determine the account_name (to be able to query the DNS zone) without fetching the account_name from service now.

If not, mig querying the information on the system like you've described should work.

[tinnightcap]

I think @gozer idea in #443 is what was discussed on slack. I will close this issue in favor of that one.

[gozer]

@gene1wood Just so you know, I've thought about my suggestion and reviewed the context I was missing, and turns out my idea wasn't actually simple or practical in terms of implementation...

So, I think we'll go back to the oriringal train of thought.

[gene1wood]

Ok.

A DNS CNAME between version.nubis.<account-id>.nubis.allizom.org and version.nubis.<account-name>.nubis.allizom.org would totally work since the only thing that makes version.nubis.<account-name>.nubis.allizom.org hard to use is figuring out how to determine the account-name

[tinnightcap]

The issue is that AWS is not authoritative for nubis.allizom.org, infoblocs is. So we have no way to programmatically create that record. We have as of yet been unable to create an integration with infoblocs for this sort of creation. If my previous suggestions do not work for you I can create a ticket in out team org to get the infoblocs integration on the radar. I spoke to rtucker some time ago and he thought at that time that we should be able to get api access once infoblocs went live. I will loop back with him now that is is and see what it might take to get that going.

[gene1wood]

Another option would be to have infoblocs delegate the entire nubis.allizom.org zone to a route53 zone in an AWS account that you control, then have your provisioning code create the records in route53

But ya, if DNS isn't a good option because of the infoblocs aspect, let's stick with the file on the systems and I'll tell @tristanweir to use mig to get the version info

[mgreensmith]

I'd prefer not to scope creep this into writing an API integration with infoblox, if possible.

If the metadata files that @tinnightcap decribed meet your needs, I'd love it if mig could scrape those files.

[gene1wood]

No no, sorry I didn't mean API integration with infoblocs, I mean a DNS delegation, an SOA record and a set of 4 NS records. You'd add these to infoblocs which would do a DNS delegation of the zone to route53. This would be an entry that would added to infoblocs, manually, one time.