Libvirt DEV & QE meetup

Beijing 2016

Michal Prívozník <mprivozn@redhat.com>

https://mprivozn.fedorapeople.org/Beijing2016_2/

DEV Team collaboration

Rules:

  • Upstream first ([nearly] no downstream specific patches)
  • QEMU first

DEV Team collaboration

Previously:

  • KVM/QEMU dev implemented feature
  • KVM/QEMU QE tested it
  • Libvirt dev implemented feature
  • Libvirt QE tested it

 

Problems:

  • Design problems caught too late (e.g. unusable monitor commands, command line, etc.)
  • Long time to market value
  • Release schedule unfit for Libvirt (QEMU features implemented too late in the release cycle, leaving too little space for proper Libvirt impl.)

DEV Team collaboration

Now:

  • KVM/QEMU dev posts patches with Libvirt dev CC'ed
  • Libvirt dev checks API for Libvirt fit
  • KVM/QEMU dev merges the feature
  • KVM/QEMU QE tests it
  • Libvirt dev merges the feature
  • Libvirt QE tests is

 

Pros:

  • Libvirt devs takes part in decision making
  • Eric Blake part of QEMU community now

 

Problems:

  • Need to bring upper layers in (RHEV, OpenStack)

DEV Team collaboration

Areas for improvement:

  • Closer collaboration within teams
  • Synchronize RHEV/RHOS release schedules with RHEL
  • Make QEMU use the Upstream first rule too
  • More testing

Testing

Current state of testing:

 

  • A lot of QE tests
    • Mostly regression testing, right?

Testing

What we could do better:

  • A lot of QE tests
    • Merge your tests to jenkins?

TESTING

If in doubt:

  • Ask on the libvir-list, libvirt-users list
  • ping libvirt dev @ IRC, e-mail, etc.
  • Ask in bugzilla
  • Attend Virt team call?
    • 1st Wed @ 13:00 CEST (19:00 CST)
    • 3rd Wed @ 16:00 CEST (22:00 CST)

Promoting (lib-)virt

How to * :

  • nobody has 100% success rate

  • Think about the audience (students?, KVM developers? QEs?)
  • What might be interesting to the audience?
    • students - introduce virtualization, promote internship,
      GSoC, etc.
    • KVM developers - how libvirt makes their life easier, what mistakes libvirt made and QEMU/KVM can still avoid
    • QEs - new test framework?
  • Helps to have some experience
    • start small (maybe some local conference, university, etc.),
      get big

* - how I usually do it

Promoting (lib-)virt

How to * :

  • Introduce virtualization, e.g. advantages of using it
    (e.g. rm -rf / in a guest with a snapshot)
  • Describe disadvantages, e.g:
    • Different hypervisors mean different ways of control
    • Update of hypervisor means changed API, changed 'best practices'
    • You don't want to chase changing hypervisor rather than focus on what's important for your application
  • Solution? Libvirt
  • Describe features from user's perspective, internals are boring

* - how I usually do it

Google Summer of Code

  • Annual program held by Google
  • Students work on Open Source and get stipends from Google
  • OSS contributors guide students

  • win-win:
    • Students get real development experience
    • OSS projects can gain new contributors, new code
    • Free T shirt for everybody involved

Google Summer of Code

  • OSS projects fill out application form (with list of ideas included)
  • Google announces participating OSS projects (organizations) for given year

 

  • Students apply for project ideas
  • Orgs chose students
  • Google allocates slots (# funded students) per orgs
  • Orgs adjust their student selection

 

  • Students work / code, mentors from orgs guide them
  • Students & mentors fill out mid-term & final evaluations

 

  • Pencils down

February

mid-March

June

end of August

Google Summer of Code

Examples of past (successful) ideas:

  • virsh domrename

  • Asynchronous lifecycle events for storage objects

  • virt-admin

  • Rewriting VBox driver

  • virsh domifaddr

  • wireshark dissector for libvirt RPC

Q & A

redhat.com