19:00:07 <vkozhukalov> #startmeeting Fuel
19:00:08 <openstack> Meeting started Thu Feb 27 19:00:07 2014 UTC and is due to finish in 60 minutes.  The chair is vkozhukalov. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:11 <openstack> The meeting name has been set to 'fuel'
19:00:25 <vkozhukalov> #chair vkozhukalov
19:00:26 <openstack> Current chairs: vkozhukalov
19:00:44 <vkozhukalov> #topic Greeting, roll-call, announcements.
19:01:26 <vkozhukalov> guys, hi everyone, it is our first weekly meeting
19:01:39 <vkozhukalov> who is here?
19:01:43 <agordeev2> o/
19:01:43 <evgeniyl`> Hi.
19:01:44 <mihgen> me is here
19:02:01 <mattymo|> Salutations!
19:02:05 <mihgen> can you share agenda pls
19:02:13 <aglarendil|mobi> Hi
19:02:14 <vk> hi
19:02:22 <vkozhukalov> #link ttps://wiki.openstack.org/wiki/Meetings/Fuel#Agenda_for_2.2F27.2F2014
19:02:26 <e0ne> hi
19:02:38 <vkozhukalov> sorry #link https://wiki.openstack.org/wiki/Meetings/Fuel#Agenda_for_2.2F27.2F2014
19:02:56 <vkozhukalov> ok, I think we can start
19:03:16 <vkozhukalov> #topic Moving fuel-web/naily into fuel-astute
19:03:32 <mihgen> I thought it's there )
19:03:38 <mihgen> so I'm +1 for sure
19:03:44 <aglarendil|mobi> I do not have any objections
19:03:52 <dpyzhov> +1
19:03:53 <vkozhukalov> mihgen, no it is not
19:04:03 <evgeniyl`> +1
19:04:09 <mihgen> we should keep in mind though all the complexity in our Jenkins jobs
19:04:22 <vkozhukalov> ok, i think vova sharshov is going to work on it
19:04:23 <e0ne> +1, it's not web-related code
19:04:33 <vkozhukalov> is he here?
19:04:39 <mihgen> so don't forget about preparing about all of that CI stuff before we move ..
19:04:43 <vkozhukalov> vova, around?
19:04:52 <evgeniyl`> vkozhukalov: yeah, we have discussed it already, we need to add in the current release.
19:04:55 <mihgen> warpc is his nick I believe. .
19:05:12 <mihgen> current release == which one?
19:05:19 <mihgen> not in 4.1 please
19:05:21 <vkozhukalov> Ok, everyone agree
19:05:23 <evgeniyl`> 5.0
19:05:32 <vkozhukalov> is there blueprint for that&
19:05:35 <vkozhukalov> is there blueprint for that?
19:05:43 <e0ne> i think that all meeting agenda is about 5.0 release
19:05:52 <e0ne> isn't it?
19:06:12 <mihgen> yep sure
19:06:22 <mihgen> it's all frozen for 4.1
19:06:29 <vkozhukalov> i think we need to have another discussion about our release cycle
19:06:34 <evgeniyl`> vkozhukalov: I was trying to find it and I didn't, so we need to create it.
19:07:05 <vkozhukalov> evgeniyl`, can you create it tomorrow?
19:07:10 <mihgen> it's perhaps rather granular task out of the whole idea in moves of repos
19:07:23 <evgeniyl`> Yeah, I can.
19:07:29 <vkozhukalov> AndreyDanin_, hi
19:07:37 <mihgen> so it can be one blueprint with ToDo items in there?
19:07:43 <AndreyDanin_> vkozhukalov, hi
19:07:50 <mihgen> or we will need to have separated bugs in LP instead?
19:08:11 <xarses> I'm here too =)
19:08:30 <vkozhukalov> mihgen, i think separate blueprint would be ok
19:08:33 <evgeniyl`> mihgen: I think we need to create a blueprint, because it is not small task.
19:08:44 <mihgen> ok, agree
19:08:58 <vkozhukalov> ok, I think we've done about this topic
19:09:08 <mihgen> mattymo: don't disappear man, we need you :)
19:09:17 <vkozhukalov> #topic Moving web UI (javascript) into separate repo
19:09:18 <mihgen> vkozhukalov: yep
19:09:31 <mihgen> can't disagree on this too
19:09:40 <vkozhukalov> it is again about refactoring
19:09:45 <e0ne> but I can
19:09:55 <mattymo|> Migen, sorry unstable pub wifi
19:09:57 <mihgen> e0ne: what's up there?
19:10:01 <vkozhukalov> and i believe there is no blueprint about this task
19:10:10 <mihgen> mattymo: bustard you are still in the pub
19:10:12 <vk> guys, there are UI tests that require both UI and nailgun
19:10:33 <mihgen> woops
19:10:35 <vk> how much complex for potentials contributors will it be to setup an env>
19:10:50 <vk> the same is for CLI
19:10:55 <e0ne> it's too difficult to separate them without any issue
19:10:56 <xarses> vk: I think it does make a bit of the testing harder, but that shouldn't preclude the test script from cloning the repo
19:10:58 <mihgen> while it's so tight to nailgun...
19:11:08 <mihgen> perhaps we should not separate then
19:11:27 <xarses> vk: maybe we should have them in seperate folders in fuel-web repo then?
19:11:32 <vkozhukalov> i still think we need to do that
19:11:34 <xarses> make it more obvious where to go
19:11:45 <vkozhukalov> but of course we need to be accurate
19:12:12 <vk> xarses, they are already in separate folders. nailgun and static respectively
19:12:13 <mihgen> separate folders are ok, but testing and overall support …. could be much more complicated
19:12:36 <mihgen> vk: separated but not in root of repo
19:12:48 <e0ne> let's assing somebody to investigate it. may be it will be too complexity to setup dev env or something else
19:12:48 <vk> yep
19:12:56 <vkozhukalov> guys, UI is a client library
19:12:59 <mihgen> I would expect smth like fuel-web/nailgun & fuel-web/fuel-ui
19:13:07 <angdraug> how about putting all tests that require code from more than one repo into fuel-main?
19:13:12 <xarses> mihgen: +1
19:13:14 <vkozhukalov> it for sure needs to be in a separate repo
19:13:30 <mattymo|> Lets call it fuel-dashboard
19:13:31 <mihgen> vkozhukalov: so why would we need it in separate repo then?
19:13:41 <mihgen> if it complicates the whole development process for UI guys?
19:13:45 <dpyzhov> angdraug: +1
19:13:55 <mihgen> they always need a certain version of python backend
19:13:56 <vkozhukalov> mihgen, it is a common tradition
19:14:02 <mihgen> they often base on each other
19:14:31 <angdraug> I think our UI could benefit from decoupling from nailgun
19:14:42 <xarses> heres my thought on seperate repo, unless ui can run on its own with out nailgun, it should be in the same repo, even if in same folder
19:14:46 <vkozhukalov> mihgen, yes, but what about writing script for automatic deployment of dev env
19:14:59 <mihgen> +1 to xarses
19:15:05 <vk> it cannot
19:15:28 <vk> UI needs nailgun API to work properly
19:15:44 <angdraug> in that case we should decouple them first, and shelve the topic of splitting the repos until they're properly decoupled
19:16:05 <xarses> vk: then it stays somewhere under fuel-web/ but preferably not in fuel-web/nailgun/static
19:16:23 <mihgen> again +1 to xarses  :)
19:16:26 <vk> okay
19:16:36 <vkozhukalov> cli also needs nailgun api, is it supposed to be in the same repo as well?
19:16:44 <e0ne> xarses, agree with you
19:16:50 <angdraug> fuel-web/ui/?
19:16:51 <e0ne> vkozhukalov: no
19:17:16 <angdraug> e0ne: why not?
19:17:28 <vkozhukalov> let's have a look how ppl from openstack do the same thing
19:17:38 <vkozhukalov> horizon is a separate project
19:17:41 <angdraug> fuel-web/api + fuel-web/ui + fuel-web/cli
19:17:52 <e0ne> fuel client could be installed not on the same node as fuel-master
19:17:54 <vkozhukalov> it is also unable to work without nova
19:17:57 <angdraug> horizon talks to dozens of different APIs
19:18:01 <vk> i'm not sure if web.py can handle static outside of its root dir, but in that case we can put a symlink in our repo static -> ../../fuel-ui
19:18:08 <xarses> vkozhukalov: it can stand alone, given there is an api server somewhere to test with, but if we look at lke nova, nova-client is inside of nova project
19:18:10 <vkozhukalov> why they don't put it in nova repo?
19:18:16 <mattymo|> We should split to fuel-api fuel-dashboard and python-fuelclient
19:18:42 <vkozhukalov> our UI is also can be just put into web server directory
19:18:43 <angdraug> I don't like fuel-dashboard, horizon is dashboard
19:18:44 <vk> horizon has a backend part
19:18:47 <mattymo|> Just to mirror fuel
19:18:57 <mattymo|> Ooops openstack
19:19:00 <vk> our ui is a pure js app which doesn't work without a server
19:19:07 <xarses> well there is another thing to note, we cam make seperate packages from the same repo, if they share common code, its common for them to stay in the same repo
19:19:13 <vk> unlike horizon
19:19:31 <xarses> like in the case of nova and nova client
19:19:50 <davideaster> +1 to angdraug.  Name should not be dashboard as that would confuse with OpenStack Dashboard (Horizon)
19:20:09 <mihgen> +1 to xarses and vk. unless you prove necessity of separate repos, I would not try to disperse the code
19:20:12 <vkozhukalov> ok, let's vote
19:20:15 <mihgen> maintenance becomes hard
19:20:16 <vkozhukalov> #startvote
19:20:16 <openstack> Unable to parse vote topic and options.
19:20:34 <angdraug> +1 mihgen
19:20:47 <xarses> +1 mihgen
19:20:59 <vkozhukalov> -1
19:21:02 <vk> +1 mihgen
19:21:04 <mihgen> +1 mihgen =)))
19:21:16 <dpyzhov> +1 m
19:21:21 <vkozhukalov> lol
19:21:27 <evgeniyl`> 0
19:21:38 <mihgen> how this voting thing works actually
19:21:49 <e0ne> guys, what's about to spell about 1d for PoC with separating nailgun and UI?
19:21:56 <vkozhukalov> mihgen, i don't know
19:22:07 <vkozhukalov> i believe it is just a tag
19:22:09 <mattymo|> +1
19:22:16 <vkozhukalov> ok, let's move on
19:22:32 <vkozhukalov> #topic Moving fuel-web/fuelclient into separate repo python-fuelclient and making it client library not just CLI
19:22:38 <e0ne> it's very difficult for me to make a decision. need to try it
19:22:54 <e0ne> ^^ it was about nailgun & ui
19:23:11 <angdraug> e0ne: just work towards refactoring the code to reduce coupling gradually
19:23:15 <evgeniyl`> CLI use nailgun for testing too.
19:23:17 <e0ne> +!
19:23:18 <mihgen> so basically here same thing, CLI fully relies on nailgun
19:23:21 <vkozhukalov> what about moving cli into separate repo and renaming it into python-fuelclient
19:23:26 <e0ne> angdraug:+1
19:23:45 <mihgen> so same what I and angdraug said, keep in fuel-web/cli
19:23:52 <e0ne> vkozhukalov: absolutely agree. but need to rename blueprint. it's a bit confusing
19:23:53 <angdraug> I think the same approach proposed by xarses for ui applies: same repo, different packages
19:24:04 <mihgen> yep
19:24:20 <vk> but CLI can work standalone if provided with nailgun api url. UI cannot
19:24:35 <angdraug> vk: UI runs in the web browser, same thing
19:24:39 <mihgen> still what are the benefits of having it separatee repo?
19:24:49 <vk> no, let me explain
19:25:00 <e0ne> separate repo for fuel-client === using openstack infra for testing and review-request w/o modifications, just configuration
19:25:14 <vkozhukalov> guys, we have invented fully test driven development process, we can not move anything wherever we want because of tests ))
19:25:16 <angdraug> if it's coupled to api and can't be tested without a matching api server, they should stay in the same repo
19:25:25 <e0ne> client is a standalone application/package
19:25:44 <vk> you can run cli with nailgun api url and it will work. UI must be served bu nailgun our you need to configure a separate reverse proxy server to make it work
19:26:14 <e0ne> vk, agree with you about cli
19:26:16 <vkozhukalov> actually ui also can work without nailgun in the same sense as our cli can
19:26:20 <mihgen> anyway cli can't work without nailgun, so don't see any point at the moment of having it in separated repo
19:26:21 <vk> but like UI, CLI has tests that require nailgun
19:26:37 <mihgen> e0ne: ^^ see about tests
19:26:49 <mihgen> infra won't help here out of the box anyway
19:26:50 <e0ne> let's create real unit tests:)))
19:26:53 <angdraug> I thought CLI relies on REST requests to nailgun for most of its functionality?
19:27:02 <dpyzhov> why do we need to have all in one repo because of tests? we can have a pre-installed environment and test new commits in cli/ui with it.
19:27:12 <angdraug> 1
19:27:17 <angdraug> +1 e0ne on unit tests
19:27:22 <mihgen> dpyzhov: -1 to this approach
19:27:26 <e0ne> thanks, angdraug
19:27:27 <vkozhukalov> +1 dpyzhov
19:27:36 <mihgen> your nailgun would be outdated
19:27:36 <e0ne> +1 dpyzhov
19:27:40 <mihgen> while cli is newer
19:27:48 <mihgen> how can you test newer code on outdated nailgun?
19:27:55 <mihgen> that's why it must be in sync
19:27:58 <dpyzhov> cli is always came later then nailgun
19:28:01 <angdraug> we should do better at separating unit tests from integration tests
19:28:03 <mihgen> that's why ideally in same repo
19:28:11 <dpyzhov> and ui should be updated after changes in rest api
19:28:14 <evgeniyl`> dpyzhov: -1 we can't, we need to have nailgun from master
19:28:15 <e0ne> angdraug, +1
19:28:39 <e0ne> stop
19:28:51 <e0ne> let's use fuelclient name instead cli
19:28:59 <e0ne> it's different
19:29:09 <mihgen> why?
19:29:10 <dpyzhov> are we going to have all this stuff tied together forever?
19:29:23 <xarses> guess unless we are starting to ensure that the REST api is backwards compatible, fuelclient relies on the same version of nailgun as is in the repo, they need to stay together
19:29:37 <vk> as for syncing of different repos, you can later look into android approach which has hundreds of repos managed by "repo" tools which keeps different repos in sync and provides actions to all of them
19:29:38 <xarses> s/guess/guys
19:29:39 <dpyzhov> or we should have stable api instead?
19:29:42 <e0ne> mihgen: it's the same for now
19:30:02 <angdraug> dpyzhov: xarses: we also need to have each of them have at least 80% unit test coverage before we can consider separating them
19:30:13 <e0ne> mihgen: but in the future, we want have fuel client as python/cli client
19:30:16 <xarses> angdraug: +1
19:30:18 <mihgen> angdraug: +1
19:30:41 <mihgen> I suggest to do final vote, fully agree with angdraug here
19:30:45 <angdraug> e0ne: +1
19:30:50 <vkozhukalov> ok, about version, let's add something like /v1/ in the beginning of every url and it would mean than v1 work exactly as we expect it to be
19:31:09 <e0ne> vkozhukalov: already done:)
19:31:09 <dpyzhov> we can not split repos right now, it will produce a lot of pain. but we should take this approach it our minds
19:31:10 <angdraug> mihgen: I don't think we're ready to vote
19:31:19 <angdraug> not done laying out the options
19:31:23 <vk> +1 dpyzhov
19:31:36 <e0ne> dpyzhov: let's do it step-by-step/repo-by-repo
19:31:42 <mihgen> regarding pain - that's for sure
19:31:46 <vkozhukalov> ok, what is the problem then about mismatching of versions?
19:31:48 <dpyzhov> and we should create good interfaces first
19:31:51 <evgeniyl`> I think we need to find a way to test cli/ui against fresh nailgun.
19:31:54 <mihgen> I configured all the CI initially and I know it for sure )
19:31:59 <angdraug> I think first step is tests
19:32:11 <angdraug> then, enforcing backwards compatibility for API
19:32:26 <nmarkov> we need to refactor or even completely rewrite our tests
19:32:32 <vkozhukalov> ok, guys. it is almost obvious that we need to discuss it somewhere else
19:32:43 <vkozhukalov> let's again vote and then move on
19:32:45 <nmarkov> hangout tomorrow?
19:32:48 <mihgen> about tests: while integration are lightweight as unit for fuel-cli, I would not even bother about unit for it
19:32:51 <vkozhukalov> #startvote
19:32:52 <openstack> Unable to parse vote topic and options.
19:33:15 <dpyzhov> I think we can move all the stuff to separate folders one repo now.
19:33:18 <angdraug> what are we voting for/against?
19:33:32 <vk> +1 for keeping CLI in fuel-web repo
19:33:38 <vk> (for now)
19:33:40 <vkozhukalov> i vote for moving fuelclient in a separate repo
19:33:41 <e0ne> vk: -1
19:33:43 <dpyzhov> And wait till upgrades solution
19:33:46 <mihgen> vk: +1
19:33:48 <evgeniyl`> -1 for keeping
19:33:49 <xarses> vk: +1
19:33:51 <nmarkov> -1
19:33:52 <angdraug> vk: +1
19:34:20 <angdraug> looks like we don't have a consensus
19:34:27 <nmarkov> yep
19:34:31 <evgeniyl`> it's ok)
19:34:37 <mihgen> ok and I don't have explanation about separate repo too
19:34:37 <angdraug> lets bring it up in the next meeting
19:34:38 <vk> but guys, we should reapply consider repo tool: http://source.android.com/source/using-repo.html it is perfect to manage multi-repo project and has integration with gerrit
19:34:38 <dpyzhov> I can't even understand who votes for what
19:34:40 <vkozhukalov> yes, we'll discuss it later
19:34:44 <vkozhukalov> moving on
19:35:00 <vkozhukalov> #topic Building bootstrap (discovery) image using diskimage-builder
19:35:11 <mihgen> vkozhukalov: pls state what we should vote for before calling for it
19:35:25 <vkozhukalov> mihgen, ok
19:35:42 <mihgen> sounds like right approach.. but I need more details on that to say for sure...
19:35:42 <evgeniyl`> what is this topic about?
19:35:53 <mihgen> > Building bootstrap (discovery) image using diskimage-builder
19:35:57 <nmarkov> шьфпу-ифыув зкщмшышщтштп
19:36:02 <nmarkov> image-based provisioning
19:36:03 <mihgen> :) )
19:36:09 <vkozhukalov> at the moment the size of our bootstrap is about 140M
19:36:16 <vkozhukalov> it is too big
19:36:25 <xarses> vkozhukalov: I
19:36:38 <vkozhukalov> diskimage-builder can help reduce it's size
19:36:44 <mihgen> how can you make it smaller? but excluding some stuff from centos?
19:36:46 <xarses> vkozhukalov: I looked over it and nothing execpt changing the compression will help make it smaller
19:37:00 <vkozhukalov> again it is about what ppl in openstack use for building images
19:37:03 <nmarkov> we don't need full centos as bootstrap
19:37:03 <dpyzhov> http://ci.openstack.org/irc.html#voting
19:37:14 <mihgen> how fast is the build process in comparison with our current approach?
19:37:24 <mihgen> time is important here, in building our ISOs
19:37:28 <xarses> vkozhukalov: we found that if we change from gzip to lzma it can be shunk to 80M
19:37:39 <mattymo|> This image builder has templates for purging files
19:37:46 <vkozhukalov> yes, we don't need centos based image
19:37:48 <angdraug> bulk of the image is kernel modules, we can't drop drivers
19:37:52 <mattymo|> We need a newer kernel for lzma I believe
19:38:01 <AndreyDanin_> meanwhile, howto vote here http://ci.openstack.org/meetbot.html#voting
19:38:19 <xarses> mattymo: centos 6.2+ is supposed to support it
19:38:21 <dpyzhov> AndreyDanin_: too late =)
19:38:27 <vkozhukalov> AndreyDanin_, thanks
19:38:41 <vkozhukalov> AndreyDanin_, will try next time
19:39:02 <mihgen> ok so question not about size
19:39:12 <mihgen> we can make size smaller using our current make files I assume
19:39:16 <vkozhukalov> ok, about size, we can try and then see would it reduce the size (i mean using dib)
19:39:25 <mattymo|> Ok right. I think xz is what needs newer kernel for compressed squashfs root
19:39:32 <mihgen> so what about disk-image-builder?
19:39:40 <mihgen> what about time?
19:39:48 <mihgen> easy of use, debugging, etc.?
19:39:54 <angdraug> did anyone investigate dib?
19:39:55 <xarses> i don't disagree using dib because its what other Openstack projects use, but size won't get much smaller either way
19:40:01 <vkozhukalov> it's easy to use
19:40:23 <mihgen> vkozhukalov: what about time of building?
19:40:24 <mattymo|> we can shrink by pruning kernel modules and firmware
19:40:25 <vkozhukalov> and the time of building is pretty the same
19:40:33 <angdraug> can it improve flexibility/reliability of our iso build process?
19:40:59 <angdraug> mattymo: -1 on pruning drivers/firmware
19:41:04 <vkozhukalov> yea, actually it can help to improve the flexibility
19:41:15 <angdraug> in that case we should consider it
19:41:36 <angdraug> even if we don't win on image size or build time, current process for modifying bootstrap image basically isn't
19:41:39 <vkozhukalov> maybe we will be able to reuse discovery solutions from ironic
19:41:53 <mihgen> so preliminary +1 for me for it then
19:42:02 <xarses> vkozhukalov: how would it improve? would it make it easier for end user to rebuild image in the field?
19:42:03 <mattymo|> We dont need wifi drivers for exampl
19:42:07 <mattymo|> E
19:42:08 <mihgen> however I would like to see some techtalk about it
19:42:14 <AndreyDanin_> We be able to rebuild bootstrap on the master node. It allows us to include really strength ssh keypair.
19:42:29 <vkozhukalov> xarses, in a sense
19:42:55 <vkozhukalov> modifing make file is not very pleasant
19:43:05 <AndreyDanin_> Anyone be able to rebuild its own bootstrap version, include additional drivers, etc.
19:43:26 <mattymo|> It should have a separate make system that can run independent
19:43:44 <mihgen> vkozhukalov: oh really, I remember you hard vote for it when I was trying to get rake onboard instead ;)
19:43:52 <angdraug> mattymo: fair point on wifi drivers, although I'm not sure building custom kernels is the territory we're ready to explore
19:43:58 <xarses> vkozhukalov: I think rebuilding the bootstrap in the field is the most important feature we need with regards to bootstrap, making it smaller and easier to distribute are secondary needs
19:44:09 <angdraug> xarses: +1
19:44:14 <vkozhukalov> mihgen, it was so long ago ))
19:44:31 <vkozhukalov> ok, we still have some other topics
19:44:48 <vkozhukalov> #topic Rewriting discovery agent into python
19:44:49 <xarses> vkozhukalov: if moving to dib helps then yes, but so far I've heard no features that dib brings to us. regardless, it doesn't really matter how we build the bootstrap image
19:44:59 <mihgen> so +1 for disk-image-builder according to what is said here
19:45:00 <mattymo|> Sorry I am on a moble device now. I will share a cool set of scripts for shrinking images
19:45:39 <nmarkov> as for agent, I heard you meant something more than just rewriting it as it is
19:45:41 <evgeniyl`> I don't think that we should just rewrite agent in python, it will be better to completely rewrite our discovering logic with mcollective (or any other transport).
19:45:45 <xarses> +1 to discovery agent in python, it should make it easier for community to participate
19:45:45 <nmarkov> could you clarify, please?
19:45:49 <mihgen> what about vote for previous topic?
19:45:52 <vkozhukalov> it is again about refactoring, ruby is not very suitable for openstack
19:45:58 <mihgen> discovery agent on python = we are heavily dependent on ohai
19:46:06 <mihgen> I don't know anything like that in python
19:46:13 <mihgen> now agent is trivial
19:46:18 <angdraug> +1 to _research_ what dib can actually give us
19:46:27 <mihgen> it takes ohai output and does rest api call
19:46:31 <evgeniyl`> ohai can give json and we can parse it in python easily
19:46:38 <nmarkov> #startvote Should we use diskimage-builder? Yes, No, Maybe
19:46:39 <openstack> Only the meeting chair may start a vote.
19:46:39 <AndreyDanin_> evgeniyl`, +1 to rewrite logic
19:46:42 <vk> afair we anyway gather some data in many places as we cannot rely on ohai
19:46:47 <mattymo|> Ohai and facter use proc and dmidecode. Its just abstravtion magic
19:46:55 <angdraug> can we have Research vote option please?
19:46:57 <mattymo|> Abstraction*
19:46:59 <mihgen> would you call ohai then as external program?
19:46:59 <vkozhukalov> mihgen, salt grains is pretty much the same as ohai
19:47:12 <mihgen> pretty much is not the same
19:47:18 <mihgen> ohai is in place for years
19:47:26 <mihgen> opscode fixed tons of bugs
19:47:34 <mihgen> on different systems and drivers/hw
19:47:36 <mattymo|> Its not ambrosia. It can be replaced
19:47:38 <nmarkov> ohai actually has some shitty code inside
19:47:40 <evgeniyl`> mihgen: +1
19:47:42 <AndreyDanin_> #vote PoC
19:47:45 <nmarkov> I tried to research it one day
19:47:47 <evgeniyl`> Don't touch ohai please)
19:47:49 <mihgen> rewriting that from scratch is very dangerous
19:48:09 <mihgen> nmarkov: you rather have shitty code in nailgun dude
19:48:32 <e0ne> mihgen, nmarkov :)))
19:48:36 <mihgen> that's stability thing, and we rely on it now
19:48:42 <nmarkov> mihgen, nailgun is perfect, don't touch it
19:49:00 <mihgen> so I consider it's very dangerous to replace it on any other source of hardware information
19:49:03 <xarses> nmarkov: all of the issues we have had with agent has been our internal logic, not ohai failing to work
19:49:14 <xarses> recently anyway
19:49:37 <nmarkov> xarses, not really, I remember some issues we had when were working with chef 1.5 years ago
19:49:40 <vkozhukalov> ok, mihgen is right about danger
19:49:56 <angdraug> if we don't need to fix ohai itself, I don't care how ugly it is on the inside long as it works
19:49:57 <vkozhukalov> stability is extremely important here
19:50:14 <nmarkov> but ohai is just a source of info, one of the many
19:50:22 <vkozhukalov> ok, guys let's discuss it later
19:50:24 <angdraug> in my experience pretty code and stability have a very weak correlation
19:50:30 <vkozhukalov> we have just 10 minutes
19:50:30 <mihgen> angdraug: +1
19:50:35 <AndreyDanin_> xarses, our logic fails because of ohai internal logic.
19:50:50 <mihgen> AndreyDanin_: be more concrete
19:50:51 <angdraug> vkozhukalov: call a vote and lets move to the next topic
19:51:08 <nmarkov> there are some issues when ohai fails to fetch some hw info
19:51:22 <vkozhukalov> #startvote for rewriting agent in python
19:51:22 <xarses> nmarkov: AndreyDanin_  since i stared we have found 0 errors with ohai failing to find what we want, we just dont use what ohai sends us.
19:51:23 <openstack> Unable to parse vote topic and options.
19:51:27 <mihgen> it even proves what I said
19:51:38 <mihgen> one bug in a long run - perfect code
19:51:39 <nmarkov> and nailgun rebuilds half of the DB according to invalid data it sends
19:51:44 <AndreyDanin_> mihgen, I talk about magic with MAC and IP.
19:51:53 <nmarkov> vkozhukalov, specify answers
19:52:01 <vkozhukalov> -1  need to do  additional research
19:52:01 <nmarkov> AndreyDanin_, +1
19:52:06 <evgeniyl`> nmarkov: invalid data sends not ohai, agent does it.
19:52:17 <mattymo|> +1 to research alternatives in python to ohai
19:52:29 <nmarkov> evgeniyl`, so, it is agent which can't get a MAC? please, dude
19:52:30 <mihgen> I vote for keeping existing ohai and agent
19:52:41 <nmarkov> +1 mattymo|
19:52:41 <mihgen> as they are small and doing it's job now pretty well
19:52:43 <angdraug> -1 on research, let's focus on bigger problems first
19:52:45 <evgeniyl`> nmarkov: did you see agent code, it parses data from ohai and make additional filtering and data preparation
19:52:56 <mihgen> we don't need them to be extended any heavily
19:53:02 <evgeniyl`> nmarkov: what are you talking about?
19:53:05 <mihgen> we have plenty other more important things
19:53:09 <nmarkov> evgeniyl`, yep, and sometimes ohai just doesn't return some necessary things
19:53:09 <xarses> -1 for now, but I'd love to see the ruby replace with python
19:53:11 <vkozhukalov> #topic Moving fuel-web/fuelmenu into fuel-library
19:53:15 <mihgen> such as scalability of nailgun for exmaple
19:53:17 <e0ne> angdraug, +1
19:53:27 <mihgen> so -1 on research
19:53:29 <angdraug> mihgen: +1 :p
19:53:47 <vkozhukalov> fuelmenu does not work w/o puppet modules
19:53:52 <angdraug> I'd like us exploring the ipmi/snmp discovery tools from compass first
19:53:54 <mihgen> ok fuel menu relies on code from fuel-library
19:53:59 <mattymo|> Fuelmenu only configures fuelweb
19:54:04 <e0ne> vkozhukalov: why to fuel-lib, not to a separate repo?
19:54:06 <mattymo|> Not library
19:54:35 <evgeniyl`> -1 i think it should be moved to fuel-main because it's more about iso
19:54:42 <angdraug> evgeniyl`: +1
19:54:51 <mattymo|> But it should be separate if anything or in main
19:54:56 <mihgen> what's the benefit from being in fuel-main?
19:55:13 <vkozhukalov> fuel-main is just a bunch of build scripts
19:55:16 <e0ne> it is not related nor -web, nor -library
19:55:34 <angdraug> evgeniyl`: 0 (changed my mind)
19:55:39 <evgeniyl`> vkozhukalov: fuel-library is a bunch of puppet manifests
19:55:41 <mihgen> fuel-menu heavily relies on fuel-library
19:55:46 <xarses> fuel-menu should be in library more than main, at least the puppet it needs is in there
19:55:46 <e0ne> let's move to a new separate repo
19:55:50 <mihgen> at this moment ..
19:55:56 <vkozhukalov> #startvote for moving fuelmenu into separate repo
19:55:56 <openstack> Unable to parse vote topic and options.
19:56:06 <mihgen> -1 on that
19:56:11 <mattymo|> -1
19:56:11 <vkozhukalov> -1 for separate repo
19:56:11 <e0ne> +1
19:56:15 <angdraug> -1
19:56:18 <nmarkov> +1
19:56:23 <evgeniyl`> -1
19:56:28 <xarses> -1
19:56:33 <angdraug> -1 on repo proliferation in general
19:56:35 <vkozhukalov> #startvote for moving fuelmenu into fuel-library
19:56:36 <openstack> Unable to parse vote topic and options.
19:56:38 <AndreyDanin_> #startvote Do we want to  move fuelmenu into separate repo? Yes, No, Maybe
19:56:39 <openstack> Only the meeting chair may start a vote.
19:56:45 <xarses> angdraug: +1
19:56:46 <mihgen> Yes
19:56:48 <nmarkov> +1
19:56:50 <mihgen> (+1)
19:56:52 <vkozhukalov> +1
19:56:54 <xarses> +1
19:56:56 <nmarkov> #vote Yes
19:57:02 <mattymo|> -1
19:57:06 <e0ne> yes
19:57:28 <mihgen> e0ne: how can you vote the same?
19:57:32 <vkozhukalov> we need to read manual about meetings )))
19:57:40 <evgeniyl`> :)
19:57:50 <angdraug> vkozhukalov: just resend what AndreyDanin_ proposed )
19:57:55 <vkozhukalov> ok, guys looks like we have just a couple of minutes
19:58:07 <mihgen> I think we need to close now
19:58:13 <xarses> angdraug: agreed, we have more than enough repos to confuse everyone as it is
19:58:16 <mihgen> and move other stuff to next meeting..
19:58:22 <e0ne> mihgen: what do you mean?
19:58:41 <mihgen> e0ne: you voted for separated repo and then said Yes for fuel-library
19:58:49 <vkozhukalov> yes, let's go away and continute our discussion somewhere else
19:59:04 <mihgen> > xarses: angdraug: agreed, we have more than enough repos to confuse everyone as it is   <-  so true
19:59:04 <nmarkov> let's wrap up little by little
19:59:21 <vkozhukalov> unfortunately we had too large agenda
19:59:23 <e0ne> it was my fail with 'yes for fuel-lib'
19:59:25 <mihgen> we can do in fuel-dev...
19:59:33 <mihgen> end meeting pls
19:59:33 <vkozhukalov> #endmeeting