1 / 27

Milestone IV

VMWeb Team Members: Matthew Fusaro , Brendan Heckman, Ryan Mcgivern. Milestone IV. Lets start with a quote ( our contribution to the ‘w’ in CSE 4939W ). “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” – Bill Gates.

dalton
Télécharger la présentation

Milestone IV

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. VMWeb Team Members: Matthew Fusaro, Brendan Heckman, Ryan Mcgivern Milestone IV

  2. Lets start with a quote (our contribution to the ‘w’ in CSE 4939W) “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.” – Bill Gates 3000 lines of code to date! This does not include libraries or generated code. As usual, Mr. Gates forgot to mention anything about usefulness and quality…

  3. Languages in use

  4. Libraries in use • Apache AXIS • VMware vSphere Web Services SDK for Java • Catalyst Web Framework • Connector/J MySQL JDBC • MooTools - A Compact Javascript Framework

  5. ExecutionProcess

  6. Thread Map • Main Thread • Spawn Scheduler • Spawn Job Checker • Scheduler Spawns Worker Threads

  7. Utility functions • Perform various actions on what are called Managed Objects or Managed Entities. • Managed object/entities exist on the server side and are referred to by the client via Managed Object References (MOR). • For our purposes the MOR's will refer to either a virtual machine, a host machine, a resource pool, or a task.

  8. Virtual machine utility functions

  9. Host Utility functions

  10. Resource Pool utility

  11. Interface - DBIx::class review • ORM – Object-Relational Mapping • Creates objects associated with tables in a relational database • Database Model • Creates result class file for each table • Corresponds to row-level data in table • Enable this model in the appropriate controllers • Allows the flow control to query data as necessary • Layer of abstraction – remove DB dependence

  12. Interface - Result sets $c->stash(vms => [$c->model('InventoryDB::VirtualMachine')->all]); my $host = $c->req->arguments->[0]; $c->stash(host => [$c->model('InventoryDB::Host')->search({ host_pk => $host })]); $c->stash(template => 'HostView.tt');

  13. Interface - Restful uri • Suppose VMWeb::Controller::Inventory • With function sub showHost :Local • /inventory/showHost/x/y/z • /inventory/showHost • Calls the relevant function • x,y,z are arguments stored in context ($c)

  14. Some screenshots

  15. Auth module

  16. Dashboard

  17. Inventory menu

  18. Host view

  19. Vm view

  20. Integration Path • End-to-End testing (entire stack functionality) • Front-end perl code monitoring job status • Front-end perl code placing jobs into job db • Front-end perl code pulling result sets from inventory • Have scheduler's worker threads talk to utility functions • Implement job contract inside worker thread.

  21. Dependencies • I must provide data in the database so Ryan can test his result sets • Brendan must provide a job definition contract so I can parse the job from the database and have the worker thread call his functions properly. • Brendan must also send task objects back so the worker threads can monitor completion status and progress. • I must provide Ryan with a table that has currently running and recently executed jobs. I must also clear this table so the interface doesn’t have to. (A read-only set of tables dramatically reduces the chances of SQL injection)

  22. risks • Database concurrency. We are still working on a way to remove entities that no longer exist on the ESX server without truncating the whole table and refilling it. • Foreign Key dependencies MUST BE SPOT ON and update correctly.

  23. A note on scaling • Why are we making this so complicated? • While we are writing this for only one ESX host, this framework will take about 1 to 2 weeks of coding to manage a datacenter of hosts and a large amount of VMs on the order of 500-1000 depending on hardware. • Who would use this? • Cloud providers, universities, and large datacenters • Role based access is a highly desired feature.

  24. Okay, we’re done. Questions or Comments?

More Related