Re: [openstack-dev] [TripleO] [app-catalog] TripleO, Advanced Services, and the App Catalog
On Sat, Jul 25, 2015 at 4:00 PM, Fox, Kevin M wrote: > I'm not really sure how to start this conversation so I'll just start in. > Please bare with me for a bit. > > Something of a problem description: > With my Operator hat on, I've been quite interested in adopting TripleO. Due > to many reasons, its been hard for me to to explore as much as I'd like. > While time is one reason, another is its kind of monolithic. To try it out, > the best way so far has been to try and use it all. > > We've been interested in deploying some advanced services on our clouds to > add features for our users. Again, due to limited time limitations, I > haven't been able to explore as many of them as I would have liked. > > Some of the advanced services we've had a chance to play with, to varying > degrees are Sahara, Trove, Designate, and Barbican. We'd also like to play > with Manilla, Octavia, Murano, Mistral, Magnum, etc. The majority of these > services can be deployed in VM's (or Containers) running within the Cloud > and then provided through the Cloud. > > Proposal: > So that got me thinking. Could the TripleO deployment template set be broken > up in such a way that it could be used to augment an existing cloud > deployment instead of just deploying a fresh cloud? This would allow Clouds > to add advanced features such as Manilla before the Cloud distribution they > are running on supports it. Also, to make it easy for this enhancement to be > discoverable, they could be added to the application catalog: > http://apps.openstack.org. As the App Catalog UI gets integrated further > with Horzion, it would make it very easy for Operators to extend their > clouds with Advanced services. They would just do a quick search, hit > Launch, and fill out a simple form. Yes, I think it would be possible. It would take a little work to get there though, as I don't expect it to work today without someone diving into the templates and starting to try it out, and fixing mistakes and possibly some bad assumptions that were made, etc. What you're proposing though I think is very compelling. Ideally, you could take just the compute template from tripleo-heat-templates and use Heat to deploy a ResourceGroup of compute nodes. Since the implementation in the templates is so heavily reliant on provider templates and nested stacks, I think it could work without large architectural changes. You'd have to manually pass in via parameters to the compute template what would usually be passed in by the parent template in a full TripleO deployment. For instance, the compute-puppet.yaml template takes a KeystoneHost parameter. When deploying a cloud with TripleO, that IP address is known to Heat since it asked Nova to launch the instance running Keystone, so it passes in that IP address as the value for KeystoneHost. Without Heat orchestrating the parent template as well, you'd have to pass this parameter in manually. Not a huge deal, but it would be a fair amount of manual work that is usually handled by the Heat orchestration automatically. Assuming the cloud had Ironic, you could even use this method to scale out an existing cloud not deployed with TripleO onto more baremetal machines, not just things that can run in VM's. Effectively, it's Heat scaling out the same cloud Heat is running on. We've had similar thoughts before about doing such a thing to scale out a TripleO undercloud so that the seed vm is no longer needed. I think we've developed (and continue to do so) some good patterns in tripleo-heat-templates to not make things so tightly coupled. The puppet implementation proved that out and helped drive a lot of that. We've been able to build on that, and do things like deploy a puppet based controller, and a docker based compute node by just swapping out the compute template. So, I think we're continuing to move towards having less coupling, and that's a good thing. There is also some preliminary work going on into looking at using Heat to configure already running instances that are not known to Nova. Since most (all?) of the configuration of instances is driven via SoftwareDeployments, it serves to reason that if you created a Heat stack that was a bunch of SoftwareDeployments (as TripleO does), and then configured os-collect-config on an already installed system that you could then run os-collect-config and apply those SoftwareDeployments. This requires mapping the OS::Nova::Server resource to a custom resource that you then map to a nested stack that doesn't actually launch an instance. This would allow someone to make use of all the work that has gone into the templates about how to install and configure OpenStack, but use less of OpenStack itself to take advantage of it. -- -- James Slagle -- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.o
Re: [openstack-dev] [TripleO] [app-catalog] TripleO, Advanced Services, and the App Catalog
Excerpts from Christopher Aedo's message of 2015-07-26 14:52:31 -0700: > On Sun, Jul 26, 2015 at 10:53 AM, Clint Byrum wrote: > > Excerpts from Christopher Aedo's message of 2015-07-25 19:35:24 -0700: > >> My understanding of TripleO > >> is that the entire model is tightly coupled such that you must take an > >> all or nothing approach (i.e. you can not use one deployment method > >> for your cloud, and then use TripleO to deploy other components of > >> your cloud later on). I would be happy to hear my understanding is > >> wrong in this case though. > >> > > > > I can understand why it might have seemed that way because we were > > driving at producing something production-like that ran in the gate, > > but you actually heard wrong. The entire thing is intended to be modular > > and one of the reasons to use OpenStack to deploy OpenStack is so that > > you can easily move components into the cloud. Any tight coupling is an > > accident and is likely only there because at this point there is only > > one implementation receiving much attention (the puppet one). > > That's great and I'm glad to be corrected. If what I said was not > completely clear, I was under the impression that if you did not start > with "OpenStack on OpenStack", you would have trouble using the OoO > Heat templates in a cloud deployed differently (Juju, Fuel, or Puppet > for instance). Sounds to me like you are saying you do not need to > start from TripleO to make use of the TripleO templates. > I think this is sometimes how we end up thinking about OpenStack because so many are doing it as a single org with homogeneous tooling because thats how things are done in many orgs, and certainly thats how products do things. But I'm certain there are clouds where each service is its own island, and that's a good thing. Hang your API shingle out in the Keystone catalog. Who cares how you're deployed, right? > > Mixing and matching chef and puppet on a single box doesn't work, because > > they both make assumptions about what they own. But you can quite easily > > have two services managed by two separate sets of tools. > > Yes, I should have been more clear here, I'm taking Kevin's original > question as "can we use the heat templates to deploy additional > services in an already-deployed cloud". My chef vs. puppet example > muddied things - I was really trying to highlight a situation where > you're using one of those tools to deploy and manage a service (say > your message queue), and that if you've done that with one service you > will have great difficulty trying to update/modify that service with a > different tool if it's still actively managing it. > Understood. > >> I would love to see some way for the App Catalog to allow OpenStack > >> users or operators add additional services easily though, and I'm > >> excited to see this floated here. It's possible at least to do this > >> with Rally via Murano[2] but that assumes the environment has included > >> Murano and also has a Heat environment that includes everything needed > >> by the resulting template. As many have seen, it's not necessarily > >> easy for users to know in advance whether this will work (another good > >> thread, unfortunately with an unsatisfactory resolution). > >> > >> Hopefully we'll see some great responses here on how we can solve some > >> of this together! > >> > > > > This is blowing my mind a little, because I've always been told that > > Rally is a performance measuring tool. :-P I guess I should read up on > > it because it sounds like it is also a packaging or deployment tool? > > I think you misunderstood me :) I was using "deploy Rally via Murano" > as an example of deploying a service (Rally) that was not originally > deployed with the cloud. It sounds like the Heat templates could be > used in the same way, that's great! > Indeed, that did confuse me. Thanks. :) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [app-catalog] TripleO, Advanced Services, and the App Catalog
On Sun, Jul 26, 2015 at 10:53 AM, Clint Byrum wrote: > Excerpts from Christopher Aedo's message of 2015-07-25 19:35:24 -0700: >> My understanding of TripleO >> is that the entire model is tightly coupled such that you must take an >> all or nothing approach (i.e. you can not use one deployment method >> for your cloud, and then use TripleO to deploy other components of >> your cloud later on). I would be happy to hear my understanding is >> wrong in this case though. >> > > I can understand why it might have seemed that way because we were > driving at producing something production-like that ran in the gate, > but you actually heard wrong. The entire thing is intended to be modular > and one of the reasons to use OpenStack to deploy OpenStack is so that > you can easily move components into the cloud. Any tight coupling is an > accident and is likely only there because at this point there is only > one implementation receiving much attention (the puppet one). That's great and I'm glad to be corrected. If what I said was not completely clear, I was under the impression that if you did not start with "OpenStack on OpenStack", you would have trouble using the OoO Heat templates in a cloud deployed differently (Juju, Fuel, or Puppet for instance). Sounds to me like you are saying you do not need to start from TripleO to make use of the TripleO templates. > Mixing and matching chef and puppet on a single box doesn't work, because > they both make assumptions about what they own. But you can quite easily > have two services managed by two separate sets of tools. Yes, I should have been more clear here, I'm taking Kevin's original question as "can we use the heat templates to deploy additional services in an already-deployed cloud". My chef vs. puppet example muddied things - I was really trying to highlight a situation where you're using one of those tools to deploy and manage a service (say your message queue), and that if you've done that with one service you will have great difficulty trying to update/modify that service with a different tool if it's still actively managing it. >> I would love to see some way for the App Catalog to allow OpenStack >> users or operators add additional services easily though, and I'm >> excited to see this floated here. It's possible at least to do this >> with Rally via Murano[2] but that assumes the environment has included >> Murano and also has a Heat environment that includes everything needed >> by the resulting template. As many have seen, it's not necessarily >> easy for users to know in advance whether this will work (another good >> thread, unfortunately with an unsatisfactory resolution). >> >> Hopefully we'll see some great responses here on how we can solve some >> of this together! >> > > This is blowing my mind a little, because I've always been told that > Rally is a performance measuring tool. :-P I guess I should read up on > it because it sounds like it is also a packaging or deployment tool? I think you misunderstood me :) I was using "deploy Rally via Murano" as an example of deploying a service (Rally) that was not originally deployed with the cloud. It sounds like the Heat templates could be used in the same way, that's great! > Anyway, It should be relatively easy to take the Heat provider templates > from TripleO and deploy them into a cloud in the same way you should > have no trouble deploying os-ansible-deployment into a cloud. Whatever > assumptions about real hardware are made will need to be addressed, but > ultimately 99% of what is called "advanced services" is just services > running regular binaries speaking regular protocols storing things on > regular filesystems. -Christopher __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [app-catalog] TripleO, Advanced Services, and the App Catalog
Excerpts from Christopher Aedo's message of 2015-07-25 19:35:24 -0700: > On Sat, Jul 25, 2015 at 1:00 PM, Fox, Kevin M wrote: > > I'm not really sure how to start this conversation so I'll just start in. > > Please bare with me for a bit. > > > > Something of a problem description: > > With my Operator hat on, I've been quite interested in adopting TripleO. Due > > to many reasons, its been hard for me to to explore as much as I'd like. > > While time is one reason, another is its kind of monolithic. To try it out, > > the best way so far has been to try and use it all. > > > > We've been interested in deploying some advanced services on our clouds to > > add features for our users. Again, due to limited time limitations, I > > haven't been able to explore as many of them as I would have liked. > > > > Some of the advanced services we've had a chance to play with, to varying > > degrees are Sahara, Trove, Designate, and Barbican. We'd also like to play > > with Manilla, Octavia, Murano, Mistral, Magnum, etc. The majority of these > > services can be deployed in VM's (or Containers) running within the Cloud > > and then provided through the Cloud. > > > > Proposal: > > So that got me thinking. Could the TripleO deployment template set be broken > > up in such a way that it could be used to augment an existing cloud > > deployment instead of just deploying a fresh cloud? This would allow Clouds > > to add advanced features such as Manilla before the Cloud distribution they > > are running on supports it. Also, to make it easy for this enhancement to be > > discoverable, they could be added to the application catalog: > > http://apps.openstack.org. As the App Catalog UI gets integrated further > > with Horzion, it would make it very easy for Operators to extend their > > clouds with Advanced services. They would just do a quick search, hit > > Launch, and fill out a simple form. > > > > Thoughts? > > I think this is a really interesting idea, but I would be surprised to > hear an approach like this is possible. My understanding of TripleO > is that the entire model is tightly coupled such that you must take an > all or nothing approach (i.e. you can not use one deployment method > for your cloud, and then use TripleO to deploy other components of > your cloud later on). I would be happy to hear my understanding is > wrong in this case though. > I can understand why it might have seemed that way because we were driving at producing something production-like that ran in the gate, but you actually heard wrong. The entire thing is intended to be modular and one of the reasons to use OpenStack to deploy OpenStack is so that you can easily move components into the cloud. Any tight coupling is an accident and is likely only there because at this point there is only one implementation receiving much attention (the puppet one). > I think Kevin points out a very legitimate use case, but the only > approach I've seen that is really nicely decoupled is the "Rally in a > container" model [1]. The challenge all the deployment methods face > is that they legitimately want to own the configuration and deployment > from top to bottom of all components. That's why mixing and matching > Chef and Puppet for managing your deployment doesn't tend to work out > (as many projects expect to share the message queue or DB). > Mixing and matching chef and puppet on a single box doesn't work, because they both make assumptions about what they own. But you can quite easily have two services managed by two separate sets of tools. > I would love to see some way for the App Catalog to allow OpenStack > users or operators add additional services easily though, and I'm > excited to see this floated here. It's possible at least to do this > with Rally via Murano[2] but that assumes the environment has included > Murano and also has a Heat environment that includes everything needed > by the resulting template. As many have seen, it's not necessarily > easy for users to know in advance whether this will work (another good > thread, unfortunately with an unsatisfactory resolution). > > Hopefully we'll see some great responses here on how we can solve some > of this together! > This is blowing my mind a little, because I've always been told that Rally is a performance measuring tool. :-P I guess I should read up on it because it sounds like it is also a packaging or deployment tool? Anyway, It should be relatively easy to take the Heat provider templates from TripleO and deploy them into a cloud in the same way you should have no trouble deploying os-ansible-deployment into a cloud. Whatever assumptions about real hardware are made will need to be addressed, but ultimately 99% of what is called "advanced services" is just services running regular binaries speaking regular protocols storing things on regular filesystems. __ OpenStack Development Mailing List
Re: [openstack-dev] [TripleO] [app-catalog] TripleO, Advanced Services, and the App Catalog
On Sat, Jul 25, 2015 at 1:00 PM, Fox, Kevin M wrote: > I'm not really sure how to start this conversation so I'll just start in. > Please bare with me for a bit. > > Something of a problem description: > With my Operator hat on, I've been quite interested in adopting TripleO. Due > to many reasons, its been hard for me to to explore as much as I'd like. > While time is one reason, another is its kind of monolithic. To try it out, > the best way so far has been to try and use it all. > > We've been interested in deploying some advanced services on our clouds to > add features for our users. Again, due to limited time limitations, I > haven't been able to explore as many of them as I would have liked. > > Some of the advanced services we've had a chance to play with, to varying > degrees are Sahara, Trove, Designate, and Barbican. We'd also like to play > with Manilla, Octavia, Murano, Mistral, Magnum, etc. The majority of these > services can be deployed in VM's (or Containers) running within the Cloud > and then provided through the Cloud. > > Proposal: > So that got me thinking. Could the TripleO deployment template set be broken > up in such a way that it could be used to augment an existing cloud > deployment instead of just deploying a fresh cloud? This would allow Clouds > to add advanced features such as Manilla before the Cloud distribution they > are running on supports it. Also, to make it easy for this enhancement to be > discoverable, they could be added to the application catalog: > http://apps.openstack.org. As the App Catalog UI gets integrated further > with Horzion, it would make it very easy for Operators to extend their > clouds with Advanced services. They would just do a quick search, hit > Launch, and fill out a simple form. > > Thoughts? I think this is a really interesting idea, but I would be surprised to hear an approach like this is possible. My understanding of TripleO is that the entire model is tightly coupled such that you must take an all or nothing approach (i.e. you can not use one deployment method for your cloud, and then use TripleO to deploy other components of your cloud later on). I would be happy to hear my understanding is wrong in this case though. I think Kevin points out a very legitimate use case, but the only approach I've seen that is really nicely decoupled is the "Rally in a container" model [1]. The challenge all the deployment methods face is that they legitimately want to own the configuration and deployment from top to bottom of all components. That's why mixing and matching Chef and Puppet for managing your deployment doesn't tend to work out (as many projects expect to share the message queue or DB). I would love to see some way for the App Catalog to allow OpenStack users or operators add additional services easily though, and I'm excited to see this floated here. It's possible at least to do this with Rally via Murano[2] but that assumes the environment has included Murano and also has a Heat environment that includes everything needed by the resulting template. As many have seen, it's not necessarily easy for users to know in advance whether this will work (another good thread, unfortunately with an unsatisfactory resolution). Hopefully we'll see some great responses here on how we can solve some of this together! [1]: https://registry.hub.docker.com/u/rallyforge/rally/ [2]: http://apps.openstack.org/#tab=murano-apps&asset=Rally -Christopher __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] [app-catalog] TripleO, Advanced Services, and the App Catalog
I'm not really sure how to start this conversation so I'll just start in. Please bare with me for a bit. Something of a problem description: With my Operator hat on, I've been quite interested in adopting TripleO. Due to many reasons, its been hard for me to to explore as much as I'd like. While time is one reason, another is its kind of monolithic. To try it out, the best way so far has been to try and use it all. We've been interested in deploying some advanced services on our clouds to add features for our users. Again, due to limited time limitations, I haven't been able to explore as many of them as I would have liked. Some of the advanced services we've had a chance to play with, to varying degrees are Sahara, Trove, Designate, and Barbican. We'd also like to play with Manilla, Octavia, Murano, Mistral, Magnum, etc. The majority of these services can be deployed in VM's (or Containers) running within the Cloud and then provided through the Cloud. Proposal: So that got me thinking. Could the TripleO deployment template set be broken up in such a way that it could be used to augment an existing cloud deployment instead of just deploying a fresh cloud? This would allow Clouds to add advanced features such as Manilla before the Cloud distribution they are running on supports it. Also, to make it easy for this enhancement to be discoverable, they could be added to the application catalog: http://apps.openstack.org. As the App Catalog UI gets integrated further with Horzion, it would make it very easy for Operators to extend their clouds with Advanced services. They would just do a quick search, hit Launch, and fill out a simple form. Thoughts? Thanks, Kevin __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
