[00:00] thumper: do you have some direction for me regarding feature flags? We'd like to begin landing the Actions CLI behind a feature toggle until it's complete. === kadams54 is now known as kadams54-away [00:01] thumper: I'm planning on using an envar say DEV_ACTIONS_CLI or something [00:02] wallyworld_, that would be great [00:02] np, done [00:02] or will be real soon :-) [00:15] hazmat: are some of those instance types only available in certain regions? [00:16] cause Juju is complaining there's missing cost data in regions for G1 etc [00:16] wallyworld_, bummer [00:16] wallyworld_, bummer.. needs better unit tests.. [00:17] wallyworld_, the G series are not publicly available, i put in the definitions for them.. but only setup mappings for the g5s for a partner request [00:17] their in a public beta atm, but pricing is not known [00:17] but a partner was interested in using them [00:17] what default would be sensible you think? [00:18] or would a default even be worthwhile [00:18] if i put in a high figure, that would mre or ess require explicit instance type selection by the user [00:19] that probably could be ok i think [00:19] wallyworld_, sounds reasonable [00:19] ok, will do thanks [00:19] wallyworld_, g series are mostly monster machines. === kadams54-away is now known as kadams54 [00:19] so i imagine the price is.. well if you have to ask ;-) [00:19] lol [00:35] jw4: oh hai [00:35] jw4: the feature flag branch needs tweaking and can land shortly after [00:35] didn't realise anyone else was waiting on it [00:37] mwhudson: 1.5 discussion will start in the next 48 hours [00:37] probably sooner [00:38] davecheney: \o/ [00:38] in other news, i've found yet another gccgo bug [00:43] thumper: no worries - we just started talking about it too [00:43] axw: i had to make a fix to gwacl to ensure all instance types had costs. I fixed the tests also. these changes are in rolesizes.go and rolesizes_test.go. However, I got sick of the non-standard formatting cause my editor gofmts on save, so the branch has had vanilla gofmt run over it so the diff is large. all tests run, the real changes are in the files i just mentioned. are you able to take a look? [00:44] https://code.launchpad.net/~wallyworld/gwacl/ensure-all-roles-have-costs/+merge/243346 [00:44] ignore my crappy branch name [00:44] thumper: I will be interested to see it when the branch is ready to land [00:44] jw4: ack === kadams54 is now known as kadams54-away [00:54] mwhudson: sorry, there is no prize for gccgo bugs [00:58] wallyworld_: ok [00:59] ty and sorry :-) [00:59] hopefully you can ignore the white space [01:00] wallyworld_: if you haven't already, can you please either delete the format target in Makefile, or change it to "go fmt"? [01:02] davecheney: heh heh [01:02] axw: yeah did that :-) [01:05] wallyworld_ hazmat: do we even care about actual costs? I think we only care about relative costs... I wonder if we could just do "1, 2, 3, ..." in order of role size [01:05] axw: i made the costs arbitary and large [01:05] and in order of role size [01:05] wallyworld_: I guess I should just actually look at the MP ;) [01:06] axw: that way, G1 etc are not selected by default, and require an explicit instance type constraint [01:06] right. goodo [01:22] I try to run my tests with -gocheck.f="myfilter" but whenever I use -gocheck.something the only run test is dependenciesTest.TestDependenciesTsvFormat [01:22] anybody hit tat before? [01:24] perrito666: are you still stuck on that dependency problem ? [01:25] davecheney: nope, I just tried to run one test alone of a suite [01:26] davecheney: tx for your help the other day, I realized too late you where not working that day, apologies [01:28] davecheney: ah no, it's probably just a go tool bug [01:28] davecheney: even tinier non-prize [01:31] perrito666: meh, if i'm not working, i'll ignore you [01:31] you don't need to appologise [01:33] :p I am a very nice person, why would you ignore me? [01:33] * perrito666 is offended [01:34] yes [01:37] davecheney: do you remember enough of the pain to say if this makes sense? http://paste.ubuntu.com/9338212/ [01:40] mwhudson: i remember that link order was super fragile [01:41] we occasionally see builds blow up on power64 when link order is wrong [01:41] i can't say that what you have proposed is wrong [01:41] davecheney: yeah, that's the bug i'm poking at [01:41] but it does make sense that that is the cause [01:42] davecheney: the problem seems to be that i added code to not pass the target of two actions for the same a.p [01:42] but there are two different a.p's for the package being tested when you run go test [01:42] (which makes sense, maybe, now that i think about it: one has the internal _test.go files in it) [01:46] katco: i asked for tests, let me know if you have any questions [02:03] mwhudson: juju uses 'external' tests a lot more than the stb lib [02:03] and we're also leaning hevily on the export_test.go escape hatch to get access to internal functions during tests [02:04] i'm sure this has agrevated the issue === kadams54 is now known as kadams54-away [02:55] thanks thumper - I see your PR [03:08] hmm... is juju/cmd hooked up to review board? [03:08] https://github.com/juju/cmd/pull/10 [03:17] menn0: you might like that one :-) ^^^^ [03:22] thumper: looking... [03:23] menn0: obviously the supercommand code wasn't complicated enough... [03:24] menn0: I've just noticed the I never got around to updating the doc strings for the new functions [03:29] thumper: i'll ignore that then :) [03:29] thumper: reviews for other repos don't go to RB then? [03:30] menn0: some do, some don't [03:30] I don't know which do [03:31] thumper: well this hasn't so I'll do the review on GH [03:37] thumper: so I should ignore the incorrect docstring for RegisterSuperAlias? [03:38] yes [03:43] axw: patch to add AZ to instanceData: http://reviews.vapour.ws/r/557/ [03:43] axw: let me know if that's what you had in mind === kadams54-away is now known as kadams54 [03:44] axw: with that my unit-get patch will get a lot simpler :) [03:46] ericsnow: yep, pretty much. I don't think Instance needs to get a new AvailabilityZone method; we should just return it from StartInstance [03:47] I guess it doesn't hurt to have it there though [03:48] ericsnow: oh right, it's needed for upgrades. never mind me [03:49] ah hm, not really if it's a ZonedEnviron ... anyway. [04:10] thedac: review done [04:10] thedac: sorry, that was supposed to be for thumper [04:38] mwhudson: the patch attached to this issue appears to be a patch, if it's not a patch, then remove the patch tag from this issue ... [04:38] thanks, i guess === kadams54 is now known as kadams54-away [05:19] Hi, I was just wanting to try a few things with 1.21 and wondering which ppa to use? [05:30] huwshimi: I think you want https://launchpad.net/~juju/+archive/ubuntu/devel [05:31] axw: A brilliant thanks, I'll take a look [05:32] *Ah [05:48] morning [07:35] fwereade_: any chance you could take a look at https://github.com/juju/charm/pull/77 some time soon? I expect we can iterate on this for changes due to mandatory constraints [07:36] axw, sorry, queued it up [07:36] fwereade_: thanks [09:06] fwereade_, wallyworld_, TheMue, hey guys, any of you willing to review a fix for bug 1395908 ? http://reviews.vapour.ws/r/558/ [09:06] Bug #1395908: LXC containers in pending state due to juju-br0 misconfiguration

