d there, does that effect our transactionality ?
<jam> (things which we touch are never refreshed
<voidspace> dimitern: the network id that AllocateAddress will take, is that a "provider specific" id (i.e. one we can pass directly to ec2)
<dimitern> voidspace, that's the idea, yes
<dimitern> voidspace, for ec2 it probably will be a subnet-id
<fwereade> jam, so, the idea is that you *can* always get settings for remote units that aren't currently part of the relation
<dimitern> voidspace, but it's unused for now - intended to be future-proof :)
<fwereade> jam, but that we expect that to be "rare"
<jam> fwereade: I don't disagree on either of those points
<fwereade> jam, so we persist them only for the lifetime of the context
<jam> is this a lifetime of data cached in memory issue ?
<fwereade> jam, it doesn't affect the guarantees we make
<fwereade> jam, yeah
<fwereade> jam, it's always been, and always will be, possible to see relation data "from the future"
<fwereade> jam, but within a given context, once you've asked for some settings, they won't change
<jam> fwereade: sure, but what causes Prune() to be called
<jam> as if you do "relation-get NOT_A_MEMBER" and then trigger a Prune and then another "relation-get NOT_A_MEMBER" you will get different data
<jam> (*can* get different data)
<voidspace> dimitern: ah, we're designing in imaginary future use cases...
<dimitern> voidspace, it's not imaginary, it's in the draft model :)
<voidspace> dimitern: :-p
<jam> fwereade: also "relation-get A_MEMBER" and then mark that as no longer a member and "relation-get WAS_A_MEMBER" will give different data
<fwereade> jam, we Prune to the current membership list at context creation time
<fwereade> jam, calling prune/remove/invalidate while a context is in play will not have happy consequenes, I agree
<jam> fwereade: so I do see one possible bug, which is if you do "context.Settings("x/2"), then context.InvalidateMember("x/2"), and then context.Settings("x/2") it won't reread the data
<jam> because it will pull it out of "other