Author(s):	Martin Schwenke
Location	OGGB3
Date	jan Thu 15	Days Raw Files
Start	13:20	First Raw Start	12:24
Duration	0:45:00	Offset	0:55:27
End	14:05	Last Raw End	14:18
Chapters	00:00
Total cuts_time	40 min.

http://lca2015.linux.org.au/schedule/30175/view_talk
raw-playlist raw-mp4-playlist encoded-files-playlist host public tweet mp4 svg png

assets release.pdf A_methodical_makeover_for_CTDB.json
logs
Admin: episode episode list cut list raw files day marks day marks day image_files

State:	--------- borked edit encode push to queue post richard review 1 email review 2 make public tweet to-miror conf done
Locked:	clear this to unlock
Locked by:	user/process that locked.
Start:	initially scheduled time from master, adjusted to match reality
Duration:	length in hh:mm:ss
Name:	Video Title (shows in video search results)
Emails:	email(s) of the presenter(s)
Released:	Unknown Yes No has someone authorised pubication
Normalise:
Channelcopy:	m=mono, 01=copy left to right, 10=right to left, 00=ignore.
Thumbnail:	filename.png
Description:	Presented by Martin Schwenke and Amitay Isaacs CTDB is the Clustered Trivial Database (TDB) and is used to provide clustering support for Samba. CTDB is a monolithic daemon that provides several different services: clustered database, service monitoring, management of a pool of IP addresses for NAS services, various types of consistency checking... and logging. It isn't exactly monolithic - there are 2 main daemons but functionality isn't cleanly split and there is duplication. Additionally, the protocols are not well defined: just structs on the wire. Things could be better. In an ideal world we would stop everything else we're doing for a few months, define protocols, restructure everything and, after some time, suddenly release a shiny, brand new version of CTDB. However, that's not going to happen. So, is it possible to do a major restructure of CTDB, with new protocols, in a methodical, step-by-step manner, maintaining some amount of backward compatibility as we go? With CTDB now merged into the Samba source tree, we can't break the Samba build at any stage. What is the plan? What are the really clever ideas? Is this really possible? Join us on a hacker's tale where we describe where we started, the problems we encountered, where we got to before Linux.conf.au 2015 ... and what still needs to be done. markdown
Comment:	production notes