[09:07] dimitern_: i've been called to dinner but can look afterwards if not done by then [09:07] wallyworld_, no worries [09:08] dimitern_, LGTM, very clean, ty [09:09] morning all [09:09] fwereade_, thanks! [09:10] morning matty [09:10] dimitern_, morning [09:11] fwereade_, morning, would you have a few minutes to take a look at http://reviews.vapour.ws/r/553/ [09:46] fwereade_, when you have 5m, I have a backport for the same bug fix - http://reviews.vapour.ws/r/559/ (for 1.21) - no other changes [09:48] dimitern_, LGTM again :) [09:50] fwereade_, cheers :) [09:52] Nobody has posted to juju or canonical-tech about rocket... [09:54] voidspace, it was on cloud though [09:54] * fwereade_ popping out, bbs [09:59] fwereade_: ah, I may not be on that list then... [10:01] jam1: dimitern_: stdup? [10:02] voidspace, omw, sorry [10:50] menn0, ping [10:51] fwereade_: hi [10:51] menn0, remind/reassure me: did we manage to close off the paths whereby non-state server agents can end up connecting to state servers of an earlier version than themselves? [10:53] fwereade_: you mean while an upgrade is in progress? [10:53] menn0, yeah [10:53] fwereade_: yes, that was already done before I touched the upgrade code [10:53] fwereade_: state servers don't advertise the new version until they themselves have upgrades [10:53] upgraded [10:53] menn0, I'm just looking at the bit I wrote in the uniter for spinning on CodeNotImplemented from a particular call while waiting for the state server to be upgraded [10:53] menn0, and suspecting I can drop it [10:53] menn0, cool [10:54] menn0, thanks [10:55] fwereade_: and given that an upgrade can't start unless all the hosts in the env are on the current or next version there's really no way a non-state server can get ahead of the state servers [11:11] fwereade_: do you mind if I tweak this a little? I'm not really a fan of the cast here, since it can panic: http://bazaar.launchpad.net/~fwereade/juju-core/provider-skeleton/view/head:/provider/skeleton/config.go#L125 [11:12] natefinch: here's a fix for the critical bug on master http://reviews.vapour.ws/r/560/ [11:12] fwereade_: I'd much rather do it once in validateConfig and just store the values in a normal old struct [11:12] wallyworld_: looking [11:12] ty [11:13] natefinch, so, in *theory* it won't panic because it should have been validated on creation [11:14] natefinch, but *hell yes* put things in structs if you can [11:14] fwereade_: kk will do. I know it shouldn't panic, but it gives me the heebie jeebies [11:21] man, %q was just the best idea ever [11:32] hi folks, I'm consistently getting errors on FAIL: status_test.go:2702: StatusSuite.TestFilterSubordinateButNotParent. Anyone else? It seems to have been happening for a while for me so it must just be me [11:33] jam1: do you know the history surrounding the change in api endpoints as per bug 1397376? it's claimed the change to only return a single address for api-endpoints is a regression, and it sure seems that way. also the use of dns name rather than ip address [11:33] Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints

