a methodical makeover for ctdb
play

A methodical makeover for CTDB Martin Schwenke < martin@meltin.net - PowerPoint PPT Presentation

Mar 04, 2024 •186 likes •1.82k views

A methodical makeover for CTDB Martin Schwenke < martin@meltin.net > Amitay Isaacs < amitay@samba.org > Samba Team IBM (Australia Development Laboratory, Linux Technology Center) Martin Schwenke, Amitay Isaacs A methodical makeover

  1. Limitations: Design Main daemon and recovery daemon overloaded Mix of time critical and non-critical in single daemon Difficult to maintain in asynchronous, non-blocking design Communication bottleneck All messages must pass through (single threaded) main daemon Cluster leader election Each node tries to become leader on starting up Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  2. Limitations: Design Main daemon and recovery daemon overloaded Mix of time critical and non-critical in single daemon Difficult to maintain in asynchronous, non-blocking design Communication bottleneck All messages must pass through (single threaded) main daemon Cluster leader election Each node tries to become leader on starting up Does not scale with number of nodes! Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  3. Limitations: Design Main daemon and recovery daemon overloaded Mix of time critical and non-critical in single daemon Difficult to maintain in asynchronous, non-blocking design Communication bottleneck All messages must pass through (single threaded) main daemon Cluster leader election Each node tries to become leader on starting up Does not scale with number of nodes! Database recovery Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  4. Limitations: Design Main daemon and recovery daemon overloaded Mix of time critical and non-critical in single daemon Difficult to maintain in asynchronous, non-blocking design Communication bottleneck All messages must pass through (single threaded) main daemon Cluster leader election Each node tries to become leader on starting up Does not scale with number of nodes! Database recovery Cluster leader recovers databases one at a time Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  5. Limitations: Design Main daemon and recovery daemon overloaded Mix of time critical and non-critical in single daemon Difficult to maintain in asynchronous, non-blocking design Communication bottleneck All messages must pass through (single threaded) main daemon Cluster leader election Each node tries to become leader on starting up Does not scale with number of nodes! Database recovery Cluster leader recovers databases one at a time Centralised state Some state is in main daemon but is used in recovery daemon Tight coupling Membership, service health, IP allocation are tightly coupled Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  6. Limitations: Implementation Protocol is “structs on the wire” 32-bit vs 64-bit, not endian-neutral Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  7. Limitations: Implementation Protocol is “structs on the wire” 32-bit vs 64-bit, not endian-neutral Hand-marshalling of structures Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  8. Limitations: Implementation Protocol is “structs on the wire” 32-bit vs 64-bit, not endian-neutral Hand-marshalling of structures Simpler protocol – single packet request/response Streams / Large packets (e.g. multiple database records) Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  9. Limitations: Implementation Protocol is “structs on the wire” 32-bit vs 64-bit, not endian-neutral Hand-marshalling of structures Simpler protocol – single packet request/response Streams / Large packets (e.g. multiple database records) Large data buffer (talloc), Large send/recv (socket handling) Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  10. Limitations: Implementation Protocol is “structs on the wire” 32-bit vs 64-bit, not endian-neutral Hand-marshalling of structures Simpler protocol – single packet request/response Streams / Large packets (e.g. multiple database records) Large data buffer (talloc), Large send/recv (socket handling) No (internal) messaging framework Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  11. Limitations: Implementation Protocol is “structs on the wire” 32-bit vs 64-bit, not endian-neutral Hand-marshalling of structures Simpler protocol – single packet request/response Streams / Large packets (e.g. multiple database records) Large data buffer (talloc), Large send/recv (socket handling) No (internal) messaging framework Fire-and-forget method of communication with recovery daemon Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  12. Limitations: Implementation Protocol is “structs on the wire” 32-bit vs 64-bit, not endian-neutral Hand-marshalling of structures Simpler protocol – single packet request/response Streams / Large packets (e.g. multiple database records) Large data buffer (talloc), Large send/recv (socket handling) No (internal) messaging framework Fire-and-forget method of communication with recovery daemon Unstructured CLI and configuration Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  13. Limitations: Implementation Protocol is “structs on the wire” 32-bit vs 64-bit, not endian-neutral Hand-marshalling of structures Simpler protocol – single packet request/response Streams / Large packets (e.g. multiple database records) Large data buffer (talloc), Large send/recv (socket handling) No (internal) messaging framework Fire-and-forget method of communication with recovery daemon Unstructured CLI and configuration Need to re-design Scalability, Maintainability Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  14. Component: Logging daemon Motivation What is the smallest chunk that can be split as a separate daemon? Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  15. Component: Logging daemon Motivation What is the smallest chunk that can be split as a separate daemon? Logging daemon Self-contained code Can be used as a template for other daemons Looks simple enough. . . Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  16. Component: Logging daemon Before: Custom logging daemon Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  17. Component: Logging daemon Before: Custom logging daemon Why? syslog(3) blocks when syslog daemon gets busy What? Log each received message using syslog(3) How? Custom UDP protocol Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  18. Component: Logging daemon Before: Custom logging daemon Why? syslog(3) blocks when syslog daemon gets busy What? Log each received message using syslog(3) How? Custom UDP protocol Problems Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  19. Component: Logging daemon Before: Custom logging daemon Why? syslog(3) blocks when syslog daemon gets busy What? Log each received message using syslog(3) How? Custom UDP protocol Problems Only used when syslog enabled, not file logging File logging can block too! Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  20. Component: Logging daemon Before: Custom logging daemon Why? syslog(3) blocks when syslog daemon gets busy What? Log each received message using syslog(3) How? Custom UDP protocol Problems Only used when syslog enabled, not file logging File logging can block too! Protocol is “structs on the wire” Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  21. Component: Logging daemon Before: Custom logging daemon Why? syslog(3) blocks when syslog daemon gets busy What? Log each received message using syslog(3) How? Custom UDP protocol Problems Only used when syslog enabled, not file logging File logging can block too! Protocol is “structs on the wire” After? Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  22. Component: Logging daemon Before: Custom logging daemon Why? syslog(3) blocks when syslog daemon gets busy What? Log each received message using syslog(3) How? Custom UDP protocol Problems Only used when syslog enabled, not file logging File logging can block too! Protocol is “structs on the wire” After? Shiny new daemon with well-defined protocol. . . Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  23. Component: Logging daemon Before: Custom logging daemon Why? syslog(3) blocks when syslog daemon gets busy What? Log each received message using syslog(3) How? Custom UDP protocol Problems Only used when syslog enabled, not file logging File logging can block too! Protocol is “structs on the wire” After? Shiny new daemon with well-defined protocol. . . . . . that handles all logging Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  24. Component: Logging daemon The big idea! Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  25. Component: Logging daemon The big idea! Create an asynchronous framework for CTDB daemons! Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  26. Component: Logging daemon The big idea! Create an asynchronous framework for CTDB daemons! Use Samba’s tevent_req framework! Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  27. Component: Logging daemon The big idea! Create an asynchronous framework for CTDB daemons! Use Samba’s tevent_req framework! Define protocol and auto-generate marshalling code! Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  28. Component: Logging daemon The big idea! Create an asynchronous framework for CTDB daemons! Use Samba’s tevent_req framework! Define protocol and auto-generate marshalling code! Use all this to write logging daemon (as a template)! Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  29. Component: Logging daemon The big idea! Create an asynchronous framework for CTDB daemons! Use Samba’s tevent_req framework! Define protocol and auto-generate marshalling code! Use all this to write logging daemon (as a template)! And then use the template for writing other daemons! Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  30. Component: Logging daemon The big idea! Create an asynchronous framework for CTDB daemons! Use Samba’s tevent_req framework! Define protocol and auto-generate marshalling code! Use all this to write logging daemon (as a template)! And then use the template for writing other daemons! The big problem! Logging is hard! How do you handle errors in logging daemon? Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  31. Component: Logging daemon The big idea! Create an asynchronous framework for CTDB daemons! Use Samba’s tevent_req framework! Define protocol and auto-generate marshalling code! Use all this to write logging daemon (as a template)! And then use the template for writing other daemons! The big problem! Logging is hard! How do you handle errors in logging daemon? The better idea! We’re not in the logging business . . . daemons already exist! Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  32. Component: Logging daemon The big idea! Create an asynchronous framework for CTDB daemons! Use Samba’s tevent_req framework! Define protocol and auto-generate marshalling code! Use all this to write logging daemon (as a template)! And then use the template for writing other daemons! The big problem! Logging is hard! How do you handle errors in logging daemon? The better idea! We’re not in the logging business . . . daemons already exist! Use RFC5424 message format Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  33. Component: Logging daemon The big idea! Create an asynchronous framework for CTDB daemons! Use Samba’s tevent_req framework! Define protocol and auto-generate marshalling code! Use all this to write logging daemon (as a template)! And then use the template for writing other daemons! The big problem! Logging is hard! How do you handle errors in logging daemon? The better idea! We’re not in the logging business . . . daemons already exist! Use RFC5424 message format Transmit via UDP as per RFC5426 Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  34. Component: Logging daemon So, how did that work out? Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  35. Component: Logging daemon So, how did that work out? First Linux version quite easy but not merged because. . . Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  36. Component: Logging daemon So, how did that work out? First Linux version quite easy but not merged because. . . Unified Samba/CTDB build coming up (see later) Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  37. Component: Logging daemon So, how did that work out? First Linux version quite easy but not merged because. . . Unified Samba/CTDB build coming up (see later) Samba’s debug. { ch } is completely different to CTDB’s Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  38. Component: Logging daemon So, how did that work out? First Linux version quite easy but not merged because. . . Unified Samba/CTDB build coming up (see later) Samba’s debug. { ch } is completely different to CTDB’s Spend a month completing the unified build Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  39. Component: Logging daemon So, how did that work out? First Linux version quite easy but not merged because. . . Unified Samba/CTDB build coming up (see later) Samba’s debug. { ch } is completely different to CTDB’s Spend a month completing the unified build Send to Unix domain socket in non-blocking mode? Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  40. Component: Logging daemon So, how did that work out? First Linux version quite easy but not merged because. . . Unified Samba/CTDB build coming up (see later) Samba’s debug. { ch } is completely different to CTDB’s Spend a month completing the unified build Send to Unix domain socket in non-blocking mode? rsyslogd doesn’t speak RFC5424 on Unix domain socket? Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  41. Component: Logging daemon So, how did that work out? First Linux version quite easy but not merged because. . . Unified Samba/CTDB build coming up (see later) Samba’s debug. { ch } is completely different to CTDB’s Spend a month completing the unified build Send to Unix domain socket in non-blocking mode? rsyslogd doesn’t speak RFC5424 on Unix domain socket? Learn about RFC3164! Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  42. Component: Logging daemon So, how did that work out? First Linux version quite easy but not merged because. . . Unified Samba/CTDB build coming up (see later) Samba’s debug. { ch } is completely different to CTDB’s Spend a month completing the unified build Send to Unix domain socket in non-blocking mode? rsyslogd doesn’t speak RFC5424 on Unix domain socket? Learn about RFC3164! Location of socket is not standardised Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  43. Component: Logging daemon So, how did that work out? First Linux version quite easy but not merged because. . . Unified Samba/CTDB build coming up (see later) Samba’s debug. { ch } is completely different to CTDB’s Spend a month completing the unified build Send to Unix domain socket in non-blocking mode? rsyslogd doesn’t speak RFC5424 on Unix domain socket? Learn about RFC3164! Location of socket is not standardised Much of RFC3164 is only recommended. . . Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  44. Component: Logging daemon So, how did that work out? First Linux version quite easy but not merged because. . . Unified Samba/CTDB build coming up (see later) Samba’s debug. { ch } is completely different to CTDB’s Spend a month completing the unified build Send to Unix domain socket in non-blocking mode? rsyslogd doesn’t speak RFC5424 on Unix domain socket? Learn about RFC3164! Location of socket is not standardised Much of RFC3164 is only recommended. . . . . . and sometimes not supported Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  45. Component: Logging daemon So, how did that work out? First Linux version quite easy but not merged because. . . Unified Samba/CTDB build coming up (see later) Samba’s debug. { ch } is completely different to CTDB’s Spend a month completing the unified build Send to Unix domain socket in non-blocking mode? rsyslogd doesn’t speak RFC5424 on Unix domain socket? Learn about RFC3164! Location of socket is not standardised Much of RFC3164 is only recommended. . . . . . and sometimes not supported FreeBSD supports RFC3164, not RFC5424, over UDP Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  46. Component: Logging daemon So, how did that work out? First Linux version quite easy but not merged because. . . Unified Samba/CTDB build coming up (see later) Samba’s debug. { ch } is completely different to CTDB’s Spend a month completing the unified build Send to Unix domain socket in non-blocking mode? rsyslogd doesn’t speak RFC5424 on Unix domain socket? Learn about RFC3164! Location of socket is not standardised Much of RFC3164 is only recommended. . . . . . and sometimes not supported FreeBSD supports RFC3164, not RFC5424, over UDP Tear out hair. . . Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  47. Component: Logging daemon CTDB logging=syslog* options syslog Use syslog(3) syslog:nonblocking RFC3164 to Unix domain socket RFC3164 to UDP socket syslog:udp syslog:udp-rfc5424 RFC5424 to UDP socket (RFC5426) Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  48. Component: Logging daemon CTDB logging=syslog* options syslog Use syslog(3) syslog:nonblocking RFC3164 to Unix domain socket RFC3164 to UDP socket syslog:udp syslog:udp-rfc5424 RFC5424 to UDP socket (RFC5426) After Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  49. Component: Logging daemon CTDB logging=syslog* options syslog Use syslog(3) syslog:nonblocking RFC3164 to Unix domain socket RFC3164 to UDP socket syslog:udp syslog:udp-rfc5424 RFC5424 to UDP socket (RFC5426) After A lot of time passed. . . more than 12 months Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  50. Component: Logging daemon CTDB logging=syslog* options syslog Use syslog(3) syslog:nonblocking RFC3164 to Unix domain socket RFC3164 to UDP socket syslog:udp syslog:udp-rfc5424 RFC5424 to UDP socket (RFC5426) After A lot of time passed. . . more than 12 months Above merged into (Samba) master branch Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  51. Component: Logging daemon CTDB logging=syslog* options syslog Use syslog(3) syslog:nonblocking RFC3164 to Unix domain socket RFC3164 to UDP socket syslog:udp syslog:udp-rfc5424 RFC5424 to UDP socket (RFC5426) After A lot of time passed. . . more than 12 months Above merged into (Samba) master branch Retired from the logging business Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  52. Component: Logging daemon CTDB logging=syslog* options syslog Use syslog(3) syslog:nonblocking RFC3164 to Unix domain socket RFC3164 to UDP socket syslog:udp syslog:udp-rfc5424 RFC5424 to UDP socket (RFC5426) After A lot of time passed. . . more than 12 months Above merged into (Samba) master branch Retired from the logging business Future? Promote some of this to Samba’s debug. { ch } Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  53. New design Motivation Separate functionality in individual daemons Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  54. New design Motivation Separate functionality in individual daemons Design Public IP address daemon Service management daemon Cluster management daemon Database daemon . . . Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  55. New design: Public IP address daemon Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  56. New design: Public IP address daemon Single daemon with public IP address: Management Failover Consistency checking Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  57. New design: Public IP address daemon Single daemon with public IP address: Management Failover Consistency checking Simple management and status CLI Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  58. New design: Public IP address daemon Single daemon with public IP address: Management Failover Consistency checking Simple management and status CLI Simple IP (re)allocation trigger: Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  59. New design: Public IP address daemon Single daemon with public IP address: Management Failover Consistency checking Simple management and status CLI Simple IP (re)allocation trigger: Simple CLI command: these nodes can host addresses Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  60. New design: Public IP address daemon Single daemon with public IP address: Management Failover Consistency checking Simple management and status CLI Simple IP (re)allocation trigger: Simple CLI command: these nodes can host addresses Callback from other daemons when status changes Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  61. New design: Public IP address daemon Single daemon with public IP address: Management Failover Consistency checking Simple management and status CLI Simple IP (re)allocation trigger: Simple CLI command: these nodes can host addresses Callback from other daemons when status changes Callback can be a script that gathers extra status data. For example, cluster membership and/or service health status. Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  62. New design: Public IP address daemon Single daemon with public IP address: Management Failover Consistency checking Simple management and status CLI Simple IP (re)allocation trigger: Simple CLI command: these nodes can host addresses Callback from other daemons when status changes Callback can be a script that gathers extra status data. For example, cluster membership and/or service health status. An interface like this should also allow support for LVS, HAProxy, . . . Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  63. New design: Service management daemon Four functions: Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  64. New design: Service management daemon Four functions: Startup Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

  65. New design: Service management daemon Four functions: Startup Shutdown Martin Schwenke, Amitay Isaacs A methodical makeover for CTDB

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend

