| *** evgenyl has quit IRC | 00:08 | |
| *** sylwesterB has quit IRC | 00:09 | |
| *** evgenyl has joined #openstack-solar | 00:09 | |
| *** sylwesterB has joined #openstack-solar | 00:10 | |
| *** evgenyl has quit IRC | 00:16 | |
| *** evgenyl has joined #openstack-solar | 00:17 | |
| *** ikalnitsky_ has joined #openstack-solar | 05:42 | |
| *** pigmej_ has joined #openstack-solar | 05:48 | |
| *** ikalnitsky has quit IRC | 05:49 | |
| *** pigmej has quit IRC | 05:49 | |
| *** pigmej_ is now known as pigmej | 05:49 | |
| *** ikalnitsky_ is now known as ikalnitsky | 05:50 | |
| *** salmon_ has joined #openstack-solar | 07:27 | |
| openstackgerrit | Lukasz Oles proposed openstack/solar: Allow to use any IPs with fuel-devops https://review.openstack.org/273665 | 08:16 |
|---|---|---|
| openstackgerrit | Lukasz Oles proposed openstack/solar: Use yaml to load data in solar create https://review.openstack.org/273664 | 08:18 |
| openstackgerrit | Lukasz Oles proposed openstack/solar: Allow to use any IPs with fuel-devops https://review.openstack.org/273665 | 08:18 |
| openstackgerrit | Lukasz Oles proposed openstack/solar: Use yaml to load data in solar create https://review.openstack.org/273664 | 08:19 |
| openstackgerrit | Lukasz Oles proposed openstack/solar: Allow to use any IPs with fuel-devops https://review.openstack.org/273665 | 08:19 |
| salmon_ | :) | 08:20 |
| *** dshulyak has joined #openstack-solar | 08:26 | |
| salmon_ | dshulyak: o/ | 08:28 |
| dshulyak | hello | 08:30 |
| pigmej | hey guys :) | 08:40 |
| openstackgerrit | Merged openstack/solar: Use yaml to load data in solar create https://review.openstack.org/273664 | 09:00 |
| openstackgerrit | Merged openstack/solar: Hardcode python 2 usage https://review.openstack.org/274282 | 09:55 |
| *** openstackgerrit has quit IRC | 10:02 | |
| *** openstackgerrit_ has joined #openstack-solar | 10:02 | |
| *** openstackgerrit_ has quit IRC | 10:03 | |
| pigmej | dshulyak: https://review.openstack.org/#/c/273540/ https://review.openstack.org/#/c/273539/ jenkins voted -1 | 10:04 |
| dshulyak | pigmej: you will go to ost summit? | 10:06 |
| pigmej | dshulyak: I'm not aware of this ;D | 10:07 |
| pigmej | btw where are mike notes ? | 10:08 |
| dshulyak | pigmej: i thought that was the purpose of getting visa | 10:08 |
| salmon_ | pigmej: https://etherpad.openstack.org/p/fuel-solar-workshop-poznan-jan-16 | 10:08 |
| pigmej | some say that I will visit sunnyvale in march | 10:08 |
| pigmej | that's all taht I know right now | 10:08 |
| pigmej | dshulyak: btw, short summary about solar things in poznan is "pretty much nothing changed from solar perspective" | 10:09 |
| pigmej | :) | 10:09 |
| dshulyak | i see, looks like nothing was changed except that we will fetch data from config service instead of nailgun | 10:12 |
| salmon_ | dshulyak: no, ConfigService will become config api on top of solar | 10:12 |
| pigmej | yup | 10:13 |
| pigmej | like UX | 10:13 |
| salmon_ | that's the biggest change | 10:13 |
| pigmej | sure, but it's kinda unrelated for whole picture | 10:14 |
| dshulyak | ok, i will wait for meeting | 10:14 |
| pigmej | one thing that changed, is that we will need immediate feedback from all DPs, so we will need to execute them frequently, we also discussed how DPs will be executed etc. | 10:15 |
| pigmej | let's say that the original idea is the same, but we know more details about it :) | 10:15 |
| dshulyak | yeah, i remember Mike was talking about it in MV | 10:15 |
| pigmej | salmon_: It looks like we did nothing in poznan :D | 10:16 |
| salmon_ | we played some foosball ;) | 10:17 |
| pigmej | dshulyak: we missed you a lot in poznan | 10:17 |
| pigmej | not only because of foosball :P | 10:18 |
| salmon_ | dshulyak: https://bugs.launchpad.net/solar/+bug/1540304 | 10:50 |
| openstack | Launchpad bug 1540304 in Solar "When solar worker is not running run-once doesn't return error" [High,New] | 10:50 |
| dshulyak | ok, but it is push/pull and you dont know if there is someone on the other side | 10:52 |
| salmon_ | dshulyak: ok, so worker when is starting should check db for tasks | 10:53 |
| dshulyak | there is no information in db | 10:54 |
| salmon_ | how so? report is taking info from db | 10:55 |
| salmon_ | so the only way is to run restart? | 10:55 |
| dshulyak | no in this sense, there is no information in db if scheduler should execut workflow | 10:55 |
| salmon_ | :/ | 10:56 |
| dshulyak | this message should come from queue | 10:56 |
| salmon_ | ok, so start worker, restart deploy | 10:56 |
| dshulyak | i think that zero should allow late binding of server | 10:56 |
| dshulyak | i will check that | 10:56 |
| pigmej | dshulyak: better not | 10:57 |
| dshulyak | why? | 10:57 |
| pigmej | because then we're not in control about messages | 10:57 |
| pigmej | and we may execute very old stuff | 10:57 |
| dshulyak | you are right, thats possible, i can also change zero sockets from push/pull to other model, and acknowledge each event before processing it | 10:59 |
| dshulyak | we will see error atleast | 10:59 |
| pigmej | yeah that may be better | 10:59 |
| dshulyak | i watched video from Rich Hickey about datomic.. | 11:06 |
| dshulyak | and was wtf.. | 11:06 |
| pigmej | why ? | 11:07 |
| dshulyak | what datomic is doing? except incremental history, additional consistency guarantees on top of common db | 11:09 |
| pigmej | pretty much nothing more | 11:12 |
| pigmej | but it can act as external coordinator, but don't worry, we will not gonna use it :) | 11:12 |
| pigmej | datomic is distaibuted datalog, it adds you kinda transactions though | 11:13 |
| dshulyak | nah, i am not, it just seemed like an interesting piece of software from clojure author | 11:13 |
| pigmej | the interesting part is closed source :) | 11:14 |
| pigmej | salmon_: https://bugs.launchpad.net/solar/+bug/1539174 to this is fixed, isn't it ? | 11:39 |
| openstack | Launchpad bug 1539174 in Solar "Composer files may changes data type" [Critical,Confirmed] | 11:39 |
| salmon_ | pigmej: nope | 11:39 |
| salmon_ | pigmej: I just have workaround in nodes.yaml | 11:39 |
| pigmej | ah right | 11:40 |
| *** openstackgerrit has joined #openstack-solar | 11:53 | |
| *** openstackgerrit has quit IRC | 11:54 | |
| *** openstackgerrit_ has joined #openstack-solar | 11:54 | |
| *** openstackgerrit_ is now known as openstackgerrit | 11:55 | |
| *** openstackgerrit has quit IRC | 11:59 | |
| *** openstackgerrit has joined #openstack-solar | 12:07 | |
| openstackgerrit | Jedrzej Nowak proposed openstack/solar: Removed all __init__ files from pep8 ignore https://review.openstack.org/274634 | 12:25 |
| pigmej | I really hate hacking + pep8 combo | 12:26 |
| openstackgerrit | Jedrzej Nowak proposed openstack/solar: Removed all __init__ files from pep8 ignore https://review.openstack.org/274634 | 12:40 |
| pigmej | salmon_: fixed probably | 12:41 |
| openstackgerrit | Dmitry Shulyak proposed openstack/solar: Introduce documentation related to new worker https://review.openstack.org/274642 | 12:43 |
| pigmej | dshulyak: cool :) | 12:44 |
| pigmej | can you guys review https://review.openstack.org/#/c/274614/ ? | 12:44 |
| dshulyak | i still need to work on it, but i want switch from documentation for now :) | 12:44 |
| pigmej | dshulyak: smart choice :D | 12:44 |
| dshulyak | btw what about that meeting? | 12:48 |
| dshulyak | salmon_: pigmej ^ | 12:48 |
| salmon_ | mihgen: tomorrow we are going to schedule a meeting with all interested guys and summarize Poznan meeting. Do you also want to attend? If yes, in which time zone are you now? | 12:51 |
| pigmej | salmon_: tomorrow time table is a bit packed from what I see | 12:57 |
| pigmej | from what I see we have no common free slot for vova | 12:58 |
| pigmej | sounds like wednesday ~1PM polish time is free slot | 12:59 |
| salmon_ | ok, scheduled for thursday... You are very busy guys... | 13:06 |
| salmon_ | If I missed someone please add him | 13:06 |
| pigmej | btw, then I think we should make fast introduction for dima tomorrow | 13:06 |
| salmon_ | Pls review: https://github.com/Mirantis/solar-resources/pull/13 | 13:13 |
| salmon_ | https://review.openstack.org/#/c/273665/4 | 13:13 |
| salmon_ | https://github.com/Mirantis/solar-resources/pull/14 | 13:13 |
| salmon_ | and merge in that order | 13:13 |
| pigmej | salmon_: https://review.openstack.org/#/c/273967/ :( | 13:15 |
| salmon_ | my was first :P | 13:16 |
| pigmej | your is easier to rebase :P | 13:16 |
| salmon_ | :P | 13:16 |
| pigmej | my was reviewed first :P | 13:17 |
| pigmej | salmon_: just check it, if it's fine, I can rebase probably | 13:17 |
| pigmej | D: | 13:19 |
| openstackgerrit | Merged openstack/solar: Removed ssh_ prefix from transports resources https://review.openstack.org/273967 | 13:20 |
| openstackgerrit | Lukasz Oles proposed openstack/solar: Allow to use any IPs with fuel-devops https://review.openstack.org/273665 | 13:32 |
| pigmej | salmon_: can you fix https://github.com/Mirantis/solar-resources/pull/13 + https://github.com/Mirantis/solar-resources/pull/14 ? | 13:38 |
| salmon_ | pigmej: done | 13:39 |
| pigmej | It would be cool if we can have script that would create resoruces | 13:40 |
| pigmej | nodes | 13:40 |
| salmon_ | ? | 13:42 |
| pigmej | after we merge this all examples and their usage will be not valid | 13:49 |
| pigmej | I would expect a script / python whatever that just creates nodes with default configuration | 13:52 |
| salmon_ | you can always create nodes with: solar resource create nodes templates/nodes count=X | 13:52 |
| pigmej | where default is let's say vagrant env | 13:52 |
| salmon_ | solar resource create nodes templates/nodes count=X | 13:52 |
| pigmej | docs updates then are required :) | 13:53 |
| salmon_ | where? | 13:53 |
| pigmej | hmm | 13:53 |
| pigmej | I was pretty sure that we docummented it | 13:54 |
| pigmej | but it turns out that no | 13:54 |
| salmon_ | we just have links to the examples | 13:54 |
| salmon_ | you may add it:P | 13:54 |
| pigmej | ;P | 13:54 |
| openstackgerrit | Jedrzej Nowak proposed openstack/solar: Removed deprecated ansible handler documentation https://review.openstack.org/274671 | 13:57 |
| pigmej | I removed it because it's deprecated / obsolete | 13:58 |
| pigmej | w need new documentation about handlers https://bugs.launchpad.net/solar/+bug/1540383 | 13:58 |
| openstack | Launchpad bug 1540383 in Solar "Add documentation about handlers internals" [Undecided,New] | 13:58 |
| dshulyak | pigmej: have you saw such errors http://paste.openstack.org/show/485602/ ? | 14:01 |
| dshulyak | but | 14:05 |
| dshulyak | from solar.orchestration.workers import tasks | 14:05 |
| dshulyak | works | 14:05 |
| pigmej | eee | 14:08 |
| pigmej | maybe my recent changes about pep8 + init.py ? | 14:09 |
| dshulyak | no, this is my patches | 14:09 |
| dshulyak | with -1 from ci | 14:10 |
| dshulyak | i noticed that gevent works same way sometimes.. | 14:10 |
| dshulyak | sometimes gevent.pool.Pool works :) and sometimes it fails with AttributeError, but i never wanted to debug it | 14:10 |
| pigmej | ah | 14:11 |
| pigmej | stupid import order probably then | 14:11 |
| pigmej | just like ansible | 14:11 |
| pigmej | dshulyak: probably circural import | 14:12 |
| pigmej | https://github.com/openstack/solar/blob/master/solar/core/handlers/ansible_playbook_local.py#L18-L22 | 14:12 |
| pigmej | check this beautifull hack :) | 14:12 |
| dshulyak | i see | 14:12 |
| dshulyak | but i am not importing orchestration.workers at all | 14:14 |
| dshulyak | thats like first import of that module | 14:15 |
| dshulyak | oh crap | 14:21 |
| dshulyak | if one wants to use submodules like that - you should do imports of all submodules in __init__.py | 14:22 |
| dshulyak | import solar.orchestration.workers.scheduler | 14:23 |
| dshulyak | import solar.orchestration.workers.tasks | 14:23 |
| dshulyak | import solar.orchestration.workers.system_log | 14:23 |
| pigmej | ... | 14:25 |
| pigmej | and because of pep8 / hacking you cannot `*` | 14:26 |
| openstackgerrit | Dmitry Shulyak proposed openstack/solar: Every extension should be able to subscribe to events of other ext https://review.openstack.org/273539 | 14:32 |
| pigmej | dshulyak: jenkins dislikes you :p | 14:45 |
| dshulyak | i dont really like gerrit workflow :( i think i will merge 2 patches into 1 | 14:46 |
| pigmej | I dislike it too ;P | 14:47 |
| pigmej | but, you can work on nested commits | 14:47 |
| pigmej | but the tests are problem | 14:47 |
| dshulyak | it is ok when you are doing simple change | 14:52 |
| pigmej | yup | 14:54 |
| pigmej | lunch! | 14:54 |
| openstackgerrit | Dmitry Shulyak proposed openstack/solar: Plugable constructors, runners and hooks https://review.openstack.org/273540 | 14:54 |
| openstackgerrit | Dmitry Shulyak proposed openstack/solar: Introduce documentation related to new worker https://review.openstack.org/274642 | 14:54 |
| pigmej | back | 15:13 |
| pigmej | dshulyak: that https://review.openstack.org/274642 is still wip, isn't it? | 15:22 |
| dshulyak | yes | 15:22 |
| pigmej | k | 15:24 |
| pigmej | btw how do you like stevedore? | 15:24 |
| openstackgerrit | Jedrzej Nowak proposed openstack/solar: Added info that our examples require nodes https://review.openstack.org/274713 | 15:29 |
| pigmej | dshulyak: have you tested your zmq thingy with multiple processes and let's say tcp transport? | 15:30 |
| dshulyak | pigmej: i expect it to fail | 15:31 |
| dshulyak | ) | 15:31 |
| pigmej | dshulyak: why? | 15:31 |
| pigmej | we should support it | 15:31 |
| pigmej | otherwise zmq thingy makes small sense for us | 15:31 |
| dshulyak | because multiple servers shouldnt be able to bind to the same endpoint | 15:31 |
| pigmej | SO_REUSEADDR :P | 15:32 |
| pigmej | but yeah, some router pattern will be needed then | 15:32 |
| dshulyak | em, no | 15:33 |
| dshulyak | it wont allow to bind 2 servers to exactly same socket | 15:33 |
| pigmej | sure it will not by default | 15:33 |
| pigmej | but still, it should be supported by solar worker to have multiple processes | 15:33 |
| pigmej | otherwise what's the point of having zmq ? | 15:34 |
| pigmej | if the same could be archived with let's say pipe / gevent queue? | 15:34 |
| dshulyak | yes, but we will need router with zero | 15:36 |
| pigmej | yup | 15:36 |
| pigmej | I wanted to know in theory if code let's say supports it | 15:37 |
| pigmej | dshulyak: so let's say I want (not that I want to do it) plug some big message system behind scenes, it should be possible then ? | 15:37 |
| dshulyak | there should be no problem to put zmq router between client and server, and for example with rabbitmq it is the same, server will declare all required exchange/queue options, and client will communicate the same way | 15:40 |
| pigmej | dshulyak: k, then the answer for me is 'yes' :) | 15:42 |
| dshulyak | but we wont be able to use only soe gevent queue, because scheduler should be available for external clients | 15:44 |
| dshulyak | s/soe/some | 15:44 |
| dshulyak | pigmej: how rollback different from update? | 15:55 |
| pigmej | ? | 15:56 |
| pigmej | I don't understand context :) | 15:56 |
| pigmej | dshulyak: | 15:56 |
| dshulyak | you said that you found some issues with rollback | 15:56 |
| dshulyak | i am interested how it is different from update | 15:57 |
| dshulyak | :) | 15:57 |
| pigmej | in poznan? | 15:57 |
| dshulyak | yes | 15:57 |
| dshulyak | i think so :) | 15:57 |
| pigmej | from solar side it's thesame | 15:57 |
| pigmej | from bigger perspective it's not | 15:57 |
| pigmej | you cannot rollback when you don't own the data | 15:57 |
| dshulyak | from nailgun side lets say | 15:57 |
| dshulyak | any client of solar | 15:58 |
| pigmej | so, if you assigned ip 10.0.0.10 first, then you released it, someone other may take 10.0.0.10 ip for other purpose, then you can't rollback to 10.0.0.10 | 15:59 |
| pigmej | we can set it in solardb but any automatic rollback will fail | 15:59 |
| dshulyak | yes | 15:59 |
| pigmej | and that's the point why "we cannot support rollbacks" | 15:59 |
| dshulyak | and this is quite easy for nailgun to decide | 15:59 |
| pigmej | from solar perspective it's easy, from bigger picture it's not | 15:59 |
| dshulyak | it is just update | 15:59 |
| pigmej | yup | 15:59 |
| pigmej | BUT would you expect that rollback in your environment affects another environment ? Even when it's totally isolated ? | 16:00 |
| pigmej | not to mention that changes in the second environment may affect other envs, or other parts in first env | 16:01 |
| dshulyak | if 2 envs will share some network - they are not isolated, but is is actually not important | 16:01 |
| dshulyak | the importatnt part is that you can validate this | 16:01 |
| pigmej | the same situation with bind ports, and pretty much all "not solar" managed stuf :) | 16:01 |
| pigmej | yeah we can validate it. But that's all | 16:01 |
| pigmej | but the result is: "we *may* support rollbacks if you're lucky" | 16:02 |
| pigmej | :) | 16:02 |
| dshulyak | not lucky.. | 16:02 |
| pigmej | kinda lucky, | 16:03 |
| pigmej | we could also throw an error / message that manual invervention is needed | 16:03 |
| dshulyak | ok, my point was that rollback is nothing special from update | 16:03 |
| pigmej | and "please resume when you're set" | 16:03 |
| pigmej | dshulyak: sure, it changes nothing :) | 16:03 |
| dshulyak | and saying that rollback of ips is not possible means that even update isnt possible | 16:03 |
| pigmej | no, because update is new fresh state | 16:03 |
| pigmej | like you cannot acquire used ip | 16:04 |
| dshulyak | no | 16:04 |
| pigmej | because network manager will take care about it | 16:04 |
| dshulyak | see example | 16:04 |
| pigmej | BUT with rollback / revert we cannot guarantee it | 16:04 |
| dshulyak | x = 10.0.0.1 y 10.0.0.2 , swap them with update | 16:04 |
| dshulyak | same sequence of actions | 16:04 |
| pigmej | dshulyak: sure but it's good case | 16:05 |
| pigmej | I mean "the working one" | 16:05 |
| dshulyak | yes, it is both rollbackable and updatable because 1 == 2 :) | 16:05 |
| dshulyak | can you show me bad one? | 16:06 |
| dshulyak | with x and y :) | 16:06 |
| pigmej | imagine, x = 10.0.0.10, then you update 10.0.0.0/24 network to 192.168.0.0/24, so you regenerated ip 10.0.0.10 to 192.168.0.10 (let's say), you kinda refreshed this info with solar update (or whatever), and well, you cannot rollback this change easily | 16:06 |
| pigmej | because something other may need 192.168.0.0 network, and we can't just set 10.0.0.10/24 in a place of 192.168.0.10/24 because it will be also invalid | 16:06 |
| dshulyak | but can you update x to 10.0.0.0/24 :) ? | 16:07 |
| pigmej | same happens when you change IP like x= 10.0.0.10 then x = 10.0.0.11, what happens is that you acquire new ip, then release 10.0.0.10, so other service may take 10.0.0.10 (it *may* be not managed by solar / fuel), and.... you have a problem | 16:07 |
| pigmej | dshulyak: sure, in solar and fuel sure, BUT we may be unable to set these values back to 3rd party service | 16:08 |
| pigmej | there is small chance that having versioned 3rd party service storage would help there, but then we may endup with pretty complicated chained revert/rollback like thingy | 16:08 |
| dshulyak | for the data managed by some 3rd party - update should be made there atfirst | 16:09 |
| pigmej | sure | 16:09 |
| dshulyak | if there is no history | 16:09 |
| dshulyak | then ofcourse we cant call it rollback | 16:10 |
| dshulyak | but update itself it possible | 16:10 |
| pigmej | yeah | 16:10 |
| pigmej | and that's the message :) | 16:10 |
| pigmej | it's kinda like a rollback "if you're lucky enough" (because even rollback of IP may succeed) BUT in general rollback will require manual intervention :) | 16:11 |
| dshulyak | idk, it seems pretty ok to me, if service that manages this data is reliable ofc | 16:11 |
| pigmej | well, it changes pretty much nothing, because still, this service can be source not only for solar/fuel | 16:12 |
| pigmej | or 2 separate environments within solar/fuel | 16:12 |
| pigmej | if everything would be managed by solar, and all data would be in solar db then we could support very cool rollbacks, but even then not everything would be possible | 16:14 |
| dshulyak | but its ok i guess, it is responsibility of that other service to react on changes correctly | 16:15 |
| pigmej | sure, | 16:15 |
| dshulyak | also there is not that much components in fuel right now | 16:15 |
| pigmej | and what about beloved cmdb ? | 16:15 |
| dshulyak | configdb you mean? | 16:16 |
| dshulyak | or smth else? | 16:16 |
| pigmej | no, cmdb | 16:16 |
| pigmej | external configuration database like thingy | 16:16 |
| pigmej | configdb is not a big deal, it seems that we can make it on top of solar api | 16:16 |
| pigmej | so for solar it will change nothing | 16:16 |
| pigmej | and for user it may be just another way to work with solar resource connections | 16:17 |
| pigmej | that's also quite good solution for both words | 16:17 |
| pigmej | *worlds | 16:17 |
| pigmej | :) | 16:18 |
| dshulyak | so whats with that cmdb? i think it is the same, if they have history - they can try to do rollback, if they dont - updates, but thats like competely separate workflow | 16:19 |
| pigmej | dshulyak: even when it has history, it *may* be a problem, because that change will require to be somehow propagated for whole system | 16:20 |
| pigmej | and it maybe *not* only solar managed stuff | 16:20 |
| pigmej | because if we will assume that we have only solar, then it's super coll | 16:20 |
| pigmej | s/coll/cool | 16:20 |
| pigmej | but it turned out that we can't assume that | 16:20 |
| pigmej | dshulyak: I reviewed your changes, it works :) | 16:27 |
| pigmej | hmm ansible 2.0 changed a lot on API level | 17:15 |
| pigmej | hmm I think we should switch to use ansible as separate process (even local one), it's way easier to integrate (speed-- though) but... even 2.0 ansible cli API is compatible with 1.9.x | 17:34 |
| pigmej | https://bugs.launchpad.net/solar/+bug/1534145/comments/1 | 17:57 |
| openstack | Launchpad bug 1534145 in Solar "Make ansible handlers working with ansible 2.0" [High,Confirmed] | 17:57 |
| pigmej | that's my comment salmon_ dshulyak please tell what do you think about it | 17:59 |
| *** dshulyak has quit IRC | 19:30 | |
| salmon_ | pigmej: +1 from me | 20:13 |
| *** nihilifer has quit IRC | 20:26 | |
| *** nihilifer has joined #openstack-solar | 20:30 | |
| openstackgerrit | Merged openstack/solar: Add support for configurable executor https://review.openstack.org/273014 | 21:12 |
| openstackgerrit | Merged openstack/solar: Extensions mechanism for orchestration components https://review.openstack.org/273115 | 21:12 |
| openstackgerrit | Merged openstack/solar: Plugable constructors, runners and hooks https://review.openstack.org/273540 | 21:15 |
| *** angdraug has joined #openstack-solar | 21:52 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!