| axw | anastasiamac: if we can avoid it, I'd rather not change the API to be bulk, but instead, have a transaction API. Begin, <make a series of updates>, End | 00:13 |
|---|---|---|
| anastasiamac | 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:30 |
| anastasiamac | axw: there is no problems having an UpdateModel and UpdateModels | 00:31 |
| axw | 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:05 |
| axw | 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:06 |
| anastasiamac | 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:07 |
| anastasiamac | axw: right now, RefreshModels call store to UpdateModel per each model and each of these calls takes a lock. | 01:08 |
| axw | anastasiamac: I understand all that, so not following how I've misread... | 01:08 |
| anastasiamac | axw: if u r updating a collection, u have n muber of models and n of locks | 01:08 |
| anastasiamac | axw: store API should support updating bulk | 01:08 |
| anastasiamac | axw: don;t get thr resisitance... how did we add accounts, cookie jar, etc to jujuclient api... | 01:09 |
| axw | 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:09 |
| axw | anastasiamac: maybe this is better on a HO, I don't think I'm getting my point across very well here | 01:10 |
| anastasiamac | axw: sure, but this are internal to jujuclint implementation. why expose Begin and End, especially i interface? | 01:10 |
| anastasiamac | axw: k. m ahppty to HO... gimme 10mins to put a face on :D | 01:11 |
| axw | anastasiamac: because it would be useful for reasons other than updating a bunch of models at once... | 01:11 |
| anastasiamac | axw: sure, but would b irrelevant to other implementation of client.. like mem... | 01:11 |
| anastasiamac | let's talk ina 10-15.. i'll ping | 01:11 |
| axw | anastasiamac: not really. they can use an (in-memory) lock too. they're just for testing atm though. talk soon... | 01:12 |
| babbageclunk | axw: ping? | 03:00 |
| axw | babbageclunk: pong! | 03:02 |
| babbageclunk | axw: Hi! Can you explain the maas agent name thing to me? | 03:03 |
| babbageclunk | axw: What's it updating it from/to? | 03:03 |
| axw | babbageclunk: sure. do you know what agent_name is? | 03:04 |
| axw | I mean, conceptually, not the value | 03:04 |
| babbageclunk | axw: nope | 03:04 |
| axw | 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 |
| axw | babbageclunk: we use it to identify nodes for a model | 03:05 |
| axw | 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:05 |
| babbageclunk | axw: So is it destructive? After the update could the old environment still run? | 03:06 |
| babbageclunk | axw: Thanks though, that makes sense. | 03:06 |
| axw | babbageclunk: the old environment won't find those nodes any more, unless you were to change it back again | 03:07 |
| babbageclunk | 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 |
| axw | rollback for that can't really be automated, because you need to get onto the region controller | 03:07 |
| axw | babbageclunk: yes it is, and yes we could | 03:07 |
| thumper | oh ffs | 03:08 |
| babbageclunk | axw: Ok - I'll do that, if you can point me to the right place? | 03:08 |
| thumper | I'm looking at merging 2.2 into devel | 03:08 |
| * babbageclunk ducks | 03:08 | |
| thumper | there are so many conflicts | 03:08 |
| thumper | I thought that wallyworld fixed those | 03:09 |
| axw | babbageclunk: wait... the command already does that :) | 03:09 |
| babbageclunk | thumper: I think they're probably caused by the rearranging of API facades? | 03:09 |
| axw | babbageclunk: at the end, it calls UpdateEnvironConfig with the new maas_agent | 03:09 |
| babbageclunk | axw: ha ha, that was clever of you! | 03:09 |
| thumper | babbageclunk: some of it | 03:10 |
| babbageclunk | thumper: Might be simpler if we make the same change in 2.2 branch. | 03:10 |
| wallyworld | each time you merge into develop now you'll get conflicts | 03:10 |
| * thumper enfixorates | 03:10 | |
| thumper | wallyworld: really? that blows | 03:10 |
| thumper | can't it figure this shit out? | 03:10 |
| babbageclunk | axw: Ok cool, so it sounds like this isn't really a destructive thing. | 03:11 |
| wallyworld | not that i've seen | 03:11 |
| axw | babbageclunk: yeah sorry, I forgot I did that bit | 03:11 |
| axw | babbageclunk: if you were to revert to an older version of state, it would be busted | 03:11 |
| axw | in that case you'd need to update maas_agent in the MAAS pg database | 03:11 |
| wallyworld | thumper: the issue from what i recall is the big facade moves, it gets confused with those if you make facade changes | 03:12 |
| babbageclunk | axw: You mean an older version in the juju1 tree? | 03:12 |
| babbageclunk | thumper: That's why I think it might be easier if we do the same rearranging in the 2.2 branch. | 03:13 |
| axw | babbageclunk: no I mean, if you took a mongo backup before running the update-maas-agentname command, and reverted to that | 03:13 |
| babbageclunk | Ah, right. | 03:13 |
| babbageclunk | thumper: (although I'm not sure how much work the rearranging was - at least a lot of import fixing, maybe more than that.) | 03:14 |
| thumper | I have a feeling that some of these methods that 2.2 is trying to add to the client backend interface have moved | 03:15 |
| * thumper sighs | 03:17 | |
| * thumper takes a stab | 03:17 | |
| thumper | oh ffs | 03:47 |
| thumper | axw: do you have a few minutes? | 03:58 |
| thumper | perhaps jump in tech board early? | 03:58 |
| axw | thumper: sure, brt | 03:58 |
| thumper | looking at 2.2 merge into develop | 03:58 |
| babbageclunk | thumper: hey do you have a moment? | 04:15 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!