OpenStack - User contributions [en]

Nova/ScalableSchedulerSpec

2013-11-18T14:37:31Z

Soren: Add scalable scheduler spec

= Horizontally Scalable (O(1)) scheduler =
== Summary ==
Add a massively scalable scheduler to Nova. By massively scalable, we mean "Schedulding a new instance on a hundred thousand node deployment with millions of current and past instances should not take more than a second."

Blueprint: https://blueprints.launchpad.net/nova/+spec/horizontally-scalable-scheduling
== Rationale ==
The existing scheduler implementations allocate resources on what is currently considered the optimal location for the given resource. Not only is this a costly process, since the data set to be evaluated is potentially very, very large, but since the workloads across the cloud is highly variable and entirely non-deterministic, the designated optimal location may soon be a below average location for the resource. This spec outlines an alternative approach that simply puts resources whereever they'll fit with no attempt to make a centralised decision about anything at all. The end result is an O(1) scheduler.

== User Stories ==
# Soren has a cloud with tens of thousands of nodes with scores of VM's on each. He's fed up with how long it takes to schedule new instances.

== Design ==

Incoming resource requests are validated (sanity checks, quota checks, etc.) as per usual. After this, they're sent to a scheduler that simply puts it on a queue. Nodes poll this queue for work items if they have spare capacity.

== Implementation ==

For simplicity, the first iteration simply adds a new scheduler class, so we keep nova-scheduler around even though it's of very little use, since nova-api might as well stick things directly onto the queue.

The new scheduler class will send out the scheduling request on the message queue using fanout.

Any compute node that has capacity to spare will listen on this topic. The messaging layer will "at random" distribute the request to a listening compute node. The compute node will ensure that it can actually accomodate the instance (based on the instance type) and raise an exception if it does not have sufficient capacity after all. This will cause the message to be requeued (if using the kombu messaging driver) and another node can attempt to fulfill the
request. If it does have capacity, it will go ahead with the allocation as usual.

The next iteration will add per-instance-type topics. Nodes only subscribe to topics for instance types that they can actually accommodate.

The next iteration will remove the scheduler entirely and make nova-api put resource requests directly on the work queue.

The final iteration (which depends on Marconi being ready for production) will use Marconi as the queueing backend. (This may or may not come for free depending on whether a Marconi RPC backend gets added to the RPC layer).

Design Summit/Icehouse/Etherpads

2013-11-07T06:43:02Z

Soren:

[[Category:Summit]]
[[Category:Icehouse]]
[[Category:Etherpad]]

A list of etherpads for the various tracks over days. For the convenience of everyone, please organize this page by Topic, and put the etherpads for each project in chronological order over the course of their track.

