Skip to content
Adam Spiers edited this page Jan 31, 2013 · 5 revisions

Sprint 0823

Coordination Meetings

Weekly Design Review Meeting

Tuesday 08/28 @ 10am CDT. Recording: http://youtu.be/0rJuWBe9HfI

Background Information

  • We've merged the Rails3andDB branch intro trunk. Please do your development there
    • The tree does not function because we're still working on the refactoring

Ordering of Roles for Barclamps

  • In Crowbar 1x
    • This is related to work the Inktank is doing on the Ceph barclamps
    • There's a need to create ordering within and between barclamps.
    • This will be updated onto the wiki (on the Create Barclamps page) - https://github.com/crowbar/crowbar/wiki/Barclamp:-create-&-install-steps
    • The order of role application is not controlled
      • run list ordering is not managed
      • original design - give role to node and that was enough
      • now it looks like you have multiple roles per node and that is not protected.
      • this does need to be addressed - will be a challenge for Ceph
    • This dialog will continue on the thread
    • There may be a low risk approach for CB1
  • For CB2, is there a way to have more fine grained control in the roles ordering
    • This needs to be addressed in Crowbar 2
    • Question "should the role be orderable outside of it's barclamp"
    • E.g.: if I had a role that represents configurating and another that relies on activating then I need to make sure config is before activation or vice versa. This could be able file permissions - you cannot grant the user permission to files that you just added until the user is configured
    • This type of back and forth is a very common problem in multi-system configuration

API Design

http://crowbar.sync.in/crowbar2API This will be moved into the Dev Guide documentation - do not expect changes from the Etherpad to be updated after a few weeks This is the home: https://github.com/crowbar/barclamp-crowbar/blob/master/crowbar_framework/doc/default/crowbar/devguide/api.md

Notes shifted over to the etherpad for the API

  • Barclamp Action
    • CRUD operations on configurations & instances
    • Command operations to make an instance active
    • Barclamps may have their own verbs
      • e.g.: allocate IP would be a verb against the active network barclamp
      • some see this as a configuration change, others consider it to be a service
    • this "API needs to get out of the way" and let the barclamps do what they do
    • e.g.: network barclamp maintains it own state (like in DB tables just for it)
      • network will not be a simple json
      • instances for the network json have less meaning because the barclamp could model it differently
      • each barclamp may have their own concepts for instances depending on their complexity
    • API will evolve as we create the more complex barclamps

Note: For the latest information on Creating barclamps & Dev documentation, it is going into the Crowbar Docs in the repos: https://github.com/crowbar/barclamp-crowbar/blob/master/crowbar_framework/doc/default/crowbar/devguide

Next Week's Design Topics

  • Core Workflow and Jobs
  • BDD & Testing
  • Testing strategy document

Sprint Coordination

Thursday 08/23 @ 8am CDT. Recording: http://youtu.be/fD58583D5no

Agenda:

  • 25 minutes review
  • 10 minutes process check
  • 25 minutes planning

Participants

Review Items

This sprint we accomplished the following:

  • Proposals -> Barclamp Configurations
  • Jobs system design
  • DevTool changes for multiple repos
  • API documentation stubs
  • Networking objects
  • BDD & Unit testing frameworks (documentation)
  • SUSE bugs reviewed & pulled into Fred and Trunk
  • CMDB integration continues (see sprint 2012-08-16)

Process Items

  • OpenStack members - remember to vote!
  • SUSE showing Bugzilla to Dell team
    • recursive merge of default attributes into nodes role has some problems
    • now using Chef deep merge
    • this is causing issues w/ the ssh keys that don't get fixed until the next chef-client run
    • Dell sees this as intermittent timing issues
    • Adam adding tracking code

Changes to improve process:

  • ramping up for more engagement from SUSE
  • missed getting recording of last design session
    • Simon to corrdinate redundant recordings
  • backlog of design topics... probably a good thing? yes
    • for training related topics are recordings OK....yes
  • code review process? like Gerrit?
    • pull requests as the gate mechanism today (limits Reviews to Dell)
    • this is something that we are working torwards broader reviews
      • we want to make sure that unit tests are a gate
      • ensure that documentation is updated for reviews too!
  • training videos
    • BDD & Unit tests
    • DevTool training w/ new remotes strategy
  • changes to branching
    • we are carrying branches for each product suite
    • we end up doing a lot of pulls just ot change the branch/product management
    • current approach does not scale
    • we spend a lot of time managing submodule & branch sync
    • new plan
      • flatten into a single branch
      • suites would be tracked as a release tree w/ meta data
      • devtool would handle bringing all the parts together
      • new pull requests would be "sane" because we would not have to do all the pulls just to manage submodules
      • it will be easier to pull in small changes in individual barclamps
      • makes it easier to handle barclamps as individual packages
      • reduces devtool complexity by a lot
      • expecting feedback from community during next sprint
    • We need SUSE input on this
      • will help having a SUSE team repository
      • will help having the "endless" merge history on flowing between branches
  • Dell is working on getting access to the IRC channel (not going to be fast)
    • we monitor skype -> send a contact request to "DellCrowbar" using "barclamp" in the request and Rob will add you to the active chat.

Do these meeting times still work? -> This is good.

Planned Items

Fred Items

Design Impacts from planned activities

  • Web-UI needs a async disconnected job system, which will allow Barclamps across the board to push job into a queue to be execute reliably
Clone this wiki locally