[11:34] mattyw: katco should be able to help with that [11:38] wallyworld_: lgtm [11:38] natefinch: tyvm [11:55] wallyworld_, ack, thanks very much [11:55] np, she should be on soon [12:01] wallyworld_, your fix landed, but the bot still refuses new PRs [12:01] __JFDI__ doesn't seem to work either :/ [12:01] dimitern_: i think it takes a while for the fix to go through CI [12:02] wallyworld_, ah, my mistake - it did work with __JFDI__ [12:02] great [12:18] fwereade_, ping? [12:19] mattyw, pong, in meeting, responding slowly === Ursinha is now known as Ursinha-brb === Ursinha-brb is now known as Ursinha [12:27] fwereade_, last backport - for 1.20; same bug, no changes - will you approve it? http://reviews.vapour.ws/r/561/ [12:54] voidspace, can you have a look instead? http://reviews.vapour.ws/r/561/ === dimitern_ is now known as dimitern [12:56] * dimitern is afk for a while [13:02] dimitern: sure [13:03] dimitern: LGTM [13:09] voidspace, thanks! [13:51] can anyone think of a reason not to make "machineenvironmentworker.MachineEnvironmentWorker" into something a bit more readable like "proxy.Worker"? [13:54] is anyone very very savvy about github.com/juju/cmd? [14:04] fwereade_, +100 [14:04] perrito666, rogpeppe or thumper I think [14:05] dimitern: tx, I figured out, testing subcommands was confusing me a bitç [14:05] fwereade_: why "proxy"? [14:06] fwereade_: i'd certainly use less stuttering [14:07] wallyworld_: how can I know definitively when CI is accepting new builds? CI must be using some check that I can run myself before $$merge$$? [14:08] fwereade_: +1 to have names that can be pronounced without taking a breath at the point [14:09] rogpeppe, because it's all about setting proxy-related env vars, and writing out files describing what proxies to use ;) [14:09] jw4, I use this bookmark https://bugs.launchpad.net/juju-core/+bugs?field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.importance%3Alist=CRITICAL&field.tag=ci+regression+&field.tags_combinator=ALL [14:09] rogpeppe, but maybe I missed some detail? [14:10] dimitern: that's basically what I use too, but CI is still rejecting builds even though that reports zero bugs [14:11] jw4, it was blocked earlier, but not anymore - a PR of mine landed less than an hour ago [14:11] fwereade_: is there any reason to export the worker type at all from that package? [14:11] rogpeppe, fair point [14:11] dimitern: hmm; mine was rejected after yours was accepted [14:11] fwereade_: i'd suggest proxyworker as the package identifier [14:11] fwereade_: and define proxyworker.New as the creator of the worker [14:12] rogpeppe, "worker/proxyworker" is a little bit yucky, but yeah, that sounds sane [14:12] fwereade_: and use "worker" as the internal type [14:12] fwereade_: i think it's fairly idiomatic - e.g. http/httputil [14:13] rogpeppe, yeah [14:14] wallyworld_, dimitern yeah - again : Does not match ['fixes-1396981'] [14:14] CI must be using a different query - I just want to know what that is so I don't have to keep guessing when CI gets unblocked [14:26] jw4, they must've changed it [14:27] mgz_, sinzui, any clue why the bot is still blocked on bug 1396981 ? [14:27] Bug #1396981: Upgrade fails because product json is renamed

