*** angdraug has quit IRC | 00:40 | |
*** openstack has joined #openstack-solar | 04:29 | |
*** openstack has quit IRC | 04:30 | |
*** openstack has joined #openstack-solar | 04:32 | |
*** openstack has quit IRC | 04:34 | |
*** openstack has joined #openstack-solar | 04:36 | |
*** openstack has quit IRC | 04:36 | |
*** openstack has joined #openstack-solar | 04:37 | |
*** openstack has quit IRC | 04:39 | |
*** openstack has joined #openstack-solar | 14:07 | |
*** openstackgerrit_ has quit IRC | 14:36 | |
*** openstackgerrit_ has joined #openstack-solar | 14:37 | |
dshulyak | solar becomes broken if i accidentally will try to create same node 2 times :) | 14:45 |
---|---|---|
dshulyak | solar.dblayer.solar_models.DBLayerSolarException: No input port for ssh_transport_node_4 | 14:45 |
pigmej | there is a chance | 14:45 |
pigmej | ;) | 14:45 |
pigmej | because we don't check for duplicates at all | 14:46 |
pigmej | or for cycles in connections afai | 14:46 |
pigmej | afair | 14:46 |
dshulyak | do we have transaction rollback on error for sql backends ? | 14:46 |
pigmej | dshulyak: even if don't implement it | 14:48 |
dshulyak | it seems as something fails in the middle, and we end up with crappy state | 14:48 |
pigmej | it could be implemented but don't doo it | 14:48 |
dshulyak | why? | 14:48 |
salmon_ | we need a solution for duplicates, it's annoying | 14:48 |
pigmej | because you can't support the same for riak | 14:48 |
salmon_ | and i would say we need it asap :P | 14:49 |
pigmej | just don't do rollback on error, then we should drop riak completely | 14:50 |
pigmej | and redesign dblayer for "relational" stuff | 14:51 |
pigmej | we could write simple resolver which will revert previous version | 14:52 |
pigmej | but still, there is no way of creating let's say decent and stable "create if not exists" | 14:52 |
salmon_ | we just need to check for duplicates :P | 14:52 |
dshulyak | i think that we need transcations | 14:52 |
pigmej | salmon_: whan if 2 funcitons do the same check in the same time? | 14:52 |
salmon_ | pigmej: we have locks already, we may have one more :P | 14:53 |
pigmej | salmon_: and performance-- like 100s times | 14:53 |
salmon_ | at least it will be usable | 14:53 |
salmon_ | when you create 2 nodes with the same name it's unusable | 14:54 |
dshulyak | yes, it is no go to use solar res clear_all in prod:) | 14:54 |
pigmej | well, the duplicate resource is another story | 14:54 |
pigmej | ;) | 14:54 |
pigmej | anyway why do you create the same resource twice? | 14:55 |
dshulyak | it is wrong question | 14:55 |
dshulyak | u want user to check in solar if something exists before every operation? | 14:55 |
salmon_ | pigmej: because solar lets me to do it :) | 14:55 |
salmon_ | *allows | 14:56 |
pigmej | ok we can change this by stroing used names "somewhere" | 14:57 |
pigmej | in riak in strong consistent bucket (then we can easily cover in code inconsistent state) | 14:57 |
pigmej | and also you will be unable to create the same resource twice | 14:58 |
dshulyak | also it seems to me that such operations as solar create resource should be atomic, otherwise if it will fail 1st time in the middle - we will have inconsistent state in database | 14:58 |
dshulyak | and every 2nd operation will lead to error | 14:58 |
dshulyak | every next | 14:58 |
pigmej | single resource.create is atomic | 14:59 |
dshulyak | with inputs? | 14:59 |
pigmej | inputs are stored inside resource | 14:59 |
pigmej | so yes, with inputs | 15:00 |
dshulyak | i meant with connections | 15:00 |
pigmej | connections are given on resource.connect() | 15:00 |
pigmej | and it's also atomic, because you resoruce.connect(other_resouce) | 15:00 |
dshulyak | yes, but if u do creation of vr - it is not atomic :) | 15:01 |
pigmej | you mean several resources? | 15:01 |
dshulyak | from user point of view - vr is single operation, isnt it? | 15:01 |
pigmej | several resources == several db objects != atomic | 15:02 |
dshulyak | yeah, but using transcations it could be | 15:02 |
dshulyak | and i think thats the problem for us | 15:02 |
pigmej | then mv riak Trash/ | 15:02 |
dshulyak | or implement our own transcations stuff, yes? which is not very good idea | 15:03 |
pigmej | it's possible but for sure not now :) | 15:03 |
pigmej | we could do some post check on riak though | 15:03 |
pigmej | also, I'm not sure if you need transactions for this, what we for sure need is to *not* fuckup database | 15:04 |
pigmej | like we can do now | 15:04 |
dshulyak | btw resource.connect cretes 1 or atleast 2 indexes? one on receiver, another on emitter? | 15:04 |
pigmej | no | 15:04 |
pigmej | only receiver | 15:04 |
dshulyak | so only 1? | 15:04 |
pigmej | or emitter because I don't remebmer exacly | 15:04 |
pigmej | several indexes but bound to single object | 15:04 |
pigmej | and all operations inside single objects are "all or none" | 15:05 |
pigmej | it seems that connections are stored in emitter | 15:09 |
pigmej | (I always mess it up so I may be wrong :D) | 15:09 |
pigmej | ? | 15:14 |
pigmej | salmon_: what would you expect on name conflict ? | 15:21 |
pigmej | I can fix it in ~1minute | 15:21 |
pigmej | it will be ugly fix | 15:21 |
pigmej | but it will allow you to work | 15:21 |
salmon_ | pigmej: exception will be fine | 15:22 |
pigmej | I can do naive check | 15:22 |
pigmej | with big warning in code | 15:22 |
openstackgerrit | Bogdan Dobrelya proposed openstack/solar: Separate vagrantfile for the docker provider https://review.openstack.org/288525 | 15:22 |
pigmej | that it will work only under certain conditions | 15:22 |
salmon_ | what conditions? | 15:25 |
pigmej | no concurrent env | 15:26 |
pigmej | maybe later we could add something smarter | 15:26 |
pigmej | like write smarter conflict solver there | 15:26 |
pigmej | which could inform you that something is fucked up, and it should provide then way to solve this | 15:26 |
dshulyak | this anchors are really painfull.. we need somehow insert them every time something needs is changed/added | 15:29 |
pigmej | And I still don't know why that graph part is slow | 15:31 |
pigmej | lazy_save is pretty much everywhere ;/ | 15:31 |
openstackgerrit | Jedrzej Nowak proposed openstack/solar: Added naive method to check if object already exists https://review.openstack.org/288560 | 16:15 |
pigmej | salmon_: with dedication for you :) | 16:15 |
pigmej | dshulyak: after we will land F2S we can sit and fix our things for "already exists", sounds like a plan? | 16:16 |
pigmej | :) | 16:16 |
salmon_ | :) | 16:20 |
pigmej | salmon_: consider this as "hacky" solution ;) | 16:21 |
pigmej | we may add later smarter way for each backend | 16:21 |
pigmej | ok I know why PG is 100% cpu | 16:58 |
pigmej | because of broken pool implementation, it's too complicated and it causes ~80% of load | 16:58 |
pigmej | it seems... | 16:58 |
pigmej | and it's slow | 16:58 |
pigmej | I will swap it and it will be probably fast agai | 16:58 |
pigmej | again* | 16:58 |
*** angdraug has joined #openstack-solar | 17:00 | |
pigmej | but that pool is not used by default, so on non pool stuff, it's even worse, and there is our reason :) | 17:01 |
pigmej | I wasted day for it;/ | 17:01 |
pigmej | ok like half | 17:01 |
pigmej | ok even with default pool it's better, but that pool is stupid as hell, on monday I will write custom pool that will suit our needs | 17:24 |
pigmej | on pg: Total Delta: 8.561658144 | 17:25 |
pigmej | Total Time: 8.56659507751 | 17:25 |
pigmej | :) | 17:25 |
pigmej | and no 100% | 17:25 |
pigmej | dshulyak: salmon_ | 17:25 |
salmon_ | I use sqlite but cool ;) | 17:26 |
pigmej | do you have 100% cpu ? | 17:26 |
pigmej | https://bpaste.net/show/cfde75f7e23a | 17:26 |
pigmej | with this and solar o run-once last (stage && process before) on PG you will have 100% CPU | 17:27 |
salmon_ | I have | 17:27 |
pigmej | on sqlite? | 17:28 |
pigmej | for sqlite I even can understand 100% without optimization in that garphs update | 17:28 |
*** dshulyak has left #openstack-solar | 17:51 | |
*** salmon_ has quit IRC | 22:53 | |
*** angdraug has quit IRC | 23:16 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!