== Devstack ==
=== Tuesday ===
* 11:15 - [https://etherpad.openstack.org/p/icehouse-summit-devstacks-new-bits Devstack's New Bits]
* 12:05 - [https://etherpad.openstack.org/p/icehouse-summit-devstack-support Defining Supported Distros / Projects]

== QA ==
=== Wednesday ===
* 11:15 - [https://etherpad.openstack.org/p/icehouse-summit-qa-neutron Neutron QA and Testing]
* 12:05 - [https://etherpad.openstack.org/p/icehouse-summit-qa-tempest-policy Tempest Policy in Icehouse]
* 2:00 - [https://etherpad.openstack.org/icehouse-summit-qa-unit-testing Who watches the watchers - aka Tempest Unit Tests]
* 2:50 - [https://etherpad.openstack.org/icehouse-summit-qa-stress-tests Tempest Stress Test - Overview and Outlook]
* 3:40 - [https://etherpad.openstack.org/icehouse-summit-qa-parallel Parallel tempest moving forward]

=== Thursday ===
* 1:50 - [https://etherpad.openstack.org/icehouse-summit-qa-rolling-upgrades Testing Rolling Upgrades]
* 2:40 - [https://etherpad.openstack.org/icehouse-summit-qa-grenade Grenade Update and Futures]
* 3:30 - [https://etherpad.openstack.org/icehouse-summit-qa-multi-node Enablement for multiple nodes test]

=== Friday ===

* 11:00 - [https://etherpad.openstack.org/icehouse-summit-qa-keystone Keystone needs on the QA Pipeline]
* 11:50 - [https://etherpad.openstack.org/icehouse-summit-qa-coverage-tooling Coverage analysis tooling]
* 1:30 - [https://etherpad.openstack.org/icehouse-summit-qa-future-of-scenario-testing Future of Scenario Testing]
* 2:20 - [https://etherpad.openstack.org/icehouse-summit-qa-negative-tests Negative Testing Strategy]
* 3:10 - [https://etherpad.openstack.org/icehouse-summit-qa-gate-debugability Enhancing Debugability in the Gate]

== Nova ==
=== Tuesday ===
* 11:15 - [https://etherpad.openstack.org/p/IcehouseConductorTasksNextSteps Conductor Tasks Next Steps]
* 12:05 - [https://etherpad.openstack.org/p/IcehouseTaskAPI Instance tasks in API]
* 2:00 - [https://etherpad.openstack.org/p/NovaIcehouseSummitUnconference Nova Un-conference]
* 2:50 - [https://etherpad.openstack.org/p/icehouse-summit-live-snapshot Nova live-snapshot feature]
* 3:40 - [https://etherpad.openstack.org/p/IcehouseNovaPrestartServers Improve VM boot times, by pre-starting VMs]
* 4:40 - [https://etherpad.openstack.org/p/NovaIcehousePclouds Implementing Private clouds on Nova via aggregates]
* 5:30 - [https://etherpad.openstack.org/p/icehouse_flavor_level_capabilities Flavor level capabilities]

=== Wednesday ===
* 11:15 - [https://etherpad.openstack.org/p/NovaIcehouseProjectStructureAndProcess Nova Project Structure and Process]
* 12:05 - [https://etherpad.openstack.org/p/RethinkingSchedulerDesign Rethinking scheduler design]
* 2:00 - [https://etherpad.openstack.org/p/NovaIcehouseSummitUnconference Nova Un-conference (Wednesday)]
* 2:50 - [https://etherpad.openstack.org/p/NovaIcehouse-Smart-Resource-Placement Smart Resource Placement]
* 3:40 - [https://etherpad.openstack.org/p/IcehouseNovaExtensibleSchedulerMetrics Extensible Scheduler Metrics]
* 4:40 - [https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API Instance Group Model and API Extension]
* 5:30 - [https://etherpad.openstack.org/p/icehouse_plugable_api Adding plugability at the API layer]

=== Thursday ===
* 9:00 - [https://etherpad.openstack.org/p/_PCI_Passthrough___the_next_step PCI Passthrough : the next step]
* 9:50 - [https://etherpad.openstack.org/p/NovaIcehouseSummitUpgrades The road to live upgrades]
* 11:00 - [https://etherpad.openstack.org/p/NovaIcehouseSummitObjects Nova Objects update and plans forward]
* 11:50 - [https://etherpad.openstack.org/IcehouseNovaMetadataService Metadata Service Enhancements: Callbacks + Network]
* 1:50 - [https://etherpad.openstack.org/p/NovaIcehouseSummitUnconference Nova Un-conference (Thursday)]
* 2:40 - [https://etherpad.openstack.org/p/nova-horizontally-scalable-db Horizontally scalable db backend]
* 3:30 - [https://etherpad.openstack.org/icehouse-summit-nova-v3-api Nova V3 API]
* 4:30 - [https://etherpad.openstack.org/icehouse-summit-nova-pecan-wsme Pecan/WSME for the Nova V3 API]
* 5:20 - [https://etherpad.openstack.org/icehouse-summit-nova-cross-project-request-ids Cross project Request Ids]

=== Friday ===
* 9:00 - [https://etherpad.openstack.org/p/T4tQMQf5uS VMWare Driver Roadmap For Icehouse]
* 9:50 - libvirt driver roadmap
* 11:00 - [https://etherpad.openstack.org/p/docker-nova-hkg Docker support in OpenStack]
* 11:50 - [https://etherpad.openstack.org/p/IcehouseXenAPIRoadmap XenAPI Roadmap for Icehouse]
* 1:30 - [https://etherpad.openstack.org/p/NovaIcehouseSummitUnconference Nova Un-conference (Friday)]
* 2:20 - [https://etherpad.openstack.org/p/NovaIcehouseDB Work on the DB in Icehouse]
* 3:10 - AWS compatibility perspective back into OpenStack
* 4:10 - Hyper-V: Icehouse features

== Keystone ==
=== Tuesday ===
* 2:40 - [https://etherpad.openstack.org/p/icehouse-keystone-internal-apis API Deprecation and Extensions]
* 5:30 - [https://etherpad.openstack.org/p/icehouse-assignments Refactoring Assignments]
=== Wednesday ===
* 4:40 - [https://etherpad.openstack.org/p/icehouse-python-keystoneclient python-keystoneclient: APIClient & auth_plugins]
* 5:30 - [https://etherpad.openstack.org/p/icehouse-python-keystoneclient python-keystoneclient: middleware & caching]
=== Thursday ===
* 4:30 - [https://etherpad.openstack.org/p/icehouse-federation Federated Identity]
* 5:20 - [https://etherpad.openstack.org/p/icehouse-federation Federated Identity (Cont.)]

=== Friday ===
* 1:30 - [https://etherpad.openstack.org/p/icehouse-token-revocation Token revocation]
* 2:20 - [https://etherpad.openstack.org/p/icehouse-delegation OAuth, Trusts and Delegation]
* 3:10 - [https://etherpad.openstack.org/p/icehouse-auditing Auditing AuthN, AuthZ and Policy Decisions]

== Oslo ==
=== Tuesday ===
* 14:00 [https://etherpad.openstack.org/p/icehouse-oslo-pecan-wsme-tips Creating REST services with Pecan/WSME]
* 14:50 [https://etherpad.openstack.org/p/icehouse-oslo-openstack-client-update OpenStack Client Update]
* 15:40 [https://etherpad.openstack.org/p/icehouse-oslo-hacking-updates Updates to hacking, our code style enforcement tool]

=== Wednesday ===
* 11.15 [https://etherpad.openstack.org/p/icehouse-oslo-i18n-policies I18n policies of messages]
* 12:05 [https://etherpad.openstack.org/p/IcehouseOsloMessaging oslo.messaging - API design, plans for Icehouse]
* 14:00 [https://etherpad.openstack.org/p/icehouse-oslo-config-import-side-effects oslo.config enhancements, including removing import side-effects from consumers]
* 14:50 [https://etherpad.openstack.org/p/icehouse-oslo-rootwrap Rootwrap: Icehouse plans]
* 15:40 [https://etherpad.openstack.org/p/icehouse-oslo-db-migrations State of affairs in DB schema migrations]

=== Thursday ===
* 11:00 [https://etherpad.openstack.org/p/icehouse-oslo-structured-notifications Towards more structured & qualified notifications]
* 11:50 [https://etherpad.openstack.org/p/icehouse-oslo-logging-and-notifications Merge logging and notifications]

=== Friday ===
* 09:50 [https://etherpad.openstack.org/p/icehouse-oslo-service-synchronization Writing a service synchronisation library]
* 11:00 [https://etherpad.openstack.org/p/icehouse-oslo-status Oslo incubated libraries status]
* 11:50 [https://etherpad.openstack.org/p/icehouse-oslo-splitting-the-incubator Aggressively split oslo-incubator]

== Ironic ==
=== Thursday ===
* 1:50 [https://etherpad.openstack.org/p/IcehouseIronicNodeCommunication Hardware Management Ramdisk]
* 2:40 [https://etherpad.openstack.org/p/IcehouseIronicFirmwareUpdate Firmware Updates]
* 3:30 [https://etherpad.openstack.org/p/IcehouseIronicVolumes Disk and Volume Management]
* 4:30 [https://etherpad.openstack.org/p/IcehouseIronicFaultTolerance Making Ironic Resilient to Failures]
* 5:20 [http://etherpad.openstack.org/IcehouseIronicNextSteps Ironic's Next Steps]

== Marconi ==

=== Friday ===
* 09:00 [https://etherpad.openstack.org/p/IcehouseMarconiFeaturesAPIChanges Proposed Features and API Changes]
* 09:50 [https://etherpad.openstack.org/p/IcehouseMarconiNotificationService Notification Service Extensions for Marconi]
* 11:00 [https://etherpad.openstack.org/p/IcehouseMarconiAMQPSupport AMQP and SQL backends]
* 11:50 [https://etherpad.openstack.org/p/IcehouseMarconiInOut Marconi for Icehouse: What's in, What's out]

== Cinder ==

=== Thursday ===
* 13:50 [https://etherpad.openstack.org/p/icehouse-cinder-continuous-deployment Changing the wheels on a moving bus]
* 14:40 [https://etherpad.openstack.org/p/icehouse-cinder-incremental-backup-api Incremental Volume backup API]
* 15:30 [https://etherpad.openstack.org/p/icehouse-cinder-more-flexible-scheduler-policies More flexible scheduler policies]
* 16:30 [https://etherpad.openstack.org/p/icehouse-cinder-read-only-api-role Read Only API Role for Cinder]
* 17:20 [https://etherpad.openstack.org/p/icehouse-cinder-continuous-volume-replication Continuous volume replication]

=== Friday ===
* 11:00 [https://etherpad.openstack.org/p/icehouse-cinder-taskflow-next-steps What's next for taskflow in Cinder]
* 11:50 [https://etherpad.openstack.org/p/icehouse-cinder-exceptions-and-rescheduling Exception clarity and how rescheduling affects you]
* 13:30 [https://etherpad.openstack.org/p/icehouse-cinder-vendor-neutral-extraspecs Vendor neutral extra-specs]
* 14:20 [https://etherpad.openstack.org/p/icehouse-cinder-acls-for-volumes Access Control List Rules for Cinder Volumes]
* 15:10 [https://etherpad.openstack.org/p/icehouse-cinder-active-active-vmanagers Active/Active HA Volume managers]
* 16:10 [https://etherpad.openstack.org/p/icehouse-cinder-volume-import Volume Import]
* 17:00 [https://etherpad.openstack.org/p/icehouse-cinder-improving-api-rate-limiting Richer API rate limits in Cinder]

== Neutron ==

=== Tuesday ===
* 12:05pm [https://etherpad.openstack.org/p/icehouse-neutron-nova-parity Achieving Parity with Nova Networking]
* 2:00pm [https://etherpad.openstack.org/icehouse-neutron-fwaas Neutron Firewall as a Service (FWaaS)]
* 2:50pm [https://etherpad.openstack.org/p/NeutronVPNaaSIceHouse Neutron VPNaaS in IceHouse]
* 3:40pm [https://etherpad.openstack.org/p/NeutronAPI Neutron API Framework Replacement]
* 4.30 [https://etherpad.openstack.org/p/NeutronServiceVM Service VM Framework]
* 5:20 [https://etherpad.openstack.org/p/icehouse-neutron-vendor-extension API Extensions for Drivers]

=== Wednesday ===
* 11:15 - [https://etherpad.openstack.org/p/icehouse-summit-qa-neutron Neutron QA and Testing]
* 12:04 - [https://etherpad.openstack.org/p/icehouse-neutron-lbaas Neutron Loadbalancing service (LBaaS)]
* 2:00pm [https://etherpad.openstack.org/p/NeutronSwitchPortExtension Neutron Switch Port Extension]
* 2:50pm [https://etherpad.openstack.org/p/icehouse-summit-neutron-pain-points Neutron Pain Points]
* 3:40pm [https://etherpad.openstack.org/p/Neutron-Advanced-L3 Neutron Advanced L3 features]
* 4:40pm [https://etherpad.openstack.org/p/ML2_Extensibility Extensibility of ML2]
* 5:30pm [https://etherpad.openstack.org/p/neutron-qos-hk ML2 QoS] and [https://etherpad.openstack.org/p/ML2_Deprecated_Plugin_Migration Deprecated Plugin Migration]

=== Friday ===
* 9:50am [https://etherpad.openstack.org/p/Distributed-Virtual-Router Distributed Virtual Router]
* 11:50am [https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining Neutron Service Chaining and Insertion]
* 1:30pm [https://etherpad.openstack.org/p/Plugin_or_MechanismDriver Plugin or MechanismDriver?] and [https://etherpad.openstack.org/p/ModularAgent Modular Agent]
* 2:20pm [https://etherpad.openstack.org/icehouse-neutron-l3-agent-improvements Neutron L3 Agent improvements]
* 3:10pm [https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron Group Based Policy Abstraction for Neutron]
* 4:10pm [https://etherpad.openstack.org/p/improving_provider_api Improving the Provider API for Neutron]

== Savanna ==

=== Friday ===

* 1:30 [https://etherpad.openstack.org/p/savanna-icehouse-networking Networking and installation topologies]
* 2:20 [https://etherpad.openstack.org/p/savanna-icehouse-architecture Heat integration and scalability]
* 3:10 [https://etherpad.openstack.org/p/savanna-icehouse-integration Further OpenStack integration]
* 4:10 [https://etherpad.openstack.org/p/savanna-icehouse-roadmap Savanna in Icehouse]

== Documentation ==

=== Tuesday ===

* 12:05 [https://etherpad.openstack.org/p/icehouse-doc-automation Automated Doc Tooling - status & plans]
* 14:00 [https://etherpad.openstack.org/p/icehouse-doc-restructure Status and future of the restructure]
* 14:50 [https://etherpad.openstack.org/p/icehouse-doc-app-devs Documenting Application Developer Resources]
* 15:40 [https://etherpad.openstack.org/p/icehouse-doc-translation Publishing translated documentation]

=== Friday ===

* 09:00 [https://etherpad.openstack.org/p/icehouse-api-doc-repos API documentation repos]

== Glance ==

=== Tuesday ===

* 2:00 [https://etherpad.openstack.org/p/icehouse-summit-image-state-consistency Image state consistency between Glance and Nova]
* 2:50 [https://etherpad.openstack.org/p/icehouse-summit-images-v1-api What should happen to the v1 images api?]
* 3:40 [https://etherpad.openstack.org/p/icehouse-summit-enhance-v2-image-sharing Enhance v2 Image Sharing]
* 4:40 [https://etherpad.openstack.org/p/icehouse-summit-enhance-image-location-property Enhance image location property]
* 5:30 [https://etherpad.openstack.org/p/icehouse-summit-taskflow-and-glance Breaking ground with taskflow and glance]

== Trove ==

=== Wednesday ===

* 2:00 - 2:40 [https://etherpad.openstack.org/p/TroveTempestTesting Moving Trove integration tests to Tempest]
* 2:50 - 3:30 [https://etherpad.openstack.org/p/TroveHeatSupport Trove Current Heat Integration]
* 3:40 - 4:20 [https://etherpad.openstack.org/p/TroveReplicationClustering Trove Datastore Clustering]
* 4:40 - 5:20 [https://etherpad.openstack.org/p/TroveUpgradesNoDowntime Zero Downtime Trove Upgrades]
* 5:30 - 6:10 [https://etherpad.openstack.org/p/TroveGuestAgents Guest Agents in Trove]

== TripleO (Deployment) ==

=== Tuesday ===

* 11:15 - 11:55 [https://etherpad.openstack.org/p/tripleo-icehouse-scaling-design icehouse-scaling design] [https://etherpad.openstack.org/p/tripleo-deployment-scaling-topologies Deployment scaling/topologies]
* 12:05 - 12:45 [https://etherpad.openstack.org/p/tripleo-icehouse-ha-production-configuration HA/production configuration]
* 2:00 - 2:40 [https://etherpad.openstack.org/p/icehouse-updates-stablebranches stable branch support and updates futures]
* 2:50 - 3:30 [https://etherpad.openstack.org/p/icehouse-tripleo-deployment-ci-and-cd-automation CI and CD automation]
* 3:40 - 4:20 Futures:
** [https://etherpad.openstack.org/p/icehouse-modelling-infrastructure-sla-services network/discovery/topology modelling]
** [https://etherpad.openstack.org/p/icehouse-deployment-hardware-autodiscovery hardware autodiscovery]
** [https://etherpad.openstack.org/p/icehouse-deployment-network-infrastructure TripleO for network hardware deployment]

== Infrastructure ==

=== Tuesday ===
* 4:40 - [https://etherpad.openstack.org/p/icehouse-summit-storyboard-basic-concepts-and-next Storyboard - Basic concepts and next steps]
* 5:30 - [https://etherpad.openstack.org/p/icehouse-summit-external-replications-and-hooks External replications and hooks]

=== Wednesday ===
* 4:40 - [https://etherpad.openstack.org/p/icehouse-summit-zuul-job-runners-and-log Zuul job runners and log management]
* 5:30 - [https://etherpad.openstack.org/p/icehouse-summit-more-salt-in-infra More Salt in Infra]

=== Thursday ===
* 11:00 - [https://etherpad.openstack.org/p/icehouse-summit-translation-tools-and-scripts Translation tools and scripts]
* 11:50 - [https://etherpad.openstack.org/p/icehouse-summit-elastic-recheck elastic-recheck]
* 4:30 - [https://etherpad.openstack.org/p/icehouse-summit-requirements-project-redux Requirements project redux]
* 5:20 - [https://etherpad.openstack.org/p/icehouse-summit-preemptively-integrate-the Preemptively Integrate the Universe]

== Horizon ==
=== Tuesday ===
* 11:15 - [https://etherpad.openstack.org/p/Separate-Horizon-and-OpenStack-Dashboard Separate Horizon and OpenStack Dashboard]
*12:05 - [https://etherpad.openstack.org/p/icehouse-summit-Getting-Our-Heads-Around-IA Getting Our Heads Around IA]

=== Wednesday ===
* 11:15 - [https://etherpad.openstack.org/p/icehouse-summit-scaling-horizon Scaling Horizon]
* 12:05 - [https://etherpad.openstack.org/p/icehouse-summit-Automated-Dashboard-Generation Automated Dashboard Generation]

=== Thursday ===
* 9:00 - [https://etherpad.openstack.org/p/icehouse-summit-Integration-Testing-for-Horizon Integration Testing for Horizon]
* 9:50 - [https://etherpad.openstack.org/p/openstack-dashboard-to-cfg-hardware Openstack dashboard to configure hardware]
* 11:00 - [https://etherpad.openstack.org/p/UX-and-Future-Direction-of-OpenStack_Dashboard UX and Future Direction of OpenStack Dashboard]
* 11:50 - [https://etherpad.openstack.org/p/icehouse-summit-Plugin-architecture-for-Horizon Plugin architecture for Horizon]

== Release Management ==

=== Thursday ===
* 9:00 [https://etherpad.openstack.org/p/IcehouseVMT Icehouse Vulnerability Management]
* 9:50 [https://etherpad.openstack.org/p/stable-havana-ideas Stable branch maintenance]

=== Friday ===
* 9:00 [https://etherpad.openstack.org/p/IcehousePypyPy3 Python3 and Pypy support]
* 9:50 [https://etherpad.openstack.org/p/IcehouseReleaseArtifacts Release artifact management]
* 4:10 [https://etherpad.openstack.org/p/IcehouseReleaseSchedule Icehouse release schedule & coordination]
* 5:00 [https://etherpad.openstack.org/p/IcehouseFutureDesignSummits The future of Design Summits]

== Ceilometer ==
=== Tuesday ===
* 16:40 [https://etherpad.openstack.org/p/icehouse-summit-ceilometer-central-agent improvement of central agent]
* 17:30 [https://etherpad.openstack.org/p/icehouse-summit-ceilometer-hardware-sensors Expose hardware sensor (IPMI) data]

=== Wednesday ===
* 11:15 [https://etherpad.openstack.org/p/icehouse-summit-ceilometer-big-data Big Data]
* 12:05 [https://etherpad.openstack.org/p/icehouse-summit-ceilometer-paas-collection PaaS usage collection]
* 14:00 [https://etherpad.openstack.org/p/icehouse-summit-ceilometer-stats-filtering Extended stats filtering]
* 14:50 [https://etherpad.openstack.org/p/icehouse-summit-ceilometer-fully-realize-api A fully-realized query API]
* 15:40 [https://etherpad.openstack.org/p/icehouse-summit-ceilometer-roll-up-of-sample-data Roll-up of sample data]
* 16:40 [https://etherpad.openstack.org/p/icehouse-summit-ceilometer-future-of-alarming Future of alarming]
* 17:30 [https://etherpad.openstack.org/p/icehouse-summit-ceilometer-tighten-model Tighten model]

=== Thursday ===
* 9:00 [https://etherpad.openstack.org/p/icehouse-ceilometer-feature-parity-storage-drivers Feature parity in storage drivers]
* 9:50 [https://etherpad.openstack.org/p/icehouse-summit-ceilometer-integration-tests Ceilometer integration testing]

== Swift ==
=== Thursday ===
* 9:00 Storage Policies (and other things)
* 9:50 [https://etherpad.openstack.org/p/icehouse-swift-profiling-middleware-and-tools Swift Profiling Middleware and Tools]
* 11:00 Swift Drive Workloads and Kinetic Open Storage
* 11:50 Plugging in Backend Swift Services
* 13:50 [https://etherpad.openstack.org/p/swift-kt Swift operation experiences with hot contents]
* 14:40 [https://etherpad.openstack.org/p/swift-for-messenger Supporting a global online messaging service]
* 15:30 [https://etherpad.openstack.org/p/icehouse_swift_robust Making Swift More Robust to Handling Failure]
* 16:30 [https://etherpad.openstack.org/p/icehouse-swift-metadata-search Metadata search]
* 17:20 Why is Swift's replica count configurable?

== Heat ==
=== Thursday ===
* 11:00 [https://etherpad.openstack.org/p/icehouse-summit-heat-hot Heat Software Orchestration]
* 11:50 [https://etherpad.openstack.org/p/icehouse-summit-heat-workflow Heat workflow: consider taskflow, Mistral or other]
* 13:50 [https://etherpad.openstack.org/p/icehouse-summit-heat-autoscaling Autoscaling Design]
* 14:40 [https://etherpad.openstack.org/p/icehouse-summit-heat-abandon-adopt Stack abandon and adopt]
* 15:30 [https://etherpad.openstack.org/p/icehouse-summit-heat-convergence Healing and convergence]
* 16:30 [https://etherpad.openstack.org/p/icehouse-summit-heat-multi-region-cloud Heat support for multi-region and multi-cloud]
* 17:20 [https://etherpad.openstack.org/p/icehouse-summit-heat-placehoder Heat placeholder session]
=== Friday ===
* 9:00 [https://etherpad.openstack.org/p/icehouse-summit-heat-exorcism Heat exorcism]
* 9:50 [https://etherpad.openstack.org/p/icehouse-summit-heat-stack-troubleshooting Stack troubleshooting support]

TripleO/TripleOCloud

2013-10-08T13:10:47Z

Soren: Formatting

= Draft =

This is draft docs about an [http://lists.openstack.org/pipermail/openstack-dev/2013-October/015844.html experiment] we're considering! It describes an intent, not reality.

= Overview =
TripleO developers run a production-ready cloud as part of ensuring they are delivering something usable. We treat this as a production CD environment: Kanban for the folk working on it is at https://trello.com/b/0jIoMrdo/tripleo and https://trello.com/tripleo. We iterate and evolve in response to OpenStack as a whole, while improving the deployment mechanisms and code. '''Note: trello is just -a- kanban to story the operational status: an arbitrary choice to let us experiment with the setup, and subject to change if this works'''

= tripleo-cd-admins team =

Direct access to the hardware needs to be kept to a balanced team : too few and they become a bottleneck, too many and it becomes a security / reliability concern. Any TripleO ATC can apply to be a member, and existing members will vote, with the PTL having a veto (but not an override). The tripleo-cd-admins team will be the determining factor for all access that is equivalent to 'run arbitrary code outside of kvm/Xen'; having this set be decoupled and manually reviewed is part of the security policy on the machines : we can't trivially change it - the machines were provisioned with the expectation of non-HP staff administering them, but that set is expected to be known quantities.

The current list of members is maintained in the incubator tree [http://git.openstack.org/cgit/openstack/tripleo-incubator/tree/tripleo-cloud]. Any TripleO ATC can request access by submitting a review adding themselves, but access won't take effect immediately as nova keypairs are not synced out automatically. '''Only existing tripleo-cd-admins should approve changes to the tripleo-cd-admins list'''

== access rules ==
We expect http://ci.openstack.org/sysadmin.html#ssh-access (or some to be defined subset) to be followed - this is a production, operational environment.

https://docs.google.com/spreadsheet/ccc?key=0AlLkXwa7a4bpdERqN0p5RjNMQUJJeDdhZ05fRVUxUnc&usp=sharing has the undercloud admin credentials; please only use in emergencies - normal operation should use dedicated user codes. Access to the spreadsheet is given when joining the team.

= Workflow =

Basic principles:
* unblock bottlenecks first, then unblock everyone else.
* folk are still self directed - it's open source - but clear
visibility of work needed and it's relevance to the product *right
now* is crucial info for people to make good choices. (and similar
Mark McLoughlin was asking about what bugs to work on which is a
symptom of me/us failing to provide clear visibility)
* clear communication about TripleO and plans / strategy and priority
(Datacentre ops? Continuous deployment story?)

== Reviews are king ==

Since we want to minimise folk with root access to the cluster, we need to ensure that most/all changes can be done entirely via code review or non-root-equivalent APIs. '''latency in review will drive WIP higher'''.

== Roadmap ==

The tripleo roadmap should live in the [https://trello.com/b/LhUMzQeY/roadmap roadmap Kanban] board: it's where new initiatives will be drawn down from. At any point in time there should be just one conceptual goal on the roadmap, at least until we've eliminated stalls and driven inventory down.

== TripleO WIP ==

The current TripleO team (== folk working on TripleO, regardless of organisation) track what is being worked on concurrently in the [https://trello.com/b/0jIoMrdo/tripleo TripleO Kanban] board. The following guidelines will help the team understand what things are progressing and what things are stalled at any point in time:

* any one individual should only ever be working on one card: if one yak shaves, one should clearly show what's being worked on.
* multiple people can be working on the same card: dogpiling and collaboration is fine - and a good thing
* lane priority is right-to-left: moving the cards that are closest to the right side (done) is more useful than moving cards that are further away: the goal is to reduce work in progress and deliver rapidly.
* cards can be any size/scope but the ideal, similar to code review is that they should be a single conceptual goal : there may be multiple steps in a single card.
* Anyone can split/combine cards as needed to make the board communicate our WIP more usefully.

== Bugs ==

TripleO still uses bugs:- issues in the code, and things that users would reasonably like to achieve that involve code changes are best represented as bugs. Kanban cards can and should link to bugs. We don't require a bug for every code change, but if there is a code change that you aren't going to do right now, but which should be captured: a bug is the right place.

'''use bugs for things which need code changes'''.

== Blueprints ==

TripleO still uses blueprints: they are the approval mechanism for new items on the roadmap. Design work for them should still be done in etherpads.

'''use blueprints to get new items into the roadmap'''.

== etherpads ==

TripleO still uses etherpads: they are great for collaborative editing of plans/designs, and tracking work being done on a card in a lightweight accessible fashion.

'''use etherpads for status of and design for cards'''

= Seed VM host =

The seed VM host is a manually installed machine, reachable over ssh. Until we've done an audit for prior data, access to the machine is restricted to HP employees who are TripleO ATC's. (It's also got some weird networking shit, avoid it!)

= Seed =

The seed is a VM provisioned via boot-seed vm on the Seed VM host, reachable over ssh from other machines in the cloud. Access is available to any tripleo-cd-admins member.

= Undercloud =

The API endpoint for the undercloud that deploys the cloud is: https://cd-undercloud.tripleo.org:13000/v2.0. Ssh credentials are available from Robert Collins (and is limited to tripleo-cd-admins).

== API Access ==

API access to the Undercloud is available to tripleo-cd-admins, as API access permits deploying arbitrary code to the physical machines. Credentials are setup when joining tripleo-cd-admins, and removed when leaving the team.

The undercloud can deploy machines to the range 10.10.16.171 10.10.16.188 today (limited due to hardware availability).

== Updates to software ==

We can't deploy the undercloud automatically yet, so it's basically static.

To update e.g. nova:
cd /opt/stack/nova
git review -d <somereviewwitheverythingwewantinit>
/opt/stack/venvs/nova/bin/pip install .
os-collect-config --one --force

== Hardware configuration ==

The machines have 24 cores, 96G of ram and 2x2TB hard disks with a hardware raid controller. There is a 10G mellanox dual-port card as well, which shows up as eth2 - this is the only wired up network port. As far as we can tell the BIOS defaults to not enabling/net-booting the 10G card, so it needs to be both enabled (via pci devices) and have net boot turned on for it in the system BIOS setup.

Note that you'll need to watch it try and boot to get the MAC - assume unenrolled machines have the wrong mac in machine-information-tab.txt. Use 'F12' right after the smart array scrolls by to force a network boot so that you don't have a bad enrollment in nova. The mellanox nic0 address (e.g. 78:e7:d1:03:00:23:94:cd) has the first three and last three octets of the nic1 address, which is the one we want (78:e7:d1:23:94:cd). alternatively configure pxe booting and then watch for dhcp in tcpdump:
'set system1/bootconfig1/bootsource5 bootorder=1'

== Current adhoc variance in the undercloud ==

* Nova is running https://review.openstack.org/#/c/49658/ to let deploys happen
* We are manually running the tripleo-cd logic from the undercloud control plane

= Overcloud =

The overcloud is deployed per commit, and open access is available to any TripleO ATC: they may use the cloud as desired - having users on the cloud helps validate that the cloud is usable! File all bugs on [https://bugs.launchpad.net/tripleo the tripleo bug tracker]. Access may also be granted to non-(TripleO ATC's) at the TripleO PTL's discretion.

== API Access ==

Contact anyone in tripleo-cd-admins for API credentials to the overcloud.

== SSH Access ==

This is granted via membership in tripleo-cd-admins, as bare metal access permits running anything at all in that environment. The technical implementation is that SSH keys are provisioned via the 'admin/default' key-pair in the undercloud (which is manually synced with tripleo-cd-admins).

SorenHansen

2013-09-25T13:43:41Z

Soren: /* Soren Hansen [soren] */

= Soren Hansen [soren] =
; Name
: Soren Hansen
; Affiliations
:* [http://www.ril.com/ Reliance Jio Infocomm, Ltd.]
:* [http://www.ubuntu.com/ Ubuntu]
:* [http://www.linux2go.dk/ Linux2Go]
; Launchpad page
: https://launchpad.net/~soren
; GitHub page
: https://github.com/sorenh

RickClark

2013-09-19T18:28:51Z

Soren: /* Rick Clark [dendrobates / destro] */

== Rick Clark [dendrobates] ==

{{http://www.twistedlincoln.com/downloads/sponsor-logos/RickClarkPhoto.jpeg}}
* VP, Cloud, Reliance Jio Infocomm, Ltd.
Email: <<[[MailTo]](rick AT SPAMFREE openstack DOT org)>>

----
[[Category:Homepage]]