[14:27] dimitern: oh well - I've waited almost a week to land this anyway - I can wait longer :) [14:28] dimitern, 1. the bug is not Fix released, 2. we need to remove the rule for frozen index.json. [14:28] dimitern, I think master will be open in about 30 minutes [14:29] jam can you get someone to look into Bug #1398406? the gwacl change broke azure deploys for CI [14:29] Bug #1398406: Azure provider attempts to deploy with unsupported "D1" RoleSize

[14:30] sinzui, great, thanks! [14:30] sinzui, jam is not here today, I can have a look perhaps [14:31] thank you dimitern [14:32] sinzui, btw, lest I forget - will there be a 1.20.14 release? I have just fixed an issue with maas there - bug 1395908 [14:32] Bug #1395908: LXC containers in pending state due to juju-br0 misconfiguration

[14:33] dimitern, we need to do one for the gwacl change...but the change is broke tests [14:33] sinzui, the gwacl one I'm looking at now? [14:33] dimitern, I was just looking at that bug and think about how I might verify the change works with the QA maas [14:34] dimitern, yes. bug 1398406 is fallout from bug 1389422 [14:34] Bug #1398406: Azure provider attempts to deploy with unsupported "D1" RoleSize

[14:34] Bug #1389422: azure instance-types and regions missing

[14:34] sinzui, well, if it's a virtual maas it can be tested by tweaking one or a few kvm domain configs (vms) to have disabled NICs [14:35] thank you dimitern, [14:35] sinzui, that's how I tested it locally, I can give you more details should you need them [14:36] :) [14:40] sinzui, with the fix juju will log "node "XXX" skipping disabled network interface "XYZ" for disabled devices; luckily by default only the primary interface is enabled (as discovered by lshw) so you should see these right after a node is acquired from maas (e.g. during bootstrap --debug) [14:42] sinzui, and after a few "skipping disabled network interface.." log lines (depending on how many NICs are there) there will be a final "node "" primary network interface is "XYZ" (e.g. "eth2", which will appear in /etc/network/interfaces under the juju-br0 "bridge-ports" setting) [14:55] dimitern: (sinzui ) this updated query takes into account Fix Committed and not Fix Released... : https://api.launchpad.net/devel/juju-core?ws.op=searchTasks&status%3Alist=Triaged&status%3Alist=In+Progress&status%3Alist=Fix+Committed&importance%3Alist=Critical&tags%3Alist=regression&tags%3Alist=ci&tags_combinator=All [14:56] sinzui: that should be the right query for me to check status before merging right? [14:57] jw4, do you have a bugs.launchpad.net link with the same filters? [14:57] natefinch: ericsnow can we jump into the standup since we are in it? [14:57] dimitern, no but I think I can whip it up... [14:57] jw4, cheers! [14:58] sinzui, is bug 1398406 only for 1.21 or also for trunk and 1.20 ? [14:58] Bug #1398406: Azure provider attempts to deploy with unsupported "D1" RoleSize