CTDB Stories Amitay Isaacs amitay@samba.org Samba Team IBM (Australia Development Labs, Linux

CTDB Stories Amitay Isaacs amitay@samba.org Samba Team IBM (Australia Development Labs, Linux

CTDB Stories Amitay Isaacs amitay@samba.org Samba Team IBM (Australia Development Labs, Linux Technology Center) Amitay Isaacs CTDB Stories CTDB Project Motivation: Support for clustered Samba Multiple nodes active simultaneously

1.84k views • 156 slides
CTDB Remix I: Dreaming the Fantasy Amitay Isaacs amitay@samba.org Samba Team IBM (Australia

CTDB Remix I: Dreaming the Fantasy Amitay Isaacs amitay@samba.org Samba Team IBM (Australia

CTDB Remix I: Dreaming the Fantasy Amitay Isaacs amitay@samba.org Samba Team IBM (Australia Development Labs, Linux Technology Center) SambaXP 2017 Amitay Isaacs CTDB Remix - Dreaming the Fantasy CTDB Project Motivation: Support for

1.26k views • 78 slides
CTDB database vacuuming for geniuses Amitay Isaacs amitay@samba.org Samba Team IBM (Australia

CTDB database vacuuming for geniuses Amitay Isaacs amitay@samba.org Samba Team IBM (Australia

CTDB database vacuuming for geniuses Amitay Isaacs amitay@samba.org Samba Team IBM (Australia Development Labs, Linux Technology Center) Amitay Isaacs CTDB database vacuuming for geniuses CTDB Project Motivation: Support for clustered Samba

1.59k views • 116 slides
Mississippi Makeover A Plan fo A for R r Rest estora ration, J Just st Aro Around th the

Mississippi Makeover A Plan fo A for R r Rest estora ration, J Just st Aro Around th the

Mississippi Makeover A Plan fo A for R r Rest estora ration, J Just st Aro Around th the B e Ben end Citizen Advisory Group Meeting March 31, 2011 Red Wing, MN Mississippi Makeover Where Have We Been? CAG meetings : December 2008,

298 views • 13 slides
CTDB remix II: Designing the Reality Martin Schwenke &lt; martin@meltin.net &gt; Samba Team IBM

CTDB remix II: Designing the Reality Martin Schwenke &lt; martin@meltin.net &gt; Samba Team IBM

CTDB remix II: Designing the Reality Martin Schwenke &lt; martin@meltin.net &gt; Samba Team IBM (Australia Development Laboratory, Linux Technology Center) SambaXP 2017 Martin Schwenke CTDB remix - Designing the Reality Overview Dreaming the

1.04k views • 46 slides
Untangling and Restructuring CTDB Martin Schwenke &lt; martin@meltin.net &gt; Samba Team IBM

Untangling and Restructuring CTDB Martin Schwenke &lt; martin@meltin.net &gt; Samba Team IBM

Untangling and Restructuring CTDB Martin Schwenke &lt; martin@meltin.net &gt; Samba Team IBM (Australia Development Laboratory, Linux Technology Center) Martin Schwenke Untangling and Restructuring CTDB What are we talking about? Martin

1.71k views • 113 slides
The CTDB Report Martin Schwenke &lt; martin@meltin.net &gt; Amitay Isaacs &lt; amitay@samba.org

The CTDB Report Martin Schwenke &lt; martin@meltin.net &gt; Amitay Isaacs &lt; amitay@samba.org

The CTDB Report Martin Schwenke &lt; martin@meltin.net &gt; Amitay Isaacs &lt; amitay@samba.org &gt; Samba Team IBM (Australia Development Laboratory, Linux Technology Center) SambaXP 2019 Martin Schwenke, Amitay Isaacs The CTDB Report

1.07k views • 70 slides
NARI Greater Dallas 2017 CotYs Residential Exterior Under $100,000 Exterior Makeover Vision

NARI Greater Dallas 2017 CotYs Residential Exterior Under $100,000 Exterior Makeover Vision

NARI Greater Dallas 2017 CotYs Residential Exterior Under $100,000 Exterior Makeover Vision &amp; Design Solutions Our clients goal for this exterior makeover project was to transform the exterior this single story ranch into a modern or

142 views • 13 slides
Extreme MAKEOVER College of Life Sciences Internship Online Management System

Extreme MAKEOVER College of Life Sciences Internship Online Management System

Extreme MAKEOVER College of Life Sciences Internship Online Management System lifesciences.byu.edu/internships October 2013 LfSci 399R LfSci 199R Before! The need for a makeover 1 internship coordinator; 2 internship assistants; many

452 views • 16 slides
Methodical Approximate Hardware Design and Reuse Amir Yazdanbakhsh

Methodical Approximate Hardware Design and Reuse Amir Yazdanbakhsh

Methodical Approximate Hardware Design and Reuse Amir Yazdanbakhsh Bradley Thwaites Jongse Park Hadi Esmaeilzadeh Georgia InsBtute of Technology

322 views • 13 slides
Communicating with Chefs Lateral vs Linear Visceral vs analytical Impatient vs methodical

Communicating with Chefs Lateral vs Linear Visceral vs analytical Impatient vs methodical

Communicating with Chefs Lateral vs Linear Visceral vs analytical Impatient vs methodical Opinionated vs Indifferent Stubborn vs Reasonable Ex Excit ite &amp; &amp; del deligh ght Mise en place = Design of Experiment We make food, not

676 views • 20 slides
Didactic-methodical Design Elements Engineering Didactics educational unit t 0 t 1 t 2 t 3 t 4 t

Didactic-methodical Design Elements Engineering Didactics educational unit t 0 t 1 t 2 t 3 t 4 t

Dr. Steffen Kersten Fakultt Erziehungswissenschaften , Institut fr Berufspdagogik und Berufliche Didaktiken Didactic-methodical Design Elements Engineering Didactics educational unit t 0 t 1 t 2 t 3 t 4 t 5 t 6 t 7 t 8 How we can describe

172 views • 16 slides
Content Project Analysis of Archaeal Protein Methodical approach Short excursus:

Content Project Analysis of Archaeal Protein Methodical approach Short excursus:

Content Project Analysis of Archaeal Protein Methodical approach Short excursus: biochemistry Sorting and Translocation Cryo-EM and Single Particle Analysis Equipment Sibylle Franckenberg Workflow and Data processing

342 views • 6 slides
Education Didactic of Engineering Education Didactic-methodical design of engineering education

Education Didactic of Engineering Education Didactic-methodical design of engineering education

Dr. Steffen Kersten Fakultt Erziehungswissenschaften , Institut fr Berufspdagogik und Berufliche Didaktiken Forms of Organisation in Engineering Education Didactic of Engineering Education Didactic-methodical design of engineering

306 views • 27 slides
SMB3 Multichannel with Samba/CTDB and Gluster Gnther Deschner &lt;gd@samba.org&gt; Sachin

SMB3 Multichannel with Samba/CTDB and Gluster Gnther Deschner &lt;gd@samba.org&gt; Sachin

SMB3 Multichannel with Samba/CTDB and Gluster Gnther Deschner &lt;gd@samba.org&gt; Sachin Prabhu &lt;sprabhu@redhat.com&gt; A g e n d a S a mb a / C T D B C l u s t e r i n g w i t h G l u s t e r F S

322 views • 31 slides
Earths Makeover LESSON 13 Your Response to the Lesson What was most interesting in the Bible

Earths Makeover LESSON 13 Your Response to the Lesson What was most interesting in the Bible

Earths Makeover LESSON 13 Your Response to the Lesson What was most interesting in the Bible story? What activity was most enjoyable? What new things did you learn? Activity A Neighbors With God Who would you choose to be your neighbor?

382 views • 22 slides
Extreme Makeover: Transforming Your Volunteer Engagement Efforts Agency Facilitator: Nikki

Extreme Makeover: Transforming Your Volunteer Engagement Efforts Agency Facilitator: Nikki

Extreme Makeover: Transforming Your Volunteer Engagement Efforts Agency Facilitator: Nikki Russell United Way of King County Volunteer Initiatives Manager nrussell@uwkc.org A little about your presenter Nikki Russell, CVA Volunteer

476 views • 47 slides
Math Curriculum Makeover II by Dan Meyer who writes at blog.mrmeyer.com who receives e-mail at

Math Curriculum Makeover II by Dan Meyer who writes at blog.mrmeyer.com who receives e-mail at

Math Curriculum Makeover II by Dan Meyer who writes at blog.mrmeyer.com who receives e-mail at dan@mrmeyer.com and tweets @ddmeyer presented at CAMT on 2011 July 19 link camt11.mrmeyer.com @andreabonilla andreabonilla 8 names are read per

943 views • 79 slides
The Scientific Approach to Marketing Effectiveness Jeffrey Spiegel, MD, FACS Professor Boston

The Scientific Approach to Marketing Effectiveness Jeffrey Spiegel, MD, FACS Professor Boston

The Scientific Approach to Marketing Effectiveness Jeffrey Spiegel, MD, FACS Professor Boston University School of Medicine Candace A. Quinn, MM, BS Brand=Experience Questions about Advertising Should I advertise? How much should I spend?

266 views • 26 slides
A Semantic Makeover for CMS Data Bill Levay @wjlevay Linked Jazz Project @linkedjazz //

A Semantic Makeover for CMS Data Bill Levay @wjlevay Linked Jazz Project @linkedjazz //

A Semantic Makeover for CMS Data Bill Levay @wjlevay Linked Jazz Project @linkedjazz // Code4Lib 2015 Project GitHub Repo github.com/wjlevay/tulane-jazz-data Tulane University Digital Collections Two collections: Hogan Jazz

798 views • 31 slides
The Multilingual Makeover: A side-by-side comparison of Drupal 7 and Drupal 8 Aimee Degnan &amp;

The Multilingual Makeover: A side-by-side comparison of Drupal 7 and Drupal 8 Aimee Degnan &amp;

The Multilingual Makeover: A side-by-side comparison of Drupal 7 and Drupal 8 Aimee Degnan &amp; Kristen Pol answers@hook42.com Hello! answers@hook42.com answers@hook42.com We are Hook 42 hook42.com / @hook42inc Aimee Degnan Kristen Pol

623 views • 48 slides
The Power of Unknowns Harnessing what you don't know to estimate project duration John Keklak

The Power of Unknowns Harnessing what you don't know to estimate project duration John Keklak

The Power of Unknowns Harnessing what you don't know to estimate project duration John Keklak Software Development Institute john@keklak.com The Power of Unknowns Harnessing what you don't know to estimate project duration John Keklak

1.59k views • 118 slides
NASA Astrobiology Program LIFE IN THE UNIVERSE Why is Astrobiology so useful in educa5on?

NASA Astrobiology Program LIFE IN THE UNIVERSE Why is Astrobiology so useful in educa5on?

NASA Astrobiology Program LIFE IN THE UNIVERSE Why is Astrobiology so useful in educa5on? Astrobiology tugs on those age-old ques5ons that are buried deep in our DNA, and builds on our natural curiosity. The collabora5ve essence of

86 views • 8 slides
Incent Them to Renew Quickly Discounts on early, multi- Step 1: Set a goal

Incent Them to Renew Quickly Discounts on early, multi- Step 1: Set a goal

10/13/17 RENEWAL of Associations report a decrease or no growth in membership size. Source: GrowthZone 2017 Association Survey Results Top 5 Reasons Members Dont Renew: Did you know it costs 7x more to

577 views • 8 slides

More recommend