20111205meeting.log - Foreman

Roadmap meeting Dec 05 2011 » 20111205meeting.log

12/05/2011 Meeting Log - Romain Vrignaud, 12/06/2011 04:18 AM

 /12/2011 20:02:58< ohadlevy> hello :)
 /12/2011 20:03:19< ohadlevy> fitzdsl: mind sending up a reminder email to the list?
 /12/2011 20:03:24-!- Irssi: #theforeman: Total of 65 nicks [1 ops, 0 halfops, 0 voices, 64 normal]
 /12/2011 20:03:30<@fitzdsl> ohadlevy: i do it
 /12/2011 20:03:33< f0> hi
 /12/2011 20:03:43 * ohadlevy is very excited about first foreman community meeting :)
 /12/2011 20:03:46< Phibs> haha
 /12/2011 20:03:48< Bardack> hehe
 /12/2011 20:03:50< Phibs> did you hire strippers
 /12/2011 20:04:04< ohadlevy> the goal, at least from my side, is to start as many discussions as you guys want
 /12/2011 20:04:14< ohadlevy> its not so much about me telling what Foreman roadmap should be,
 /12/2011 20:04:30< ohadlevy> rather would like to discuss where should we go
 /12/2011 20:04:42< fenrus02> o_O?
 /12/2011 20:04:42< ashp> First motion: You extend foreman to turn on the coffee pot whenever it detects me creating more than one host
 /12/2011 20:04:47< ohadlevy> a lot of people already put up some topics at roadmap meeting
 /12/2011 20:04:52< Phibs> ohadlevy: is there something to autoconfigure puppet for foreman too
 /12/2011 20:05:10< ohadlevy> so i guess you guys can just start raising up your favorite topic :)
 /12/2011 20:05:11< fenrus02> ohadlevy, walkthru for new users, including bcp and common configurations
 /12/2011 20:05:20< ohadlevy> and afterwards we will try to summarize some real action items
 /12/2011 20:05:21< fenrus02> both rpm and deb based setups.
 /12/2011 20:05:22< ohadlevy> etc
 /12/2011 20:05:33< ohadlevy> fenrus02: ok
 /12/2011 20:05:43< ohadlevy> so current topic --> new users experience?
 /12/2011 20:05:45< ashp> From my side I want to continue down the path of having foreman act as my central repository of information, so that includes the stuff on locations we discussed, as well as other things about my environment
 /12/2011 20:05:52< Bardack> finalise vmware support ^^
 /12/2011 20:05:55< ashp> I suppose some of that would include the stuff stacker has
 /12/2011 20:06:09-!- fitzdsl changed the topic of #theforeman to: new users experience
 /12/2011 20:06:11< ashp> Long term I see a place for extending foreman to know about other kinds of things, load-balancers, maybe some network stuff
 /12/2011 20:06:27< ashp> Hahaha, yes, lets bring order to this rather than a random wishlist
 /12/2011 20:06:32< marcellods> isn't an idea to follow the agenda order ?
 /12/2011 20:06:41< ashp> First thing the new user experience needs is for one of us to tackle the docs in the wiki and improve them.
 /12/2011 20:06:45<@fitzdsl> marcellods:  I think we should indeed
 /12/2011 20:06:52< ashp> Because right now they suck with things like external nodes being under the FAQ, not install docs
 /12/2011 20:06:53< fenrus02> esxi support would be absolutely fab
 /12/2011 20:06:59< ohadlevy> marcellods: ok
 /12/2011 20:07:01< f0> hm, from the nwe user experience it laks documentation and setup is not straight forwart
 /12/2011 20:07:22< ashp> Yeah, docs is definitely an area that we can improve.
 /12/2011 20:07:23-!- ken_barber [~ken_barbe@puppetlabs/ps/ken-barber] has joined #theforeman
 /12/2011 20:07:25< ohadlevy> following wiki:Roadmap_meeting
 /12/2011 20:07:26< nudnik> ohadlevy: wiki:Roadmap_meeting is http://theforeman.org/wiki/foreman/Roadmap_meeting "Foreman - Roadmap meeting - Foreman"
 /12/2011 20:07:29< ashp> Maybe some use case type docs
 /12/2011 20:07:44< ohadlevy> if your topic are not there, please add it now :)
 /12/2011 20:07:49< fenrus02> f0, that's roughly what i meant above
 /12/2011 20:07:50< ashp> "I want to setup foreman to be my external node classifer", "I want forman to build my servers via libvirt", that kind of thing
 /12/2011 20:07:53< ashp> right now it's a bit all over the place
 /12/2011 20:08:18< ohadlevy> ok guys, hold on, lets simply go over the list :)
 /12/2011 20:08:35< fenrus02> ohadlevy, foreman+katello ?  or is that too far ahead of schedule?
 /12/2011 20:08:45< ohadlevy> I suggest that the person who added the topic, should give a bit of an overview
 /12/2011 20:08:47< cosman2001> how about docs on how to get your department to accept foreman as the next biggest thing?
 /12/2011 20:08:51< ohadlevy> first one in the list is mcollective
 /12/2011 20:08:57 * gwmngilfen returns from a nasty Xorg crash
 /12/2011 20:09:09-!- meta-coder [meta-coder@unaffiliated/meta-coder] has joined #theforeman
 /12/2011 20:09:13< ohadlevy> who added it and why :)
 /12/2011 20:09:23-!- fitzdsl changed the topic of #theforeman to: mcollective integration
 /12/2011 20:09:26< fenrus02> ohadlevy, not i, but it is an excellent idea.  the alternative is func
 /12/2011 20:09:28-!- mode/#theforeman [+o ohadlevy] by ChanServ
 /12/2011 20:09:28< ashp> Not me this time, but I've seen a few requests for this in here lately
 /12/2011 20:09:33< ashp> I think it was driven by PE 2.0
 /12/2011 20:09:42< ashp> Which has some awesome mcollective integration for kicking off runs etc
 /12/2011 20:09:43< marcellods> ohadlevy: I didn't add the topic but it seems to be interesting. I saw the PE 2.0 video
 /12/2011 20:09:48< fenrus02> ohadlevy, mco-agent is WAY handy
 /12/2011 20:10:15< gwmngilfen> i really need to find out what the mco fuss is all about....
 /12/2011 20:10:16< lavaman> seems that would open up the door for staged, multi-machine deploys
 /12/2011 20:10:19< f0> i also like the idea of mcollective integration
 /12/2011 20:10:24< fenrus02> gwmngilfen, #mcollective for starters
 /12/2011 20:10:26<@ohadlevy> are you guys looking for a simply puppet kick via mco or the nicer features puppetlabs put up?
 /12/2011 20:10:37< cosman2001> not me, but I would love to have the ability to stop/restart services through mcollective with a foreman interface
 /12/2011 20:10:42< bgupta> I am not 100% convinced that it is needed, and things are still early going in the puppet /mcollective integration. That said, mcollective integration is limited to puppet 2.7+ versions only, are we ready to make that a requirement?
 /12/2011 20:10:53< ashp> Well, I think we'd definitely like the nicer features they put up
 /12/2011 20:10:55<@ohadlevy> bgupta: why is that?
 /12/2011 20:10:59< fenrus02> ohadlevy, ideally, the system would automatically balance load based upon number of agents and run-interval
 /12/2011 20:11:12< fenrus02> ohadlevy, the current way to do that is mco-agent / puppet-kick
 /12/2011 20:11:20< ashp> But I'd be pretty content, up front, with the ability to kick off runs and maybe a front end to select nodes in foreman and apply mcollective actions
 /12/2011 20:11:21<@ohadlevy> bgupta: i guess, it depends what do you expect when you say mc integration
 /12/2011 20:11:26< bgupta> ohadlevy: I believe it is due to license impedence mismatch.
 /12/2011 20:11:29< ashp> like "based on this hostgroup, do mco-agent package install blah"
 /12/2011 20:12:01-!- meta-coder [meta-coder@unaffiliated/meta-coder] has left #theforeman ["Leaving"]
 /12/2011 20:12:03< gwmngilfen> it sounds to me like mco is a way of doing "push" actions on an inherently "pull" system
 /12/2011 20:12:17< gwmngilfen> but that doesn't mean we shouldn't support some of it's features :)
 /12/2011 20:12:23< f0> i think with puppet you can do much, but restart httpd on the 10 webservers is not easy
 /12/2011 20:12:28< cosman2001> for those who don't know, mco can collect information that other monitoring tools can only dream of
 /12/2011 20:12:34< fenrus02> gwmngilfen, not really.  you can (for example) stop running puppetd on all your clients
 /12/2011 20:12:46< gwmngilfen> puppet agent is a cron job on my servers
 /12/2011 20:13:00<@ohadlevy> gwmngilfen: you can stop cron :)
 /12/2011 20:13:02< fenrus02> gwmngilfen, cron jobs are manually manipulated
 /12/2011 20:13:14< bgupta> Ok my question is, what do we mean by "mcollective integration"?
 /12/2011 20:13:19< cosman2001> I don't think puppet is even required to use mco
 /12/2011 20:13:22< fenrus02> gwmngilfen, using mco-agent, it can automatically balance without cron
 /12/2011 20:13:37< fenrus02> cosman2001, it is not required.  just works well together
 /12/2011 20:13:49< gwmngilfen> lets not turn this into a mco discussion - bguptahas the right question
 /12/2011 20:14:00< gwmngilfen> i can learn about it on my own time :)
 /12/2011 20:14:24<@ohadlevy> bgupta: ok, one simply feature, is simply run puppet via mc
 /12/2011 20:14:25< f0> hm maybe we should say "execute comand on .." instead of mcollective integration?
 /12/2011 20:14:25< fenrus02> bgupta, fair question.  i would like to see it used for inventory, reporting, and kicks
 /12/2011 20:14:32< cosman2001> in my mind mcollection integration should be (list of services at the very least)
 /12/2011 20:14:41< lavaman> It seems to me that the logical conclusion of mcollective integration is turning foreman in to an end-to-end service deployment, management, and verification tool
 /12/2011 20:14:49< cosman2001> then following with service control
 /12/2011 20:15:18< fenrus02> lavaman, well the front-end for such a collection anyhow
 /12/2011 20:15:46< ashp> For me I'd just be happy to see mcollective able to do a few basic things up front, force runs being the major one I want
 /12/2011 20:15:47< lavaman> it would be able to coordinate the application of puppet classes across machines for complex deployments
 /12/2011 20:16:05< ashp> lavaman: check out stacker on www.theforeman.org for a way to do some of this stuff in foreman today, it's neat
 /12/2011 20:16:28<@ohadlevy> ashp: yeah, i think i want to integrate stacker in foreman
 /12/2011 20:16:44<@ohadlevy> ok, so i think this breaks into two big parts
 /12/2011 20:16:53<@ohadlevy> one, is simple actions that you can do with mco today
 /12/2011 20:16:57<@ohadlevy> and simply expose them via the ui
 /12/2011 20:16:59<@ohadlevy> puppet kick
 /12/2011 20:17:02<@ohadlevy> restart service
 /12/2011 20:17:03<@ohadlevy> etc
 /12/2011 20:17:08< fenrus02> ohadlevy, +1
 /12/2011 20:17:18< cosman2001> +like
 /12/2011 20:17:21< marcellods> ohadlevy: I would also mention (as another integration topic) resource cloning
 /12/2011 20:17:23< f0> ohadlevy: +1
 /12/2011 20:17:33<@ohadlevy> and the other, is using it as a framework to do more complex flow
 /12/2011 20:17:41< lavaman> I'm getting a 404 on this http://theforeman.org/projects/stacker/wiki
 /12/2011 20:17:43<@ohadlevy> internode etc
 /12/2011 20:18:04<@ohadlevy> ok, so since we have lots of topics
 /12/2011 20:18:06< fenrus02> ohadlevy, it should use proxy though, in case mco daemonn is not the same host
 /12/2011 20:18:12<@ohadlevy> 1. setup feature requests for the first part
 /12/2011 20:18:25<@ohadlevy> fenrus02: i think i agree
 /12/2011 20:18:29<@ohadlevy> even due, it might be an overkill
 /12/2011 20:18:31< cosman2001> ohadlevy, what about mco "fact" collection
 /12/2011 20:18:50<@ohadlevy> cosman2001: sure, i mean, foreman doesnt care all that much how you collect facts
 /12/2011 20:18:59< lavaman> mco would definitely be nice for reporting
 /12/2011 20:18:59< fenrus02> cosman2001, auto-exporting factor facts?
 /12/2011 20:19:01<@ohadlevy> cosman2001: you could also do a simply facter -y | curl ...
 /12/2011 20:19:16< gwmngilfen> so we're suggesting a pluggable backend for fact collection?
 /12/2011 20:19:36<@ohadlevy> gwmngilfen: i'm not 100% sure if we need one, we just need a generic api to add facts
 /12/2011 20:19:48< gwmngilfen> ah yes, just "send me data in $format"
 /12/2011 20:19:51<@ohadlevy> and then it would be fairly simple for someone to push
 /12/2011 20:19:55< cosman2001> mco plugin --> fact --> foreman or mco plugin --> foreman
 /12/2011 20:19:57<@ohadlevy> like the enc script does that
 /12/2011 20:20:03< gwmngilfen> sure
 /12/2011 20:20:08<@ohadlevy> or the older cronjob etc
 /12/2011 20:20:20<@ohadlevy> ken_barber: any issues from your side? :)
 /12/2011 20:21:03< ashp> I sort of wish we had started the meeting with "What is ohadlevy's roadmap look like"
 /12/2011 20:21:11< ashp> I want to know what YOU want to see happen!
 /12/2011 20:21:22<@ohadlevy> ashp: well, we can try getting to that later on :)
 /12/2011 20:21:42<@ohadlevy> ok, so can we conclude that
 /12/2011 20:22:11<@ohadlevy> 1. we want to extend the proxy to know about puppet kicks, facts etc implemented via mc?
 /12/2011 20:22:20<@ohadlevy> or something around those lines?
 /12/2011 20:22:32<@ohadlevy> or is that fundamentally wrong?
 /12/2011 20:22:49<@ohadlevy> as of the current relationship between foreman --> proxy and not the other way around
 /12/2011 20:22:49< fenrus02> ohadlevy, +expose ui
 /12/2011 20:23:51<@ohadlevy> ok, i suggest we start adding some feature requests, and discuss the details in there
 /12/2011 20:24:05< f0> ohadlevy: +1
 /12/2011 20:24:05<@ohadlevy> step one should be to expose mc common actions into the ui/api.
 /12/2011 20:24:06< ashp> Do we have anyone taking a list of action items or do you want me to collect these?
 /12/2011 20:24:44< ashp> (I'll do it)
 /12/2011 20:24:47<@ohadlevy> ashp++
 /12/2011 20:24:51<@ohadlevy> lol
 /12/2011 20:25:04<@ohadlevy> ok, anything else worth mentioning in mc context?
 /12/2011 20:25:18< bgupta> Let's please keep it optional?
 /12/2011 20:25:23<@ohadlevy> bgupta: sure
 /12/2011 20:25:28< ashp> good idea
 /12/2011 20:25:29< gwmngilfen> bgupta: +1
 /12/2011 20:25:39< ashp> it's already hard enough to set everything up!
 /12/2011 20:25:57<@ohadlevy> ok, next topic, pulp
 /12/2011 20:25:59< fenrus02> bgupta, all proxy things are optional today, i dont see an advantage to mandating any of the items there
 /12/2011 20:26:06-!- fitzdsl changed the topic of #theforeman to: pulp
 /12/2011 20:26:07< ashp> If you integrate pulp I will die happy
 /12/2011 20:26:08< fenrus02> ohadlevy, does that include katello ?
 /12/2011 20:26:15-!- humbeecc [~chris@d51A4FA2A.access.telenet.be] has joined #theforeman
 /12/2011 20:26:16< Bardack> same for me
 /12/2011 20:26:17<@ohadlevy> who added that and why :)
 /12/2011 20:26:19< f0> m so thats my point, i like to configure repos in foreman e.g i can do in spacewalk
 /12/2011 20:26:30< ashp> I didn't add this but we ARE in the middle of trying to setup pulp
 /12/2011 20:26:40< ashp> and therefore +1 to this entire idea ;D
 /12/2011 20:26:56< ahuman> ohadlevy:  +1 for pulp
 /12/2011 20:26:56< ashp> I will however throw out "Do we want to avoid competing with Katello?"
 /12/2011 20:26:58< f0> so i can add or remove repos , or assign default repos to hostgroups
 /12/2011 20:27:06< fenrus02> ashp, katello uses pulp
 /12/2011 20:27:13< ashp> well that's what I mean
 /12/2011 20:27:22< ashp> a lot of what we're requesting is "ohadlevy, turn foreman into katello!"
 /12/2011 20:27:22<@ohadlevy> well, one of katello design goes is to leverage pulp, candlepin and foreman (and puppet)
 /12/2011 20:27:48< ashp> My understanding is that katello consumes foreman too right?  So is foreman the right place to add pulp support?
 /12/2011 20:27:51< fenrus02> ohadlevy, today, those two admin interfaces do not talk at all to eachother
 /12/2011 20:28:04<@ohadlevy> fenrus02: right, but that would change in the upcoming month
 /12/2011 20:28:06<@ohadlevy> s
 /12/2011 20:28:19< gwmngilfen> ashp: agreed, this sounds circular
 /12/2011 20:28:28< bgupta> Is there real interest from the pup maintainers in making pulp support debian/ubuntu? Are there alternative solutions for non-redhat shops?
 /12/2011 20:28:31< ashp> I suppose that's something I wanted to ask you ohadlevy, do you have an idea of how the future is going to look with katello and foreman - do you have any specific areas you dont want to touch because you feel they belong in katello, not foreman?
 /12/2011 20:28:32< fenrus02> ohadlevy, any rough eta on when the unified ui would take place?
 /12/2011 20:28:53< gwmngilfen> bgupta: +1 from this debian shop :)
 /12/2011 20:29:07<@ohadlevy> ashp: well, the whole packages / repos etc concept is not in foreman
 /12/2011 20:29:30<@ohadlevy> ashp: if you remember, a long time ago i did some proof of concept for something, but then later on i joined redhat
 /12/2011 20:29:39<@ohadlevy> and felt that there is some sort of a mismatch
 /12/2011 20:29:46<@ohadlevy> so overall,
 /12/2011 20:29:55 * ohadlevy puts his red hat on
 /12/2011 20:30:07< ashp> Because while I love pulp I don't want to sidetrack you into working on that kind of stuff when there's a team of guys doing so in katello already
 /12/2011 20:30:15<@ohadlevy> katello would provide an awesome ui using both foreman and pulp
 /12/2011 20:30:16< ashp> I want foreman to be a kickass provisioner/puppet front-end :)
 /12/2011 20:30:29< marcellods> so if we want to manage system updates / repo management , we need to drop Foreman's interface and use Katello ?
 /12/2011 20:30:32< fenrus02> ohadlevy, i guess some clarification is in order.  Which UI is going to be the one that the SA sees to manage katello/pulp/foreman?
 /12/2011 20:30:33<@ohadlevy> my main worry is for those not using rpms
 /12/2011 20:30:35< Bardack> +1 to ashp
 /12/2011 20:30:54<@ohadlevy> katello
 /12/2011 20:30:58< bgupta> I would say that one of the great things about puppet/foreman is it's non-secular nature when it comes to OSes/distros..
 /12/2011 20:31:10<@fitzdsl> bgupta: +1
 /12/2011 20:31:15< bgupta> s/non-//
 /12/2011 20:31:15< gwmngilfen> definitely
 /12/2011 20:31:17< ashp> That's true, it would suck for those distros to be left out of repo management.  Does pulp work for non-rpm things however?
 /12/2011 20:31:20<@ohadlevy> bgupta: i agree that this is a mismatch
 /12/2011 20:31:27<@ohadlevy> ashp: no
 /12/2011 20:31:42< fenrus02> ashp, might ask about doing that in #pulp instead.
 /12/2011 20:31:43<@ohadlevy> ashp: a lot of stuff is build with yum plugins etc
 /12/2011 20:31:53< gwmngilfen> managing a repo is easy enough using your config management, so I don't see much value in adding it to foreman
 /12/2011 20:31:58< ashp> OK, so in this context we can only be talking about pulp in rpm distros
 /12/2011 20:32:03< ashp> and so katello is probably the solution there?
 /12/2011 20:32:04<@ohadlevy> gwmngilfen: well, there are tons of other features
 /12/2011 20:32:12< gwmngilfen> fair enough
 /12/2011 20:32:12< bgupta> I would reconsider pulp integration when and if it supported 2-3 distro/OS families.
 /12/2011 20:32:19<@ohadlevy> ashp: for the time being that sounds like the right answer
 /12/2011 20:32:34<@ohadlevy> bgupta: my main question is how do we solve it for the rest of you
 /12/2011 20:33:11< ken_barber> ohadlevy: mco registration is a good way to collect facts yes. Just write a registration agent that pushes into your REST api and your done.
 /12/2011 20:33:22< ken_barber> ohadlevy: I presume this is what you are talking about?
 /12/2011 20:33:25< fenrus02> bgupta, pulp seems rather limited value until it can do that.
 /12/2011 20:33:27<@ohadlevy> ken_barber: you are lagging :)
 /12/2011 20:33:42< ken_barber> ohadlevy: well - 'catching up' - I was at the shops :-).
 /12/2011 20:34:05<@ohadlevy> bgupta: maybe one option would be a very simple repo management
 /12/2011 20:34:12<@ohadlevy> leaving the hard stuff for other tools like pulp
 /12/2011 20:34:22<@ohadlevy> but maybe targeting 60-80% of most common usage cases
 /12/2011 20:34:41<@fitzdsl> ohadlevy: what do you mean by repo management in foreman ?
 /12/2011 20:34:46<@ohadlevy> but I'm not sure if we should let foreman mirror repos, and move content between repos etc
 /12/2011 20:34:49< bgupta> Sure.. But what are we talking about that can't be done in puppet?
 /12/2011 20:34:56< fenrus02> ohadlevy, puppet already has repo mgmt, so just a way to assign repos to a host is all (i guess?)
 /12/2011 20:35:04<@fitzdsl> is it not a puppet role ?
 /12/2011 20:35:18<@ohadlevy> fitzdsl: how do you prevent access to some content?
 /12/2011 20:35:25<@ohadlevy> how do you manage maint windows
 /12/2011 20:35:33<@ohadlevy> for only selection of machines etc
 /12/2011 20:35:35< gwmngilfen> i think we're talking about repo/content creation at this point. which for debian mainly boils down to a directory full of debs
 /12/2011 20:36:03<@ohadlevy> so for those who added that request, what exactly did you had in mind?
 /12/2011 20:36:09< gwmngilfen> ohadlevy: schedules and classes :)
 /12/2011 20:36:17< marcellods> ohadlevy: Does it make sense to change Foreman's architecture more pluggable ? Maybe people could make a plugin for something like pulp ?
 /12/2011 20:36:40<@ohadlevy> marcellods: yeah, thats something on my wishlist :)
 /12/2011 20:37:11< f0> ohadlevy: i had in mind, to assing repos to hosts, pull updates, e.g spacewalk
 /12/2011 20:37:25<@ohadlevy> f0: isnt that == puppet run?
 /12/2011 20:37:25< fenrus02> f0, that is what pulp aims to do
 /12/2011 20:37:43<@ohadlevy> fenrus02: imho pulp can do more
 /12/2011 20:38:07< f0> ohadlevy: hm in a very basic view yes
 /12/2011 20:38:08<@ohadlevy> fenrus02: but we should probably leave that discussion for #pulp :)
 /12/2011 20:38:14 * fenrus02 nods
 /12/2011 20:38:25< ashp> next topic time?
 /12/2011 20:38:30<@ohadlevy> ok, so my take on this so far (feel free to disagree) is that since
 /12/2011 20:38:41<@ohadlevy> 1. its a rpm specific solution
 /12/2011 20:38:43< fenrus02> if katello ui is going to be the top-level ui, then i think it's next menu item
 /12/2011 20:38:48<@ohadlevy> 2. there is an overlap
 /12/2011 20:38:52<@ohadlevy> 3. and the entire katello thing
 /12/2011 20:39:10< Bardack> maybe good if we can add in the topics, a small discussion about foreman UI ... the fixed size columns and stuffs ...
 /12/2011 20:39:13<@ohadlevy> we can revisit this topic in our next roadmap meeting :)
 /12/2011 20:39:25<@ohadlevy> Bardack: please add it to the list in the wiki
 /12/2011 20:39:25< f0> ohadlevy: yes you are right
 /12/2011 20:39:28< gwmngilfen> ohadlevy: agreed
 /12/2011 20:39:30<@ohadlevy> ok, next topic :)
 /12/2011 20:39:44-!- fitzdsl changed the topic of #theforeman to: Parameterized class support
 /12/2011 20:39:53< gwmngilfen> this one is important I think
 /12/2011 20:39:58< ken_barber> woohoo!
 /12/2011 20:39:59< f0> gwmngilfen: +1
 /12/2011 20:40:00<@ohadlevy> yes, I want to support it
 /12/2011 20:40:00<@fitzdsl> I would love that one
 /12/2011 20:40:02< gwmngilfen> certainly to me, anyway :)
 /12/2011 20:40:13< gwmngilfen> or at least, a variety of data types in the Smart vars
 /12/2011 20:40:22< ahuman> ohadlevy: +1 for pulp
 /12/2011 20:40:33<@ohadlevy> ahuman: +1 for which part ?
 /12/2011 20:40:43< bgupta> I am confused. Why do we need it? My understanding is that parameterized classes are a work around for the fact that there is no standardized ENC, and that variable scoping is broken in puppet.
 /12/2011 20:40:49< gwmngilfen> i've gotten very tired of strings like "foo:bar,Baz:bob" and then having to split them in my manifests
 /12/2011 20:40:53< ashp> I want parameterized classes
 /12/2011 20:41:01<@fitzdsl> ohadlevy: shouldn't we target major functionality to version ?
 /12/2011 20:41:05< gwmngilfen> i want to pass in arrays and hashes :)
 /12/2011 20:41:05< ashp> because I'm real fucking tired of classes that exist to hold nothing more than a define
 /12/2011 20:41:10< ashp> I really, really, want parameterized classes
 /12/2011 20:41:15< ashp> so +1 billion for this
 /12/2011 20:41:16<@ohadlevy> so i think this breaks into two
 /12/2011 20:41:29<@fitzdsl> MCO => 0.5 / pulp => later
 /12/2011 20:41:29<@ohadlevy> 1. complex data structures (String, Array, Hash)
 /12/2011 20:41:38<@ohadlevy> 2. data validations
 /12/2011 20:41:47< Bardack> wiki updated
 /12/2011 20:42:10<@ohadlevy> 3. pushing data to classes directly
 /12/2011 20:42:19< gwmngilfen> ohadlevy: what happened to the proof-of-concept code for editing smart vars in the Hosts page? because that seemed very close to what we're looking for...
 /12/2011 20:42:21< marcellods> fitzdsl: Shouldn't we write down :  pluggability => 0.5 ?
 /12/2011 20:42:35< marcellods> i'ts on ohad's wishlist :)
 /12/2011 20:42:41< ashp> even with smart variables
 /12/2011 20:42:46< ashp> you still have to build wrapper classes that hold defines
 /12/2011 20:42:47<@ohadlevy> gwmngilfen: 1 and 2 should be done for the smart vars in general
 /12/2011 20:42:49< ashp> that you then pass data into
 /12/2011 20:42:58< ashp> so parameterized classes are still needed
 /12/2011 20:43:03<@fitzdsl> ashp: yes
 /12/2011 20:43:05< ashp> plus, for another consideration
 /12/2011 20:43:12< ashp> if we want people to move from puppet/otherenc->foreman
 /12/2011 20:43:17< ashp> they don't want to ditch their parameterized classes
 /12/2011 20:43:35< bgupta> Is there anyway to add support in a generic fashion for this without requiring upgrading puppet to the newest version?
 /12/2011 20:43:39<@fitzdsl> and workarrount for paramaterized class support is a pain in the ass
 /12/2011 20:44:05<@fitzdsl> bgupta: why do you need the newest version ?
 /12/2011 20:44:16< ashp> bgupta: I think it could be added so that if you don't use the paramaterized classes you don't need to update
 /12/2011 20:44:20< ashp> it's optional after all
 /12/2011 20:44:23< ahuman> help
 /12/2011 20:44:26<@ohadlevy> fitzdsl: well, i think it was added at 2.6.5 or os
 /12/2011 20:44:29< gwmngilfen> bgupta: if you have no param'd classes in your manifests then you shouldn't see an issue
 /12/2011 20:45:03<@ohadlevy> bgupta: we could have a setting which flag if we enable that feature or not
 /12/2011 20:45:17<@ohadlevy> as you cant provide hash/arrays in ENC in older versions too
 /12/2011 20:45:26<@fitzdsl> I don't think there is many people here who are not in 2.6
 /12/2011 20:45:27<@ohadlevy> so my take on that is
 /12/2011 20:45:36<@ohadlevy> fitzdsl: epel just recently upgraded
 /12/2011 20:45:37< gwmngilfen> in any case, it's mostly the data types that hold me back - and we'd need them to support param classes anyway
 /12/2011 20:45:48<@ohadlevy> gwmngilfen: i agree
 /12/2011 20:46:15< gwmngilfen> amos will love this... :)
 /12/2011 20:46:18<@ohadlevy> so my initial goal with smart vars, were to add the data types, and then later on add the support for params
 /12/2011 20:46:28<@ohadlevy> gwmngilfen: yeah, sadly he couldnt make it today
 /12/2011 20:46:38<@fitzdsl> and definition support ?
 /12/2011 20:46:53<@ohadlevy> fitzdsl: definition support == params classes right?
 /12/2011 20:46:55< bgupta> ohadlevy: smart vars are queryable metadata in foreman?
 /12/2011 20:47:00<@ohadlevy> bgupta: yes
 /12/2011 20:47:01<@fitzdsl> ohadlevy: nope it's different
 /12/2011 20:47:23< bgupta> As long as you keep smartvars around, I am ok with providing alternative methods.
 /12/2011 20:47:23<@fitzdsl> you can have multiple definition (like ssh pub keys)
 /12/2011 20:47:34<@fitzdsl> but only one instance of paramaterized class
 /12/2011 20:47:36-!- eshamow [~eshamow@li394-212.members.linode.com] has joined #theforeman
 /12/2011 20:47:43< gwmngilfen> fitzdsl: why do you need those in foreman? they need to be called from a manifest anyway...
 /12/2011 20:47:49-!- sp44t [~sp33t@2001:960:64b:0:5652:ff:fe0f:d4e4] has joined #theforeman
 /12/2011 20:47:53< ashp> you'd use smart vars with the param classes
 /12/2011 20:47:58< ashp> they would complement each other, not replace
 /12/2011 20:48:03< sp44t> Hi all, a bit too late I admit...
 /12/2011 20:48:05< ashp> if ohadlevy takes away smart vars I'm eating his hands
 /12/2011 20:48:09< ashp> so don't worry bgupta !
 /12/2011 20:48:10< Bardack> true :)
 /12/2011 20:48:33<@ohadlevy> fitzdsl: but you can have multiple puppet classes with different params
 /12/2011 20:48:42<@ohadlevy> fitzdsl: so you could build a class that looks like a define
 /12/2011 20:49:02< bgupta> Mostly I want to be able to call them from templates, and have a way to set them from within manifests... unrelated to parameterized classes
 /12/2011 20:49:24<@ohadlevy> bgupta: call who?
 /12/2011 20:49:25<@ohadlevy> :)
 /12/2011 20:49:28-!- sp44t [~sp33t@2001:960:64b:0:5652:ff:fe0f:d4e4] has quit [Remote host closed the connection]
 /12/2011 20:49:36-!- sp33t [~sp33t@83.101.5.149] has quit [Remote host closed the connection]
 /12/2011 20:50:02<@ohadlevy> fitzdsl: ?
 /12/2011 20:50:08< bgupta> call smartvars... IE: Stick some ruby method call in a template that populates part of a template based on smartvars
 /12/2011 20:50:17<@ohadlevy> bgupta: yeah, thats possible
 /12/2011 20:50:18 * fitzdsl has trouble to follow
 /12/2011 20:50:20-!- sp33t [~sp33t@2001:960:64b:0:5652:ff:fe0f:d4e4] has joined #theforeman
 /12/2011 20:50:32<@ohadlevy> fitzdsl: i think that params classes can replace defines
 /12/2011 20:50:43<@fitzdsl> not always
 /12/2011 20:50:59<@ohadlevy> fitzdsl: so if you have a class called mount($src, $dst)
 /12/2011 20:51:04<@fitzdsl> you can't assign for a same host twice a paramterized class
 /12/2011 20:51:16<@fitzdsl> even if params are different
 /12/2011 20:51:17<@ohadlevy> you could provide a different src and dst and have mulltiple instances of classes
 /12/2011 20:51:24<@fitzdsl> nope
 /12/2011 20:51:37<@fitzdsl> this in that case should be a definition
 /12/2011 20:51:49< sp33t> that's what I thought too
 /12/2011 20:52:37<@ohadlevy> I guess I am wrong then :)
 /12/2011 20:52:47< ken_barber> yeah parameterized classes are singletons
 /12/2011 20:52:58<@fitzdsl> ohadlevy: for latter reading http://www.craigdunn.org/2011/09/puppet-parameterized-classes-vs-definitions/
 /12/2011 20:53:03<@ohadlevy> fitzdsl: so afair, the only way to pass defines, is by using the create resource method
 /12/2011 20:53:19<@ohadlevy> and that would require some sort of a hash of options
 /12/2011 20:53:29<@fitzdsl> what do you mean to "pass defines" ?
 /12/2011 20:53:36< gwmngilfen> fitzdsl: defines don't appear in the ENC data, so I don't see how we'd use them in foreman anyway
 /12/2011 20:53:38<@ohadlevy> sorry, pass options
 /12/2011 20:53:45< ken_barber> yes - support for structured data would be required to get create_resources to work
 /12/2011 20:53:48< ken_barber> at least from an enc
 /12/2011 20:54:02<@ohadlevy> gwmngilfen: well, we could in theory support it via an external function
 /12/2011 20:54:26< gwmngilfen> i can see a class with a smart var (or param class) that takes structured data and *calls* the define - but we can do that now
 /12/2011 20:54:26<@ohadlevy> gwmngilfen: but thats not really related to this topic :)
 /12/2011 20:54:44<@ohadlevy> ok, so to summarize, yes I want to support params classes
 /12/2011 20:54:51<@ohadlevy> its mostly UI work
 /12/2011 20:55:06<@ohadlevy> but once we finish all of the smart vars stuff, it would be trivial
 /12/2011 20:55:13<@ohadlevy> next topic? :)
 /12/2011 20:55:19<@fitzdsl> ohadlevy: how do you parse puppet classes to know variables needed ?
 /12/2011 20:55:25< gwmngilfen> happy to volunteer some of limited coding time to help on that issue ohadlevy
 /12/2011 20:55:29<@ohadlevy> fitzdsl: thats one of the issues to fix
 /12/2011 20:55:33< gwmngilfen> s/of/of my/
 /12/2011 20:55:34-!- fitzdsl changed the topic of #theforeman to: BMC support
 /12/2011 20:55:50<@ohadlevy> gwmngilfen++
 /12/2011 20:56:05<@ohadlevy> gwmngilfen: i think when we are done, we should try to decide prios
 /12/2011 20:56:13<@ohadlevy> cosman2001: is that your feature request?
 /12/2011 20:56:16< gwmngilfen> for sure
 /12/2011 20:56:21< cosman2001> yes
 /12/2011 20:56:41<@ohadlevy> i would like to support it too
 /12/2011 20:56:52< cosman2001> so cobbler has bmc support and I think foreman should to
 /12/2011 20:57:14< cosman2001> only makes sense to integrate the whole provisining process (change boot order and power cycle system)
 /12/2011 20:57:14<@ohadlevy> cosman2001: how much work would it be to reuse fencing agents?
 /12/2011 20:57:21< gwmngilfen> can we define "bmc support"? We can specify some of it now, can't we?
 /12/2011 20:57:43< cosman2001> bmc = out of band management (ilo, drac, ipmi)
 /12/2011 20:57:59< Phibs> ilo/drac are  quite different than bmc/ipmi
 /12/2011 20:58:00<@ohadlevy> which translates to?
 /12/2011 20:58:00< ashp> oh ok
 /12/2011 20:58:05< gwmngilfen> i know what it is - what do want to do with it :)
 /12/2011 20:58:08<@ohadlevy> power on/off
 /12/2011 20:58:10<@ohadlevy> boot order
 /12/2011 20:58:12< cosman2001> bmc = baseboard management controller
 /12/2011 20:58:17< ashp> power on/off would be key ones I suppose
 /12/2011 20:58:27<@ohadlevy> poweron is easy :)
 /12/2011 20:58:28< Phibs> for cluster fencing it sure is
 /12/2011 20:58:37< cosman2001> fence agents can only do a few basic things
 /12/2011 20:58:44< cosman2001> ipmi can do sooo much more
 /12/2011 20:58:53<@ohadlevy> ok
 /12/2011 20:58:56<@ohadlevy> so I would suggest
 /12/2011 20:59:02< gwmngilfen> i've a fair bit of background coding for ipmi at least - used to work on a HPC clustering product :)
 /12/2011 20:59:08<@ohadlevy> 1. we put more details into the feature request
 /12/2011 20:59:22<@ohadlevy> and we start to tackle that
 /12/2011 20:59:43<@ohadlevy> i didnt hear anyone object
 /12/2011 20:59:45< cosman2001> I had already planned on making a freeipmi gem to control ipmi
 /12/2011 20:59:49<@fitzdsl> do all Drac/iLo support IPMI ?
 /12/2011 21:00:04< cosman2001> all recent (last five years or so)
 /12/2011 21:00:05<@fitzdsl> is that really a standard we could use ?
 /12/2011 21:00:09< gwmngilfen> setting the auth access is the hard part - controlling it after is easy, i think
 /12/2011 21:00:19< bgupta> I am fairly certain Dell does. I haven't used it though.
 /12/2011 21:00:20< jbaldridge> fitzdsl: Not all ILO versions.
 /12/2011 21:00:28<@fitzdsl> what about VNC support :)
 /12/2011 21:00:42<@ohadlevy> fitzdsl: for which part?
 /12/2011 21:00:55< cosman2001> ilo 1 supports ipmi 1.5
 /12/2011 21:01:03<@fitzdsl> I know Drac support VNC console
 /12/2011 21:01:04< cosman2001> ilo2+ support 2.1
 /12/2011 21:01:24<@ohadlevy> ok, so if by using ipmi we get 70-80% of the bare metal, I'm more than happy to start with that :)
 /12/2011 21:01:26< jbaldridge> Also, Lights-Out 100 (The BMC on HP's 1xx line)  is all ipmi
 /12/2011 21:01:36<@ohadlevy> we need it to build it in a generic fashion
 /12/2011 21:01:43<@ohadlevy> like the proxy should support power on  / power off
 /12/2011 21:01:47< fenrus02> afaict, ipmi support would go a long way for supporting those cards
 /12/2011 21:01:51<@ohadlevy> and ipmi would be one way to implement it
 /12/2011 21:01:59< gwmngilfen> ohadlevy: +1 on running it through the proxy
 /12/2011 21:02:00<@fitzdsl> would'nt that be possible to have console output in Foreman UI ?
 /12/2011 21:02:07< cosman2001> freeipmi is the only tool that can autodetect which version of ipmi the bmc supports
 /12/2011 21:02:19<@ohadlevy> fitzdsl: its more complicated then it sounds
 /12/2011 21:02:25<@fitzdsl> ohadlevy: I'm sure of it
 /12/2011 21:02:28<@ohadlevy> fitzdsl: it requires everyone to install an addon
 /12/2011 21:02:37<@fitzdsl> but foreman dev can do magic :)
 /12/2011 21:02:51<@fitzdsl> ohadlevy: as always is could be optional
 /12/2011 21:03:00<@ohadlevy> fitzdsl: well, we can have a vnc proxy to html5
 /12/2011 21:03:12<@ohadlevy> but that would suck over a wan
 /12/2011 21:03:33<@fitzdsl> it's generally for bios setup
 /12/2011 21:03:39<@fitzdsl> (in my case)
 /12/2011 21:03:52<@ohadlevy> fitzdsl: i agree, but ipmi does support some bios management features
 /12/2011 21:03:59<@ohadlevy> ok
 /12/2011 21:03:59<@fitzdsl> ohadlevy: yep
 /12/2011 21:04:16<@ohadlevy> so, feel free to double check and add new feature requests if none exists already
 /12/2011 21:04:34<@ohadlevy> afterwards, we would need to do an open issues review
 /12/2011 21:04:46<@ohadlevy> anything else to add on this topic?
 /12/2011 21:05:10<@ohadlevy> if not, then next topic please ;)
 /12/2011 21:05:30-!- fitzdsl changed the topic of #theforeman to: remove virt dependency
 /12/2011 21:05:34< cosman2001> ok, i created the next topic too since I worked on esx support
 /12/2011 21:05:39< ahuman> i think we should look at what Dell/others are doing with their light-outs stuff, with Crowbar, and try to re-use/leverage some of those ideas  https://github.com/dellcloudedge/barclamp-ipmi
 /12/2011 21:05:48 * fitzdsl really think we should target functionality
 /12/2011 21:06:03<@ohadlevy> ahuman: interesting
 /12/2011 21:06:19-!- ^conner [~conner@leo.tuc.noao.edu] has quit [Ping timeout: 255 seconds]
 /12/2011 21:06:42<@ohadlevy> cosman2001: ok, and ? :)
 /12/2011 21:06:47< fenrus02> esx and hyperv support would be entertaining
 /12/2011 21:07:04< torrancew> esx support++
 /12/2011 21:07:04< cosman2001> the topic is more about removing virt from foreman
 /12/2011 21:07:09< cosman2001> and make more generic
 /12/2011 21:07:22< fenrus02> remove the dep, make it optional and plugable
 /12/2011 21:07:34<@ohadlevy> fenrus02: its already optional
 /12/2011 21:07:43<@ohadlevy> fenrus02: i.e. nothing happens if libvirt is not installed
 /12/2011 21:07:45< cosman2001> as the foreman code references the virt lib in many places so there is lots of work to do if one wants to use sometime besides libvirt
 /12/2011 21:07:52<@ohadlevy> cosman2001: i agree
 /12/2011 21:07:52< gwmngilfen> i was going to say, i don't recall being force to install libvirt
 /12/2011 21:07:55< fenrus02> ohadlevy, i am behind the times, my bad
 /12/2011 21:08:01< gwmngilfen> but more backends is always good
 /12/2011 21:08:11<@ohadlevy> the way i see it
 /12/2011 21:08:20< gwmngilfen> i have some xen servers that could use some love :)
 /12/2011 21:08:27<@ohadlevy> if you are talking about a direct hypervisor (e.g. kvm/esx) communication
 /12/2011 21:08:28< cosman2001> libvirt and esx are not the best choice in my opinion
 /12/2011 21:08:33<@ohadlevy> libvirt is probably the better way
 /12/2011 21:08:50<@ohadlevy> however
 /12/2011 21:08:50< fenrus02> libvirt can already speak to esx
 /12/2011 21:08:55< Bardack> yep
 /12/2011 21:09:00< Bardack> but only to 1 esx
 /12/2011 21:09:06< Bardack> at the moment, so quite "limited"
 /12/2011 21:09:10<@ohadlevy> if you want to talk to a "cloud"
 /12/2011 21:09:13 * fenrus02 nods
 /12/2011 21:09:17<@ohadlevy> could be vshepre
 /12/2011 21:09:20<@ohadlevy> ovirt
 /12/2011 21:09:24<@ohadlevy> es2
 /12/2011 21:09:24< cosman2001> the topic isn't about esx though its about the ability to use any backend within foreman
 /12/2011 21:09:25<@ohadlevy> ec2
 /12/2011 21:09:37<@ohadlevy> then we need a complete different implementation
 /12/2011 21:09:44<@ohadlevy> because
 /12/2011 21:09:58<@ohadlevy> 1. it might be template based, so the whole provisioning flow is wrong
 /12/2011 21:10:00< fenrus02> ohadlevy, isnt that where aeolus comes in?
 /12/2011 21:10:45<@ohadlevy> template == disk image
 /12/2011 21:11:02< marcellods> ohadlevy: what about fog ?
 /12/2011 21:11:24<@ohadlevy> fenrus02: there is some overlap yes
 /12/2011 21:11:38<@ohadlevy> fenrus02: but at the moment, aeolus doesnt really do config management
 /12/2011 21:11:38< fenrus02> ohadlevy, integration plans for that? or does that fall under katello as well?
 /12/2011 21:11:52<@ohadlevy> fenrus02: i think its foreman place to do that
 /12/2011 21:11:54< Bardack> true, I read interesting stuffs abouf fog
 /12/2011 21:12:00< cosman2001> i kind of see foreman dividing systems into two categories
 /12/2011 21:12:02<@ohadlevy> marcellods: its one of the better libs for that
 /12/2011 21:12:13< marcellods> ohadlevy: any plans on that ?
 /12/2011 21:12:18< cosman2001> 1. physical
 /12/2011 21:12:25< cosman2001> 2. viritual
 /12/2011 21:12:31<@ohadlevy> marcellods: yes, amos is planning of adding support for ovirt
 /12/2011 21:12:46< marcellods> and ovirt uses it ?
 /12/2011 21:12:47<@ohadlevy> and then, we might implement other stuff using fog
 /12/2011 21:12:50< marcellods> ah
 /12/2011 21:12:53<@ohadlevy> or directly via native gems if they exists
 /12/2011 21:12:55< cosman2001> where virtual is managed by 3rd party tool (libvirt, virt, fog, ec2, ovirt)
 /12/2011 21:12:56< bgupta> cosman2001: I would add cloud as a third type.. even though it is built on virtual
 /12/2011 21:13:11< bgupta> ahh
 /12/2011 21:13:24< cosman2001> yes but cloud usually equals virtual machine right?
 /12/2011 21:13:27<@ohadlevy> cosman2001: i would put libvirt in the #1 category
 /12/2011 21:13:28< nudnik> cosman2001: #1 is http://theforeman.org/issues/show/1 "Foreman - Feature #1: Ldap/AD authentication - Foreman"
 /12/2011 21:13:41< fenrus02> shouldnt foreman shovel all vm provisioning off to a single lib set where it would delegate by type?
 /12/2011 21:13:43<@ohadlevy> as really, we provision them as like they are bare metal
 /12/2011 21:14:01< fenrus02> instead of having hardcoded any specific gem all over the code
 /12/2011 21:14:17< cosman2001> fenrus02, my thoughts exactly
 /12/2011 21:14:18<@ohadlevy> for me, cosman2001 # 2 breaks into two
 /12/2011 21:14:38<@ohadlevy> fenrus02: sure, it should be a generic interface, maybe the same concept like the proxies
 /12/2011 21:15:03< fenrus02> not a small undertaking, granted - but seems to be the most portable later
 /12/2011 21:15:23<@ohadlevy> fenrus02: well, in some degree, thats already fog
 /12/2011 21:15:40< fenrus02> not familiar with fog, seems i have some homework :)
 /12/2011 21:15:50< Bardack> so guys, I m quite sick so time to sleep ... I'll read all the history tomorrow morning
 /12/2011 21:16:03< gwmngilfen> sleep well bgupta
 /12/2011 21:16:04< Bardack> I just want to add 1 thing to you all and specially to ohad
 /12/2011 21:16:07< gwmngilfen> *Bardack
 /12/2011 21:16:14< gwmngilfen> (damn tab completion :P)
 /12/2011 21:16:25< Bardack> thanks for this amazing service you provide with the foreman
 /12/2011 21:16:35< Bardack> and really excited to be part of this story
 /12/2011 21:16:38< bgupta> One practical issue with fog support. It has a large depency graph... the majority of folks needing cloud need ec2, so bringing in fog for ec2 support is a pretty heavy requirement
 /12/2011 21:16:39<@ohadlevy> :)
 /12/2011 21:17:07<@ohadlevy> cosman2001: so i agree we need to do a major refactor for supporting other implementations
 /12/2011 21:17:13< Bardack> FIN ACK (you're all fucked and cannot talk anymore) ;) bye
 /12/2011 21:17:14< fenrus02> bgupta, tagnent, but is fog already in rhel / fedora ?
 /12/2011 21:17:26<@ohadlevy> fenrus02: not even close
 /12/2011 21:17:40< fenrus02> "tangent" erg.. typing is hard apparently.
 /12/2011 21:17:55< fenrus02> ohadlevy, bundled or license issue?
 /12/2011 21:18:09-!- hyde [4016a001@gateway/web/freenode/ip.64.22.160.1] has joined #theforeman
 /12/2011 21:18:12<@ohadlevy> fenrus02: i think just packaging effort, but i never tried, so i cant tell :)
 /12/2011 21:18:22 * fenrus02 nods
 /12/2011 21:18:24<@ohadlevy> cosman2001: ok, anything else we should add to this topic?
 /12/2011 21:18:31< cosman2001> nope
 /12/2011 21:18:34-!- ^conner [~conner@leo.tuc.noao.edu] has joined #theforeman
 /12/2011 21:18:43<@ohadlevy> cosman2001: next topic is ESX
 /12/2011 21:18:53-!- fitzdsl changed the topic of #theforeman to: ESX integration
 /12/2011 21:18:56< fenrus02> isnt esx covered from the previous?
 /12/2011 21:19:05< gwmngilfen> i thought we just did that?
 /12/2011 21:19:08<@ohadlevy> cosman2001: anything to add :) ?
 /12/2011 21:19:15< cosman2001> esx seems to work good by itself
 /12/2011 21:19:24< bgupta> I would like to add one thing
 /12/2011 21:19:36< cosman2001> I just wanted to get thoughts about going forward into developement
 /12/2011 21:19:54< cosman2001> vcenter and libvirt seems to have bugs
 /12/2011 21:20:05< bgupta> If we add multiple "provisioning types/engines" to the UI, additing one that is an additional layer of abstraction like Fog, could be problematic for UI design.
 /12/2011 21:20:08<@ohadlevy> cosman2001: I just need some free mental cycles and I'll try to add that
 /12/2011 21:20:14< ashp> ESX integration would definitely rule
 /12/2011 21:20:18< ashp> because I'm stuck using it at work
 /12/2011 21:20:25< ashp> so i spend a lot of time going into vsphere to make vm's
 /12/2011 21:20:35<@ohadlevy> bgupta: no one said any of these features are simple
 /12/2011 21:21:02 * ohadlevy hopes ovirt will take over soon :)
 /12/2011 21:21:06< cosman2001> libvirt is very limiting with esx which is why the last topic is a pain point since I cannot use a different lib
 /12/2011 21:21:13< bgupta> Plus fog has a lot of overlap with smartproxy (in particular DNS)
 /12/2011 21:21:15< ashp> ohadlevy: Non foreman question - is ovirt actually usable?
 /12/2011 21:21:25<@ohadlevy> ashp: i think so
 /12/2011 21:21:26< hyde> it would be better for foreman to use vmware sdk api.
 /12/2011 21:21:32< ashp> adding to my endless list of stuff to try
 /12/2011 21:21:38 * gwmngilfen makes a note to play with ovirt
 /12/2011 21:21:41< ashp> because I hope to persuade them not to use esx for _everything_
 /12/2011 21:22:06<@ohadlevy> cosman2001: if we go the fog route, would it solve this particular problem?
 /12/2011 21:22:07< cosman2001> I honestly think adding my esx work is good for development for not production quality
 /12/2011 21:22:24< cosman2001> no fog uses libvirt
 /12/2011 21:22:31<@ohadlevy> one issue i had with fog, is that it felt its not geared towards UI
 /12/2011 21:22:42<@ohadlevy> cosman2001: not for vsphere
 /12/2011 21:22:45< cosman2001> using something like the vmware ruby interface
 /12/2011 21:22:53< marcellods> is PE using libvirt with fog?
 /12/2011 21:23:00<@ohadlevy> marcellods: yes
 /12/2011 21:23:15< cosman2001> PE uses a fork of fog with their own submitted ESX code
 /12/2011 21:23:18<@ohadlevy> marcellods: afair, they contributed that part to fog
 /12/2011 21:23:28< bgupta> ohadlevy: My understanding is that the PE ESX integration is proprietary
 /12/2011 21:23:39<@ohadlevy> bgupta: i see
 /12/2011 21:23:43< marcellods> ohadlevy: I though Patrick did... anyway...
 /12/2011 21:23:52< bgupta> at least according to the feature comparison list between the opensource and PE versions
 /12/2011 21:23:54<@ohadlevy> marcellods: Patrick added libvirt
 /12/2011 21:23:55< eshamow> bgupta: part of it is, part isn't.  the upstream fog commits should be public.
 /12/2011 21:24:08<@ohadlevy> yeah more PL :)
 /12/2011 21:24:21< eshamow> hi ohadlevy :)
 /12/2011 21:24:56< cosman2001> libvirt and vcenter just don't make practical sense in that you need to add every ESX server in the cluster
 /12/2011 21:25:05<@ohadlevy> sorry guys, brb
 /12/2011 21:26:00< fenrus02> fog is mit license, so in theory, should be included easily into the various distros.
 /12/2011 21:26:04< cosman2001> so if we do add my esx patch it should only be for esx:// URI
 /12/2011 21:26:11< ashp> We should get ohadlevy to add an ovirt module to his stuff so we can not use esx :D
 /12/2011 21:26:22<@ohadlevy> back
 /12/2011 21:26:58<@ohadlevy> so to summarize, we can use libvirt today with esx, not ideal, as most people dont want to use a single hypervisor
 /12/2011 21:27:11< cosman2001> correct,
 /12/2011 21:27:15<@ohadlevy> and the other two alternatives is
 /12/2011 21:27:24<@ohadlevy> using fog/vmware ruby binding
 /12/2011 21:27:32<@ohadlevy> or shelling out and using the sdk or something
 /12/2011 21:27:49<@ohadlevy> but in anycase, you guys want that feature :)
 /12/2011 21:27:57< cosman2001> yep, which all depends on the previous topic
 /12/2011 21:28:33< ashp> third option: ask if puppetlabs want to share their PE work?
 /12/2011 21:28:42< hyde> i was told that enterprise puppet uses vmware sdk api to create vmware guest.
 /12/2011 21:28:45<@ohadlevy> cosman2001: no one forces us to use virt for vmware, as i mentioned, if we go to a more virtualization service solution (e.g. not a single hypervisor) then we need something else anyway
 /12/2011 21:29:35<@ohadlevy> ok, i suggest we take this topic off meeting, and continue discussion?
 /12/2011 21:29:43< cosman2001> sounds good
 /12/2011 21:29:45< gwmngilfen> +1
 /12/2011 21:29:50<@ohadlevy> next topic :)
 /12/2011 21:29:56<@ohadlevy> ruby version?
 /12/2011 21:30:06<@ohadlevy> bgupta: is that yours?
 /12/2011 21:30:10< ashp> yes, it should use a ruby version
 /12/2011 21:30:12< ashp> i agree :D
 /12/2011 21:30:18< bgupta> yes
 /12/2011 21:30:22< bgupta> it is mine sorry
 /12/2011 21:30:42< bgupta> meeting was longer than I expected so task switched for a sec
 /12/2011 21:30:51<@ohadlevy> tell us about it :)
 /12/2011 21:30:55< bgupta> I think we need to start thinking about formalizing policy for ruby version support
 /12/2011 21:31:07< bgupta> SO people can make plans
 /12/2011 21:31:13< bgupta> s/people/users/
 /12/2011 21:31:14<@ohadlevy> bgupta: for foreman itself, we are bound by what rails supports
 /12/2011 21:31:33<@ohadlevy> as you guys know, we are switching to rails 3, which requires ruby 1.87+
 /12/2011 21:31:43<@ohadlevy> so 0.5+ would require that
 /12/2011 21:31:57< ashp> when you say + it does include .87 right?
 /12/2011 21:32:01<@ohadlevy> yes
 /12/2011 21:32:02< ken_barber> fyi about 1.8.7: http://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/
 /12/2011 21:32:14< bgupta> I have no issue with that change, I just think we need to be able to telgraph these kinds of changes to our users better, so distro/version support will be easier to handle.
 /12/2011 21:32:15< ashp> ok, because I have enough fucking headaches from RHEL6 and outdated things already, phew :)
 /12/2011 21:32:57<@ohadlevy> ken_barber: thanks, but sadly its up to the distributions to decide
 /12/2011 21:33:15< ken_barber> ohadlevy: I know - just wanted to let you know what upstream is doing.
 /12/2011 21:33:18< bgupta> And if we are going to be breaking commonly deployed distro support, we should think about how to support it..
 /12/2011 21:33:30<@ohadlevy> bgupta: for the moment, i dont plan that
 /12/2011 21:33:36< cosman2001> forgot to mention, libvirt is added ESX5 support in libvirt version .9.8 (now in rc2 phase)
 /12/2011 21:33:52<@ohadlevy> bgupta: the proxy can run on even older rubys
 /12/2011 21:33:57<@ohadlevy> so if we can, we usually try to support it
 /12/2011 21:34:07<@ohadlevy> the only critical part is usually security updates
 /12/2011 21:34:17<@ohadlevy> and thats not driven by us
 /12/2011 21:35:02<@ohadlevy> bgupta: so beside saying - i agree, not sure if I have anything else to add
 /12/2011 21:35:07-!- fitzdsl changed the topic of #theforeman to: ruby version
 /12/2011 21:35:16< ken_barber> when is rhel5 eosl?
 /12/2011 21:35:21< bgupta> I guess what would work would be to point to some way for still supported older distro versions to have an official path to get newer versions of ruby, even if that is "here is the source and instructions"
 /12/2011 21:35:34<@ohadlevy> bgupta: or use older version of foreman
 /12/2011 21:36:19<@ohadlevy> next topic?
 /12/2011 21:36:41-!- fitzdsl changed the topic of #theforeman to: support 3d party tools
 /12/2011 21:37:07<@ohadlevy> is this more around foreman having hooks to start other tools?
 /12/2011 21:37:08< cosman2001> I made this next topic as bgupta and I work on third party tools
 /12/2011 21:37:13< lavaman> rhel has a 7 year life cycle
 /12/2011 21:37:32< ken_barber> lavaman: yeah found it: https://access.redhat.com/support/policy/updates/errata/ (sorry - I know we've jumped topic)
 /12/2011 21:37:39< lavaman> hehe
 /12/2011 21:37:51< marcellods> ohadlevy: is that the famous pluggability we just talked about ? :)
 /12/2011 21:37:58< cosman2001> I would like to foreman have a 3rd party tools API
 /12/2011 21:38:01<@ohadlevy> marcellods: thats what I;m trying to figure out
 /12/2011 21:38:16< hyde> When foreman could be integrated with hiera? for example: Putting hiera yaml data in some foreman database, and have GUI interfact to interact ..
 /12/2011 21:38:40<@ohadlevy> cosman2001: ok so not a plugin arch like redmine
 /12/2011 21:38:43< cosman2001> so when foreman makes drastic changes the 3rd party API can simply refactor and not mess up anybody's 3rd party tool
 /12/2011 21:39:15< cosman2001> if you are familiar with how cobbler works this is what I am requesting
 /12/2011 21:39:16<@ohadlevy> cosman2001: in other words, make sure the api doesnt break?
 /12/2011 21:39:29<@ohadlevy> cosman2001: I'm not sure exactly of what do you mean
 /12/2011 21:39:46< cosman2001> so cobbler has its api that runs as cobblerd
 /12/2011 21:40:03< cosman2001> the web ui actually talks directly to the cobblerd api
 /12/2011 21:40:24< cosman2001> and any third party tool can talk to the cobblerd api using various methods
 /12/2011 21:40:28< cosman2001> json, xmlrpc
 /12/2011 21:40:40< ashp> ohadlevy: Can I ask a quick non-meeting question while you're here - the certs between the proxy and foreman - I made certs, via puppetca for the proxy but it seems like foreman is looking for its own private key
 /12/2011 21:40:50< ashp> ohadlevy: Should I be making keys for foreman and distributing those to the proxy instead?
 /12/2011 21:41:04<@ohadlevy> ashp: simply reuse puppet certs
 /12/2011 21:41:26<@ohadlevy> cosman2001: well, what exactly do you want to change
 /12/2011 21:41:27< ashp> ohadlevy: But which because foreman is specifically looking for its own private key when I try to add a proxy
 /12/2011 21:41:35< ashp> ohadlevy: I don't understand who's key goes where and the docs are confusing
 /12/2011 21:41:53<@ohadlevy> ashp: so hold on with that thought, you could change the keys in the settings
 /12/2011 21:41:59< cosman2001> a want a api that talks to foreman on localhost:3000
 /12/2011 21:42:04< ashp> k, will look there and stop interrupting
 /12/2011 21:42:25<@ohadlevy> cosman2001: but you got that already?
 /12/2011 21:42:34< cosman2001> where I can add additionall support independently of updating the foreman code
 /12/2011 21:42:42<@ohadlevy> cosman2001: we wont change foreman internals to use the api web service to draw the ui
 /12/2011 21:42:55<@ohadlevy> cosman2001: we want to add ruby bindings to the api
 /12/2011 21:43:02<@ohadlevy> cosman2001: like i started in stacker
 /12/2011 21:43:13<@ohadlevy> so you could have a host object, which is implemented over the api
 /12/2011 21:43:17<@ohadlevy> i think thats what you are after
 /12/2011 21:43:52<@ohadlevy> cosman2001: i suggest to take this offline, its a good discussion, but probably relevant only for those who use the API
 /12/2011 21:44:03< cosman2001> agreed, next topic then
 /12/2011 21:44:12 * ohadlevy thinks everyone should checkout cosman2001 mobile app for foreman :)
 /12/2011 21:44:23< gwmngilfen> +1 for remoteadmin
 /12/2011 21:44:27< gwmngilfen> it's awesome
 /12/2011 21:44:31<@ohadlevy> next topic then
 /12/2011 21:44:38<@ohadlevy> cosman2001: pw encryption
 /12/2011 21:44:56< cosman2001> http://theforeman.org/projects/foreman/wiki/Password_Encryption
 /12/2011 21:45:00-!- fitzdsl changed the topic of #theforeman to: password encryption
 /12/2011 21:45:18< cosman2001> I feel weary about addiing all my BMC and ESX credentials knowing there is no encryption
 /12/2011 21:45:19< jpalmer> ohadlevy: I liked remoteadmin until I setup ssl.  I can't get it to accept self-signed certs from puppetca anymore :/
 /12/2011 21:45:47< jpalmer> but,  testflightapp.com is the shit!  ;)
 /12/2011 21:46:05< cosman2001> so I broke down the passwords into two types
 /12/2011 21:46:05< marcellods> jpalmer: apple only right ?
 /12/2011 21:46:06<@ohadlevy> cosman2001: how about 1. using puppet certs to encrypt, 2. using gpg or similar?
 /12/2011 21:46:23< fenrus02> ruby crypto is rather slow
 /12/2011 21:46:44< jpalmer> cosman2001: there is a decent article about encrypting data in hiera (I think)  maybe we can apply the same idea to your data in foreman somehow?
 /12/2011 21:46:45< fenrus02> using puppet certs for auth would be nice though
 /12/2011 21:46:54< ken_barber> gpg is nice. I use hiera-gpg for this purpose.
 /12/2011 21:47:07< jpalmer> yeah,  hiera-gpg.  that's the one I was thinking of.
 /12/2011 21:47:09<@ohadlevy> fenrus02: it sucks if you need to replace your certs :)
 /12/2011 21:47:18< cosman2001> I think we should stay away from certs
 /12/2011 21:47:38< fenrus02> ohadlevy, granted, but that gives you another year :)
 /12/2011 21:47:42< cosman2001> it only takes a puppet bug to make you recreate all the certs
 /12/2011 21:48:10<@ohadlevy> at the end, it boils down to somewhere you store a key
 /12/2011 21:48:35< jpalmer> although..  if we change foreman to only allow the ENC data to be pulled from authenticated clients (ie,  from puppetca) theortetically..  that'd go a long way to protecting sensitive info.  Obviously, it's not a substitute for encrypting sensitive data..  but it would be part of a bigger picture IMO
 /12/2011 21:48:38< cosman2001> i think I have a good idea with the post above, but yea where do I store a password so I don't have to prompt the user
 /12/2011 21:48:47<@ohadlevy> jpalmer: agree
 /12/2011 21:48:55<@ohadlevy> jpalmer: also who can push facts / reports
 /12/2011 21:49:00< ashp> Unable to communicate with the proxy: SSL Verification failed -- Preverify: false, Error: self signed certificate in certificate chain (19)
 /12/2011 21:49:09< ashp> Think I'm going to disable ssl for now, what a headache!
 /12/2011 21:49:22<@ohadlevy> ashp: pikelly would happy to help you as he wrote that ;)
 /12/2011 21:49:24< marcellods> If we have hiera(-pgp) support, could we use it to store the passwords (instead of in the DB)?
 /12/2011 21:49:34< ashp> pikelly: Why! Why is the ssl stuff so complicated and fragile!!
 /12/2011 21:49:36<@ohadlevy> marcellods: or we could simply use gpg ourselfs
 /12/2011 21:49:44< marcellods> true
 /12/2011 21:49:52< jpalmer> I wish the puppetca certs were slightly more useful.  I'd love to have one CA chain to use for bacula,  openvpn, and puppet.
 /12/2011 21:50:19< ken_barber> you want the data in database to be gpg encrypted … and have it decrypted before being used in the catalogue somehow.
 /12/2011 21:50:32< jpalmer> ken_barber++
 /12/2011 21:50:43<@ohadlevy> ken_barber: that would be fairly easy, I think there is a rails gem for that already
 /12/2011 21:50:48< marcellods> ken_barber++
 /12/2011 21:51:06< jpalmer> ohadlevy: you mean,  easy to support that in foreman?  or?
 /12/2011 21:51:06< ken_barber> ie. the enc data or smartvar lookup should be decrypted by that stage.
 /12/2011 21:51:37<@ohadlevy> ken_barber: for example http://rubygems.org/gems/attr_encrypted
 /12/2011 21:52:38<@ohadlevy> ok, so we agree, that stuff needs to be encrypted :)
 /12/2011 21:52:44< gwmngilfen> +1
 /12/2011 21:52:47< marcellods> yup
 /12/2011 21:53:01< cosman2001> does my wiki page make sense?
 /12/2011 21:53:05< ken_barber> ohadlevy: yeah nice. just have to have the key shipped to your foreman boxes with a secure method … as ordinarily it wouldn't have a pass-phrase.
 /12/2011 21:53:34<@ohadlevy> cosman2001: yes
 /12/2011 21:53:44< ken_barber> ohadlevy: agreed
 /12/2011 21:53:50<@ohadlevy> cosman2001: but i think we could probably use something like https://github.com/shuber/attr_encrypted
 /12/2011 21:54:05<@ohadlevy> next topic?
 /12/2011 21:54:16-!- fitzdsl changed the topic of #theforeman to: db versionning
 /12/2011 21:54:22<@ohadlevy> marcellods: ?
 /12/2011 21:54:38< marcellods> well, we've talked about the possibility of using git as a backend
 /12/2011 21:54:41<@ohadlevy> is that can audit not suck that much and be useful? :)
 /12/2011 21:54:58< marcellods> so we could keep versions of: templates for example
 /12/2011 21:55:04<@fitzdsl> ohadlevy: it's very usefull
 /12/2011 21:55:08<@ohadlevy> marcellods: the questions is
 /12/2011 21:55:08<@fitzdsl> but not exhaustive
 /12/2011 21:55:13<@ohadlevy> do you want it in git
 /12/2011 21:55:16<@ohadlevy> or do you want versioning
 /12/2011 21:55:27<@ohadlevy> as its not hard to keep all of the history of it inside a db too
 /12/2011 21:55:29<@fitzdsl> versionning is sufficient I think
 /12/2011 21:55:49<@ohadlevy> fitzdsl: ok, we just need to add the acts_as_versioning or something gem :)
 /12/2011 21:55:53< marcellods> re-implementing versioning feels like reinventing the wheel... but it's better than nothing
 /12/2011 21:55:54< gwmngilfen> git is overkill - expiring rows is sufficient
 /12/2011 21:56:24<@fitzdsl> gwmngilfen: +1
 /12/2011 21:56:24< f0> +1 for git
 /12/2011 21:56:31< ken_barber> cobbler used external vcs didn't it?
 /12/2011 21:56:32< marcellods> I think it's important to register (point in time) parameters, templates etc
 /12/2011 21:56:34<@ohadlevy> marcellods: we already kind of have support for it, thats what the audit does anyway, it keeps track of changes
 /12/2011 21:56:35< jpalmer> oh,  this is the meeting.  doh.  I forgot about it,  and didn't add the 2 topics I wanted.
 /12/2011 21:56:45< gwmngilfen> I guess we want to know what changed between version X and version X+Y - and to roll back to X if needed
 /12/2011 21:56:45< marcellods> ohadlevy: I can't roll it back
 /12/2011 21:57:00<@ohadlevy> marcellods: the ui wont let you
 /12/2011 21:57:00<@fitzdsl> jpalmer: you still can edit wiki
 /12/2011 21:57:02< gwmngilfen> we (kind of, sorry :P) have the first part :)
 /12/2011 21:57:10<@ohadlevy> marcellods: but we could fix it eventually
 /12/2011 21:57:15< marcellods> I would vote for GIT as a first option (but no clue if it's feasible
 /12/2011 21:57:16< marcellods> )
 /12/2011 21:57:20< gwmngilfen> i will write those tests!
 /12/2011 21:57:24< jpalmer> fitzdsl: you sure?  I don't want to cause this to run over if there is a specific time allotment.
 /12/2011 21:57:36<@fitzdsl> jpalmer: no no feel free
 /12/2011 21:57:46< jpalmer> ok, let me pull up that wiki page.  sorry
 /12/2011 21:57:52< gwmngilfen> more audit stuff is definitely possible under my work development time
 /12/2011 21:57:54<@ohadlevy> marcellods: is there an open ticket?
 /12/2011 21:58:05< marcellods> not sure
 /12/2011 21:58:07<@fitzdsl> wiki:Roadmap_meeting
 /12/2011 21:58:08< nudnik> wiki: wiki:Roadmap_meeting is http://theforeman.org/wiki/foreman/Roadmap_meeting "Foreman - Roadmap meeting - Foreman"
 /12/2011 21:58:10< marcellods> let me see
 /12/2011 21:58:19<@ohadlevy> marcellods: ok, so if not, we should create one, and move forward
 /12/2011 21:58:24<@ohadlevy> next topic? :)
 /12/2011 21:58:36< gwmngilfen> happy to discuss that more on the ticket
 /12/2011 21:58:50-!- fitzdsl changed the topic of #theforeman to: Cloud provisioning and unattended access/security related
 /12/2011 21:59:32< marcellods> couldn't find a ticket... we should open one
 /12/2011 21:59:37<@ohadlevy> i think we generally covered this toipc
 /12/2011 21:59:44<@ohadlevy> the main issue here, is that currently
 /12/2011 21:59:54<@ohadlevy> a host asks foreman for a kickstart / preseed etc
 /12/2011 22:00:02<@ohadlevy> which means a connection opens from the client to foreman
 /12/2011 22:00:12< marcellods> yes. Client machines should not need to talk to foreman
 /12/2011 22:00:14<@ohadlevy> in cloud like , dmz etc this is not ideal /possible
 /12/2011 22:00:26<@ohadlevy> and i think this breaks down into two
 /12/2011 22:00:38< jpalmer> fitzdsl: added my 2.  you guys decide if they are appropriate/relative for this meeting.
 /12/2011 22:00:47<@ohadlevy> 1. is cloud services (where you have some one else to talk to) --> power on, give me host details etc
 /12/2011 22:00:53< marcellods> I see this as a BIG MUST regarding security
 /12/2011 22:00:55<@ohadlevy> 2. bare metal
 /12/2011 22:01:00< marcellods> as well
 /12/2011 22:01:03<@fitzdsl> jpalmer: we are looking at all items
 /12/2011 22:01:06<@ohadlevy> for 1. i fully agree
 /12/2011 22:01:38<@ohadlevy> for 2. marcellods suggestion is to make the proxies acts as a real proxy in that respect
 /12/2011 22:01:41< ashp> for me I just want api stuff for clouds
 /12/2011 22:01:42< marcellods> +1 to move unattended to proxy
 /12/2011 22:01:44<@ohadlevy> e.g forward foreman request
 /12/2011 22:01:47< ashp> I don't want any provisioning as such
 /12/2011 22:01:52< ashp> I just want to be able to create cloud instances VIA foreman
 /12/2011 22:02:06< gwmngilfen> +1 on unattended via proxy
 /12/2011 22:02:15< gwmngilfen> but possibly an optional part
 /12/2011 22:02:16<@ohadlevy> so how would the flow look like
 /12/2011 22:02:22<@fitzdsl> marcellods: I agree about unattended moved to proxy
 /12/2011 22:02:24<@ohadlevy> client talks to proxy
 /12/2011 22:02:28<@ohadlevy> proxy just forward the request?
 /12/2011 22:02:34< f0> ohadlevy: +1
 /12/2011 22:02:38< jpalmer> I forgot who brought up this origianlly,  but I personaly think the proxies should handle all communications with client..  allowing us to have foreman on a very secure and protected network.  (especially if it's also out puppetCA machine)
 /12/2011 22:02:40<@ohadlevy> this also solves nat issues
 /12/2011 22:03:12<@ohadlevy> should the proxy validate the client in anyway?
 /12/2011 22:03:15< gwmngilfen> jpalmer: +1
 /12/2011 22:03:16<@ohadlevy> or simple forward it?
 /12/2011 22:03:24< marcellods> ohadlevy: just to make sure: it would not forward ANY request. It should validate it's an unattended request
 /12/2011 22:03:39<@ohadlevy> marcellods: how would it know?
 /12/2011 22:03:43< marcellods> url ?
 /12/2011 22:03:44<@ohadlevy> marcellods: ask foreman for that detail?
 /12/2011 22:03:58< marcellods> I've updated the ticket with my workaround
 /12/2011 22:04:03< gwmngilfen> simple forwarding would allow us to continue to use ?spoof outside the proxy's subnet, correct?
 /12/2011 22:04:08< marcellods> that should be enough on the shot term
 /12/2011 22:04:27< marcellods> gwmngilfen: spoof must be authenticated
 /12/2011 22:04:37< gwmngilfen> agreed - but where?
 /12/2011 22:04:39<@ohadlevy> marcellods: it already is
 /12/2011 22:04:44< marcellods> ohadlevy: I know
 /12/2011 22:04:50< marcellods> Just telling gwmngilfen
 /12/2011 22:05:10<@ohadlevy> would it be enough for foreman to trust the proxies via ssl?
 /12/2011 22:05:24<@fitzdsl> i think so
 /12/2011 22:05:34< marcellods> ohadlevy: why not
 /12/2011 22:05:36< marcellods> ?
 /12/2011 22:05:36< gwmngilfen> if I can't easily access web traffic in some other part of the infrastructure (e.g. I only have SSH, and tunnels are a pain) then I'll want to use spoof on the main foreman instance
 /12/2011 22:05:54< fenrus02> ohadlevy, depends if they exchanged specifics
 /12/2011 22:05:55< gwmngilfen> although I could just wget it, i suppose :P
 /12/2011 22:06:03< fenrus02> ohadlevy, just using ssl is not enough really
 /12/2011 22:06:08<@ohadlevy> gwmngilfen: you would need to provide a user/pass
 /12/2011 22:06:12< jpalmer> I don;t think the proxies completely eliminate the NAT issue, though.  My particular environment would still be NAT'd to the proxies.
 /12/2011 22:06:21<@ohadlevy> fenrus02: well, it should be a valid proxy in foreman proxy list as well?
 /12/2011 22:06:23< cosman2001> brb
 /12/2011 22:06:49< fenrus02> ohadlevy, with ssl, you have to ask a few questions:   Is the cert valid?  Is it signed by a trusted-CA ?
 /12/2011 22:06:52<@ohadlevy> maybe we need to add a uuid to the proxies
 /12/2011 22:06:54<@ohadlevy> sigh
 /12/2011 22:06:57< marcellods> jpalmer: but those are 2 different issues IMHO... The clients should not need to talk to Foreman (with or without NAT)
 /12/2011 22:07:01< fenrus02> ohadlevy, after those two, you can move on to auth or password
 /12/2011 22:07:16<@ohadlevy> fenrus02: sure, we talk about encrypted, and both side validation
 /12/2011 22:07:33< cosman2001> back
 /12/2011 22:07:42< marcellods> ohadlevy: Can't you just use firewalling ? Or am I missing something ?
 /12/2011 22:07:46< jpalmer> marcellods: agreed 100%,  I was just countering the earlier comment that this would eliminate the NAT issues
 /12/2011 22:07:51<@ohadlevy> marcellods: you can i guess
 /12/2011 22:07:57<@ohadlevy> jpalmer: i think it should
 /12/2011 22:08:07<@ohadlevy> jpalmer: assuming your proxy is in the same net
 /12/2011 22:08:12< jpalmer> ohadlevy: it won't.  at least, not in all environments.  I know it won't in mine.
 /12/2011 22:08:16<@ohadlevy> otherwise it wont know who is requesting
 /12/2011 22:08:40<@ohadlevy> jpalmer: if its a bare metal, we have nothing beside ip (and some time mac) to figure out who is requesting
 /12/2011 22:08:41< marcellods> ohadlevy: so isn't ssl enough then ?
 /12/2011 22:08:59<@fitzdsl> ssl + shared secret ?
 /12/2011 22:09:09<@ohadlevy> marcellods: lets work out the details later on?
 /12/2011 22:09:13< marcellods> sure
 /12/2011 22:09:34<@fitzdsl> what is the conclusion about that ?
 /12/2011 22:09:41< marcellods> so ? Do we agree on unattended moved to proxy ?
 /12/2011 22:09:52<@fitzdsl> client should not talk to foreman for unattended ?
 /12/2011 22:09:56< jpalmer> let me give you an example:  I have 4 servers in each datacenter.  I'm under very strict regulatory control as to whih software can be installed on those servers in each datacenter.  So,  a proxy would not be able to be installed there.   the proxies (in my env) would have to be accessible over the internet in some way (directly,  over vpn, etc)    and all servers are NAT'd.
 /12/2011 22:09:57<@ohadlevy> marcellods: i think we'll support both options?
 /12/2011 22:10:15< marcellods> what's the second option ?
 /12/2011 22:10:21< marcellods> current ?
 /12/2011 22:10:24<@ohadlevy> marcellods: yes
 /12/2011 22:10:38< marcellods> when would you need it ?
 /12/2011 22:10:44<@ohadlevy> and i guess we need to add a new role for the proxies
 /12/2011 22:10:52<@ohadlevy> like a provisioning role or something
 /12/2011 22:10:57<@ohadlevy> and then assign it somehow
 /12/2011 22:11:10<@ohadlevy> so we would know where to put the url
 /12/2011 22:11:21< jpalmer> IMO,  client should never talk to foreman directly.  always via proxy.  and as far as sending the "I'm done provisioning" packet..  IMO,  that should be done in a way that uses the authenticated client certificate for identification (which will force installing puppet at kickstart/preseed to be a requirement)
 /12/2011 22:11:30<@ohadlevy> maybe again on the subnet level
 /12/2011 22:11:58< marcellods> jpalmer++
 /12/2011 22:11:59-!- hyde [4016a001@gateway/web/freenode/ip.64.22.160.1] has quit [Ping timeout: 265 seconds]
 /12/2011 22:12:34<@ohadlevy> jpalmer: i think we need to add a uuid to each client we deploy
 /12/2011 22:12:39<@ohadlevy> it would make it easier to track them
 /12/2011 22:12:47< fenrus02> jpalmer, you are asking for an inbound-proxy service for clients to talk to foreman?   (vs the outbound proxy that exists today, for foreman to talk to other services: dhcp, dns, tftp, ..)
 /12/2011 22:12:50<@ohadlevy> as the certs are not managed by foreman, we cant relay on them
 /12/2011 22:12:54< cosman2001> ohadlevy, yea we talked about this and I made a few tickets
 /12/2011 22:13:12<@fitzdsl> ohadlevy: you would get the uuid as a fact ?
 /12/2011 22:13:25<@ohadlevy> fitzdsl: donno yet :)
 /12/2011 22:13:32<@ohadlevy> fitzdsl: no, i think it would be tracked inside foreman db
 /12/2011 22:13:35< fenrus02> fitzdsl, is that in factor ?
 /12/2011 22:13:42< cosman2001> #1243
 /12/2011 22:13:44< nudnik> cosman2001: #1243 is http://theforeman.org/issues/show/1243 "Foreman - Feature #1243: A provision to a node should be treated as an event. - Foreman"
 /12/2011 22:13:48<@ohadlevy> fitzdsl: we could provide that fact as an enc parameter
 /12/2011 22:13:50<@fitzdsl> fenrus02: not that i'm aware of
 /12/2011 22:14:01<@fitzdsl> maybe
 /12/2011 22:14:13< fenrus02> erg.  'facter'
 /12/2011 22:14:21< jpalmer> ohadlevy: the certs aren't managed by foreman,  agreed.  But,  foreman does use the puppet certs for identifying the client in several other ways.  I think the "provisioning complete" url, should be protected by the same certs.  allowing the lient to be identified by certificate.
 /12/2011 22:14:38<@ohadlevy> jpalmer: i agree
 /12/2011 22:14:48<@ohadlevy> jpalmer: the only problem, is that not everyone uses ssl
 /12/2011 22:14:56<@ohadlevy> so all of this stuff needs to be configurable
 /12/2011 22:15:19<@ohadlevy> one of the challenges we're facing is too make it simple enough for new users
 /12/2011 22:15:25< cosman2001> #1069
 /12/2011 22:15:26< nudnik> cosman2001: #1069 is http://theforeman.org/issues/show/1069 "Foreman - Feature #1069: Unattended install behind firewall and built status - Foreman"
 /12/2011 22:15:31<@ohadlevy> and i think we all agree its not simple
 /12/2011 22:15:33<@ohadlevy> enouhg
 /12/2011 22:15:39-!- fitzdsl changed the topic of #theforeman to: Audits to Hostgroups/Classes/Parameters/Provisioning should have be displayed on the Dashboard
 /12/2011 22:15:41< jpalmer> hrm.  I guess thats true.  I can't imagine not using the puppet certs for this stuff..  but I guess it's not our choice to *enforce* that as a prereq
 /12/2011 22:15:49< fenrus02> ohadlevy, every really should be using ssl though.  with a walkthru using bcp, this could be made pretty easy imho
 /12/2011 22:16:08<@ohadlevy> fenrus02: the puppet modules we provide set it up this way
 /12/2011 22:16:21 * fitzdsl has maybe changed topic a bit too early
 /12/2011 22:16:33< jpalmer> I think we need a few walkthroughs for various scenarios anyway (which is one of the reasons I'm trying to put together a foreman cookbook)
 /12/2011 22:16:50< fenrus02> jpalmer, o_O?  url for said cookbook?
 /12/2011 22:17:05< bgupta> maybe add something like an API key.. it's fairly common alternative.
 /12/2011 22:17:26<@ohadlevy> bgupta: for the proxy? yeah, thats possible
 /12/2011 22:17:27< ahuman> ohadlevy: what about #1169
 /12/2011 22:17:29< nudnik> ohadlevy: #1169 is http://theforeman.org/issues/show/1169 "Foreman - Bug #1169: Reports and Fact POST, and GET for Host ENC Yaml, should accept Authentication. - Foreman"
 /12/2011 22:17:43<@ohadlevy> ahuman: yeah, I agree
 /12/2011 22:17:56< jpalmer> fenrus02: all I have right now,  are a couple of google docs notes,  which I'll be turning into a cookbook.  nothing overly impressive atm.  but the *goal* is to have some common install scenarios documented in such a way,  that a newcomer could have an environment up in the lab in 10-15 mins,  and have a general idea of whats going on.
 /12/2011 22:17:56<@ohadlevy> ahuman: the list of puppet masters allowed to connect should be restricted
 /12/2011 22:18:21<@ohadlevy> jpalmer++
 /12/2011 22:18:43 * ohadlevy wished nudnik would print the karma count
 /12/2011 22:18:45< gwmngilfen> jpalmer: nice
 /12/2011 22:18:46< fenrus02> jpalmer, that would be outstandingly awesome
 /12/2011 22:18:56< jpalmer> fenrus02: part of whats slowing me down,  is that I'm newish to foreman myself..  so learning..  and a serious lack of time in general.   but,  I'm getting it together slowly.
 /12/2011 22:19:20<@fitzdsl> I think we should go to the next point
 /12/2011 22:19:32<@fitzdsl> time is going fast in here :)
 /12/2011 22:19:34<@ohadlevy> fitzdsl: ok
 /12/2011 22:19:42<@ohadlevy> next topic then?
 /12/2011 22:19:47<@fitzdsl> topic already changed
 /12/2011 22:19:48<@ohadlevy> gwmngilfen: is that yours?
 /12/2011 22:20:06< gwmngilfen> i didn't add any topics, although I views on a few :)
 /12/2011 22:20:10< ahuman> ohadlevy: thats mine
 /12/2011 22:20:15< gwmngilfen> *I have
 /12/2011 22:20:33<@fitzdsl> +1 for the functionality
 /12/2011 22:20:36<@ohadlevy> ahuman: ok, is there a feature request?
 /12/2011 22:20:40< ahuman> i'm not 100% sure what I want though .. just get some data on the dashboard for Audits ..
 /12/2011 22:20:42<@fitzdsl> yep
 /12/2011 22:20:44< jpalmer> maybe I'll convince ohadlevy to point cookbook.theforeman.org to a drupal installation,  where I can start translating some goole docs into "recipes"  :P
 /12/2011 22:21:03<@ohadlevy> jpalmer: if you set it up, no problems :)
 /12/2011 22:21:09< gwmngilfen> ahuman: in what style? just a simple "X changes in Y hours"?
 /12/2011 22:21:17< ahuman> maybe some way to tie recent audit chages to puppet reports/changes :)
 /12/2011 22:21:19 * ohadlevy is trying to reduce the overall operational efforts :)
 /12/2011 22:21:33< gwmngilfen> hmm
 /12/2011 22:21:37< jpalmer> ohadlevy: we can talk after.  I'd be ok with that.  I just assumed you'd want it to be under your administrative control.   but we can talk later.
 /12/2011 22:21:58< gwmngilfen> not sure we can tie it to reports easily
 /12/2011 22:21:59<@ohadlevy> ahuman: a really cool feature would be show me the audit that caused this report :)
 /12/2011 22:22:13<@ohadlevy> but i have no idea how to implement it :)
 /12/2011 22:22:15< gwmngilfen> most reports are changes in the puppet codebase :)
 /12/2011 22:22:16< ahuman> ohadlevy: , yea somethng like that
 /12/2011 22:22:26< gwmngilfen> (at least, fo me)
 /12/2011 22:22:43<@fitzdsl> at least track every modification on foreman db
 /12/2011 22:22:47<@ohadlevy> ahuman: ok, i suggest we start with a feature request, we could probably show up some useful data
 /12/2011 22:22:49<@fitzdsl> like hostgroup
 /12/2011 22:22:58<@ohadlevy> fitzdsl: i think we do already
 /12/2011 22:23:04< gwmngilfen> fitzdsl: more auditing is on my todo
 /12/2011 22:23:24<@ohadlevy> ahuman: anything else to add then?
 /12/2011 22:23:34< ahuman> ohadlevy: ill make a feature req .. put more details there
 /12/2011 22:23:37< gwmngilfen> but yeah, lets get a feaure req up and we can discuss it - ahuman, I like it, but I have no idea how hard it would be :)
 /12/2011 22:23:39< jpalmer> as for auditing..  I think it'd be awesome if we can find a way to tie report logs to old versions of files sored in the filebucket.  ie,  file changed.  old version is abcdefg,  new version is gfedcba.   you click on old version,  and see the actual file as it existed before the change.
 /12/2011 22:23:47<@fitzdsl> ohadlevy: in 0.4 I don't know in 0.3 it was not
 /12/2011 22:24:17<@fitzdsl> jpalmer: that would need to stoe the whole puppet manifest in a VCS
 /12/2011 22:24:29<@ohadlevy> next topic :)
 /12/2011 22:24:46< ahuman> jpalmer: +1 .. you're saying what i'm thingking
 /12/2011 22:24:50< jpalmer> fitzdsl: which is probably unrealistic (which is why I never filed an actual feature request for it)
 /12/2011 22:25:07-!- fitzdsl changed the topic of #theforeman to: host roles that were originally possible with puppet before adding the ENC
 /12/2011 22:25:12< jpalmer> ahuman: I think it'd be awesome.  I just don't know of a way we could actually do it ;)
 /12/2011 22:25:31< gwmngilfen> ah, multiple host groups. Yes please :)
 /12/2011 22:25:36<@fitzdsl> I think that most of us already store puppet manifest in a VCS
 /12/2011 22:25:57< cosman2001> I want to create a server role instead of a hostgroup or maybe just a way to assign multiple hostgroups to a single host or hostgroup without nesting
 /12/2011 22:26:07< gwmngilfen> cosman2001: +1
 /12/2011 22:26:34< gwmngilfen> i have 4 types of one machine, and 5 regions. at the moment, that would result in 20 nested hostgroups
 /12/2011 22:26:38<@ohadlevy> the problem here is who decide which params are set
 /12/2011 22:26:49<@ohadlevy> assuming both groups define param name
 /12/2011 22:26:51<@ohadlevy> who wins?
 /12/2011 22:26:57< gwmngilfen> user-defined precedence
 /12/2011 22:27:06<@ohadlevy> gwmngilfen: why? it should be only 4 hostgroups
 /12/2011 22:27:08< fenrus02> adding multiple roles to a single host/group would be nicer.
 /12/2011 22:27:15< lavaman> or order of assignment of host group
 /12/2011 22:27:18< lavaman> last one wins
 /12/2011 22:27:55<@ohadlevy> gwmngilfen: atleast that was my design goal
 /12/2011 22:28:03< gwmngilfen> ohadlevy: Coreserver/Version19/EMEA - Coreserver/Version20/EMEA etc, repeat for each region
 /12/2011 22:28:26<@ohadlevy> gwmngilfen: why does version19 is part of the hostgroup? isnt it a var name or something like that?
 /12/2011 22:28:26< cosman2001> my groups are based on location and functionality so I can't always inherit
 /12/2011 22:28:37<@ohadlevy> gwmngilfen: or maybe version19 should be the environment?
 /12/2011 22:28:47< marcellods> revisit #35
 /12/2011 22:28:49< nudnik> marcellods: #35 is http://theforeman.org/issues/show/35 "Foreman - Feature #35: Allow hostgroup nesting for puppet classes and parameters - Foreman"
 /12/2011 22:28:50< gwmngilfen> the software revision is significant enough to need different classes - in some cases the OS even changes
 /12/2011 22:28:58<@ohadlevy> cosman2001: they should be based on functionality only ideally
 /12/2011 22:29:21< marcellods> btw it was renamed
 /12/2011 22:29:32<@ohadlevy> gwmngilfen: so how would assigning multiple ones help here then?
 /12/2011 22:30:06< gwmngilfen> I would a host "foo.org" which is in groups "Build19" and "EMEA". no relationship between the two,
 /12/2011 22:30:09< cosman2001> "web server role" + Pacific region role + DB role
 /12/2011 22:30:21< gwmngilfen> cosman2001: thanks, a clearer example
 /12/2011 22:30:33<@fitzdsl> +1 for the feature
 /12/2011 22:30:37<@ohadlevy> cosman2001: whats inside the location role?
 /12/2011 22:30:46< f0> +1
 /12/2011 22:30:56<@ohadlevy> and i would argue that web server role + db role is a new role
 /12/2011 22:31:02<@fitzdsl> ohadlevy: ntp server ? or somthing like that
 /12/2011 22:31:03< fenrus02> ohadlevy, here, it would be things like ntp servers, and repos
 /12/2011 22:31:09< cosman2001> timezone module, specific repos
 /12/2011 22:31:18<@ohadlevy> well, thats something you should solve with params/smart vars
 /12/2011 22:31:30< gwmngilfen> hmm, ohad, so you have a webserver+db role, in each region... now you again have to maintain multiple nests...
 /12/2011 22:31:45-!- cliff-hm [cperry@nat/redhat/x-vskbichwtgoswqrb] has quit [Read error: Operation timed out]
 /12/2011 22:31:50-!- Irssi: #theforeman: Total of 67 nicks [2 ops, 0 halfops, 0 voices, 65 normal]
 /12/2011 22:31:52<@ohadlevy> gwmngilfen: i dont think the region should effect the hostgroup/role
 /12/2011 22:32:17<@ohadlevy> usually a different location simply imply different values for the same behavior
 /12/2011 22:32:34< gwmngilfen> even it only sets parameters (like ntp server), you have to edit multiple groups when you want to change Pacific/Web+DB, or Eastern/Web+DB
 /12/2011 22:32:47<@ohadlevy> gwmngilfen: why?
 /12/2011 22:32:52<@ohadlevy> isnt it simply a smart var
 /12/2011 22:33:02<@ohadlevy> ntp server
 /12/2011 22:33:03<@ohadlevy> default
 /12/2011 22:33:06<@ohadlevy> ntp.pool
 /12/2011 22:33:14<@fitzdsl> this was just an example
 /12/2011 22:33:21< fenrus02> tbf, i dont have a "webserver role" at all.  i have webapp1, webapp2, etc..  (drupal, wordpress, instead of "webserver")
 /12/2011 22:33:26<@ohadlevy> matcher fact = Pacific ==> value = 123
 /12/2011 22:33:36<@ohadlevy> fenrus02: agreed
 /12/2011 22:34:03<@ohadlevy> the only thing that is missing here, is the complex data structures
 /12/2011 22:34:09< cosman2001> ohadlevy, if your saying some of this can be done with smartvars, can you create some docs to show how.  I currently does use smartvars
 /12/2011 22:34:10< fenrus02> same with db -> pgsql / mysql / o10g / ..
 /12/2011 22:34:13< gwmngilfen> ok, new tactic :P - you say web+db should be a new group - if I have 10 roles, do I have to maintain a hostgroup for every possible combination?
 /12/2011 22:34:45<@ohadlevy> gwmngilfen: a combination of what?
 /12/2011 22:34:55<@fitzdsl> possible role used a hostgroup
 /12/2011 22:34:59< fenrus02> one server might have multiple roles though still:  drupal + mysql for example
 /12/2011 22:35:02<@ohadlevy> cosman2001: did you see the inline help and the wonderful wiki page that gwmngilfen wrote? :)
 /12/2011 22:35:15< cosman2001> no
 /12/2011 22:35:19< gwmngilfen> so I have, Web, DB, rsync, etc. do i need to create web+db, web+rsync, web+db, web+rsync+db.... ?
 /12/2011 22:35:24<@ohadlevy> cosman2001: edit a puppet class
 /12/2011 22:35:31< gwmngilfen> it's going to get messy fast
 /12/2011 22:35:43<@ohadlevy> gwmngilfen: if it something that happens only once, then you can add classes per host
 /12/2011 22:35:55<@ohadlevy> gwmngilfen: if its something that is common and happens a lot, it sounds like a hostgroup is a good idea?
 /12/2011 22:35:58< fenrus02> each role should be something specific without extra cruft ime
 /12/2011 22:36:29< gwmngilfen> if machine A has 10 classes and a few params, then moving all of that to B for a short duration could lead to human error. adding B to a second group removes that risk
 /12/2011 22:36:52<@ohadlevy> gwmngilfen: ok
 /12/2011 22:37:07<@ohadlevy> gwmngilfen: the only issue i have is who wins
 /12/2011 22:37:16<@ohadlevy> if a os attribute is defined in both groups
 /12/2011 22:37:21<@ohadlevy> which os would it be?
 /12/2011 22:37:31< gwmngilfen> let me see if i can knock up some proof of concept stuff to convince you. i have some ideas
 /12/2011 22:37:37< gwmngilfen> lts move this to the ticket
 /12/2011 22:37:39<@fitzdsl> the first/last group on the stack
 /12/2011 22:37:42<@ohadlevy> gwmngilfen: ok, let take it to a ticket / mailing list
 /12/2011 22:38:05<@ohadlevy> ok, do you guys mind if we just to the org topics
 /12/2011 22:38:11< marcellods> gwmngilfen: this goes all the way back to # 35 :) better be a good example :)
 /12/2011 22:38:25< traylenator> It could fail if a parameter clash is present.
 /12/2011 22:38:42< gwmngilfen> marcellods: examples we have, what ohadlevy seems to want is a solution :)
 /12/2011 22:38:50-!- fitzdsl changed the topic of #theforeman to: Support NonSql Databases
 /12/2011 22:39:00< gwmngilfen> i have a couple of ideas, i will detail them in a ticket/ml-post
 /12/2011 22:39:09<@ohadlevy> fitzdsl: mind if we just to the org topics, and come back to the rest later?
 /12/2011 22:39:32<@fitzdsl> ohadlevy: no pb
 /12/2011 22:39:44< gwmngilfen> i'm going to have to duck out shortly I think
 /12/2011 22:39:45-!- fitzdsl changed the topic of #theforeman to: Audits to Hostgroups/Classes/Parameters/Provisioning should have be displayed on the Dashboard
 /12/2011 22:39:53<@fitzdsl> sorry
 /12/2011 22:39:54< gwmngilfen> nearly 10pm and I've not made dinner yet :)
 /12/2011 22:40:00-!- fitzdsl changed the topic of #theforeman to: Git and Release maintenance
 /12/2011 22:40:02<@ohadlevy> gwmngilfen: yeah, same here
 /12/2011 22:40:07< jpalmer> gwmngilfen: dinner is for chumps.
 /12/2011 22:40:08<@fitzdsl> same hear to
 /12/2011 22:40:17<@fitzdsl> s/hear/here
 /12/2011 22:40:21< gwmngilfen> my wife doesn't like that answer jpalmer:P
 /12/2011 22:40:31<@fitzdsl> :)
 /12/2011 22:40:36<@fitzdsl> so ohadlevy ?
 /12/2011 22:40:37<@ohadlevy> ok, are you guys happy with the current flow of patches, releases and overall repo admin?
 /12/2011 22:40:43< gwmngilfen> yes
 /12/2011 22:40:51<@fitzdsl> yep for me
 /12/2011 22:40:55< cosman2001> +1
 /12/2011 22:41:02<@ohadlevy> sadly it takes lots of time on my behalf, and I'm looking for ways to optimize
 /12/2011 22:41:21<@fitzdsl> the only thing i wanted is more visibility on the roadmap :)
 /12/2011 22:41:29< gwmngilfen> where is your time taken up ohadlevy?
 /12/2011 22:41:31< jpalmer> ohadlevy: I know ashp had some issues the other day with older versions of augeas being available for EL6.
 /12/2011 22:41:35< cosman2001> does it take more time to have a feature branch maint branch
 /12/2011 22:41:53< cosman2001> sorry feature and maint branch
 /12/2011 22:42:16< marcellods> jpalmer: that's a known augeas issue ... I've updated the ticket with a workaround. It will be solved in RH 6.2
 /12/2011 22:42:19< jpalmer> ohadlevy:  actually, nevermind.  this is probably more of a puppet labs specific thing,  than a foreman issue.   so I'll bring it up with them
 /12/2011 22:42:28<@ohadlevy> gwmngilfen: well, patches, code review, testing, git push merge resolve conflicts etc
 /12/2011 22:42:49<@ohadlevy> gwmngilfen: sadly, I'm not writing much code recently
 /12/2011 22:42:49< gwmngilfen> so no one specific area, just general workload?
 /12/2011 22:43:22<@ohadlevy> gwmngilfen: the thing is, that since I'm the only git committer
 /12/2011 22:43:26<@ohadlevy> i need to review everything
 /12/2011 22:43:52<@fitzdsl> even for pikelly ?
 /12/2011 22:43:53< jpalmer> ohadlevy: can you put together a wiki page on..  yakshaving?  IE,  the stuff you do, that doesn't directly translate into code..   that maybe you can bring on some volunteers to help with?  ie,  infra stuff and things of that nature?
 /12/2011 22:44:07<@ohadlevy> fitzdsl: esp for pikelly ;)
 /12/2011 22:44:36<@fitzdsl> he has not been much arround here lately
 /12/2011 22:45:00<@ohadlevy> so i guess this breaks into 2
 /12/2011 22:45:02<@ohadlevy> developer related
 /12/2011 22:45:02<@fitzdsl> jpalmer: +1 I can't help much with code but I can do other things (cofee, etc ...)
 /12/2011 22:45:03< gwmngilfen> jpalmer: +1
 /12/2011 22:45:07< jpalmer> ohadlevy: I'm thinking of a "keep the developers developing" kinda page.  wher eyou outsource essentially any non-development tasks to others who are interested in contributing..  but don't know ruby ;)  (ie, me.)
 /12/2011 22:45:11<@ohadlevy> and the rest :)
 /12/2011 22:45:26<@fitzdsl> +1
 /12/2011 22:45:33<@ohadlevy> under developer stuff falls, code review / feedback, testing that it actually works etc
 /12/2011 22:45:37<@ohadlevy> the rest is
 /12/2011 22:45:43<@ohadlevy> git maint
 /12/2011 22:45:54<@ohadlevy> wiki updates (or lack of)
 /12/2011 22:45:59<@ohadlevy> packaging
 /12/2011 22:46:00<@ohadlevy> installer
 /12/2011 22:46:07< jpalmer> See,  I can help with testing patches as time permits.  but the code review..  not so much.
 /12/2011 22:46:08<@ohadlevy> bug hunting
 /12/2011 22:46:20<@fitzdsl> bug triage
 /12/2011 22:46:27<@fitzdsl> testing
 /12/2011 22:46:28<@ohadlevy> yes, thanks fitzdsl
 /12/2011 22:47:02< gwmngilfen> happy to try and spend time on bug triage
 /12/2011 22:47:05<@ohadlevy> so my feeling is that I'm getting to a point, where there are many contributions (this rocks!!)
 /12/2011 22:47:05< fenrus02> speaking of packaging … ohadlevy did you take a look at the newer .spec file for foreman that breaks out cli?
 /12/2011 22:47:33<@ohadlevy> fenrus02: i saw it, but i guess i forgot to say ++ :)
 /12/2011 22:48:06< fenrus02> ohadlevy, no worries, i have been largely afk and just wanted to confirm that you saw how
 /12/2011 22:48:06<@ohadlevy> so ideally,
 /12/2011 22:48:17<@ohadlevy> I would like to give away as many responsibilities as possible
 /12/2011 22:48:23<@ohadlevy> like packaging
 /12/2011 22:48:24<@ohadlevy> :)
 /12/2011 22:48:36< gwmngilfen> do we have a debian packager?
 /12/2011 22:48:41<@fitzdsl> what is missing about packaging ?
 /12/2011 22:48:51<@ohadlevy> gwmngilfen: joschi
 /12/2011 22:49:06< gwmngilfen> then I can;t really volunteer for that :)
 /12/2011 22:49:10< jpalmer> ohadlevy: I guess I'd suggest spending some time to see what you can "outsource" and get off your plate,  so that you can focus on the things that you really..  can't.   then solidify those ideas into something the community can consume and act on.  Once we have something like that..  we can start volunteering to handle certain aspects for you,  assuming you are comfortable with that persons contributions/capabilities.
 /12/2011 22:49:16<@ohadlevy> gwmngilfen: but he is not so active these days, maybe he would like to give some of it pu
 /12/2011 22:49:18< gwmngilfen> although I might package it for Archlinux :P
 /12/2011 22:49:30< joschi> gwmngilfen: feel free to review ;)
 /12/2011 22:49:38< gwmngilfen> joschi: sure :)
 /12/2011 22:49:48<@ohadlevy> the new upcoming 0.5 would require some effort
 /12/2011 22:49:53<@ohadlevy> because we no longer use git submodules
 /12/2011 22:49:53< joschi> although the nightly builds are broken atm
 /12/2011 22:49:55< joschi> yep
 /12/2011 22:50:02< joschi> exactly that's why ;)
 /12/2011 22:50:02<@ohadlevy> and we changed to using bundler
 /12/2011 22:50:06<@ohadlevy> yep :)
 /12/2011 22:50:23<@ohadlevy> jpalmer: i agree
 /12/2011 22:50:27<@ohadlevy> jpalmer: thanks
 /12/2011 22:50:29< fenrus02> ohadlevy, erg.  means we need to package up any/all 3rd party gems as discrete packages
 /12/2011 22:50:29< gwmngilfen> joschi: i'll grab you off-meeting to talk about how i can help
 /12/2011 22:50:44<@ohadlevy> fenrus02: or push them in vendor using bundle cache or something
 /12/2011 22:51:02<@fitzdsl> is this envisagable to have foreman included in sid ?
 /12/2011 22:51:05<@ohadlevy> which might conflict with passenger etc
 /12/2011 22:51:13< mfridh> is it ok license-wise to just toss them in the foreman package?
 /12/2011 22:51:19<@ohadlevy> it is
 /12/2011 22:51:20<@fitzdsl> or Fedora 17 ?
 /12/2011 22:51:23<@fitzdsl> it is ??
 /12/2011 22:51:23<@ohadlevy> the issue is all of the libs
 /12/2011 22:51:37<@ohadlevy> each one needs to be packaged separately
 /12/2011 22:51:43< mfridh> I'd hate foreman to turn out like Spacewalk with 5 million dependencies
 /12/2011 22:51:58<@ohadlevy> mfridh: we are working very hard to minimize deps
 /12/2011 22:52:07< fenrus02> ohadlevy, passenger and PE are no-go's with rhel / fedora
 /12/2011 22:52:07<@ohadlevy> mfridh: and disable features based on avail libs
 /12/2011 22:52:10< mfridh> I know you do :), just trolling
 /12/2011 22:52:19 * jpalmer thinks we don't need to discuss specifics right now.  ohadlevy can draft up a doc of what help he needs, that can be outsourced..  then we can discuss the specifics of each of those.. tasks individually.  I think right now though,  we're veering from the scheduled meeting
 /12/2011 22:52:32<@ohadlevy> ok
 /12/2011 22:52:32< gwmngilfen> jpalmer: +1
 /12/2011 22:52:36<@ohadlevy> next topic, installer
 /12/2011 22:52:44<@ohadlevy> aka puppet modules
 /12/2011 22:52:45-!- fitzdsl changed the topic of #theforeman to: installer
 /12/2011 22:52:51< mfridh> I've been thinking about that.
 /12/2011 22:52:55<@ohadlevy> anyone actually using that?
 /12/2011 22:53:04< marcellods>  Changed namespace to "foreman::" to allow it to live peacefully with other existing modules
 /12/2011 22:53:04< mfridh> Previously I had my mind set at metarpm with everything needed to tie stuff together.
 /12/2011 22:53:06< gwmngilfen> well, i'm testing it, does that count? :)
 /12/2011 22:53:08< mfridh> But now I'm not sure anymore.
 /12/2011 22:53:15< cosman2001> I use it, works good
 /12/2011 22:53:20< marcellods> I want to have both options: upstream foreman dependencies + my own modules (eg. apache,tftp etc)
 /12/2011 22:53:22< jpalmer> I use the foreman-puppet modules currently,  and have a cookbook "recipe" centered around that.
 /12/2011 22:53:35< ashp> I use a modified bunch of foreman-puppet modules myself
 /12/2011 22:53:52 * gwmngilfen is now randomly afk for short periods while cooking
 /12/2011 22:53:56< ashp> mostly for local environment differences, extra stuff, puppet module checkouts for foreman, adding the mysql gem, bunch of crap
 /12/2011 22:54:10< ashp> removing stuff that clashes with existing things (augeas for /etc/sudoers)
 /12/2011 22:54:15<@ohadlevy> so the main 2 issues i see is
 /12/2011 22:54:38< jpalmer> I would like to see the foreman-puppet modules expanded a bit.  for instance,  I'd like an option to automatically have passenger used for the puppetmaster, and things like that.
 /12/2011 22:54:46<@ohadlevy> 1. might still not be that easy for new users, maybe reuse what we do in katello (a simple wrapper around the puppet scripts with simple answer file)
 /12/2011 22:54:57< ashp> ohadlevy: yes, the katello installer was REALLY nice
 /12/2011 22:54:59<@ohadlevy> 2. almost no one uses the upstream modules in production
 /12/2011 22:55:08<@ohadlevy> jpalmer: thats already done
 /12/2011 22:55:09< ashp> ohadlevy: I think 2 isn't fully true
 /12/2011 22:55:15< ashp> for example when I rebased on your latest modules
 /12/2011 22:55:19< jpalmer> ohadlevy: ahh,  didn't see that.  nice.
 /12/2011 22:55:19< ashp> I used a LOT more in production
 /12/2011 22:55:26< ashp> mine were hacked to bits last time
 /12/2011 22:55:37< ashp> this time I'm using your apache and passenger stuff almost untouched except for some additional classes
 /12/2011 22:55:48< ashp> So they are definitely much more generic and easy to use now
 /12/2011 22:55:59< ashp> I would be sad if they vanished
 /12/2011 22:56:01<@ohadlevy> ashp: as long as they dont conflict with your existing apache classes?
 /12/2011 22:56:06< marcellods> ohadlevy: That's why I suggest to isolate them in their own namespace and make it optional
 /12/2011 22:56:16< ashp> your module is my apache stuff, I deleted the rest
 /12/2011 22:56:29<@fitzdsl> marcellods: +1
 /12/2011 22:56:34< ashp> I would however support them being in their own namespace I think, I had to rework things to get it this way
 /12/2011 22:56:35< jpalmer> the only thing I have to touch, other than the normal settings and paramaters..  is I have to comment out the include tftp part due to that bug in 2.7.x of puppet.  Not sure how to fix,  but since I don't use tftp in my env,  I can safely just comment it out.
 /12/2011 22:56:57< ashp> yeah I had to do a bunch of changes for 2.7, your stuff is really fucked up with the latest 2.7 (but not your fault)
 /12/2011 22:57:06<@ohadlevy> marcellods: and if someone wants to reuse it?
 /12/2011 22:57:17< jpalmer> +1 for the namespace change, though.
 /12/2011 22:57:20<@ohadlevy> i mean, want to use those modules for other stuff?
 /12/2011 22:57:37< ashp> I do that now
 /12/2011 22:57:42<@fitzdsl> ohadlevy: they can use sed :)
 /12/2011 22:57:44< ashp> i use your passenger module for puppet
 /12/2011 22:57:49 * ohadlevy feels that an environment fits better than a namespace changre
 /12/2011 22:57:54<@ohadlevy> but I might be wrong about that
 /12/2011 22:58:02< jpalmer> they can either use sed,  or..   just accept the new namespace change.  ;)
 /12/2011 22:58:05< marcellods> ohadlevy: they can always include the deep named class right ?
 /12/2011 22:58:15<@ohadlevy> marcellods: i guess
 /12/2011 22:58:15< marcellods> jpalmer: exactly
 /12/2011 22:58:23< ashp> ohadlevy: suggestion
 /12/2011 22:58:33< ashp> a space somewhere filled with
 /12/2011 22:58:41< ashp> class apache { include foreman::apache::etc }
 /12/2011 22:58:44< gwmngilfen> +1 for namespace, i can do a patch for that
 /12/2011 22:58:47< ashp> they can drop those aliases in if they really need them
 /12/2011 22:58:55< mfridh> foreman::apache exactly, was about to say
 /12/2011 22:58:57< ashp> I would use that probably
 /12/2011 22:58:58<@ohadlevy> ashp: interesting
 /12/2011 22:58:59< marcellods> ohadlevy: It's not puppet-foreman's responsibility to release an apache module...
 /12/2011 22:59:05< ashp> bunch of aliases back to the old class names
 /12/2011 22:59:07< jpalmer> I think I like the namespace change, better than an environment change.
 /12/2011 22:59:15< marcellods> ohadlevy: but to provide the minimum dependencies to install foreman
 /12/2011 22:59:18< ashp> marcellods: no, but it's nice for newbies to say "grab these modules and use them"
 /12/2011 22:59:27< ashp> I've benefited from the extra work ohadlevy has put in to the stuff around the edge
 /12/2011 22:59:35< jpalmer> ashp indeed.
 /12/2011 22:59:38< ashp> It's a huge amount of work to build a foreman/puppet environment properly
 /12/2011 22:59:39< marcellods> ashp: sure... I'm not suggesting to remove them
 /12/2011 22:59:46< ashp> I just did the work to split foreman/proxy/puppet apart and it took ages
 /12/2011 22:59:47< marcellods> ashp: just change the namespace
 /12/2011 22:59:48<@ohadlevy> marcellods: until we get to the complex stuff, like libvirt module needs to manage network devices etc
 /12/2011 22:59:56< ashp> gotta dash for the train
 /12/2011 23:00:05<@fitzdsl> we should go on
 /12/2011 23:00:14< mfridh> for newbies I think even doing that initial puppet --some-flags-to-get-it-going is hard too, hell I can't even remember the syntax
 /12/2011 23:00:21< marcellods> ashp: maybe you misunderstood my point
 /12/2011 23:00:25 * fitzdsl will soon have to sleep
 /12/2011 23:00:35< jpalmer> I would also like to see an example puppet module included with foreman,  that actually shows a smartvar use,  and a couple other things.   to this moment, I still don't understand smartvars.  I think a module with a practical use demonstrating it.. would be easier for some people to "get"
 /12/2011 23:00:47< mfridh> I still want a simple yum install foreman-server meta rpm.
 /12/2011 23:01:07< mfridh> It could put stuff in place, or you could even have a simple configuration file as a prereq you need to put in place.
 /12/2011 23:01:18< mfridh> where the incoming packages could get their "answers" from.
 /12/2011 23:01:19<@ohadlevy> mfridh: thats exactly what we have in katello
 /12/2011 23:01:19< marcellods> so, namespace change or not ? (I'll probably keep the fork anyway as it's not usable for me right now)
 /12/2011 23:01:21< mfridh> aka, katello
 /12/2011 23:01:27< jpalmer> mfridh: that'd probably not easy though.  because some people will want webrick,  some want passenger+apache,  some want nginx..  etc
 /12/2011 23:01:28< mfridh> ohadlevy: i've never tried katello
 /12/2011 23:01:41<@ohadlevy> mfridh: i wrote the puppet modules, then someone smarter then me wrote the installer ;)
 /12/2011 23:01:42<@fitzdsl> I agree with the fact that the simples way to have foreman installed is still package{'foreman': ensure => installed; }
 /12/2011 23:01:44< mfridh> jpalmer: indeed, foreman-server-passenger, foreman-server-whatever
 /12/2011 23:02:15< jpalmer> +1 for having never tried katello.  I have my hands full in learning puppet and foreman.  I haven't even started down the augeas/mcollective/pulp/katello/etc path.
 /12/2011 23:02:30< mfridh> I don't want to try it either.
 /12/2011 23:02:30<@ohadlevy> ok, so it seems everyone here is favor of namespace
 /12/2011 23:02:43<@ohadlevy> another issue is the params stuff
 /12/2011 23:02:52<@ohadlevy> since everyone might be changing it
 /12/2011 23:03:15<@ohadlevy> maybe add a puppet function which tries to look for the same var top scope or something, and then fallback to the module default
 /12/2011 23:03:20< fenrus02> jpalmer, +aeolus :)
 /12/2011 23:03:38< marcellods> ohadlevy: btw, I intentionally left the manifests in their original structure , so it should be pretty easy if someone want's to use it as an isolated module
 /12/2011 23:03:54<@ohadlevy> marcellods: ok, then, send a patch :)
 /12/2011 23:04:05< marcellods> ohadlevy: pull request is also ok ?
 /12/2011 23:04:10<@ohadlevy> sure
 /12/2011 23:04:11<@ohadlevy> doesnt matter
 /12/2011 23:04:18< marcellods> ohadlevy: About params
 /12/2011 23:04:20< jpalmer> fenrus02: never even heard of it.  but really..  I've got so little time to learn right now..  that puppet+foreman is more than I can currently handle.
 /12/2011 23:04:27<@ohadlevy> but normally for docs reasons, we also want a issue so people can find out the details
 /12/2011 23:04:46< marcellods> ohadlevy: I would suggest supporting something puppet native for the bootstrap (like extlookup)
 /12/2011 23:04:52< marcellods> with default values
 /12/2011 23:05:06< jpalmer> fenrus02: I'm currently one of a VERY small team that manages a total of about 4,000 servers,  with no centralized management at all.  (my puppet+foreman is still 100% lab)   so..  time is very tight  ;)
 /12/2011 23:05:07< marcellods> I've also have some example in the changed code
 /12/2011 23:05:09<@ohadlevy> marcellods: its easy to use a function, if you use the modulepath and pluginsync or --libdir or something
 /12/2011 23:05:13<@ohadlevy> ok
 /12/2011 23:05:18<@ohadlevy> I think we can skip
 /12/2011 23:05:21<@ohadlevy> or call it a day
 /12/2011 23:05:28<@ohadlevy> as it seems we are losing a lot of people :)
 /12/2011 23:05:37< gwmngilfen> heh, still here, just about
 /12/2011 23:06:10<@ohadlevy> any one wants to bring up any other topic?
 /12/2011 23:06:39< cosman2001> are we taking the rest of the topics offline?
 /12/2011 23:06:44< fenrus02> jpalmer, eek!  puppet is not overly complicated to do up front, but adding foreman in after seems a bit of a trick
 /12/2011 23:06:44<@ohadlevy> fitzdsl: btw: about packaing, also rpm needs the same :)
 /12/2011 23:07:06<@ohadlevy> cosman2001: well, if you want to speak up, now sounds like a good time
 /12/2011 23:07:19< mfridh> once foreman is in place I think puppet is even easier.
 /12/2011 23:07:20< cosman2001> how about the scheduling feature?
 /12/2011 23:07:22< jpalmer> fenrus02: yeah,  I learned that.  I completely scratched my whole puppet lab env,  when I discovered foreman.  luckily,  it *was* still just a lba env.
 /12/2011 23:07:23< fenrus02> ohadlevy, fitzdsl i can help with rpm packaging, but missed whatever it was that is needed above
 /12/2011 23:07:55<@ohadlevy> cosman2001: which means?
 /12/2011 23:08:15< jpalmer> fenrus02: I think it was "meta packages" to install foreman in it's entirety.   ie "foreman-apache-passenger.rpm"
 /12/2011 23:08:42<@ohadlevy> fenrus02: and bundler, and f15/16, maybe a rpm per db type too
 /12/2011 23:08:45< fenrus02> jpalmer, oh.  passenger is a no-go for rhel / fedora.  been tried a few times apparently
 /12/2011 23:08:46< cosman2001> so the point of the scheduler would be to schedule a class to be applied to a host/hostgroup at a specific time (outage windows)
 /12/2011 23:09:15< jpalmer> ohadlevy: I'd really like to discuss the 'bulk upload of paramaters' before we call it a day.
 /12/2011 23:09:16< fenrus02> ohadlevy, foreman*rpm should pull in whatever deps it needs.  those deps should be in the same repo as foreman
 /12/2011 23:09:24<@fitzdsl> sorry to hurry you but could we go forward ?
 /12/2011 23:09:53< gwmngilfen> cosman2001: couldn't you code that *in* the class?
 /12/2011 23:09:58< gwmngilfen> as a schedule resource?
 /12/2011 23:09:58<@ohadlevy> fitzdsl: yeah i agree, I'm also short in time
 /12/2011 23:10:05< gwmngilfen> but anyway :)
 /12/2011 23:10:07< marcellods> what is the state of Windows support ? Do we have demand for that ?
 /12/2011 23:10:11< cosman2001> no because the puppet schedule only works at a resource level
 /12/2011 23:10:17 * fitzdsl think about the fact that ohad thought the meeting could last for less thant one hour and a half :)
 /12/2011 23:10:26< cosman2001> I want a scheduler to work at a class level
 /12/2011 23:10:37<@ohadlevy> fitzdsl: :)
 /12/2011 23:10:37-!- fitzdsl changed the topic of #theforeman to: scheduler support
 /12/2011 23:10:49<@ohadlevy> fitzdsl: I never thought I'll have a community when I started foreman too
 /12/2011 23:10:55<@ohadlevy> and that people would find it useful
 /12/2011 23:10:58<@ohadlevy> so YMMV
 /12/2011 23:11:17< cosman2001> can somebody order a pizza for ohad
 /12/2011 23:11:33< fenrus02> pizza?  it's well past bedtime for him now i suspect :)
 /12/2011 23:11:37<@ohadlevy> cosman2001: i need sleeping hours, children are keeping me extra busy :)
 /12/2011 23:11:59< mfridh> since I got kids my favourite project is to sleep.
 /12/2011 23:12:07< mfridh> too bad it's the least prioritized project though
 /12/2011 23:12:14< cosman2001> well I am fine with discussing additional topic inside google group
 /12/2011 23:12:15< jpalmer> cosman2001: how about hostgroup based schedules instead?  (or in addition to)   so lets say you have a hostgroup for app version 1.0,  and one for 1.1.  you schedule the hostrgroup for a specific host to change at 2am when the maint window starts.  and put the logic of the actual upgrade into the classes.
 /12/2011 23:12:27<@ohadlevy> ok then
 /12/2011 23:12:55<@ohadlevy> next is to think of what we want to do first
 /12/2011 23:13:02<@ohadlevy> and who would do it :)
 /12/2011 23:13:19<@ohadlevy> translate the list of items from today into features
 /12/2011 23:13:24<@ohadlevy> etc
 /12/2011 23:13:29< jpalmer> alright.  so all other topics will be discussed on the list?
 /12/2011 23:13:38<@ohadlevy> sounds like a good plan
 /12/2011 23:13:41< gwmngilfen> +1
 /12/2011 23:13:48<@ohadlevy> in general, really, no need to wait for a meeting such as this
 /12/2011 23:13:49< jpalmer> drat ;)   ok.
 /12/2011 23:14:04< cosman2001> jpalmer, interesting, I don't see why assigning a class would be any different than assigning a group
 /12/2011 23:14:08< gwmngilfen> we'll want a set of minutes from this - ashp was taking notes, right? :)
 /12/2011 23:14:22<@ohadlevy> mailing list is usually best, as more people are usually involved
 /12/2011 23:14:47<@ohadlevy> gwmngilfen: wiki say that fitzdsl did all of the hard work
 /12/2011 23:14:55< jpalmer> I think meetings are good occasionally,  cus misunderstandings or unclear "feature" requests can be instantly cleared up..  rather than having a 50+ chain email thread.. to clear up a misunderstanding.  (I think my "bulk upload paramaters" request is one of those that will easily be misunderstood.
 /12/2011 23:15:01< cosman2001> ohadlevy, foreman-dev or foreman-users?
 /12/2011 23:15:08<@ohadlevy> so fitzdsl thanks a lot of organizing this meeting today!
 /12/2011 23:15:31<@ohadlevy> jpalmer: luckily most of us can be found here too :)
 /12/2011 23:15:31 * gwmngilfen refreshes the page
 /12/2011 23:15:33< gwmngilfen> wow
 /12/2011 23:15:36< gwmngilfen> fitzdsl++
 /12/2011 23:15:39<@ohadlevy> cosman2001: either
 /12/2011 23:15:42<@ohadlevy> !karma fitzdsl
 /12/2011 23:15:42< nudnik> karma for fitzdsl: 7
 /12/2011 23:15:43<@fitzdsl> ohadlevy: no worries I just propose a date :)
 /12/2011 23:15:48<@ohadlevy> fitzdsl++
 /12/2011 23:15:54<@ohadlevy> !karma fitzdsl
 /12/2011 23:15:54< nudnik> karma for fitzdsl: 8
 /12/2011 23:15:59<@fitzdsl> I hope to see you all guys in Fosdem :)
 /12/2011 23:16:07 * ohadlevy hopes to be there too
 /12/2011 23:16:07< gwmngilfen> fitzdsl: yup
 /12/2011 23:16:13< gwmngilfen> i really need to book flights and such
 /12/2011 23:16:15<@ohadlevy> ok, thakns a lot guys
 /12/2011 23:16:22< gwmngilfen> cheers all
 /12/2011 23:16:23<@ohadlevy> been a pleasure :)
 /12/2011 23:16:28< gwmngilfen> dinner ready in about 2 min too :)
 /12/2011 23:16:32<@fitzdsl> thanks of you ohadlevy for your openness :)
 /12/2011 23:16:49<@fitzdsl> I'll finish the report on the wiki
 /12/2011 23:16:57<@ohadlevy> fitzdsl: thanks a lot :)
 /12/2011 23:16:58<@fitzdsl> and attach the log of the discussion to :)
 /12/2011 23:17:24< gwmngilfen> fitzdsl: agreed. thanks ohadlevy!
 /12/2011 23:17:29< gwmngilfen> cya all tomorrow
 /12/2011 23:17:31<@ohadlevy> cya

(1-1/1)

Project

General

Profile

Roadmap meeting Dec 05 2011 » 20111205meeting.log