[14:58] dimitern, the Lp only claims the merge was in 1.21 [14:58] * sinzui checks log [14:59] natefinch: ? [14:59] dimitern, I don't see the dep change in master. just 1.21 [14:59] sinzui, right; so after some analysis I think the issue is MS renamed "D1" to "Standard_D1" etc. [15:00] sinzui, I'll propose a fix, can it be tested in the same CI scenario easily? [15:00] yes [15:04] dimitern, this is the command that failed. the constraint is important, the env can be any asure: juju --show-log bootstrap -e azure-deploy-precise-amd64 --constraints mem=2G [15:05] sinzui, right, I'll try it locally as well [15:05] thanks [15:06] jw4, that call is right. I use [15:06] juju-ci-tools/check_blockers.py master 1234 [15:06] where the number is random [15:06] sinzui: perfect [15:08] dimitern: check_blockers.py is the best route, but I think the query would look like: https://bugs.launchpad.net/juju-core/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field. [15:08] importance%3Alist=CRITICAL&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=ci+regression+&field.tags_combinator=ALL&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field. [15:08] has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on [15:08] jw4: it's possible to get a shorter version of that url :) [15:09] dimitern, jw4 abentley: bug 1398406 is wrongly on master (and the wrong milestone), I am going to target it to the 1.21 branch and beta4 to get master unblocked [15:09] Bug #1398406: Azure provider attempts to deploy with unsupported "D1" RoleSize

[15:09] mgz_: lol - you mean with a shortner or by removing all the empty fields ? [15:09] jw4, thanks! [15:09] mgz_: I keep trimming the empty fields by hand, but the search tool puts them back in whenever I tweak the params [15:09] sinzui, cool, thank you [15:10] jw4: :) [15:12] mgz_: (dimitern) how about : https://bugs.launchpad.net/juju-core/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&field.tag=ci+regression+&field.tags_combinator=ALL [15:12] tiny bit shorter [15:12] that looks reasonable [15:12] thanks again jw4 [15:13] dimitern: :) [15:20] ericsnow, perrito666: sorry, chrome crashed again, and I can't get back in. I think we mostly were done. I'll be back in like 5 minutes. [15:20] natefinch: we noticed [15:20] btw, is it possible to downgrade back to trusty? Because this is just ridiculous [15:20] natefinch: ping me when you are ready for our 1-on-1 [15:20] ericsnow: will do] [15:27] natefinch: mm, I am not sure, it should be it requires some crafting by hand and some things might break [15:28] there are not that many changes in utopic [15:28] natefinch: you could downgrade the browser [15:28] I don't even know that it changed the browser. I'm running Chrome, not Chromium [15:30] natefinch: chances are that the browser updated and it might also be broken in trusty, chrome comes from a ppa iirc [15:34] hey there team, I see katco has pickup one critical bug do we have an assignee for this one: [15:34] https://bugs.launchpad.net/juju-core/+bug/1397376 [15:34] Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints

