14:40:44 <herlo> #startmeeting
14:40:44 <zodbot> Meeting started Sun Jan 30 14:40:44 2011 UTC.  The chair is herlo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:40:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:03:42 <CodeBlock> good morning
16:04:06 <DiscordianUK> afternoon CodeBlock
16:04:14 <CodeBlock> I will transcribe the first session; about asterisk
16:04:23 <brunowolff> Was that from you or the instructor?
16:04:38 <CodeBlock> brunowolff: hm?
16:04:53 <brunowolff> I wasn't sure if you had started transcribing.
16:05:03 <CodeBlock> Russel is talking about himself, he's a core developer and project manager of asterisk, since 2004.
16:05:19 <CodeBlock> He's an engineering manager at Digium, inc., which sponsors the asterisk project.
16:05:47 <CodeBlock> He's co-authored two books about Asterisk.
16:06:09 <CodeBlock> Asking the audience how many of us have used Asterisk
16:06:19 <brunowolff> I use it at home.
16:06:42 <CodeBlock> "What are the first things that come to mind with using telephones?" (some responses) conferencing, voice communication
16:07:22 <CodeBlock> [slide] Asterisk can help you: Financially, personally, professionally
16:07:53 <CodeBlock> [slide] Asterisk Hacks: How To.... Make free PSTN phone calls, grow your company, avoid your Ex, make grandma louder, never be late to a conference call
16:08:19 <CodeBlock> He is talking about each one of those slightly
16:08:37 <CodeBlock> nothing worth typing out ;)
16:08:54 <CodeBlock> [slide] How to make free PSTN phone calls
16:09:03 <CodeBlock> Google Voice
16:09:54 <CodeBlock> Google talk: IM/Call people via a web interface, etc.  Google voice: Free DID number to accept calls, place calls
16:10:13 <CodeBlock> Only for residents of the USA and Canada
16:10:26 <CodeBlock> Can sign up out of country via VPN
16:10:32 <CodeBlock> (located in the US)
16:11:06 <CodeBlock> Showing us a jabber.conf example to set up google talk with asterisk
16:11:18 <CodeBlock> another file, gtalk.conf
16:11:31 <CodeBlock> (going through it too fast for me to type out the example, unfortunately)
16:12:13 <CodeBlock> extensions.conf, and a sample [gtalk-incoming] section
16:13:34 <CodeBlock> showing extensions.conf pattern matching, and showing how to place calls through google voice...hope he has this presentation online somewhere
16:13:57 <CodeBlock> Next hack: How to grow your company
16:14:55 <CodeBlock> talking about PITCH_SHIFT() which can change the pitch of input volume (to make yourself sound differently)
16:15:42 <CodeBlock> Talking about how to fake caller ID info and make it look like people are calling each other
16:15:47 <CodeBlock> for fun :)
16:16:41 <CodeBlock> Growing your company with PITCH_SHIFT() -> incoming calls enter the auto-attendant then transfer to administrative assistant. Modify the pitch of your voice to the opposite spectrum.
16:16:53 <CodeBlock> Gah, missed some of those bullets
16:17:04 <CodeBlock> Next hack: how to avoid your Ex: call routing based on callerID
16:18:01 <CodeBlock> Simple extensions.conf one-line addition to Hangup() based on phone number
16:18:13 <CodeBlock> #topic Asterisk Hacks
16:18:21 <CodeBlock> guess I should have done that...or not, I'm not a chair
16:18:33 <CodeBlock> Next hack: How to make Grandma Louder
16:18:49 <CodeBlock> extensions.conf: Set(VOLUME(rx)=3)
16:19:01 <CodeBlock> Next hack: How to never be late to a conference call
16:19:06 <CodeBlock> Calendar Integration
16:19:40 <CodeBlock> Origin of Calendar Integration, programmer who works remotely at digium, and got involved in code and always was late to meetings
16:19:50 <CodeBlock> Uses calendar.conf
16:20:08 <CodeBlock> Can work with google calendar, or any DAV calendaer
16:20:26 <CodeBlock> Can trigger calls based on entries in calendar
16:20:38 <CodeBlock> Can be used for meeting reminders, wakeup calls
16:21:55 <CodeBlock> Showing a Dialplan example for setting up calls between two meeting participants
16:22:06 <CodeBlock> Based on the calendar entry
16:22:49 <CodeBlock> Thank-you slide
16:23:22 <CodeBlock> Question can you make the rest of your phone rings if you use this at home
16:23:50 <CodeBlock> Talking about various options to do that - PCI cards that digium sells, boxes that Linksys sells (for $50 bucks or so)
16:24:36 <CodeBlock> Talking about IP phone vs. using existing wiring in the house, and how to use existing wiring
16:25:22 <CodeBlock> VoIP clients on various platforms
16:25:30 <brunowolff> I have a tdm400p at home and have different phones in the house on different lines so my wife can call me in my office (in the basement).
16:25:49 <CodeBlock> [questions] Storing the plain-text google password in a config file....
16:26:17 <CodeBlock> [answer] set proper permissions, and probably only use that google hack at home, not in a professional setting
16:26:54 <CodeBlock> [q] LDAP integration
16:27:16 <CodeBlock> [a] It is possible, but there are modifications that modules need in order to use it
16:27:22 <CodeBlock> [q] SMS integration
16:27:43 <CodeBlock> [a] There is a module called chan_mobile that lets you hook up to cell phones over bluetooth, and this can be used for SMS
16:28:17 <CodeBlock> ..talking about how SMS uses SS7
16:29:12 <CodeBlock> [a continued] email to sms, or other sms gateway .. asterisk not a very good solution
16:29:56 <CodeBlock> Talking about an asterisk <-> IM protocol gateway
16:30:07 <CodeBlock> will probably be in next release
16:30:42 <CodeBlock> Saying thank you for our time
16:30:50 <CodeBlock> [presentation complete, clapping]
16:38:16 <herlo> #chair CodeBlock
16:38:16 <zodbot> Current chairs: CodeBlock herlo
16:38:38 <CodeBlock> herlo: thank you sir; though it's over now ;)
16:38:54 <herlo> CodeBlock: but you might transcribe more later
16:39:01 <herlo> :)
16:39:02 <CodeBlock> herlo: probably in another room
16:39:19 <CodeBlock> likely not coming back here
16:39:30 <CodeBlock> alright bbiab
16:40:42 <herlo> nw
17:14:51 <nb> anyone transcribing here?
17:15:24 <zoglesby> nope :(
17:19:38 <suehle> If anyone at the migrating to open source session would like to write it up for opensource.com, let me know.
17:27:05 <herlo> someone should
17:27:14 <herlo> please transcribe if you are in this room
18:04:52 <zodbot> tflink: Error: Can't start another meeting, one is in progress.
18:05:04 <tflink> ==> start of matahari presentation
18:05:37 <tflink> * note for people trying to follow - feel free to ask questions and I will try to ask them in person
18:05:55 <tflink> what is matahari? - a name of a spy in the past
18:06:19 <tflink> it is a collection of fenerically useful apis accessible over a remote interface via a collection of agents
18:06:46 <tflink> basiaclly, we are trying to collect all of these useful APIs into one place so that people from the community can extend it
18:07:11 <tflink> we want it to be cross-platform but we are starting with fedora before moving on to linux, windows etc
18:07:25 <nb> #chair tflink
18:07:25 <zodbot> Current chairs: CodeBlock herlo nb tflink
18:07:27 <tflink> it is important to run on windows
18:07:27 <tflink> go into why in a bit
18:07:48 <tflink> we also want it to work on virtual guests and bare metal
18:08:16 <tflink> matahari started as a framework formanaging a ovirt server using fedora etc.
18:08:54 <tflink> we want to be able to manage machines, even on EC2 where you don't have information on the host running the VM
18:09:18 <tflink> we want something that works as a client on the guest OS, so that we know when it is really still working
18:09:35 <tflink> if something is just in qemu, qemu could say that the VM is alive when it really isn't
18:10:17 <tflink> we could use some of the stuff to integrate with stuff like puppet or kickstart
18:10:38 <tflink> most of what we need is the guest getting dat from the host but also want to get data from the guest at the host
18:10:56 <tflink> *q - will this be able to restart services in addition to monitoring them
18:11:09 <tflink> yes, it will be able to do that if so configured - one piece of the puzzle
18:11:20 <tflink> * showing an architecture diagram
18:12:21 <tflink> another thing that we want to do is use QMF or a generic REST interface but for now is qpid
18:12:32 <tflink> * another diagram of matahari on KVM guest
18:13:03 <tflink> the difference is that now you are going rhough the qemu-kvm layer to get the information that you used to get from the bare metal
18:13:59 <tflink> *q - so we're going to rely on virtio serial to communicate with the guest, but you said that matahari also works on bare metal
18:14:11 <tflink> the previous slide showed the bare metal use case
18:14:25 <tflink> the machine uses tcp/ip to communicate with the controller
18:14:48 <tflink> an agent is a "QMF Agent" which is a daemon that runs and exposes a QMF model to a qpid bus
18:15:11 <tflink> agents provide method invocation with parameters, acces to properties and statistics and an event mechanism
18:15:31 <tflink> any QMF agent can be a matahari agent - there isn't a whole lot of difference between the two
18:15:43 <tflink> what we;re trying to do is provide better data for the management server
18:16:08 <tflink> *q - I assume that it can do package management, too? for windows, linux etc.
18:16:23 <tflink> its on our roadmap for the future, interface with yum, packagekit etc.
18:16:37 <tflink> for windows, we don't have as many options since you don't have much package management
18:16:59 <tflink> one thought is to do something like pulp which does want to do management of windows content, too
18:17:36 <tflink> *c - we have similar problems for the cloud stuff, so there should be some overlap - talk after the presentation (from the pulp guys)
18:17:51 <tflink> the core here is that we want to get some community involvement
18:18:06 <tflink> I don't want to build it by myself, don't have the resources :)
18:18:18 <tflink> matahari will ship with several agents for core OS management
18:18:39 <tflink> these core agents will exand over time as additional functionality is needed
18:18:50 <tflink> QMF is structured sucht that everything is done through a console
18:19:07 <tflink> the consoles are applicatiosn that call agen methods, questy agent propertie and receive agent events
18:19:23 <tflink> *q - is this a lightweight messsaging format, or could it
18:19:52 <tflink> QMF could do that but an agent would have to be a daemon so that something responds to requests
18:21:00 <tflink> FUnctional areas that we're starting witrh - Host (hw id), net (dealing with network interfaces), services and logging (not replacing system log, querying logs and filtering it)
18:21:14 <tflink> *q - is the goal to expose a common API for linux and windows
18:21:28 <tflink> yes, that is what we want to do. it would be hard and there are going to be places where there is no overlap
18:21:47 <tflink> we aren't trying ot have a complete api, just enough to be able to work with them  both in the could
18:22:12 <tflink> also want to do stuff in the area of configuration management (simple?), user management, soteage and packages
18:22:16 <tflink> storage
18:22:46 <tflink> limits ot scope = agent and API functionality is dribven by concrete needs instead of imagined future functionality
18:23:02 <tflink> we could plug into stuff like puppet of spacewalk, but won't be duplicating their functionality
18:23:12 <tflink> * showing host api example
18:23:23 <tflink> methods: identify, shutdown, reboot
18:23:28 <tflink> events: heartbeaat
18:23:50 <tflink> statitistics and properties, too like load average, hostname, OS arch etc.
18:24:19 <tflink> *c - this sort of stuff is also good for a testing framework
18:24:39 <tflink> yeah, our goal is to get this part of fedora, part of RHEL so that everyone could use it
18:24:49 <tflink> *q - are you going to cover the state of the project?
18:24:49 <tflink> yes
18:25:00 <tflink> let's not reinvent the wheel if we don't have to
18:25:10 <tflink> reuse apis, not create new ones
18:25:25 <tflink> whenever possible, we simply expose an existing API via a AMF model
18:26:11 <tflink> for example, libraries liek sigar (cross platform APIs - added to fedora), augeas (granular config management), libvirt (virt management for hosts)
18:26:33 <tflink> probably goign to try to merge libvirt-qpid into matahari so that they don't ahve to be separate
18:26:43 <tflink> -> artitecture
18:27:02 <tflink> QMF is an ovject modeling framework that layers on top of AMQP/Qpid
18:27:22 <tflink> API functions are wittten in C for maximum reusability and them vrouped into C++ objects for QMF to expose
18:27:46 <tflink> qpid has the ability to transport over different methods, we want to do that but for now, just TCP
18:27:53 <tflink> why do we split this up into multiple daemon?
18:27:56 <tflink> security, mostly.
18:28:29 <tflink> by splitting them up into multiple daemons, you can restrict security so that the network daemon isn't doing something it shouldn't and don't ahve a single daemon that could do anything
18:28:43 <tflink> configuration ->
18:28:55 <tflink> the QMF and matahari agents are roughly the same
18:29:13 <tflink> but we still need to configure stuff like "where do I connect to etc."
18:29:44 <tflink> qpid provides a decent amount of this, but doing this securely over TCP is not trivial
18:29:51 <tflink> already works over virtio-serial port
18:30:04 <tflink> the security needs to be good to prevent spying on other guests
18:30:37 <tflink> right now, it is a lot of fedora, but we want to get this working on other linuxes but we really want to make it work on windows
18:30:51 <tflink> *c - mingw works really well for us, too
18:31:20 <tflink> using mingw32 allows us to build the windows parts in the infrastructure we already have in fedora
18:31:41 <tflink> the disadvantage is that there is no 64 bit binaries (yet, working on it) and can't build drivers
18:31:53 <tflink> debugging also needs gdb instead of any MS tools
18:32:13 <tflink> also, the WMI api is problematic. it is an OO design but that is more complex to make available from mingw
18:32:21 <tflink> * starting section on QPID
18:32:35 <tflink> why use qpid? it is standars complient, open source mesage bus
18:32:56 <tflink> it supports SSL/TLS and kerberos encription independent of which transport is use
18:33:24 <tflink> tQpid supports full ACLs in the brokers
18:33:50 <tflink> it is really important to keep one guest from finding out information about another guest
18:34:24 <tflink> by using the ACLs, we can prevent guests from spying on eachother while giving a different interface to the host
18:34:51 <tflink> * some stuff on performance that I missed
18:35:10 <tflink> status: host, network and services APIs working won Fedora and windows
18:35:21 <tflink> windows is done in NSIS
18:35:31 <tflink> Packaged in RPOM as an .ede in an ISO
18:36:08 <tflink> *q - what about WIX?
18:36:22 <tflink> we looked at it in the past, but ended up scrapping it?
18:36:57 <tflink> we might look at it again in the future, but we'll see
18:37:16 <tflink> we are trying to get everything into F15
18:37:23 <tflink> ==> roadmap
18:37:41 <tflink> would like to get everything into F15 (host, net, services agents for fedora and windows)
18:37:48 <tflink> Initial use cases:
18:37:59 <tflink> - cloud guest agent for aeolus (cloud engine) project
18:38:11 <tflink> - LRM (local resource manger) replacement for pacemeaker
18:38:32 <tflink> * can't seem to keep up with the presenation - hopefully it will be posted
18:39:05 <tflink> in the future, we would like to get FMCI (using DBus) to midffof QMF models to integrate
18:39:33 <tflink> we would like to replace vhostmd of rSAP/kvm for cirt support
18:40:02 <tflink> we would like to get community input, too
18:40:21 <tflink> so that we can get the stuff people want done now - done now and then work on the future stuff
18:41:03 <tflink> *q - what is your packaging model for the agents - would it be possible to use for just config (for example)
18:41:19 <tflink> the agents are separate, but for now they are all packaged in the same RPM
18:41:33 <tflink> if there is an interest, we can go that direction
18:41:44 <tflink> *q - what is the RHEL support going to look like
18:41:49 <tflink> eventually, but can't talk about when
18:42:10 <tflink> *q - is there any discussion of integration with packagekit, yum etc.
18:42:18 <tflink> there has been discussion, no conclusion yet
18:42:23 <tflink> would love to have more input
18:42:52 <tflink> we aren't trying to replicate the yum api but there is a basic subset taht would be nice to replicate on linux on windows
18:43:07 <tflink> would like to see people look at the list of APIs on the wiki and say "this is useful for me" etc.
18:43:35 <tflink> *c - some of us are already using satellite, etc. and using deltacloud to work with vmware and windows
18:44:04 <tflink> *q - if you;re looking to build a reference arch now, are you going to use deltacloud etc.?
18:44:21 <tflink> for now, they aren't compatible but eventually, we would like to make them work together
18:44:36 <tflink> so that you deploy an image to the cloud, and then you want to do something else
18:44:51 <tflink> eventually, they may use matahari to do something like that
18:45:03 <tflink> so you might want to feed a puppet script through matahari
18:45:20 <tflink> but we aren't trying to replace puppet server with matahari
18:45:31 <tflink> *q - are the data models defined staically?
18:45:39 <tflink> we are trying to have a stable data api
18:46:06 <tflink> once we get there, we are going to reach a point that the apis aren't going to change
18:46:18 <tflink> you can certainly add apis that won't get stomped on
18:46:30 <tflink> *q - but no introspection?
18:46:50 <tflink> we want to have a versioning part of qmf for introspection
18:46:56 <tflink> *q - do you have a release date
18:47:12 <tflink> not really - we want to be part of F15, but nothing specific. Hoping for earlier than that
18:47:33 <tflink> ==> end of presenation on matahari
18:47:38 <tflink> #endmeeting