[00:14] <alexisb> do we have documentation somehwere that walks one through how to use clock to get rid of time. (in favor of clock)?
[00:14] <alexisb> or are there good examples in the code I could follow?
[00:16] <natefinch> alexisb: instead of using stuff from time.Time, use clock.Clock, which has an interface close enough to identical to what's offered in time.Time, and use that
[00:16] <natefinch> er sorry, instead of using stuff from the time package
[00:16] <alexisb> well that is convienent, thanks natefinch
[00:16] <natefinch> alexisb: therre's a clock.WallClock value that you use in production that wraps the time package into an interface-able value
[00:33] <menn0> alexisb: a fairly simple example of some code which uses an injected Clock is the resumer (worker/resumer/)
[00:37] <thumper> hmm...
[00:37] <thumper> why does restoring a model give it a new uuid?
[00:38] <thumper> perhaps controller model uuid
[00:38] <natefinch> I presume because nothing ensures the old model is actually gone?
[00:42] <thumper> except the agents can't connect to the new model
[00:43] <thumper> because they all have the old model uuid
[00:43] <natefinch> ahh
[00:43] <natefinch> conundrum
[00:43] <thumper> there seems to be a break in logic somewhere
[00:43] <natefinch> indeed
[00:44] <natefinch> I have only seen backup and restore work being done from afar, I know one of the details, unfortunately
[00:44] <thumper> As part of restore, all known instances are
[00:44] <thumper> configured to treat the new controller as their master.
[00:44] <thumper> form the help
[00:44] <thumper> let's hope that they are
[00:45] <menn0> thumper: so I figured out the i/o timeout thing
[00:45] <menn0> thumper: fixing it will be non-trivial
[00:45] <thumper> oh?
[00:46] <menn0> thumper: CodeRetry is only being handled if the API call itself returns an error
[00:46] <menn0> thumper: but the error is usually turning up in an Error field
[00:46] <thumper> ah
[00:46] <thumper> ugh
[00:46] <menn0> thumper: and the apiclient code doesn't check there
[00:46] <thumper> yeah, that is horrible
[00:47] <menn0> thumper: I'm considering some kind of reflection magic
[00:47] <thumper> and you have the situations where something may have worked while another timed out
[00:48] <menn0> thumper: which makes that pretty terrible
[00:48] <thumper> it does
[00:48] <menn0> thumper: you only want to redo the parts of the request which failed
[00:48] <thumper> so not trivial
[00:48]  * menn0 is annoyed this didn't occur to him before this work was done
[00:50] <menn0> thumper: perhaps the right place to handle this is inside or just above State
[00:51] <menn0> in our database layer
[00:51] <menn0> and have that retry
[00:51] <menn0> i'm going to have lunch and mull it over
[00:51] <thumper> in juju/txn package?
[00:51] <thumper> ok
[00:52] <menn0> just doing it for txns isn't enough because queries can fail too
[00:54] <menn0> thumper: it'll probably have to happen in both the txn layer and the collections layer (state/collection.go)
[00:54]  * thumper nods
[00:54] <menn0> we really need to get rid of mongo....
[00:54] <menn0> lunch!
[01:22]  * perrito666 reads backup and restore and pops in
[01:23] <perrito666> Thumper menn0 anything I can do?
[01:40] <thumper> perrito666: you could start by telling me what it is supposed to do and not do
[01:40] <thumper> perrito666: I tried to restore into a running controller, and it just dies
[01:41] <thumper> controller gets stuck
[01:41] <thumper> restore doesn't work
[01:41] <thumper> apiserver and state are down
[01:55]  * thumper goes to walk the dog and think
[02:35] <menn0> thumper: ping?
[02:48] <thumper> menn0: ba ck
[02:48] <menn0> thumper: 1:1? I'm stuck
[02:48] <thumper> me too
[02:59] <anastasiamac> natefinch: m guessing u r not really here, r u?
[03:00] <natefinch> anastasiamac: night time is the right time
[03:02] <anastasiamac> natefinch: :) re: bug 1552274, r u working on it already?
[03:02] <mup> Bug #1552274: juju list-credentials inconsistencies between format output <2.0-count> <bitesize> <conjure> <juju-release-support> <rc1> <usability> <juju:In Progress by natefinch> <https://launchpad.net/bugs/1552274>
[03:04] <natefinch> anastasiamac: wow uh, nom sorry
[03:05] <anastasiamac> natefinch: awesome, i was going to pick it up but saw ur name on it.. so r u k for me to do it? :)
[03:05] <natefinch> anastasiamac: totally
[03:05] <anastasiamac> \o/
[03:06] <natefinch> anastasiamac: that was during the london sprint. I probably started looking at it, then ran out of time, then was on vacation for 11 days, and forgot about it
[03:06] <anastasiamac> nps, i'll count this as my win ;) might need to get u to review tho :-P
[03:07] <natefinch> anastasiamac: sure thing
[03:08] <natefinch> at one time I heard someone was going to fix needing to use --config=something.yaml during bootstrap to get reusable defaults on bootstrap.  Anyone know if that ever happened?
[03:11] <natefinch> thumper, menn0 ^ ?
[03:13] <menn0> natefinch: that's been done. define a custom cloud as per https://github.com/juju/juju/wiki/Faster-LXD#suggested-juju-config-for-lxd-deployments
[03:16] <natefinch> menn0: oh, hmm.  I wondered why we could add clouds for things like AWS.
[03:17] <anastasiamac> menn0: axw: as tech strategy gurus, what's ur take on defining json tags outside of cli package?
[03:18] <anastasiamac> m seeing inconsistencies btw json/yaml output because yaml tags are defined but json aren;t and we are pulling juju/juju objects without transforming them at presentation layer
[03:18] <axw> anastasiamac: better not to do that, because of unintended consequences
[03:18] <axw> i.e. changing something outside CLI-related packages probably shouldn't affect presentation
[03:19] <natefinch> anastasiamac: we're supposed to be transforming them at the presentation layer into display values
[03:19] <axw> and it's surprising when it does happen
[03:19] <anastasiamac> axw: awesome \o/ that was my take too :)
[03:19] <axw> and leads to bugs.
[03:23] <menn0> anastasiamac: what axw said :)
[03:23] <anastasiamac> axw: menn0: \o/
[04:08] <thumper> anastasiamac: want a trivial branch to do?
[04:08] <thumper> anastasiamac: I'm in the middle of debugging restore
[04:08] <anastasiamac> thumper: mayb :) what's needed?
[04:09] <anastasiamac> thumper: m trying to figure out how to print value but not the label of the field in json :)
[04:09] <thumper> cmd/juju/status/output_tabular.go:83 	const maxVersionWidth = 7
[04:09] <thumper> that number is way to small
[04:10] <thumper> e.g. "9.0.0~b3" is ellided to "9.0...."
[04:10] <thumper> just make it something like 12
[04:10] <thumper> or 15
[04:10] <anastasiamac> thumper: sure :)
[04:10] <anastasiamac> thu`was oging to say 15 :)
[04:11] <anastasiamac> thumper: do u know how to NOT print field label but value in json? kind of like `yaml:","`
[04:11] <thumper> json:"-"
[04:12] <thumper> I think it is also  jaml""-"
[04:12] <thumper> I think it is also jaml:"-"
[04:12] <thumper> yaml:"-"
[04:12] <thumper> perhaps "," works too, but I think the official supported way is the dash
[04:13] <anastasiamac> thumper: that prints actual "-", when ommitted completely as in "", it prints captialised property name
[04:13] <anastasiamac> anyay, i'll get back to it later, I'll increase version line chars first for :)
[04:13] <anastasiamac> u*
[04:14] <thumper> for yaml or json
[04:14] <thumper> ?
[04:14] <thumper> https://golang.org/pkg/encoding/json/#Marshal
[04:14] <thumper> Each exported struct field becomes a member of the object unless
[04:14] <thumper> - the field's tag is "-", or
[04:14] <thumper> - the field is empty and its tag specifies the "omitempty" option.
[04:15] <thumper> pretty sure yaml does the same
[04:16] <anastasiamac> thumper: for json: if tag is "", then property name printed; if tag is "-", then "-" printed. i've played with it for hours now ;)
[04:16] <thumper> umm... no
[04:16] <thumper> check that you are getting a hyphen
[04:16] <anastasiamac> for yaml if "-", filed name is not printed (as I want) but value is printed ;)
[04:17] <thumper> and not an ndash
[04:17] <anastasiamac> anyway.. m going to come back to it later
[04:17] <thumper> we are using this in juju
[04:17] <thumper> cmd/juju/cloud/show.go
[04:17] <anastasiamac> thumper: oh.. what's the diff btw dash and hyphen? i thought we only had problmes with underscores...
[04:18] <thumper> hyphen, ndash and mdash are all different characters
[04:18] <thumper> search the codebase for `json:"-"`
[04:18] <thumper> many uses
[04:18] <anastasiamac> thumper: awesome! tyvm!
[04:27] <anastasiamac> thumper: https://github.com/juju/juju/pull/6273
[04:28] <thumper> thanks
[05:11] <thumper> hmm...
[05:11] <thumper> it seems I can't use a specific identity file key for juju ssh
[05:12] <thumper> menn0: ^ ideas?
[05:13] <menn0> thumper: no I think you can. juju ssh/scp/debughooks now get the appropriate public key for the target via the API and write that to a temp file which is then passed to ssh/scp.
[05:13] <veebers> thumper: The 'default' hosted model has (or will be?) removed right?
[05:14] <menn0> s/can/can't/
[05:14] <menn0> thumper: ^
[05:14] <thumper> menn0: quick call?
[05:14] <menn0> thumper: sure
[05:32] <anastasiamac> thumper: certainly, "-" from cmd/juju/cloud/show gets shown as "-"
[05:32] <anastasiamac> thumper:  but thnx for the tip, i'll kee looking
[05:37] <veebers> anastasiamac would you know? ^^ (re: default model)
[05:37] <anastasiamac> veebers: i know that there is a bug for it but I do not know where it is at
[05:38] <anastasiamac> veebers: let me find a reference for ur pleasure and tracking :)
[05:38] <veebers> anastasiamac: awesome, thanks :-)
[05:38] <anastasiamac> veebers: bug 1621295
[05:38] <mup> Bug #1621295: Drop the 'default' model <juju:Triaged> <https://launchpad.net/bugs/1621295>
[05:42] <thumper> anastasiamac: https://play.golang.org/p/6Bdpkkk7lw
[05:42] <thumper> anastasiamac: yes it does
[05:42] <anastasiamac> veebers: in since we r trading info, do u happen to know if retry-provisioning is tested vigorously/rigorously/at all?
[05:42] <anastasiamac> thumper: it ignores the fiedl entirely ;) i want to ignore field name but print its value :)
[05:43] <thumper> what?
[05:44] <anastasiamac> thumper: field/property name
[05:49] <veebers> anastasiamac: no idea sorry, I can bring it up in tomorrows standup if you would like
[05:49] <anastasiamac> veebers: it's k.. just curious.. it can simmer for now ;)
[05:49] <veebers> anastasiamac: :-)
[09:13] <perrito666> Thumper a bit late but, restoring into a running controller should work, what exactly are you trying to do? About to start my day and I can most likely take over
[09:17] <babbageclunk> Whoa, early in the morning for you perrito666! Or are you travelling?
[09:30] <perrito666> I have irc on the phone so I answer from bed before getting up
[09:31] <perrito666> Currently is 6:30 anyway and am already up
[09:33] <lazypower> whats my excuse at 4:30?
[09:33] <lazypower> oh right :D wizarding hour
[09:33] <perrito666> You have no life
[09:34] <lazypower> and that
[10:06] <dimitern> morning all
[10:16] <babbageclunk> anyone: do I need to be on the VPN, given that I'm at Bluefin?
[10:17] <dimitern> babbageclunk: unlikely, but shouldn't hurt if you're
[10:19] <babbageclunk> dimitern: If I turn it on I can't get to irc.canonical.com
[10:19] <dimitern> babbageclunk: btw I've only noticed last week during my maas testing the devices are cleaned up along with their containers - nice work! :)
[10:20] <dimitern> babbageclunk: really? well, come to think of it I had issues while on the vpn and irc.c.c connection drops
[10:20] <dimitern> babbageclunk: I usually connect to irc first and only then start openvpn
[10:21] <babbageclunk> dimitern: :)
[10:23] <dimitern> frobware: hey, I've just landed the gomaasapi change thumper reviewed, and since your QA was OK, I'm thinking of starting to land the chain of PRs I have up - objections?
[10:25] <dimitern> frobware: alternatively, I can push the last commit bumping deps of gomaasapi and give the whole thing a QA run today first
[10:27] <dimitern> *facepalm*
[10:27]  * dimitern fixed thumper's suggestions, but should've pushed before merging :/
[10:33] <frobware> dimitern: I would like to do a complete QA run today; want to sync?
[10:34] <frobware> dimitern: my 1 broken case was fixed, but that's because I only had 1 broken setup to test. Let's create a spreadsheet with the combos we want to test and split the effort up.
[10:38] <dimitern> frobware: let's sync
[10:39] <frobware> dimitern: in the standup HO
[10:39] <dimitern> frobware: omw - bluetooth issues again
[10:55] <dimitern> ooh mgz :)
[10:56] <dimitern> you're an +o now? sweet :D
[11:03] <mgz> dimitern: yo
[11:03] <mgz> just channel spammer prevention
[11:17] <anastasiamac> natefinch: axw: lis-credentials with json output - https://github.com/juju/juju/pull/6274
[11:18] <dimitern> ;)
[12:19] <frobware> dimitern: tar -cvf ~/juju-2-0-rc1-for-brad.tar --transform='s!^!juju-2.0-rc1-for-brad/!' bin/juju*
[13:16] <natefinch> gah, we need a style guide for the CLI :/
[13:22] <rick_h_> natefinch: heh grtting there
[13:23] <rick_h_> we have most of the rules on place, polish time
[13:24] <natefinch> rick_h_:  I was working on the output for when there's no results for a list-* command and decided to check some of the other list-* commands...  I realized we don't have rules like "always/never capitalize the first word"
[13:25] <natefinch> also there's an unfortunate inconsistency between our flag parser's error output and the rest of juju's error output.  The flag parser writes "error: <something>" and everything else writes ERROR <something> (with error in red)
[13:26] <natefinch> rick_h_: should I file bugs?
[13:29] <mgz> well, there's a difference between the logging output
[13:29] <mgz> and the general command response
[13:30] <mgz> that's just somewhat blurred in a few cases
[13:30] <rick_h_> natefinch: there's a bug on the different table list- output already I think
[13:30] <rick_h_> natefinch: but yea, if you see anything file bugs please
[13:33] <rick_h_> frobware: dimitern morning how goes folks?
[13:34] <dimitern> frobware: morning!
[13:34] <dimitern> oops
[13:35] <dimitern> rick_h_: morning :) - goes well - we're waiting for a pre-merge CI run for the VLAN bug
[13:35] <rick_h_> dimitern: cool, how are we feeling about it?
[13:35] <dimitern> all seems to work fine so far, after my last change to gomaasapi
[13:36] <dimitern> rick_h_: I feel pretty good about it, no issues so far from several sources that tested it
[13:37] <rick_h_> dimitern: k, can we see about getting a build out to folks int he bug for early testing perhaps?
[13:37] <dimitern> (well, some issues do exist, but they seem to be related to broken MAAS setups, not the fix itself)
[13:37] <dimitern> rick_h_: frobware sent a build to a couple of guys
[13:38] <rick_h_> dimitern: k
[13:38] <rick_h_> dimitern: I just want to make sure we're solid on this
[13:39] <dimitern> rick_h_: sure, so far we are good AFAICS
[13:39] <rick_h_> dimitern: k, so branches are all reviewed/going in for landing?
[13:39] <dimitern> well now.. wouldn't it be nice if MAAS CLI had a tabular output mode, like Juju? http://paste.ubuntu.com/23202865/
[13:39] <rick_h_> dimitern: heh, have to see what this UX stuff they're doing in 2.1 is
[13:40] <dimitern> rick_h_: there are several branches up, almost all changes are reviewed/approved
[13:40] <rick_h_> dimitern: k, we have to get things landed EOD so they can look at a build tomorrow
[13:40] <rick_h_> frobware: ^
[13:40] <dimitern> rick_h_: but frobware and me wanted to see how the CI run will go on that branch, which contains all the stacked changes
[13:41] <rick_h_> dimitern: k
[13:43] <frobware> dimitern: +1 on the maas output - nice1
[13:44] <dimitern> rick_h_: do you recall when/why it was decided to get rid of the tabular sections - e.g. [TITLE] and just go with headers?
[13:45] <rick_h_> dimitern: because the heading were split enough and folks aren't meant to be parsing the tabular output which they tend to do with the [apps] and such
[13:45] <rick_h_> so it was wasted space
[13:45] <mgz> the `juju generate-config` command is totally dead, right?
[13:45] <mgz> just updating some doc, and it still references that
[13:45] <dimitern> it might be worth to have sections for that maas-tabular experiment I'm trying out though..
[13:46] <mgz> we just have the common public clouds usable without that now...
[13:47] <mgz> evurk, this neeeds much more rewriting...
[13:48] <rick_h_> dimitern: typical thing is to try to fit whatever you would title into the heading in a clean way
[13:48] <rick_h_> dimitern: so you have the info you need, and none of the info you don't
[13:48] <dimitern> rick_h_: good point, yeah
[13:48] <rick_h_> dimitern: e.g. a heading "interfaces" is kind of redundant whehn you see eth0, eth1, etc.
[13:48] <rick_h_> but storage maybe a STORAGE NAME heading fits better
[13:49] <dimitern> rick_h_: great suggestions, cheers!
[13:49] <dimitern> btw the output is just a nice side-effect
[13:50] <dimitern> the reason I'm doing this is to help automate maas setups via the API - easily change nodes networking for example
[14:01] <rick_h_> dimitern: ping for standup
[14:01] <dimitern> sorry omw
[15:01] <rick_h_> babbageclunk: https://hangouts.google.com/hangouts/_/canonical.com/ui-daily?authuser=1
[15:22] <frobware> dimitern: ping
[15:33] <dimitern> r
[15:33] <dimitern> frobware: pong
[15:33] <frobware> dimitern: HO? I have a failing case (lxdbr0)
[15:51] <mup> Bug #1625243 opened: Simplestreams for rackspace are now live! <cloud-images:Fix Released by josvaz> <juju-core:New> <https://launchpad.net/bugs/1625243>
[15:55] <dimitern> frobware: sorry, got distracted.. joining standup HO?
[15:57] <frobware> dimitern: great!
[15:59] <dimitern> frobware: omw
[16:21] <mup> Bug #1625243 changed: Simplestreams for rackspace are now live! <cloud-images:Fix Released by josvaz> <juju:In Progress by sinzui> <https://launchpad.net/bugs/1625243>
[16:27] <mup> Bug #1625243 opened: Simplestreams for rackspace are now live! <cloud-images:Fix Released by josvaz> <juju:In Progress by sinzui> <https://launchpad.net/bugs/1625243>
[16:30] <mup> Bug #1625243 changed: Simplestreams for rackspace are now live! <cloud-images:Fix Released by josvaz> <juju:In Progress by sinzui> <https://launchpad.net/bugs/1625243>
[17:10] <frobware> dimitern: http://pastebin.ubuntu.com/23203649/
[17:21] <rick_h_> frobware: where did the maas scripts end up?
[17:21] <rick_h_> frobware: in github did we get it moved to /juju?
[17:21] <frobware> rick_h_: nope
[17:21] <rick_h_> frobware: k, where are they?
[17:22] <frobware> rick_h_: github.com/frobware/kvm-maas
[17:22] <rick_h_> frobware: k, if I create a fork there then and we can move that way please?
[17:22] <frobware> rick_h_: if you create the fork you're saying continue development in the [juju] fork?
[17:23] <rick_h_> frobware: yes I'm looking to email various teams that drive maas and try to point folks at a location for working together
[17:23] <frobware> rick_h_: ack
[17:23] <rick_h_> frobware: so will propose we start there and let the bikeshedding begin
[17:23] <frobware> :)
[17:50] <rick_h_> frobware: dimitern you guys chat? Where are we at?
[17:50] <frobware> rick_h_: otp with dimitern
[17:50] <rick_h_> frobware: k
[17:50] <frobware> rick_h_: want to join? I think we should make a call RSN
[17:51] <rick_h_> frobware: sure thing, linky?
[17:51] <frobware> rick_h_: Standup: https://hangouts.google.com/hangouts/_/canonical.com/core?authuser=0
[18:54] <frobware> rick_h_, mgz, sinzui: I just pushed another update for the vlan bug (lp-1566791-bridge-all). Do we want to wait for another CI run?
[18:56] <rick_h_> frobware: asking QA to force a run in the other channel
[18:57] <mgz> frobware: to address issues, or just with the new change rolled in as well?
[18:57] <frobware> mgz: bumped gomaasapi deps; we found a panic in there which has since merged in gomaaspi
[19:01] <mgz> frobware: gotcha
[19:46] <perrito666> k all going out for a bit bbl
[19:59] <natefinch> ew
[19:59] <natefinch> $ juju list-spaces
[19:59] <natefinch> cannot list spaces: spaces not supported (not supported)
[19:59] <natefinch> ERROR cannot list spaces: spaces not supported (not supported)
[20:00] <natefinch> I guess maybe spaces are not supported?
[20:12] <redir>  
[20:12] <redir> ruh?
[20:14] <natefinch> I think it's because I'm on lxd, which would make sense... but the error message is somewhat kinda  redundant and repetitive
[20:33] <babbageclunk> alexisb: free?
[20:33] <alexisb> babbageclunk, for you always :)
[20:34] <alexisb> babbageclunk, I will meet you in our standup HO
[20:34] <alexisb> https://hangouts.google.com/hangouts/_/canonical.com/alexis-bruemmer?
[20:34] <alexisb> https://hangouts.google.com/hangouts/_/canonical.com/alexis-bruemmer
[20:43] <alexisb> thumper, perrito666 you guys available for a HO?
[20:44] <alexisb> also, good morning thumper :)
[20:44] <thumper> morning
[20:44] <alexisb> hmm perrito666 may not be back yet
[21:00] <anastasiamac> alexisb: rick_h_: have to reboot. b there in asec- sorry
[21:23] <perrito666> Alexis still going home, I think another 30 min
[21:24] <perrito666> Alexisb^
[21:24] <alexisb> perrito666, np, just ping when you area available
[21:25]  * perrito666 is delayed by his wife shopping list
[21:25] <perrito666> If I don't get a second car soon I am going crazy
[22:05] <alexisb> thumper, on the HO if you want to meet
[22:14] <perrito666> alexisb: thumper back
[22:15] <alexisb> perrito666, do you have skype?
[22:15] <perrito666> alexisb: sure, let me snap install 1990
[22:16] <alexisb> lol
[22:16] <perrito666> alexisb: logging in
[22:18] <alexisb> let us know when you are logged in perrito666
[22:19] <perrito666> alexisb: just a few mins, had to re-download the client just finishing
[22:24] <alexisb> perrito666, are you downloading from 1990??
[22:24] <perrito666> apparently, the static got me a version that requires a set of i386 libs, lemme use my phone
[22:24] <perrito666> I am in
[22:25] <thumper> what is your skypename?
[22:25] <perrito666> perrito666
[23:06] <babbageclunk> menn0, thumper, perrito666: Can someone review this charm change? https://github.com/juju/charm/pull/221
[23:07] <babbageclunk> I mean charm url change
[23:07] <menn0> babbageclunk: sure, I'll take a look
[23:07] <babbageclunk> menn0: Ta!
[23:15] <alexisb> babbageclunk, if you are still on feel free to join the actual standup :)
[23:15] <alexisb> thumper, ping
[23:17] <thumper> babbageclunk: good to see you
[23:18] <babbageclunk> thumper: :)
[23:41] <perrito666> anastasiamac: https://bugs.launchpad.net/juju/+bug/1625390 <-- this is by design
[23:41] <mup> Bug #1625390: add  user fail after remove some user <juju:New> <https://launchpad.net/bugs/1625390>
[23:42] <perrito666> deletion of user "marks them as deleted" for "auditability" this was ian's idea iirc, perhaps redir can tell you more
[23:45] <anastasiamac> perrito666: i think we'd ned a message to say" user is in-active, re-activate user" or something like that
[23:45] <perrito666> for which we need re-activate user command
[23:46] <redir> When we implmented user removal we determined it was best to mark users deleted and leave them in the db. For 1) if a user has been deleted and an or wants to see who made change x, then we need to be able to resolve the user that made the change even if they are deleted. 2) If you created a new user with the same name, they would have surprise permissions and blame.
[23:46] <redir> anastasiamac: inactive is different than deleted
[23:46] <redir> deleted it gone permanently, no recovering.
[23:47] <anastasiamac> redir: i understand. but since they r trying to add the same username, we can tell them that this user existed but is now inactive
[23:47] <anastasiamac> this way, admin will decide whether to re-activate or to add different usernmae
[23:48] <redir> anastasiamac: IIRC we return a unique error if the user is a deleted user. And that choice was made with the intention of capturing in the add command at a future date.
[23:48] <perrito666> if you ask me it was a bad decision, one can want to delete and re-create users
[23:48] <redir> anastasiamac: there's no reactivating a deleted user
[23:50] <redir> perrito666: I think that casual users may want that, but "enterprise" users won't
[23:50] <perrito666> redir: really? sounds like re-hire is a clear use case for this
[23:51] <redir> perrito666: I've worked for a couple very large orgs more than once. And each time I get a new username.
[23:51] <perrito666> redir: I am curious what kind of username that was
[23:51] <redir> perrito666: and email name-1 name-2 name-1@example.com
[23:51] <redir> etc..
[23:51] <perrito666> lol
[23:52] <redir> yes, but if you are a large enterprise that has a lot of regulatory compliance like, say a telecom, healthcare, gov't etc... that's what they do
[23:52] <perrito666> thumper: please keep me posted on the restore issue
[23:53] <thumper> perrito666: ack
[23:53] <redir> perrito666: if they want to deactivate a user that is available too.
[23:54] <redir> and if the actual id was not the username also you could recreate users with the same username and still identify them uniquely, alas.
[23:55] <redir> adding a flag or command to resurrect a user is also possible if desired.
[23:56] <redir> whatevs
[23:57] <anastasiamac> redir: ack. i'll comment on the bug. Having worked for large enterprises and govs, I agree for auditing purposes, users r never deleted and generally once de-activated are not re-activated :)