I presented on the OCCI and OpenStack implementation that I’ve been working on at the SNIA’s Cloud Plugfest.

Access to the source is coming very very soon and from there we’d like to contribute it to the OpenStack project and maintain it there.

Along with another nice addition (/cough OCCI implementation) to OpenStack, I’ve also been working on the integration of SmartOS on OpenStack with Thijs. Thijs has a revised post of how to get the SmartOS environment up and running. Follow this and once you’ve installed all dependencies the following will have you up and running with nova-compute on a SmartOS machine!

Thijs bet me to the post, pardon the pun!

Next up sorting out rabbitmq and getting down and dirty with nova-compute drivers!

Update: To set the rabbitmq host you’ll need to do it via a flagfile. Also you need to supply location information relating to Glance.

./bin/nova-compute --flagfile=smartos.cfg

smartos.cfg:

In future, large-scale Internet-based service deployments (/cough cloud), the current and contemporary issues beneath it encountered by consumers will and must be tackled.

• Current Internet services are not a “cure-all” and are not fully cognisant of end-user requirements, especially for enterprises and mission critical applications.
• Current Internet services operate on a “best-effort” basis: there is little consideration for quality, e.g. of service, of experience, etc. Indeed in certain parts of a service stack there no comprehension of quality guarantees.
• There are little or no service guarantees to the consumer: if any, they are static, inflexible and not negotiable. Often it is left up to the consumer to implement their own systems to ensure guaranteed service.

To address this, the services must be imbued with the principle of Dependability. Dependability is a set of attributes that a service SHOULD (requirement) exhibit in order to be deemed dependable. It should be noted that only a subset of those attributes MUST be exhibited (Reliability and Availability) as these are quantifiable. The other attributes are somewhat more subjective. For all Internet services to be dependable they will share new common requirements or constraints and as Eames said, “Design depends largely on constraints” and “design is an expression of the purpose”, where the purpose is dependability. To be dependable a service must exhibit/implement the following attributes as defined by an IEEE group,which is the embodiment of 24 years of work in the IEEE:

• Availability: readiness for correct service.
• Reliability: continuity of correct service.
• Safety: absence of catastrophic consequences on the user(s) and the environment.
• Integrity: absence of improper system alteration.
• Maintainability: ability for a process to undergo modifications and repairs.
• Confidentiality: absence of unauthorised disclosure of information.

This taxonomy was formed in 2004, however in the age of the Internet of services, where end-users are service- and not product-oriented, this list needs to be updated to better reflect the need for trustworthiness through such capabilities as service inspection, introspection and ultimately a service-aware Future Internet. For this we propose the additional attribute of Transparency:

• Transparency: the ability to inspect and introspect a service so that the delivered and guaranteed quality of the service agreement can be verified and observed.

This is essential to tackle the issue of lack of trust many enterprises have with placing their workloads on today’s service offerings (be they IaaS, PaaS or SaaS). What these service-oriented customers (e.g. service broker or an end-user) require are all of the above comprised by guarantees that the service provider offers. Service providers may offer and many do today guarantees however currently it is very difficult for the customer to verify these guarantees. It is why the ability to inspect and introspect a service should be offered by the provider, (embodied as transparency) to the customer so that they can indeed validate the guarantee that has been agreed upon between the two parties and compare the agreed versus the observed behaviours of a service. This would avoid such cases where a curious consumer suddenly realises they’re not getting what they paid for. It is also recognised by the UK that such needs should be satisfied especially in the areas of converged Future Internet services.

Footnote: Oh yea, OCCI and cloud interoperability do fit into this picture…