[00:13] anastasiamac: if we can avoid it, I'd rather not change the API to be bulk, but instead, have a transaction API. Begin, , End [00:30] axw: why not? with current indiivudal update, u r taking lock every single time... if u have 100s models to update, u'll b getting this lock 100s times... feels yuck [00:31] axw: there is no problems having an UpdateModel and UpdateModels [01:05] anastasiamac: any additional code is not free, so I reject the statement that there are "no problems". what I meant by a transactional API is one that takes a lock at the beginning of the transaction, and releases it at the end, and only does a single write at the end [01:06] anastasiamac: that will be useful for doing things other than just writing a bunch of models at once. e.g. writing controller, account, and model details all at once [01:07] axw: u misread what i said... right now jujuclient api has 2 official/our implementations: file and mem. mem is used for testing. file is the real deal/production we ship. file one takes a lock in implementation (i.e. once u r in a call to UpdateModel)... [01:08] axw: right now, RefreshModels call store to UpdateModel per each model and each of these calls takes a lock. [01:08] anastasiamac: I understand all that, so not following how I've misread... [01:08] axw: if u r updating a collection, u have n muber of models and n of locks [01:08] axw: store API should support updating bulk [01:09] axw: don;t get thr resisitance... how did we add accounts, cookie jar, etc to jujuclient api... [01:09] anastasiamac: yep, at the moment. again: I'm proposing we introduce a pair of methods, Begin & End (say), which will make the locking happen in the Begin and End calls rather than each UpdateModel call [01:10] anastasiamac: maybe this is better on a HO, I don't think I'm getting my point across very well here [01:10] axw: sure, but this are internal to jujuclint implementation. why expose Begin and End, especially i interface? [01:11] axw: k. m ahppty to HO... gimme 10mins to put a face on :D [01:11] anastasiamac: because it would be useful for reasons other than updating a bunch of models at once... [01:11] axw: sure, but would b irrelevant to other implementation of client.. like mem... [01:11] let's talk ina 10-15.. i'll ping [01:12] anastasiamac: not really. they can use an (in-memory) lock too. they're just for testing atm though. talk soon... [03:00] axw: ping? [03:02] babbageclunk: pong! [03:03] axw: Hi! Can you explain the maas agent name thing to me? [03:03] axw: What's it updating it from/to? [03:04] babbageclunk: sure. do you know what agent_name is? [03:04] I mean, conceptually, not the value [03:04] axw: nope [03:05] babbageclunk: ok. when you acquire a node from MAAS, you can specify a string (agent_name value) to associate with that node. you can then use that for filtering node queries later on [03:05] babbageclunk: we use it to identify nodes for a model [03:05] babbageclunk: in 1.25, we used to generate a new UUID for the agent_name. in juju 2.x, we just use the model UUID [03:06] axw: So is it destructive? After the update could the old environment still run? [03:06] axw: Thanks though, that makes sense. [03:07] babbageclunk: the old environment won't find those nodes any more, unless you were to change it back again [03:07] axw: I guess in 1.25 the uuid is stored somewhere in config - could we update it there so it still matched up? [03:07] rollback for that can't really be automated, because you need to get onto the region controller [03:07] babbageclunk: yes it is, and yes we could [03:08] oh ffs [03:08] axw: Ok - I'll do that, if you can point me to the right place? [03:08] I'm looking at merging 2.2 into devel [03:08] * babbageclunk ducks [03:08] there are so many conflicts [03:09] I thought that wallyworld fixed those [03:09] babbageclunk: wait... the command already does that :) [03:09] thumper: I think they're probably caused by the rearranging of API facades? [03:09] babbageclunk: at the end, it calls UpdateEnvironConfig with the new maas_agent [03:09] axw: ha ha, that was clever of you! [03:10] babbageclunk: some of it [03:10] thumper: Might be simpler if we make the same change in 2.2 branch. [03:10] each time you merge into develop now you'll get conflicts [03:10] * thumper enfixorates [03:10] wallyworld: really? that blows [03:10] can't it figure this shit out? [03:11] axw: Ok cool, so it sounds like this isn't really a destructive thing. [03:11] not that i've seen [03:11] babbageclunk: yeah sorry, I forgot I did that bit [03:11] babbageclunk: if you were to revert to an older version of state, it would be busted [03:11] in that case you'd need to update maas_agent in the MAAS pg database [03:12] thumper: the issue from what i recall is the big facade moves, it gets confused with those if you make facade changes [03:12] axw: You mean an older version in the juju1 tree? [03:13] thumper: That's why I think it might be easier if we do the same rearranging in the 2.2 branch. [03:13] babbageclunk: no I mean, if you took a mongo backup before running the update-maas-agentname command, and reverted to that [03:13] Ah, right. [03:14] thumper: (although I'm not sure how much work the rearranging was - at least a lot of import fixing, maybe more than that.) [03:15] I have a feeling that some of these methods that 2.2 is trying to add to the client backend interface have moved [03:17] * thumper sighs [03:17] * thumper takes a stab [03:47] oh ffs [03:58] axw: do you have a few minutes? [03:58] perhaps jump in tech board early? [03:58] thumper: sure, brt [03:58] looking at 2.2 merge into develop [04:15] thumper: hey do you have a moment? === tinwood_ is now known as tinwood === salmankhan1 is now known as salmankhan === frankban is now known as frankban|afk === mjs0 is now known as menn0