[15:41] alexisb: looking [15:53] sinzui: about that api-endpoints bug.... it sounds like the scripts were relying on behavior that was not guaranteed, but simply happened to be somewhat reliable in their particular environments. I'm with Tim in that I'm not sure this is a regression. [15:54] natefinch, They are relying on behaviour that worked most of the time, now doesn't work most of the time [15:55] natefinch, I think we need to know if anyone has built tools on the unguaranteed behaviour. If deployer assumes it, we have a problem [15:57] hazmat, juju 1.21 api-endpoints is more likely to return a dns address instead of an ip address. Some people assume it only returned an IP address. does deployer make such assumptions? [16:02] sinzui: isn't deployer on the server? api-endpoints is a client-only command, I don't think deployer could call it if it wanted to. Also, again, deployer is on the server, so it shouldn't need to get the api endpoint, right? [16:02] natefinch, no, deployer drives your client [16:02] or am I crazy about how deployer works [16:02] * natefinch is crazy, ok. :) [16:02] I've never used the deployer, sorry :) [16:02] well supplants your client with an bulk api clinet [16:03] natefinch, a deployer files/bundle is a summary of an end state of an env. deployer/quickstart walks juju through the steps to but the env into the state [16:27] dimitern: ping [16:28] voidspace, pong [16:28] dimitern: I'm stuck on a failing test [16:28] dimitern: this is for IPAddress.SetState [16:29] dimitern: the Assert seems to prevent State being changed at all [16:29] dimitern: this is the code https://github.com/voidspace/juju/compare/state-ipaddresses [16:29] dimitern: this is the error message: http://pastebin.ubuntu.com/9346641/ [16:29] voidspace, looking [16:30] dimitern: the failing test is TestIPAddressSetState [16:30] dimitern: it fails on line 1306 - where we attempt to change the state (actually calling SetState) [16:30] dimitern: I've checked other Asserts in our code and can't see the difference [16:31] dimitern: the Assert itself is line 96 of the diff (first block - the new ipaddresses.go file) [16:32] voidspace, unknownOrSame? [16:32] dimitern: yes [16:32] dimitern: to change the state, the existing state must be AddressStateUnknown, or the same state as the one we're setting [16:32] so the state must be unknownOrSame [16:33] which was your name I believe... yesterday :-) [16:33] voidspace, yeah [16:33] voidspace, hmm.. weird.. [16:34] dimitern: the test creates a new address, checks that the state is AddressStateUnknown and then attempts to set the state to AddressStateAllocated [16:34] dimitern: and that fails with "transaction aborted" [16:34] voidspace, how about if you use getCollection + defer like in other places, rather than using C: ipaddressesC [16:34] dimitern: ok, I'll try that [16:34] voidspace, ah, another thing I just noticed [16:35] dimitern: hmm... other places uses st.runTransaction with C [16:35] voidspace, state is omitempty, which means it can be null in addition to any valid state [16:35] voidspace, it shouldn't be omitempty [16:35] dimitern: ok [16:35] dimitern: that might be it [16:35] StateUnknown is "" [16:35] voidspace, we have an "unknown" .. yeah :) [16:37] dimitern: getting rid of omitempty worked! [16:37] dimitern: thanks :-) [16:38] voidspace, sweet! [16:38] I knew there was a reason we kept you around ;-) [16:38] :D [16:38] indeed [16:38] :-) [16:43] ok, eod for me [16:43] g'night all [16:43] dimitern: g'ngight [16:43] voidspace, o/ === kadams54 is now known as kadams54-away [16:52] ericsnow, ping? [16:52] mattyw_: hey [16:52] ericsnow, hey hey, what's the current process for proposing a branch with a prereq? [16:53] mattyw_: Do it like normal and then use "rbt post -u --parent ..." afterward [16:54] ericsnow, perfect thanks very much [16:54] mattyw_: np :) === kadams54-away is now known as kadams54 [16:59] cmars, http://reviews.vapour.ws/r/563/ [18:13] g'night all [18:33] on call reviewer today available to PTAL? Very small change - fully tested with juju-core (small fix to juju-core to follow this update) http://reviews.vapour.ws/r/565/ [18:34] jw4: what have we learned? [18:35] never use regular expressions [18:36] natefinch: that is a rather firm stance to take [18:36] katco: perhaps only slightly too firm. Never use regular expressions longer than 10 characters? [18:37] natefinch: i can at least consider that statement :) [18:37] natefinch: very useful: http://www.colm.net/open-source/ragel/ [18:38] natefinch: lol! [18:38] jw4: haha, did we not even have a positive testcase for that? [18:38] wait wait wait [18:38] natefinch: blush [18:39] why is IsValidUUIDString not just [18:39]