=== gschanuel6 is now known as gschanuel
[17:37] <blackboxsw> falcojr: I think I've finally addressed all the complexities of the user/groups schema. Too many options please recheck docs I rewrote for typo/grammar misses etc.
[17:52] <minimal> blackboxsw: side-equestion - do the schemas in general take into account a requirement for some values to be quoted (so they *are* treated as strings, not numbers)?
[17:52] <minimal> thinking of values like dates where (from memory) they are treated as numeric equations (i.e. "-" as minus) unless quoted
[18:02] <blackboxsw> minimal: the JSON schema looks at the YAML type as it is interpreted. For dates specifically, we'd have to declare something like {"type": "string" "format": "date"} for our schema to allow without error.  Ultimately when YAML loads the date, it can accept things like `date: 2022-04-15` and yaml.safe_load turns it into the python dict `{"date": datetime.date(2032,  4, 15)}`
[18:03] <blackboxsw> it may have been an older version of YAML that bungled the date formatted strings 
[18:04] <blackboxsw> but to answer your underlying question, JSON schema validation is on the content which has been interpreted by YAML during load I believe
[18:07] <minimal> blackboxsw: I'm thinking back to a MR I had merged maybe 12-18 months ago to fix some of the user-data examples including things like expiry date as they didn't work without quotes - so you think the quotes are no longer needed?
[18:10] <minimal> ah, here's the MR I'm thinking of: https://github.com/canonical/cloud-init/pull/618
[18:10] <ubottu> Pull 618 in canonical/cloud-init "Correct documentation and testcase data for some user-data YAML" [Merged]
[18:10] <blackboxsw> minimal: and examples that have landed on every cloudinit/config/cc_* module are automatically run through validation by CI in our unittests per  https://github.com/canonical/cloud-init/blob/main/tests/unittests/config/test_schema.py#L401
[18:15] <blackboxsw> minimal: ahh right, so I just made the schema in this case specifically require a type: string https://github.com/canonical/cloud-init/pull/1379/files#diff-c18cfd88ec0bd5f1077576fee00a0b2e87cf0b30aa547ad1eaacfd5742e4a757R27
[18:15] <ubottu> Pull 1379 in canonical/cloud-init "Schema users" [Open]
[18:15] <blackboxsw> but hrm, maybe worth properly supporting a date type. Reviews comments welcome on my open PR here.
[18:16] <blackboxsw> minimal: though I might want to pull in that functionality in a separate PR as this one has gotten a lot bigger than I'd hoped
[18:16] <minimal> blackboxsw: no issue with it defining string, was just wanting to clarify if single quotes are therefore still needed in the YAML for it to be treated as a string
[18:16] <blackboxsw> so at the moment, schema will tell you you have to have a string
[18:18] <minimal> I guess my question is regarding implicit versus explicit strings in YAML
[18:19] <minimal> as I thought the underlying problem was the Python YAML lib used could misinterpret implicit strings like dates
[18:21] <falcojr> minimal: I think that's just a yaml problem more broadly
[18:22] <minimal> in other words will "expiredate: 2022-04-16" pass both the schema validation and be treated by the code as a date, or will it pass the schema validation but be treated by the code as a number, in which case the schema needs to enforce "expiredate: '2022-04-16'" instead
[18:23] <blackboxsw> minimal: sorry just dropped the laptop trying to paste that example.  Schema will warn about non string I. That case 
[18:24] <minimal> blackboxsw: warn about non-string? or non-explicit-string?
[18:24] <blackboxsw> minimal https://paste.ubuntu.com/p/WgscmSjkxg/
[18:25] <blackboxsw> yet quoted     `expiredate: "2024-10-04"  ` will pass without warnings
[18:26] <minimal> for that paste, is login for a Launchpad acct?
[18:26] <blackboxsw> bah
[18:26] <blackboxsw> pasting elsewhere
[18:27] <blackboxsw> minimal: 2nd try https://paste.opendev.org/show/bgROMPxKtqtahai5C6w0/
=== holman is now known as holmanb
[18:28] <minimal> ok, that seems to answer my question. Thanks
[18:29] <blackboxsw> I do wonder if JSON schema can handle date discrete date types anyway, but as falcojr mentioned it's probably a JSON schema/YAML general prob to sort.
[18:29] <blackboxsw> I forsee that I'll spend some googling time today :)
[18:30] <holmanb> started in on ephemeraldhcp for v6 and one bugfix led to another and I guess I just refactored the networking code a bit: https://github.com/canonical/cloud-init/pull/1383
[18:30] <ubottu> Pull 1383 in canonical/cloud-init "Network functions refactor and bugfixes" [Open]
[18:30] <minimal> yeah YAML is a mess with its "magic detection" of types - remember the issue I'd raised again 18months or so ago about MAC address treatment lol
[18:30] <blackboxsw> heh true. I had forgotten about that.
[18:30] <blackboxsw> -> relocating for lunch
[18:31] <blackboxsw> nice fast work holmanb 
[18:31] <minimal> blackboxsw: if you ever doing any future work on expiredate (and/or "inactive"), there's no testing in place for those (validating the numbers put into /etc/shadow fields) and I've never found the time to have a go at it myself
[18:32] <holmanb> @blackboxsw: don't get too excited, that's only bugfixes + refactorization ;) - no ephemeral work in that 
[18:37] <holmanb> blackboxsw: I was just like "alright let's make is_ipv6_addr not so awful real quick", and after fixing it suddenly 125 tests were failing :/
[19:53] <blackboxsw> Thanks falcojr https://github.com/canonical/cloud-init/pull/1379 landed.
[19:53] <ubottu> Pull 1379 in canonical/cloud-init "Schema users" [Merged]
[19:53] <falcojr> nice!
[19:53] <blackboxsw> knocked out a number of JIRA tickets with that given the 'enum' doc handling and 'hidden' key thank!
[19:53] <blackboxsw> thank you for the correct assessment of that schema crud in review
[19:56] <blackboxsw> falcojr: one minor PR for migrating legacy schema coming 
[19:56] <blackboxsw> $ fgrep -r "schema =" cloudinit/config/cc_*
[19:56] <blackboxsw> cloudinit/config/cc_ntp.py:schema = {
[20:01] <holmanb> @falcojr: Thanks for the review, just landed https://github.com/canonical/cloud-init/pull/1383 (tests passed after the spelling nit commit)
[20:47] <blackboxsw> minor followup to migrate ntp legacy schema https://github.com/canonical/cloud-init/pull/1384
[20:48] <ubottu> Pull 1384 in canonical/cloud-init "cc_ntp: migrated legacy schema to cloud-init-schema.json" [Open]
[20:48] <blackboxsw> ok hitting James' review now.
[21:47] <blackboxsw> falcojr: cc_* meta looks good I think minimally we want to filter docs out of `cloud-init devel schema --docs all` for those modules without JSON schema.
[21:47] <blackboxsw> otherwise big +1 on cleanup\
[21:47] <falcojr> TIL 'cloud-init devel schema --docs all' :D
[21:48] <falcojr> never realized you could get doc info on the cli
[21:48] <holmanb> :)
[21:48] <blackboxsw> yeah developer docs
[21:48] <blackboxsw> yeah it's been my saving grace while going through and reviewing and schema changes
[21:48] <blackboxsw> much faster than iterating through `tox -e doc`
[21:48] <blackboxsw> and visually comparing 
[21:48] <falcojr> so I DIDN'T need to 'tox -e doc' a million times this whole time?
[21:49] <falcojr> ;)
[21:49] <blackboxsw> ha! well next time we rewrite the whole schema we can use it :)
[21:49] <falcojr> heh, just give it a couple more years
[21:49] <blackboxsw> #toosoon
[22:00] <holmanb> if we throw half of it away first it won't take so long on the rewrite :)
[22:07] <blackboxsw> getting to EOW holmanb but minor thought on ssh-import-id https://github.com/canonical/cloud-init/pull/1334/files
[22:07] <ubottu> Pull 1334 in canonical/cloud-init "declare dependency on ssh-import-id (SC-864)" [Open]
[22:09] <holmanb> @blackboxsw: looking now
[22:10] <blackboxsw> sorry might want to refresh on latest comment
[22:10] <holmanb> +1: I assumed that's what you meant
[22:14] <holmanb> oh last comment, not updated suggested change, I see now
[22:16] <blackboxsw> ahh sorry will redact my suggested change in that first comment. as I think the latter is more appropriate given multiple entrypoints to ssh-import-id
[22:18] <holmanb> blackboxsw: np at all - at the rate that my own EOW is approaching, however, I think this is going to have to wait until monday to implement the second comment
[22:19] <blackboxsw> holmanb: totally get that. I'm about turning the lights off over her 
[22:19] <blackboxsw> *here
[22:20] <blackboxsw> hey CloudCIX is going to look at implementing EphermealDHCP4 support for local timeframe IMDS detection... so that'll be good. that PR will likely idle to stale while they do that.
[22:21] <holmanb> I saw that, sounds good to me
[22:22] <holmanb> making some progress on EphemeralDHCP6 today, I grok it quite a bit more at least
[22:22] <holmanb> *made
[22:31] <blackboxsw> awesome, that'll help a few folks trying to spin up systems ipv6/dhcp6 only envs.
[22:34] <blackboxsw> for that ds-identify branch detected NoCloud in `/etc/cloud/cloud.cfg(.d/*)` I've got to run it through the paces with live-server installer ephemeral environment and make sure we don't get into a pickle with current implementation
[22:34] <blackboxsw> so, probably won't finish that review today