Skip to content

sprint 2012 08 02

Adam Spiers edited this page Feb 1, 2013 · 5 revisions
Clone this wiki locally

Sprint 0802

Objective: Establish process for future sprints

Previous Sprint: sprint 2012-07-26 Following Sprint: sprint 2012-08-09

Coordination Meetings

Weekly Design Review Meeting

Recording: <http://youtu.be/ccxJmkqxFYw>

Networking

We used to leverage the underlying tools in each distro, but this was causing some problems. If it was not perfect, then you would loose nodes. We needed to get rid of the if up and if down. We wanted to be a able to configure the network more reliable and earlier.

Features of the new networking design:

  • simplified coding
  • directly configure the networking files
  • SUSE support is pending because we don't have an internal SUSE build yet (working on that from last meeting)
  • Should be more configurable with we change networking on-the-fly
  • Mostly driving using the IP comment, sys helpers, and bridge helpers. Not using the distro tools, but the underlying Linux tools
  • If we support Windows then this will create a whole new set of issues - we are not trying to address that at this time
  • Some other operating systems will require their own code paths - we are testing on "modern Linux"
  • Question: are we manipulating the init scripts on the network
    • The network config is smart enough to look at live running configuration by running IP or getting it from sys.fs as a source of information
    • This is in a helper class called NIC that knows how to do all this work
  • This has been nearly a complete rewrite from the 1.x code - we chose to hold this for 2.x
  • This change was needed because we were seeing a lot of changes from each distro, this helps make us have a single code base
  • Escallate issues to Victor
    • our testing is highly focused on VLANs, so you may not
    • this should make it easier to use on VMware workstation because of the tagging
  • This work interacts w/ the networking changes
    • there was a conflict between the truth from the node, chef, and crowbar
    • at Crowbar, we can model the netowrking
    • the barclamp code is setup to better respect the type of API CRUD operations that we are moving to with the network model
  • Heart of the change is to allow the interfaces to be more dynamic
    • We try to avoid downing the interface
    • Adding/Removing from a bond is just about the only thing that takes an interface offline
    • old code use to "take a big hammer approach" so the interfaces would go up and down
  • Changes to the model should map to the new code smoothly
    • Models should generate attribute based confiugration that drives the new code
    • New code has the idea of networks as objects and components of objects
    • We should test how the models pass attributes to the recipes
    • We need to have a focused set of attributes that does the configuration because they create API
  • Using networking attributes allows us to have cookbooks (or modules) that use the API to request network configuration
    • this would allow CMDB users to make networking requests in a consistent/generic manner
    • for Chef, that is likely to be a role that has the network attributes
    • we want to provide open source community recipes that are not Crowbar specific that can be used within Crowbar
    • we are trying to create attributes that are not Crowbar specific
      • the conduit mappings are very Crowbar specific - we need to move that logic somewhere else
      • the abstraction will exist, but needs to be in the orchestration piece and out of the network barclamp

> Note: Expect to see a lot of change on the Network Barclamp because that had to be so hard wired to make it work w/ Crowbar

Changing the API URIs DIscussion

Question: should we change the API designation from /1.0/ to /2.0/?

  • For the next sprint, we will change the designator to 2.0.
  • We will give people a 1.0 landing page.
  • We need to keep having the API a first order concern, not just in the UI
  • We MUST NOT have a UI only approach - actions need to be exposed via REST

Pending action: we need a style guide for the 2.0 API

Heterogeneous OS

  • If you put the provisioner into online mode then you can build Crowbar
  • Documetationed: readme heterogeneous os support in the Crowbar source
  • These pieces have been coming in over time
  • There's a role on the node then you can pick the OS and the provisioner will setup that OS
  • OS selection is currently an attribute on the node
  • The deployer and provisioner use this attribute to make these choices
  • Trees are not merged yet - so the models are not there
  • You have to set this attribute before allocation
  • Logic is just added to allow you to know which OSes are available
    • this information is determined provisioner
    • setup base images recipe in the provisioner is responsible for discovering that
    • these get populated on the 1.x Wall
  • In CB2, they become CMDB_Attributes that the provisioner
    • this comes out of the directory trees by discovery
    • right now, code can pick Ubuntu 12.04 and Centos 6.2
    • we don't see a need right now to go backwards for older OS
  • this is for exploration right now
    • current questions about attribute configuration
    • differentiate the issue - how do I take that OS and manage it w/ Crowbar
    • this will create more issues when we have things that are not managed

Merge the Tree?

TIming is still a question.

Please add them to this list if you want to vote...

Next week's design topics 1. Changes from Rails2 to Rails3 1. Object Models 1. Networking 1. Style changes for Barclamp writing - using guidelines for community cookbooks to make upstreamings

Tuesday 8/7 @ 10am CDT. Voice & Screen Share: https://join.me/dellcrowbar

Sprint Coordination

Meeting: Thursday 8/2 @ 8am CDT. Voice & Screen Share: https://join.me/dellcrowbar

Agenda:

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

Participants

The following people are available for development this sprint

  • Dell: Rob @zehicle Hirschfeld, Greg Althaus, Victor Lowther, Andi Abes, Judd Maltin, ...

Review Items

This sprint we accomplished the following:

  • Rails3 & DB work progressing (rail3 branch)
    • Documentation added
    • Scaffold added
  • UEFI is progressing in trunk
    • Canonical bug
    • Pending question on if we have to do this on "Fred" - this may impact the schedule

Process Items

Changes to improve process:

  • Do these meeting times still work?
    • 6:30 pm in India, works ok
    • 6:00 am in Ca is hard
  • Jason plans to have technical people join, thinks this is ok to help keep people area aware

Planned Items

  • Continue on Rails3 merge

    • Merge expected when we have a fully functional UI
    • Ajax commits are needed
    • Potentially something in 8/7 sprint
    • Migrate to use barclamp model
  • UEFI

    • Surya is interested in the UEFI work - has some experience
    • Most of the code is ready, needs to testing
    • We are blocked on the Ubuntu issue, we will escallate the issue w/ 12.04 to ubuntu
      • UEFI code may be more stable in 12.10
      • Easiest fix (for us) for them is to update 12.04 LTS (but this will take a while)
  • Database Changes

    • Core objects- node, barclamp, cmdb, network
    • UI plumbing to move to the new objects
  • BDD UI test system
  • Questions

    • Is there a way to include a kick start in the boot process for the hypervisors? Yes - this is a topic included in the multi-OS topic.
    • Surya was wondering when Ubuntu 12.10 will come into Crowbar
  • Blocks

    • No blocks at this point

This sprint we are expecting to accomplish

  • Continue Rails & DB migration
Something went wrong with that request. Please try again.