Re: Digest for devops-toolchain@googlegroups.com - 4 Messages in 2 Topics
19 views
Skip to first unread message
Guna
Mar 2, 2012, 10:20:29 PM3/2/12
to devops-t...@googlegroups.com
On 2/25/12, devops-t...@googlegroups.com
<devops-t...@googlegroups.com> wrote:
> =============================================================================
> Today's Topic Summary
> =============================================================================
>
> Group: devops-t...@googlegroups.com
> Url: http://groups.google.com/group/devops-toolchain/topics
>
> - Virtual Open Source Build a Cloud Days with DevOps Talk [1 Update]
> http://groups.google.com/group/devops-toolchain/t/3d36cb5908c362f
> - Specification driven provisioning [3 Updates]
> http://groups.google.com/group/devops-toolchain/t/623befb5a0ee5743
>
>
> =============================================================================
> Topic: Virtual Open Source Build a Cloud Days with DevOps Talk
> Url: http://groups.google.com/group/devops-toolchain/t/3d36cb5908c362f
> =============================================================================
>
> ---------- 1 of 1 ----------
> From: "Mark R. Hinkle" <mrhi...@gmail.com>
> Date: Feb 24 08:42PM -0800
> Url: http://groups.google.com/group/devops-toolchain/msg/73c0e5e56caca4e9
>
> I suspect that most of the members of this group might find these
> presentations a little more geared to the DevOps beginner but we do
> have a pretty good DevOps talk planned for the 29th with Cloud/DevOps
> guy John M. Willis from enStratus and a number of the talks cover how
> DevOps should be an essential part of your cloud strategy.
>
> Here's the overview, sign-up link included below:
>
> Next week, on February 28th and 29th, we'll be holding a two day
> online session focusing on the open source technologies you can use to
> build, manage and deploy an open source cloud compute environment as
> well as DevOps presentation on operational methodologies for managing
> "cloudy" infrastructure. The program will feature speakers from
> CloudStack, Citrix, Xen.org, Red Hat, Gluster, PuppetLabs, Opscode,
> Zenoss and enStratus.
>
> Even if you can't attend all the sessions feel free to sign-up and
> we'll make our best effort to get you links to recordings and slide
> decks after the event.
>
> Details for the events
> http://www.cloudstack.org/about-cloudstack/cloudstack-events.html?categoryid=6
>
> Day 1 Agenda
>
> Day 1 of Build an Open Source Cloud Day will focus on the
> infrastructure that compromises an infrastructure-as-a-service (IaaS)
> cloud computing environment. The speakers will outline options for
> virtualization, storage and orchestration that provide the foundation
> for an open source cloud compute environment.
>
> To register for Day 1 of this virtual event you must sign-up via the
> GoToMeeting Registration. (All times are EST).
>
> 10:00 a.m. -11:00 a.m. - Welcome & Introduction to Open Source Cloud
> Computing - Mark Hinkle, Director, Cloud Computing Community,
> CloudStack.org
> 11:00 a.m. - 12:30 p.m. - Cloud Computing with Xen Cloud Platform -
> Todd Deshane, Evangelist , Xen.org
> 1:00 p.m. - 2:00 p.m. - Distributed Pedabyte Scale Cloud Storage with
> Gluster - John Mark Walker, Director of Communities, Red Hat/Gluster
> 2:30 p.m. - 4:00 p.m. - Deploying Infrastructure-as-a-Service with
> CloudStack - David Nalley, Community Manager, CloudStack.org
>
> Day 2 Agenda
>
> Build a Cloud Day 2 will focus on the tools you can use to manage and
> deploy cloud computing infrastructure. Find out how to rapidly
> provision and configure infrastructure using tools that automate your
> management tasks then learn about methodologies for deploying
>
> To register for this live event via the GoToMeeting Registration. (All
> times are EST).
>
> 10:00 a.m.- 11:30 a.m. - Introduction to Puppet, Configuration
> Management and IT Automation Software, Luke Kanies, Founder PuppetLabs
> 11:30 a.m. - 1:00 p.m. - Automating your Cloud Deployments with
> Opscode Chef, Matt Ray, Senior Technical Evangelist, Opscode
> 1:30 p.m. - 3:00 p.m. - Monitoring the Cloud with Zenoss Core, Simon
> Jakesch, Principal Engineer, Zenoss
> 3:00 p.m. - 4:30 p.m. - DevOps Your Competitive Advantage in the
> Cloud, John M. Willis, enStratus
>
>
>
> =============================================================================
> Topic: Specification driven provisioning
> Url: http://groups.google.com/group/devops-toolchain/t/623befb5a0ee5743
> =============================================================================
>
> ---------- 1 of 3 ----------
> From: Anthony Shortland <ant...@controltier.com>
> Date: Feb 21 08:23AM -0800
> Url: http://groups.google.com/group/devops-toolchain/msg/c6bccb59f5ca3d7
>
> Your comment "Our definitions were different from TOSCA's - a service was
> software on board the box" broaches the subject of node/role-centric vs.
> service-centric modeling.
>
> With ControlTier we always modeled applications from the service perspective
> (in your sense), but since then - with Rundeck and the current crop of
> configuration and infrastructure management tools - the world has gone hard
> over to node/role-centric modeling. Perhaps most people always thought that
> way (e.g. the "web box" or the "database server"), and we just failed to
> convince them otherwise!
>
> That said, TOSCA's notion of "node" is more akin to any general resource so
> I believe there's provision for modeling topology at either level.
>
> Beyond that, while it's the least developed part of the specification, the
> Plan section opens the door to specifying *what* is required to deploy and
> manage applications without dictating *how* it is done. Although TOSCA is
> not a framework in itself, it does provide a missing piece to the
> loosely-coupled tool-chain framework puzzle.
>
> Anthony.
>
> On Feb 17, 2012, at 2:01 PM, Ernest Mueller wrote:
>
>
>
> ---------- 2 of 3 ----------
> From: Anthony Shortland <ant...@controltier.com>
> Date: Feb 23 08:25AM -0800
> Url: http://groups.google.com/group/devops-toolchain/msg/6ce6bc2c59870529
>
> Actually I don't think the TOSCA TC is ever going to worry about "code which
> satisfies it" - the point being that the specification is the goal in
> itself.
>
> That said, I couldn't agree more that their work should be informed by
> real-world experience. Those edge-cases'll get you every time!
>
> With that in mind, if you are as interested in this as I am, you could
> consider subscribing to their comment mail group
> (http://lists.oasis-open.org/archives/tosca-comment) as a way to provide
> feedback.
>
> Anthony.
>
> On Feb 22, 2012, at 5:31 PM, Nathaniel Eliot wrote:
>
>
>>>> Better than inventing your own each time, surely? Great way to avoid
>>>> lock-in, perhaps?
>
>>>> Anthony.
>
> Anthony Shortland
> [ Developer | ControlTier Open Source Project | mobile: 650.215.3117 aim:
> anthony....@me.com yahoo: anthony.shortland irc.freenode.net:
> #controltier skype: anthony.shortland ]
>
>
> ---------- 3 of 3 ----------
> From: Lee Hambley <lee.h...@gmail.com>
> Date: Feb 21 04:35PM +0100
> Url: http://groups.google.com/group/devops-toolchain/msg/7ae8f9a862bf7d7
>
> As the Capistrano maintainer (however, not the original author), I'm a
> massive proponent of "doing one thing and doing it right", therefore
> toolkits which provision, and deploy make me disappointed that after years
> of having the internet we haven't learned these lessons yet. Although I
> acknowledge in a modern web application stack the line between application
> and infrastructure is blurry.
>
> Heroku have made an art of this for Ruby (and recently other languages)
> by trivializing deployment to a few knobs and dials, and pushing code via
> Git. Their model works exceptionally well, although it is prohibitively
> expensive.
>
> For me the notion that "app is not infrastucture" boils down to not
> trusting the tools, as a software-focused jack-of-trades, the ops side
> still feels like a dark art at times, and the idea that I'd "upgrade" my
> "application" dependency via Puppet or Chef, the same way as one might
> upgrade postgresql or something worries me a little, and
> whilst continuously deploying the app makes sense (unit tests, integration
> tests) but continuously deploying /infrastructure/ is another level for me,
> and a level with which I am not personally comfortable.
>
> I hope that these tools continue to specialize, or else people package
> their applications as .deb, or whatever package the tool is expecting,
> that's to say, if you want to treat your application as a infrastructure
> component, engineer and distribute it as such, and use your choice of
> Chef/Puppet as sugar on top of using apt/emerge/etc to pull the latest copy
> down onto the servers in your cluster.
>
> Just my not very helpful .2¢
>
> Lee Hambley
>
>
>
>
>
>
<devops-t...@googlegroups.com> wrote:
> =============================================================================
> Today's Topic Summary
> =============================================================================
>
> Group: devops-t...@googlegroups.com
> Url: http://groups.google.com/group/devops-toolchain/topics
>
> - Virtual Open Source Build a Cloud Days with DevOps Talk [1 Update]
> http://groups.google.com/group/devops-toolchain/t/3d36cb5908c362f
> - Specification driven provisioning [3 Updates]
> http://groups.google.com/group/devops-toolchain/t/623befb5a0ee5743
>
>
> =============================================================================
> Topic: Virtual Open Source Build a Cloud Days with DevOps Talk
> Url: http://groups.google.com/group/devops-toolchain/t/3d36cb5908c362f
> =============================================================================
>
> ---------- 1 of 1 ----------
> From: "Mark R. Hinkle" <mrhi...@gmail.com>
> Date: Feb 24 08:42PM -0800
> Url: http://groups.google.com/group/devops-toolchain/msg/73c0e5e56caca4e9
>
> I suspect that most of the members of this group might find these
> presentations a little more geared to the DevOps beginner but we do
> have a pretty good DevOps talk planned for the 29th with Cloud/DevOps
> guy John M. Willis from enStratus and a number of the talks cover how
> DevOps should be an essential part of your cloud strategy.
>
> Here's the overview, sign-up link included below:
>
> Next week, on February 28th and 29th, we'll be holding a two day
> online session focusing on the open source technologies you can use to
> build, manage and deploy an open source cloud compute environment as
> well as DevOps presentation on operational methodologies for managing
> "cloudy" infrastructure. The program will feature speakers from
> CloudStack, Citrix, Xen.org, Red Hat, Gluster, PuppetLabs, Opscode,
> Zenoss and enStratus.
>
> Even if you can't attend all the sessions feel free to sign-up and
> we'll make our best effort to get you links to recordings and slide
> decks after the event.
>
> Details for the events
> http://www.cloudstack.org/about-cloudstack/cloudstack-events.html?categoryid=6
>
> Day 1 Agenda
>
> Day 1 of Build an Open Source Cloud Day will focus on the
> infrastructure that compromises an infrastructure-as-a-service (IaaS)
> cloud computing environment. The speakers will outline options for
> virtualization, storage and orchestration that provide the foundation
> for an open source cloud compute environment.
>
> To register for Day 1 of this virtual event you must sign-up via the
> GoToMeeting Registration. (All times are EST).
>
> 10:00 a.m. -11:00 a.m. - Welcome & Introduction to Open Source Cloud
> Computing - Mark Hinkle, Director, Cloud Computing Community,
> CloudStack.org
> 11:00 a.m. - 12:30 p.m. - Cloud Computing with Xen Cloud Platform -
> Todd Deshane, Evangelist , Xen.org
> 1:00 p.m. - 2:00 p.m. - Distributed Pedabyte Scale Cloud Storage with
> Gluster - John Mark Walker, Director of Communities, Red Hat/Gluster
> 2:30 p.m. - 4:00 p.m. - Deploying Infrastructure-as-a-Service with
> CloudStack - David Nalley, Community Manager, CloudStack.org
>
> Day 2 Agenda
>
> Build a Cloud Day 2 will focus on the tools you can use to manage and
> deploy cloud computing infrastructure. Find out how to rapidly
> provision and configure infrastructure using tools that automate your
> management tasks then learn about methodologies for deploying
>
> To register for this live event via the GoToMeeting Registration. (All
> times are EST).
>
> 10:00 a.m.- 11:30 a.m. - Introduction to Puppet, Configuration
> Management and IT Automation Software, Luke Kanies, Founder PuppetLabs
> 11:30 a.m. - 1:00 p.m. - Automating your Cloud Deployments with
> Opscode Chef, Matt Ray, Senior Technical Evangelist, Opscode
> 1:30 p.m. - 3:00 p.m. - Monitoring the Cloud with Zenoss Core, Simon
> Jakesch, Principal Engineer, Zenoss
> 3:00 p.m. - 4:30 p.m. - DevOps Your Competitive Advantage in the
> Cloud, John M. Willis, enStratus
>
>
>
> =============================================================================
> Topic: Specification driven provisioning
> Url: http://groups.google.com/group/devops-toolchain/t/623befb5a0ee5743
> =============================================================================
>
> ---------- 1 of 3 ----------
> From: Anthony Shortland <ant...@controltier.com>
> Date: Feb 21 08:23AM -0800
> Url: http://groups.google.com/group/devops-toolchain/msg/c6bccb59f5ca3d7
>
> Your comment "Our definitions were different from TOSCA's - a service was
> software on board the box" broaches the subject of node/role-centric vs.
> service-centric modeling.
>
> With ControlTier we always modeled applications from the service perspective
> (in your sense), but since then - with Rundeck and the current crop of
> configuration and infrastructure management tools - the world has gone hard
> over to node/role-centric modeling. Perhaps most people always thought that
> way (e.g. the "web box" or the "database server"), and we just failed to
> convince them otherwise!
>
> That said, TOSCA's notion of "node" is more akin to any general resource so
> I believe there's provision for modeling topology at either level.
>
> Beyond that, while it's the least developed part of the specification, the
> Plan section opens the door to specifying *what* is required to deploy and
> manage applications without dictating *how* it is done. Although TOSCA is
> not a framework in itself, it does provide a missing piece to the
> loosely-coupled tool-chain framework puzzle.
>
> Anthony.
>
> On Feb 17, 2012, at 2:01 PM, Ernest Mueller wrote:
>
>
>
> ---------- 2 of 3 ----------
> From: Anthony Shortland <ant...@controltier.com>
> Date: Feb 23 08:25AM -0800
> Url: http://groups.google.com/group/devops-toolchain/msg/6ce6bc2c59870529
>
> Actually I don't think the TOSCA TC is ever going to worry about "code which
> satisfies it" - the point being that the specification is the goal in
> itself.
>
> That said, I couldn't agree more that their work should be informed by
> real-world experience. Those edge-cases'll get you every time!
>
> With that in mind, if you are as interested in this as I am, you could
> consider subscribing to their comment mail group
> (http://lists.oasis-open.org/archives/tosca-comment) as a way to provide
> feedback.
>
> Anthony.
>
> On Feb 22, 2012, at 5:31 PM, Nathaniel Eliot wrote:
>
>
>>>> Better than inventing your own each time, surely? Great way to avoid
>>>> lock-in, perhaps?
>
>>>> Anthony.
>
> Anthony Shortland
> [ Developer | ControlTier Open Source Project | mobile: 650.215.3117 aim:
> anthony....@me.com yahoo: anthony.shortland irc.freenode.net:
> #controltier skype: anthony.shortland ]
>
>
> ---------- 3 of 3 ----------
> From: Lee Hambley <lee.h...@gmail.com>
> Date: Feb 21 04:35PM +0100
> Url: http://groups.google.com/group/devops-toolchain/msg/7ae8f9a862bf7d7
>
> As the Capistrano maintainer (however, not the original author), I'm a
> massive proponent of "doing one thing and doing it right", therefore
> toolkits which provision, and deploy make me disappointed that after years
> of having the internet we haven't learned these lessons yet. Although I
> acknowledge in a modern web application stack the line between application
> and infrastructure is blurry.
>
> Heroku have made an art of this for Ruby (and recently other languages)
> by trivializing deployment to a few knobs and dials, and pushing code via
> Git. Their model works exceptionally well, although it is prohibitively
> expensive.
>
> For me the notion that "app is not infrastucture" boils down to not
> trusting the tools, as a software-focused jack-of-trades, the ops side
> still feels like a dark art at times, and the idea that I'd "upgrade" my
> "application" dependency via Puppet or Chef, the same way as one might
> upgrade postgresql or something worries me a little, and
> whilst continuously deploying the app makes sense (unit tests, integration
> tests) but continuously deploying /infrastructure/ is another level for me,
> and a level with which I am not personally comfortable.
>
> I hope that these tools continue to specialize, or else people package
> their applications as .deb, or whatever package the tool is expecting,
> that's to say, if you want to treat your application as a infrastructure
> component, engineer and distribute it as such, and use your choice of
> Chef/Puppet as sugar on top of using apt/emerge/etc to pull the latest copy
> down onto the servers in your cluster.
>
> Just my not very helpful .2¢
>
> Lee Hambley
>
>
>
>
>
>
--
Sent from my mobile device
Reply all
Reply to author
Forward
0 new messages