Re: [openstack-dev] [new][app-catalog] App Catalog next steps
On Fri, May 29, 2015 at 7:55 PM, Fox, Kevin M wrote: > As an Op, I really really want to replace one image with a new one > atomically with security updates preapplied. Think shellshock, ghost, etc. > It will be basically be the same exact image as before, but patched. > Referencing local ID's explicitly makes it harder to ensure things are > patched, since new vm's will tend to pop up after things are patched with > new vulnerabilities. > That's the exact use case for the versioning concept we have in Artifacts: each artifact is identified by name and version, so there is always "latest version of X" and an API call which returns it. However, that's the question of different API calls and their proper usage: get-by-id returns the very same object which was uploaded, and get by name - the latest object matching the required version. First is good for bit-to-bit immutability guarantees, cache checks etc, second - for the use cases like yours. Same is true for the cross-artifact dependency relations: they may be static (i.e. reference by ID) or dynamic (i.e. reference by name and version). __ 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] [new][app-catalog] App Catalog next steps
I think the next logical step is to add versioning and predefined tags so we can distinguish application versions and application status. Right now the catalog has just information about application without any strict schema enforced. The separate problem is to how this information should be handled by OpenStack services. Potentially it should be done by Artifact repository during the import phase. It will be nice to meet with Glance team and discuss this so we can draft this import process land something in L release. Thanks Gosha On Fri, May 29, 2015 at 3:16 PM, Christopher Aedo wrote: > On Fri, May 29, 2015 at 9:55 AM, Fox, Kevin M wrote: > > As an Op, I really > > really want to replace one image with a new one atomically with security > > updates preapplied. Think shellshock, ghost, etc. It will be basically be > > the same exact image as before, but patched. > > On Fri, May 29, 2015 at 11:16 AM, Georgy Okrokvertskhov > wrote: > > I believe that current app store approach uses only image name rather > then > > ID. So you can replace image with a new one without affecting application > > definitions. > > In my opinion this is a pretty serious shortcoming with the app > catalog as it stands right now. There's no concept of versions for > catalog assets, only whatever is put in with the asset name. It's not > obvious when the binary component of an asset has been replaced for > instance. Maybe the latest one has the security updates applied, > maybe it doesn't? If you are watching the repo you might catch it, > but that's not very use friendly. We are also unable to account for > duplicate names currently (i.e. no protection against having two > identically named glance images). > > I think the easiest way to handle at least the versions is by > including additional information in the metadata. If we eventually > switch to using the artifacts implementation in glance, I think some > of this is resolved, but a switch like that is a long way off. Any > thoughts on what we could do in the near term? > > -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 > -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ 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] [new][app-catalog] App Catalog next steps
On Fri, May 29, 2015 at 9:55 AM, Fox, Kevin M wrote: > As an Op, I really > really want to replace one image with a new one atomically with security > updates preapplied. Think shellshock, ghost, etc. It will be basically be > the same exact image as before, but patched. On Fri, May 29, 2015 at 11:16 AM, Georgy Okrokvertskhov wrote: > I believe that current app store approach uses only image name rather then > ID. So you can replace image with a new one without affecting application > definitions. In my opinion this is a pretty serious shortcoming with the app catalog as it stands right now. There's no concept of versions for catalog assets, only whatever is put in with the asset name. It's not obvious when the binary component of an asset has been replaced for instance. Maybe the latest one has the security updates applied, maybe it doesn't? If you are watching the repo you might catch it, but that's not very use friendly. We are also unable to account for duplicate names currently (i.e. no protection against having two identically named glance images). I think the easiest way to handle at least the versions is by including additional information in the metadata. If we eventually switch to using the artifacts implementation in glance, I think some of this is resolved, but a switch like that is a long way off. Any thoughts on what we could do in the near term? -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] [new][app-catalog] App Catalog next steps
I believe that current app store approach uses only image name rather then ID. So you can replace image with a new one without affecting application definitions. Both Heat and Murano can use just image name without IDs. I think it should be supported in artifact repository too. As for other then Heat, Murano and Glance entities in the catalog, the reason why these types where selected is current OpenStack infrastructure. Application catalog uses standard OpenStack infrastructure for CI\CD and we know how to test Murano packages, Heat templates and Glance images via tempest. It should be pretty straightforward to do this and I believe it was on app catalog roadmap. For other artifacts type it is not clear yet how to do this CI\CD automation. I am not sure if we have OpenStack infrastructure for ansible, puppet or chef testing. Thanks Gosha On Fri, May 29, 2015 at 9:55 AM, Fox, Kevin M wrote: > I've ran into the opposite problem though with Glance. As an Op, I > really really want to replace one image with a new one atomically with > security updates preapplied. Think shellshock, ghost, etc. It will be > basically be the same exact image as before, but patched. Referencing local > ID's explicitly makes it harder to ensure things are patched, since new > vm's will tend to pop up after things are patched with new vulnerabilities. > > Thanks, > Kevin > > -- > *From:* Alexander Tivelkov [ativel...@mirantis.com] > *Sent:* Friday, May 29, 2015 9:24 AM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [new][app-catalog] App Catalog next steps > > Hi Kevin, > > I don't suggest to use random IDs as artifact identifiers in the > community app catalog. Of course we will need to have some globally unique > names there (my initial idea on that is to have a combination of > fully-qualified namespace-based name + version + signature) - and such > names should be used to replicate artifacts across the cloud boundaries. > > By "Referencing by ID" I mean only the local referencing: when the > artifact is already present in cloud's local Glance (be it imported from > the community catalog, copied from other cloud or uploaded directly), the > particular service (Heat in our example) should be able to consume it by > ID, same as Nova currently does with Images. > This has its own purpose to guarantee objects' immutability: once the user > has selected an object in the local catalog, she may be sure that nobody > will interfere and modify it, as the object itself is immutable and the id > is not reusable. If the object is referenced only by name, then it may be > deleted and a different artifact with the same name may be uploaded > instead, which may introduce a potential security issue. Using IDs will > prevent such behavior. > Fully qualified object names are still needed, of course - but that's > Glance goal to locate an artifact based on its FQN and return the id for > it. > At least, this was the design idea of the initial artifact concept. > > But that's an off-topic here, as this concept is related only to the > local artifact repos, and world-global app catalog has nothing to do with > this. > > > -- > Regards, > Alexander Tivelkov > > On Fri, May 29, 2015 at 6:47 PM, Fox, Kevin M wrote: > >> Hi Alexander, >> >> Sweet. I'll have to kick the tires on the current state of Liberty soon. >> :) >> >> Reference by artifact IDs is going to be problematic I think. How do you >> release a generic set of resources to the world that reference specific >> randomly generated ID's? >> >> What about by Name? If not, then it will need to be some kind of mapping >> mechanism. :/ >> >> Thanks, >> Kevin >> >> -- >> *From:* Alexander Tivelkov [ativel...@mirantis.com] >> *Sent:* Friday, May 29, 2015 4:19 AM >> >> *To:* OpenStack Development Mailing List (not for usage questions) >> *Subject:* Re: [openstack-dev] [new][app-catalog] App Catalog next steps >> >>Hi Kevin, >> >> Has the Glance Artifact Repository implemented enough bits to have >>> Heat and/or Murano artefacts yet? >>> >> >> Most of the code is there already, couple of patchsets are still on >> review but we'll land them soon. L1 is a likely milestone to have it ready >> in master. >> >> >> Also, has there been any work on Exporting/Importing them through some >>> defined format (tarball?) that doesn't depend on the artefact type? >>> >> >> This one is not completely implemen
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
I've ran into the opposite problem though with Glance. As an Op, I really really want to replace one image with a new one atomically with security updates preapplied. Think shellshock, ghost, etc. It will be basically be the same exact image as before, but patched. Referencing local ID's explicitly makes it harder to ensure things are patched, since new vm's will tend to pop up after things are patched with new vulnerabilities. Thanks, Kevin From: Alexander Tivelkov [ativel...@mirantis.com] Sent: Friday, May 29, 2015 9:24 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps Hi Kevin, I don't suggest to use random IDs as artifact identifiers in the community app catalog. Of course we will need to have some globally unique names there (my initial idea on that is to have a combination of fully-qualified namespace-based name + version + signature) - and such names should be used to replicate artifacts across the cloud boundaries. By "Referencing by ID" I mean only the local referencing: when the artifact is already present in cloud's local Glance (be it imported from the community catalog, copied from other cloud or uploaded directly), the particular service (Heat in our example) should be able to consume it by ID, same as Nova currently does with Images. This has its own purpose to guarantee objects' immutability: once the user has selected an object in the local catalog, she may be sure that nobody will interfere and modify it, as the object itself is immutable and the id is not reusable. If the object is referenced only by name, then it may be deleted and a different artifact with the same name may be uploaded instead, which may introduce a potential security issue. Using IDs will prevent such behavior. Fully qualified object names are still needed, of course - but that's Glance goal to locate an artifact based on its FQN and return the id for it. At least, this was the design idea of the initial artifact concept. But that's an off-topic here, as this concept is related only to the local artifact repos, and world-global app catalog has nothing to do with this. -- Regards, Alexander Tivelkov On Fri, May 29, 2015 at 6:47 PM, Fox, Kevin M mailto:kevin@pnnl.gov>> wrote: Hi Alexander, Sweet. I'll have to kick the tires on the current state of Liberty soon. :) Reference by artifact IDs is going to be problematic I think. How do you release a generic set of resources to the world that reference specific randomly generated ID's? What about by Name? If not, then it will need to be some kind of mapping mechanism. :/ Thanks, Kevin From: Alexander Tivelkov [ativel...@mirantis.com<mailto:ativel...@mirantis.com>] Sent: Friday, May 29, 2015 4:19 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps Hi Kevin, Has the Glance Artifact Repository implemented enough bits to have Heat and/or Murano artefacts yet? Most of the code is there already, couple of patchsets are still on review but we'll land them soon. L1 is a likely milestone to have it ready in master. Also, has there been any work on Exporting/Importing them through some defined format (tarball?) that doesn't depend on the artefact type? This one is not completely implemented: the design is ready (the spec had this feature from the very beginning) and a PoC was done. The final implementation is likely to happen in L cycle. I've been talking with the Heat folks on starting a blueprint to allow heat templates to use relative URL's instead of absolute ones. That would allow a set of Heat templates to be stored in one artefact in Glance. That's awesome. Also I'd consider allowing Heat to reference Templates by their artifact IDs in Glance, same as Nova does it for images. From: Alexander Tivelkov [ativel...@mirantis.com<mailto:ativel...@mirantis.com>] Sent: Thursday, May 28, 2015 4:46 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps Hi folks, I believe that at least part of the filtering we are discussing here may be done at the client side if the client is sophisticated enough to be aware about the capabilities of the local cloud. And by "sophisticated client" I mean "Glance V3" (previously known as "Artifact Repository"), which may (and, in my vision, should) become the ultimate consumer of the app catalog on the cloud side. Each asset type (currently Image, Murano Package, Heat template, more to come) should be implemented as Glance Artifact type (i.e. a plugin), and may define the required ca
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
Hi Kevin, I don't suggest to use random IDs as artifact identifiers in the community app catalog. Of course we will need to have some globally unique names there (my initial idea on that is to have a combination of fully-qualified namespace-based name + version + signature) - and such names should be used to replicate artifacts across the cloud boundaries. By "Referencing by ID" I mean only the local referencing: when the artifact is already present in cloud's local Glance (be it imported from the community catalog, copied from other cloud or uploaded directly), the particular service (Heat in our example) should be able to consume it by ID, same as Nova currently does with Images. This has its own purpose to guarantee objects' immutability: once the user has selected an object in the local catalog, she may be sure that nobody will interfere and modify it, as the object itself is immutable and the id is not reusable. If the object is referenced only by name, then it may be deleted and a different artifact with the same name may be uploaded instead, which may introduce a potential security issue. Using IDs will prevent such behavior. Fully qualified object names are still needed, of course - but that's Glance goal to locate an artifact based on its FQN and return the id for it. At least, this was the design idea of the initial artifact concept. But that's an off-topic here, as this concept is related only to the local artifact repos, and world-global app catalog has nothing to do with this. -- Regards, Alexander Tivelkov On Fri, May 29, 2015 at 6:47 PM, Fox, Kevin M wrote: > Hi Alexander, > > Sweet. I'll have to kick the tires on the current state of Liberty soon. :) > > Reference by artifact IDs is going to be problematic I think. How do you > release a generic set of resources to the world that reference specific > randomly generated ID's? > > What about by Name? If not, then it will need to be some kind of mapping > mechanism. :/ > > Thanks, > Kevin > > -- > *From:* Alexander Tivelkov [ativel...@mirantis.com] > *Sent:* Friday, May 29, 2015 4:19 AM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [new][app-catalog] App Catalog next steps > > Hi Kevin, > > Has the Glance Artifact Repository implemented enough bits to have Heat >> and/or Murano artefacts yet? >> > > Most of the code is there already, couple of patchsets are still on > review but we'll land them soon. L1 is a likely milestone to have it ready > in master. > > > Also, has there been any work on Exporting/Importing them through some >> defined format (tarball?) that doesn't depend on the artefact type? >> > > This one is not completely implemented: the design is ready (the spec > had this feature from the very beginning) and a PoC was done. The final > implementation is likely to happen in L cycle. > > > I've been talking with the Heat folks on starting a blueprint to allow >> heat templates to use relative URL's instead of absolute ones. That would >> allow a set of Heat templates to be stored in one artefact in Glance. >> > > That's awesome. > Also I'd consider allowing Heat to reference Templates by their artifact > IDs in Glance, same as Nova does it for images. > > > >> ------ >> *From:* Alexander Tivelkov [ativel...@mirantis.com] >> *Sent:* Thursday, May 28, 2015 4:46 AM >> >> *To:* OpenStack Development Mailing List (not for usage questions) >> *Subject:* Re: [openstack-dev] [new][app-catalog] App Catalog next steps >> >>Hi folks, >> >> I believe that at least part of the filtering we are discussing here >> may be done at the client side if the client is sophisticated enough to be >> aware about the capabilities of the local cloud. >> And by "sophisticated client" I mean "Glance V3" (previously known as >> "Artifact Repository"), which may (and, in my vision, should) become the >> ultimate consumer of the app catalog on the cloud side. >> >> Each asset type (currently Image, Murano Package, Heat template, more >> to come) should be implemented as Glance Artifact type (i.e. a plugin), and >> may define the required capabilities as its type specific metadata fields >> (for example, Heat-template type may list plugins which are required to run >> this template; Murano-package type may set the minimum required version of >> Core library etc). The logic which is needed to validate this capabilities >> may be put into this type-specific plugin as well. This custom logic method >>
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
Hi Alexander, Sweet. I'll have to kick the tires on the current state of Liberty soon. :) Reference by artifact IDs is going to be problematic I think. How do you release a generic set of resources to the world that reference specific randomly generated ID's? What about by Name? If not, then it will need to be some kind of mapping mechanism. :/ Thanks, Kevin From: Alexander Tivelkov [ativel...@mirantis.com] Sent: Friday, May 29, 2015 4:19 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps Hi Kevin, Has the Glance Artifact Repository implemented enough bits to have Heat and/or Murano artefacts yet? Most of the code is there already, couple of patchsets are still on review but we'll land them soon. L1 is a likely milestone to have it ready in master. Also, has there been any work on Exporting/Importing them through some defined format (tarball?) that doesn't depend on the artefact type? This one is not completely implemented: the design is ready (the spec had this feature from the very beginning) and a PoC was done. The final implementation is likely to happen in L cycle. I've been talking with the Heat folks on starting a blueprint to allow heat templates to use relative URL's instead of absolute ones. That would allow a set of Heat templates to be stored in one artefact in Glance. That's awesome. Also I'd consider allowing Heat to reference Templates by their artifact IDs in Glance, same as Nova does it for images. From: Alexander Tivelkov [ativel...@mirantis.com<mailto:ativel...@mirantis.com>] Sent: Thursday, May 28, 2015 4:46 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps Hi folks, I believe that at least part of the filtering we are discussing here may be done at the client side if the client is sophisticated enough to be aware about the capabilities of the local cloud. And by "sophisticated client" I mean "Glance V3" (previously known as "Artifact Repository"), which may (and, in my vision, should) become the ultimate consumer of the app catalog on the cloud side. Each asset type (currently Image, Murano Package, Heat template, more to come) should be implemented as Glance Artifact type (i.e. a plugin), and may define the required capabilities as its type specific metadata fields (for example, Heat-template type may list plugins which are required to run this template; Murano-package type may set the minimum required version of Core library etc). The logic which is needed to validate this capabilities may be put into this type-specific plugin as well. This custom logic method will gets executed when the artifact is being exported from app catalog into the particular cloud. In this case the compatibility of particular artifact with particular cloud will be validated by that cloud itself when the app catalog is browsed. Also, if the cloud does not have support of some artifact types at all (e.g. does not have Murano installed and thus cannot utilize Murano Packages), then it does not have the Murano plugin in its glance and thus will not be able to import murano-artifacts from the Catalog. Hope this makes sense. -- Regards, Alexander Tivelkov On Thu, May 28, 2015 at 10:29 AM, Morgan Fainberg mailto:morgan.fainb...@gmail.com>> wrote: On Wed, May 27, 2015 at 5:33 PM, Joe Gordon mailto:joe.gord...@gmail.com>> wrote: On Wed, May 27, 2015 at 4:27 PM, Fox, Kevin M mailto:kevin@pnnl.gov>> wrote: I'd say, tools that utilize OpenStack, like the knife openstack plugin, are not something that you would probably go to the catalog to find. And also, the recipes that you would use with knife would not be specific to OpenStack in any way, so you would just be duplicating the config management system's own catalog in the OpenStack catalog, which would be error prone. Duplicating all the chef recipes, and docker containers, puppet stuff, and . is a lot of work... I am very much against duplicating things, including chef recipes that use the openstack plugin for knife. But we can still easily point to external resources from apps.openstack.org<http://apps.openstack.org>. In fact we already do (http://apps.openstack.org/#tab=heat-templates&asset=Lattice). The vision I have for the Catalog (I can be totally wrong here, lets please discuss) is a place where users (non computer scientists) can visit after logging into their Cloud, pick some app of interest, hit launch, and optionally fill out a form. They then have a running piece of software, provided by the greater OpenStack Community, that they can interact with, and their Cloud can bill them for. Think of it as the Apple App St
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
Hi Kevin, Has the Glance Artifact Repository implemented enough bits to have Heat > and/or Murano artefacts yet? > Most of the code is there already, couple of patchsets are still on review but we'll land them soon. L1 is a likely milestone to have it ready in master. Also, has there been any work on Exporting/Importing them through some > defined format (tarball?) that doesn't depend on the artefact type? > This one is not completely implemented: the design is ready (the spec had this feature from the very beginning) and a PoC was done. The final implementation is likely to happen in L cycle. I've been talking with the Heat folks on starting a blueprint to allow heat > templates to use relative URL's instead of absolute ones. That would allow > a set of Heat templates to be stored in one artefact in Glance. > That's awesome. Also I'd consider allowing Heat to reference Templates by their artifact IDs in Glance, same as Nova does it for images. > -- > *From:* Alexander Tivelkov [ativel...@mirantis.com] > *Sent:* Thursday, May 28, 2015 4:46 AM > > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [new][app-catalog] App Catalog next steps > > Hi folks, > > I believe that at least part of the filtering we are discussing here may > be done at the client side if the client is sophisticated enough to be > aware about the capabilities of the local cloud. > And by "sophisticated client" I mean "Glance V3" (previously known as > "Artifact Repository"), which may (and, in my vision, should) become the > ultimate consumer of the app catalog on the cloud side. > > Each asset type (currently Image, Murano Package, Heat template, more to > come) should be implemented as Glance Artifact type (i.e. a plugin), and > may define the required capabilities as its type specific metadata fields > (for example, Heat-template type may list plugins which are required to run > this template; Murano-package type may set the minimum required version of > Core library etc). The logic which is needed to validate this capabilities > may be put into this type-specific plugin as well. This custom logic method > will gets executed when the artifact is being exported from app catalog > into the particular cloud. > > In this case the compatibility of particular artifact with particular > cloud will be validated by that cloud itself when the app catalog is > browsed. Also, if the cloud does not have support of some artifact types at > all (e.g. does not have Murano installed and thus cannot utilize Murano > Packages), then it does not have the Murano plugin in its glance and thus > will not be able to import murano-artifacts from the Catalog. > > Hope this makes sense. > > > -- > Regards, > Alexander Tivelkov > > On Thu, May 28, 2015 at 10:29 AM, Morgan Fainberg < > morgan.fainb...@gmail.com> wrote: > >> >> >> On Wed, May 27, 2015 at 5:33 PM, Joe Gordon >> wrote: >> >>> >>> >>> On Wed, May 27, 2015 at 4:27 PM, Fox, Kevin M >>> wrote: >>> >>>> I'd say, tools that utilize OpenStack, like the knife openstack >>>> plugin, are not something that you would probably go to the catalog to >>>> find. And also, the recipes that you would use with knife would not be >>>> specific to OpenStack in any way, so you would just be duplicating the >>>> config management system's own catalog in the OpenStack catalog, which >>>> would be error prone. Duplicating all the chef recipes, and docker >>>> containers, puppet stuff, and . is a lot of work... >>>> >>> >>> I am very much against duplicating things, including chef recipes that >>> use the openstack plugin for knife. But we can still easily point to >>> external resources from apps.openstack.org. In fact we already do ( >>> http://apps.openstack.org/#tab=heat-templates&asset=Lattice). >>> >>> >>>> >>>> The vision I have for the Catalog (I can be totally wrong here, lets >>>> please discuss) is a place where users (non computer scientists) can visit >>>> after logging into their Cloud, pick some app of interest, hit launch, and >>>> optionally fill out a form. They then have a running piece of software, >>>> provided by the greater OpenStack Community, that they can interact with, >>>> and their Cloud can bill them for. Think of it as the Apple App Store for >>>> OpenStack. Having a reliable set of deployment engines (Murano, Heat, >>>>
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
This thread is awesome :) I love the conversation we've kicked off, and it's touching on all the considerations we had in mind when we put this together to begin with. Regarding vision: I agree with a lot of what Monty, Kevin (and others) have said. For me, what I want to see is the pace to go for people who have an OpenStack cloud to play with (or are thinking about deploying their own OpenStack cloud). I would like to see this be the biggest/best showcase of what you can do with OpenStack. The biggest audience we will see are people who aren't quite ready to build their own glance image (even though DIB makes that ridiculously easy). People who kinda-sorta get heat or murano, but want some examples to play with. I think it should also encompass other assets, and if we shift to a more open tagging/categorizing model rather than "choose one of three buckets" we can pretty easily support that. The biggest thing missing from what is in the catalog right now are details around what's required to use the assets, or how you can use them. It's a tricky balance though, if we totally overload every description with a wall of text (and requirements that might seem obscure to the uninitiated) we're going to drive away the biggest group of potential consumers. I look forward to discussing how to find that balance though, as I have some ideas but they're by no means perfect. One last thing I wanted to touch on was refstack involvement... I think it would be great to have something like a refstack tag that can be included. I think it would be a mistake to require that for something to be added to the catalog. As Keith said, that would lead us to only supporting the lowest common denominator, which goes against at least my own vision here - we should include all the things, and just focus on making those things easy to find/consume/use for people using OpenStack. I do believe having this central resource available will drive more providers to adopt standards shared by others (portability), as it should make it more obvious when their particular cloud only supports a small subset of assets. Going back to what Monty said, we shouldn't have to worry about the vendor side. Complaining won't fix it, but shining a light on the parts that don't match up will at least bring more visibility and spur more conversations (hopefully!) -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] [new][app-catalog] App Catalog next steps
Makes sense to me. Has the Glance Artifact Repository implemented enough bits to have Heat and/or Murano artefacts yet? Also, has there been any work on Exporting/Importing them through some defined format (tarball?) that doesn't depend on the artefact type? I've been talking with the Heat folks on starting a blueprint to allow heat templates to use relative URL's instead of absolute ones. That would allow a set of Heat templates to be stored in one artefact in Glance. Thanks, Kevin From: Alexander Tivelkov [ativel...@mirantis.com] Sent: Thursday, May 28, 2015 4:46 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps Hi folks, I believe that at least part of the filtering we are discussing here may be done at the client side if the client is sophisticated enough to be aware about the capabilities of the local cloud. And by "sophisticated client" I mean "Glance V3" (previously known as "Artifact Repository"), which may (and, in my vision, should) become the ultimate consumer of the app catalog on the cloud side. Each asset type (currently Image, Murano Package, Heat template, more to come) should be implemented as Glance Artifact type (i.e. a plugin), and may define the required capabilities as its type specific metadata fields (for example, Heat-template type may list plugins which are required to run this template; Murano-package type may set the minimum required version of Core library etc). The logic which is needed to validate this capabilities may be put into this type-specific plugin as well. This custom logic method will gets executed when the artifact is being exported from app catalog into the particular cloud. In this case the compatibility of particular artifact with particular cloud will be validated by that cloud itself when the app catalog is browsed. Also, if the cloud does not have support of some artifact types at all (e.g. does not have Murano installed and thus cannot utilize Murano Packages), then it does not have the Murano plugin in its glance and thus will not be able to import murano-artifacts from the Catalog. Hope this makes sense. -- Regards, Alexander Tivelkov On Thu, May 28, 2015 at 10:29 AM, Morgan Fainberg mailto:morgan.fainb...@gmail.com>> wrote: On Wed, May 27, 2015 at 5:33 PM, Joe Gordon mailto:joe.gord...@gmail.com>> wrote: On Wed, May 27, 2015 at 4:27 PM, Fox, Kevin M mailto:kevin@pnnl.gov>> wrote: I'd say, tools that utilize OpenStack, like the knife openstack plugin, are not something that you would probably go to the catalog to find. And also, the recipes that you would use with knife would not be specific to OpenStack in any way, so you would just be duplicating the config management system's own catalog in the OpenStack catalog, which would be error prone. Duplicating all the chef recipes, and docker containers, puppet stuff, and . is a lot of work... I am very much against duplicating things, including chef recipes that use the openstack plugin for knife. But we can still easily point to external resources from apps.openstack.org<http://apps.openstack.org>. In fact we already do (http://apps.openstack.org/#tab=heat-templates&asset=Lattice). The vision I have for the Catalog (I can be totally wrong here, lets please discuss) is a place where users (non computer scientists) can visit after logging into their Cloud, pick some app of interest, hit launch, and optionally fill out a form. They then have a running piece of software, provided by the greater OpenStack Community, that they can interact with, and their Cloud can bill them for. Think of it as the Apple App Store for OpenStack. Having a reliable set of deployment engines (Murano, Heat, whatever) involved is critical to the experience I think. Having too many of them though will mean it will be rare to have a cloud that has all of them, restricting the utility of the catalog. Too much choice here may actually be a detriment. calling this a catalog, which it sounds accurate, is confusing since keystone already has a catalog. Naming things is unfortunately a difficult problem. This is in itself turns into a really unfortunately usability issue for a number of reason; colliding namespaces that end users need to be aware of serves to generate confusion. Even the choices made naming things currently in use by OpenStack (I openly admit Keystone is particularly bad in this light) have this issue. I would support a "catalog-like" name that limits confusion especially when it comes to conveying this information to the end users (not just deployers and operators). I will reiterate Joe's statement: Naming things is unfortunately a difficult problem. I respectfully disagree with this vision. I mostly agree with the first
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
agree with your concern about too >> many choices here being a detriment (after all isn't OpenStack about >> choices?). >> >> > ++ > > We should be as inclusive as we can be. There are many cases of prior art > where (as long as it's workable) we can do filtering (someone brought up > the mobile app stores). Even if we want to be measured in ensuring the > filtering works before opening the flood gates, allowing alternate > deployment engines is a good thing. It makes OpenStack more usable and more > desirable as a platform > > >> Secondly IMHO the notion that 'if it wasn't invented here we shouldn't >> support it' [0] is a dangerous one that results on us constantly >> re-inventing the wheel while alienating the larger developer community by >> saying there solutions are no good, you should use the OpenStack version of >> it. >> >> >> OpenStack isn't a single 'thing' it is a collection of 'things' and >> user's should be able to pick and choose which components they want and >> which components they want to get from elsewhere. >> >> [0] http://en.wikipedia.org/wiki/Not_invented_here >> >> >> If chef, or what ever other configuration management system became >>> multitenant aware, and integrated into OpenStack and provided by the Cloud >>> providers, then maybe it would fit into the app store vision? >>> >> >> I am not sure why this matters? As a dependency you simply state chef, >> and either require users to provide it or tell them to use a chef heat >> template, glance image, etc. >> >> >>> >>> Thanks, >>> Kevin >>> -- >>> *From:* Joe Gordon [joe.gord...@gmail.com] >>> *Sent:* Wednesday, May 27, 2015 3:20 PM >>> *To:* OpenStack Development Mailing List (not for usage questions) >>> *Subject:* Re: [openstack-dev] [new][app-catalog] App Catalog next steps >>> >>> >>> >>> On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo >>> wrote: >>> >>>> I want to start off by thanking everyone who joined us at the first >>>> working session in Vancouver, and those folks who have already started >>>> adding content to the app catalog. I was happy to see the enthusiasm >>>> and excitement, and am looking forward to working with all of you to >>>> build this into something that has a major impact on OpenStack >>>> adoption by making it easier for our end users to find and share the >>>> assets that run on our clouds. >>>> >>> >>> Great job. This is very exciting to see, I have been wanting something >>> like this for some time now. >>> >>> >>>> >>>> The catalog: http://apps.openstack.org >>>> The repo: https://github.com/stackforge/apps-catalog >>>> The wiki: https://wiki.openstack.org/wiki/App-Catalog >>>> >>>> Please join us via IRC at #openstack-app-catalog on freenode. >>>> >>>> Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox, >>>> Serg Melikyan. >>>> >>>> I’ve started a doodle poll to vote on the initial IRC meeting >>>> schedule, if you’re interested in helping improve and build up this >>>> catalog please vote for the day/time that works best and get involved! >>>> http://doodle.com/vf3husyn4bdkui8w >>>> >>>> At the summit we managed to get one planning session together. We >>>> captured that on etherpad[1], but I’d like to highlight here a few of >>>> the things we talked about working on together in the near term: >>>> >>>> -More information around asset dependencies (like clarifying >>>> requirements for Heat templates or Glance images for instance), >>>> potentially just by providing better guidance in what should be in the >>>> description and attributes sections. >>>> -With respect to the assets that are listed in the catalog, there’s a >>>> need to account for tagging, rating/scoring, and a way to have >>>> comments or a forum for each asset so potential users can interact >>>> outside of the gerrit review system. >>>> -Supporting more resource types (Sahara, Trove, Tosca, others) >>>> >>> >>> What about expanding the scope of the application catalog to any >>> application that can run *on* OpenStack, versus the implied scope of >>> applications that can be
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
On Wed, May 27, 2015 at 5:33 PM, Joe Gordon wrote: > > > On Wed, May 27, 2015 at 4:27 PM, Fox, Kevin M wrote: > >> I'd say, tools that utilize OpenStack, like the knife openstack plugin, >> are not something that you would probably go to the catalog to find. And >> also, the recipes that you would use with knife would not be specific to >> OpenStack in any way, so you would just be duplicating the config >> management system's own catalog in the OpenStack catalog, which would be >> error prone. Duplicating all the chef recipes, and docker containers, >> puppet stuff, and . is a lot of work... >> > > I am very much against duplicating things, including chef recipes that use > the openstack plugin for knife. But we can still easily point to external > resources from apps.openstack.org. In fact we already do ( > http://apps.openstack.org/#tab=heat-templates&asset=Lattice). > > >> >> The vision I have for the Catalog (I can be totally wrong here, lets >> please discuss) is a place where users (non computer scientists) can visit >> after logging into their Cloud, pick some app of interest, hit launch, and >> optionally fill out a form. They then have a running piece of software, >> provided by the greater OpenStack Community, that they can interact with, >> and their Cloud can bill them for. Think of it as the Apple App Store for >> OpenStack. Having a reliable set of deployment engines (Murano, Heat, >> whatever) involved is critical to the experience I think. Having too many >> of them though will mean it will be rare to have a cloud that has all of >> them, restricting the utility of the catalog. Too much choice here may >> actually be a detriment. >> >> > calling this a catalog, which it sounds accurate, is confusing since > keystone already has a catalog. Naming things is unfortunately a > difficult problem. > This is in itself turns into a really unfortunately usability issue for a number of reason; colliding namespaces that end users need to be aware of serves to generate confusion. Even the choices made naming things currently in use by OpenStack (I openly admit Keystone is particularly bad in this light) have this issue. I would support a "catalog-like" name that limits confusion especially when it comes to conveying this information to the end users (not just deployers and operators). I will reiterate Joe's statement: Naming things is unfortunately a difficult problem. > > I respectfully disagree with this vision. I mostly agree with the first > part about it being somewhere users can go to find applications that can be > quickly deployed on OpenStack (note all the gotchas that Monty described > here). The part I disagree with is about limiting the deployment engines to > invented here. Even if we have 100 deployment engines on > apps.openstack.org, it would be very easy for a user to filter by the > deployment engines they use so I do not agree with your concern about too > many choices here being a detriment (after all isn't OpenStack about > choices?). > > ++ We should be as inclusive as we can be. There are many cases of prior art where (as long as it's workable) we can do filtering (someone brought up the mobile app stores). Even if we want to be measured in ensuring the filtering works before opening the flood gates, allowing alternate deployment engines is a good thing. It makes OpenStack more usable and more desirable as a platform > Secondly IMHO the notion that 'if it wasn't invented here we shouldn't > support it' [0] is a dangerous one that results on us constantly > re-inventing the wheel while alienating the larger developer community by > saying there solutions are no good, you should use the OpenStack version of > it. > > > OpenStack isn't a single 'thing' it is a collection of 'things' and user's > should be able to pick and choose which components they want and which > components they want to get from elsewhere. > > [0] http://en.wikipedia.org/wiki/Not_invented_here > > > If chef, or what ever other configuration management system became >> multitenant aware, and integrated into OpenStack and provided by the Cloud >> providers, then maybe it would fit into the app store vision? >> > > I am not sure why this matters? As a dependency you simply state chef, > and either require users to provide it or tell them to use a chef heat > template, glance image, etc. > > >> >> Thanks, >> Kevin >> -- >> *From:* Joe Gordon [joe.gord...@gmail.com] >> *Sent:* Wednesday, May 27, 2015 3:20 PM >> *To:* OpenStack Development Mailing List
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
Oh and one more thing... I think one of the first cloud apps we may want to consider is refstack. :) That way users can easily deploy and test. Thanks, Kevin From: Keith Bray Sent: Wednesday, May 27, 2015 5:20:48 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps Maybe. I'm not up to speed on defcore/refstack requirements.. But, to put the question on the table, do folks want the OpenStack App-catalog to only have support for the "lowest-common-denominator" of artifacts and cloud capabilities, or instead allow for showcasing all that is possible when using cloud technology that major vendors have adopted but are not yet part of refstack/defcore? -Keith On 5/27/15 6:58 PM, "Fox, Kevin M" wrote: >Should RefStack be involved here? To integrate tightly with the App >Catalog, the Cloud Provider would be required to run RefStack against >their cloud, the results getting registered to an App Catalog service in >that Cloud. The App Catalog UI in Horizon could then filter out from the >global App Catalog any apps that would be incompatible with their cloud. >I think the Android app store works kind of like that... > >Thanks, >Kevin > >From: Keith Bray [keith.b...@rackspace.com] >Sent: Wednesday, May 27, 2015 4:41 PM >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps > >In-line responses. Thanks for chipping in Monty. >-Keith > >On 5/27/15 6:03 PM, "Monty Taylor" wrote: > >>On 05/27/2015 06:35 PM, Keith Bray wrote: >>> Joe, regarding apps-catalog for any app deployable on OpenStack >>> (regardless of deployment technology), my two cents is that is a good >>> idea. I also believe, however, that the app-catalog needs to evolve >>> first with features that make it super simple to understand which >>> artifacts will work on which clouds (out-of-the-box) vs. needing >>> additional required dependencies or cloud operator software. My >>> guess is there will be a lot of discussions related to defcore, >>> and/or tagging artifacts with known public/private cloud >>> distributions the artifacts are known to work on. To the extent an >>> openstack operator or end user has to download/install 3rd party or >>> stack forge or non defcore openstack components in order to deploy an >>> artifact, the more sophisticated and complicated it becomes and we >>> need a way to depict that for items shown in the catalog. >>> >>> For example, I'd like to see a way to tag items in the catalog as >>> known-to-work on HP or Rackspace public cloud, or known to work on >>> RDO. Even a basic Heat template optimized for one cloud won't >>> necessarily work on another cloud without modification. >> >>That's an excellent point - I have two opposing thoughts to it. >> >>a) That we have to worry about the _vendor_ side of that is a bug and >>should be fixed. Since all clouds already have a service catalog, >>mapping out a "this app requires trove" should be easy enough. The other >>differences are ... let's just say as a user they do not provide me value > >I wouldn't call it a bug. By design, Heat is pluggable with different >resource implementations. And, different cloud run different plug-ins, >hence a template written for one cloud won't necessarily run on another >cloud unless that cloud also runs the same Heat plug-ins. > >> >>b) The state you describe is today's reality, and as much as wringing >>out hands and spitting may feel good, it doesn't get us anywhere. You >>do, in _fact_ need to know those things to use even basic openstack >>functions today- so we might as well deal with it. > >I don't buy the argument of you need to know those things to make >openstack function, because: The catalog _today_ is targeted more at the >end user, not the operator. The end user shouldn't need to know whether >trove is or is not set up, let alone how to do it. Maybe that isn't the >intention of the catalog, and probably worth sorting out. > >> >>I'll take this as an opportunity to point people towards work in this >>direction grew out of a collaboration between infra and ansible: >> >>http://git.openstack.org/cgit/openstack-infra/shade/ >>and >>http://git.openstack.org/cgit/openstack/os-client-config >> >>os-client-config knows about the differences between the clouds. It has, >>sadly, this file:
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
Ah. So maybe rather then filter out, gray out? Thanks, Kevin From: Jeremy Stanley Sent: Wednesday, May 27, 2015 5:31:51 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps On 2015-05-28 00:20:48 + (+), Keith Bray wrote: > Maybe. I'm not up to speed on defcore/refstack requirements.. But, > to put the question on the table, do folks want the OpenStack > App-catalog to only have support for the > "lowest-common-denominator" of artifacts and cloud capabilities, > or instead allow for showcasing all that is possible when using > cloud technology that major vendors have adopted but are not yet > part of refstack/defcore? I sort of like the idea that the App Catalog can steer service providers and solutions deployers to support more official OpenStack services. Say I run ProviderX and haven't yet implemented/exposed Heat to my customers. Now someone adds KillerAppY to apps.openstack.org as a Heat template. It's entirely likely that more customers may try to convince me to add Heat support (or will start leaving for other providers who do). That's market pressure driving companies toward better support for OpenStack, with a lot more carrot than stick. -- Jeremy Stanley __ 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 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] [new][app-catalog] App Catalog next steps
On Wed, May 27, 2015 at 4:27 PM, Fox, Kevin M wrote: > I'd say, tools that utilize OpenStack, like the knife openstack plugin, > are not something that you would probably go to the catalog to find. And > also, the recipes that you would use with knife would not be specific to > OpenStack in any way, so you would just be duplicating the config > management system's own catalog in the OpenStack catalog, which would be > error prone. Duplicating all the chef recipes, and docker containers, > puppet stuff, and . is a lot of work... > I am very much against duplicating things, including chef recipes that use the openstack plugin for knife. But we can still easily point to external resources from apps.openstack.org. In fact we already do ( http://apps.openstack.org/#tab=heat-templates&asset=Lattice). > > The vision I have for the Catalog (I can be totally wrong here, lets > please discuss) is a place where users (non computer scientists) can visit > after logging into their Cloud, pick some app of interest, hit launch, and > optionally fill out a form. They then have a running piece of software, > provided by the greater OpenStack Community, that they can interact with, > and their Cloud can bill them for. Think of it as the Apple App Store for > OpenStack. Having a reliable set of deployment engines (Murano, Heat, > whatever) involved is critical to the experience I think. Having too many > of them though will mean it will be rare to have a cloud that has all of > them, restricting the utility of the catalog. Too much choice here may > actually be a detriment. > > calling this a catalog, which it sounds accurate, is confusing since keystone already has a catalog. Naming things is unfortunately a difficult problem. I respectfully disagree with this vision. I mostly agree with the first part about it being somewhere users can go to find applications that can be quickly deployed on OpenStack (note all the gotchas that Monty described here). The part I disagree with is about limiting the deployment engines to invented here. Even if we have 100 deployment engines on apps.openstack.org, it would be very easy for a user to filter by the deployment engines they use so I do not agree with your concern about too many choices here being a detriment (after all isn't OpenStack about choices?). Secondly IMHO the notion that 'if it wasn't invented here we shouldn't support it' [0] is a dangerous one that results on us constantly re-inventing the wheel while alienating the larger developer community by saying there solutions are no good, you should use the OpenStack version of it. OpenStack isn't a single 'thing' it is a collection of 'things' and user's should be able to pick and choose which components they want and which components they want to get from elsewhere. [0] http://en.wikipedia.org/wiki/Not_invented_here If chef, or what ever other configuration management system became > multitenant aware, and integrated into OpenStack and provided by the Cloud > providers, then maybe it would fit into the app store vision? > I am not sure why this matters? As a dependency you simply state chef, and either require users to provide it or tell them to use a chef heat template, glance image, etc. > > Thanks, > Kevin > -- > *From:* Joe Gordon [joe.gord...@gmail.com] > *Sent:* Wednesday, May 27, 2015 3:20 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [new][app-catalog] App Catalog next steps > > > > On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo > wrote: > >> I want to start off by thanking everyone who joined us at the first >> working session in Vancouver, and those folks who have already started >> adding content to the app catalog. I was happy to see the enthusiasm >> and excitement, and am looking forward to working with all of you to >> build this into something that has a major impact on OpenStack >> adoption by making it easier for our end users to find and share the >> assets that run on our clouds. >> > > Great job. This is very exciting to see, I have been wanting something > like this for some time now. > > >> >> The catalog: http://apps.openstack.org >> The repo: https://github.com/stackforge/apps-catalog >> The wiki: https://wiki.openstack.org/wiki/App-Catalog >> >> Please join us via IRC at #openstack-app-catalog on freenode. >> >> Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox, >> Serg Melikyan. >> >> I’ve started a doodle poll to vote on the initial IRC meeting >> schedule, if you’re interested in helping improve and build up this >> catalog please vote for t
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
I'm thinking that refstack would have tests for things that aren't always required, but if they were there, it would ensure they were up to spec? If so, then we could use it to detect which standard but optional features where there and filter appropriately? Ideally every cloud would provide everything every app would need, but I realize that's totally unrealistic. So is catering to the lowest common denominator. That would be no NaaS, and a lot of my templates need it. :/ I fear lowest common denominator at this point is strictly glance only. :/ Thanks, Kevin From: Keith Bray [keith.b...@rackspace.com] Sent: Wednesday, May 27, 2015 5:20 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps Maybe. I'm not up to speed on defcore/refstack requirements.. But, to put the question on the table, do folks want the OpenStack App-catalog to only have support for the "lowest-common-denominator" of artifacts and cloud capabilities, or instead allow for showcasing all that is possible when using cloud technology that major vendors have adopted but are not yet part of refstack/defcore? -Keith On 5/27/15 6:58 PM, "Fox, Kevin M" wrote: >Should RefStack be involved here? To integrate tightly with the App >Catalog, the Cloud Provider would be required to run RefStack against >their cloud, the results getting registered to an App Catalog service in >that Cloud. The App Catalog UI in Horizon could then filter out from the >global App Catalog any apps that would be incompatible with their cloud. >I think the Android app store works kind of like that... > >Thanks, >Kevin > >From: Keith Bray [keith.b...@rackspace.com] >Sent: Wednesday, May 27, 2015 4:41 PM >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps > >In-line responses. Thanks for chipping in Monty. >-Keith > >On 5/27/15 6:03 PM, "Monty Taylor" wrote: > >>On 05/27/2015 06:35 PM, Keith Bray wrote: >>> Joe, regarding apps-catalog for any app deployable on OpenStack >>> (regardless of deployment technology), my two cents is that is a good >>> idea. I also believe, however, that the app-catalog needs to evolve >>> first with features that make it super simple to understand which >>> artifacts will work on which clouds (out-of-the-box) vs. needing >>> additional required dependencies or cloud operator software. My >>> guess is there will be a lot of discussions related to defcore, >>> and/or tagging artifacts with known public/private cloud >>> distributions the artifacts are known to work on. To the extent an >>> openstack operator or end user has to download/install 3rd party or >>> stack forge or non defcore openstack components in order to deploy an >>> artifact, the more sophisticated and complicated it becomes and we >>> need a way to depict that for items shown in the catalog. >>> >>> For example, I'd like to see a way to tag items in the catalog as >>> known-to-work on HP or Rackspace public cloud, or known to work on >>> RDO. Even a basic Heat template optimized for one cloud won't >>> necessarily work on another cloud without modification. >> >>That's an excellent point - I have two opposing thoughts to it. >> >>a) That we have to worry about the _vendor_ side of that is a bug and >>should be fixed. Since all clouds already have a service catalog, >>mapping out a "this app requires trove" should be easy enough. The other >>differences are ... let's just say as a user they do not provide me value > >I wouldn't call it a bug. By design, Heat is pluggable with different >resource implementations. And, different cloud run different plug-ins, >hence a template written for one cloud won't necessarily run on another >cloud unless that cloud also runs the same Heat plug-ins. > >> >>b) The state you describe is today's reality, and as much as wringing >>out hands and spitting may feel good, it doesn't get us anywhere. You >>do, in _fact_ need to know those things to use even basic openstack >>functions today- so we might as well deal with it. > >I don't buy the argument of you need to know those things to make >openstack function, because: The catalog _today_ is targeted more at the >end user, not the operator. The end user shouldn't need to know whether >trove is or is not set up, let alone how to do it. Maybe that isn't the >intention of the catalog,
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
On 2015-05-28 00:20:48 + (+), Keith Bray wrote: > Maybe. I'm not up to speed on defcore/refstack requirements.. But, > to put the question on the table, do folks want the OpenStack > App-catalog to only have support for the > "lowest-common-denominator" of artifacts and cloud capabilities, > or instead allow for showcasing all that is possible when using > cloud technology that major vendors have adopted but are not yet > part of refstack/defcore? I sort of like the idea that the App Catalog can steer service providers and solutions deployers to support more official OpenStack services. Say I run ProviderX and haven't yet implemented/exposed Heat to my customers. Now someone adds KillerAppY to apps.openstack.org as a Heat template. It's entirely likely that more customers may try to convince me to add Heat support (or will start leaving for other providers who do). That's market pressure driving companies toward better support for OpenStack, with a lot more carrot than stick. -- Jeremy Stanley __ 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] [new][app-catalog] App Catalog next steps
Maybe. I'm not up to speed on defcore/refstack requirements.. But, to put the question on the table, do folks want the OpenStack App-catalog to only have support for the "lowest-common-denominator" of artifacts and cloud capabilities, or instead allow for showcasing all that is possible when using cloud technology that major vendors have adopted but are not yet part of refstack/defcore? -Keith On 5/27/15 6:58 PM, "Fox, Kevin M" wrote: >Should RefStack be involved here? To integrate tightly with the App >Catalog, the Cloud Provider would be required to run RefStack against >their cloud, the results getting registered to an App Catalog service in >that Cloud. The App Catalog UI in Horizon could then filter out from the >global App Catalog any apps that would be incompatible with their cloud. >I think the Android app store works kind of like that... > >Thanks, >Kevin > >From: Keith Bray [keith.b...@rackspace.com] >Sent: Wednesday, May 27, 2015 4:41 PM >To: OpenStack Development Mailing List (not for usage questions) >Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps > >In-line responses. Thanks for chipping in Monty. >-Keith > >On 5/27/15 6:03 PM, "Monty Taylor" wrote: > >>On 05/27/2015 06:35 PM, Keith Bray wrote: >>> Joe, regarding apps-catalog for any app deployable on OpenStack >>> (regardless of deployment technology), my two cents is that is a good >>> idea. I also believe, however, that the app-catalog needs to evolve >>> first with features that make it super simple to understand which >>> artifacts will work on which clouds (out-of-the-box) vs. needing >>> additional required dependencies or cloud operator software. My >>> guess is there will be a lot of discussions related to defcore, >>> and/or tagging artifacts with known public/private cloud >>> distributions the artifacts are known to work on. To the extent an >>> openstack operator or end user has to download/install 3rd party or >>> stack forge or non defcore openstack components in order to deploy an >>> artifact, the more sophisticated and complicated it becomes and we >>> need a way to depict that for items shown in the catalog. >>> >>> For example, I'd like to see a way to tag items in the catalog as >>> known-to-work on HP or Rackspace public cloud, or known to work on >>> RDO. Even a basic Heat template optimized for one cloud won't >>> necessarily work on another cloud without modification. >> >>That's an excellent point - I have two opposing thoughts to it. >> >>a) That we have to worry about the _vendor_ side of that is a bug and >>should be fixed. Since all clouds already have a service catalog, >>mapping out a "this app requires trove" should be easy enough. The other >>differences are ... let's just say as a user they do not provide me value > >I wouldn't call it a bug. By design, Heat is pluggable with different >resource implementations. And, different cloud run different plug-ins, >hence a template written for one cloud won't necessarily run on another >cloud unless that cloud also runs the same Heat plug-ins. > >> >>b) The state you describe is today's reality, and as much as wringing >>out hands and spitting may feel good, it doesn't get us anywhere. You >>do, in _fact_ need to know those things to use even basic openstack >>functions today- so we might as well deal with it. > >I don't buy the argument of you need to know those things to make >openstack function, because: The catalog _today_ is targeted more at the >end user, not the operator. The end user shouldn't need to know whether >trove is or is not set up, let alone how to do it. Maybe that isn't the >intention of the catalog, and probably worth sorting out. > >> >>I'll take this as an opportunity to point people towards work in this >>direction grew out of a collaboration between infra and ansible: >> >>http://git.openstack.org/cgit/openstack-infra/shade/ >>and >>http://git.openstack.org/cgit/openstack/os-client-config >> >>os-client-config knows about the differences between the clouds. It has, >>sadly, this file: >> >>http://git.openstack.org/cgit/openstack/os-client-config/tree/os_client_c >>o >>nfig/vendors.py >> >>Which lists as much knowledge as we've figured out so far about the >>differences between clouds. >> >>shade presents business logic to users so that they don't have to know. >>For instance: > >I'm all
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
There's an alternate vision which is simply, resources that can be launched in an OpenStack environment directly. Solum, Mistral, Glance, etc fit into that definition. This is kind of how it is arranged today. Even with the high level app store only vision I proposed, these other types of catalog entries will probably be needed since the higher level app store's apps will probably depend on them... Say I want to create a Cloud Application that as part of it, launches a rather obscure, hard to build database software as the backend of a set of web servers... Having that part of the app be a Glance Image might be the best way to go. So your Cloud App would depend on maybe a heat template, and a couple of Glance Images (the appliance and a generic Linux one being loaded too). I know the glance folks want to support storing these things as part of their artefact api, which is good, but there still is the discovery part of it that the app catalog can provide... So, maybe we really need two different types of things in the catalog. * Applications (thing that a user will launch, and optionally answer a few questions) * Resources (OpenStack resources. Glance, Heat, Solum, Mistral, etc Artefacts that Applications use, or users can manually use directly if they have the know how.) Then when the application catalog users that are not developers go to the ui, it would only present the first category of things. Thanks, Kevin From: Keith Bray [keith.b...@rackspace.com] Sent: Wednesday, May 27, 2015 4:48 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps Kevin, I like your vision. Today we have images, heat templates, Murano packages. What are your thoughts on how to manage additions? Should it be restricted to things in the OpenStack namespace under the big tent? E.g., I'd like to see Solum language packs get added to the app-catalog. Solum is currently in stack forge, but meets all the criteria I believe to enter OpenStack namespace. We plan to propose it soon. Folks from various companies did a lot of work the past few summits to clearly distinguish, Heat, Murano, Mistral, and Solum as differentiated enough to co-exist and add value to the ecosystem. Thanks, -Keith From: , Kevin M mailto:kevin@pnnl.gov>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, May 27, 2015 6:27 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps I'd say, tools that utilize OpenStack, like the knife openstack plugin, are not something that you would probably go to the catalog to find. And also, the recipes that you would use with knife would not be specific to OpenStack in any way, so you would just be duplicating the config management system's own catalog in the OpenStack catalog, which would be error prone. Duplicating all the chef recipes, and docker containers, puppet stuff, and . is a lot of work... The vision I have for the Catalog (I can be totally wrong here, lets please discuss) is a place where users (non computer scientists) can visit after logging into their Cloud, pick some app of interest, hit launch, and optionally fill out a form. They then have a running piece of software, provided by the greater OpenStack Community, that they can interact with, and their Cloud can bill them for. Think of it as the Apple App Store for OpenStack. Having a reliable set of deployment engines (Murano, Heat, whatever) involved is critical to the experience I think. Having too many of them though will mean it will be rare to have a cloud that has all of them, restricting the utility of the catalog. Too much choice here may actually be a detriment. If chef, or what ever other configuration management system became multitenant aware, and integrated into OpenStack and provided by the Cloud providers, then maybe it would fit into the app store vision? Thanks, Kevin From: Joe Gordon [joe.gord...@gmail.com<mailto:joe.gord...@gmail.com>] Sent: Wednesday, May 27, 2015 3:20 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo mailto:ca...@mirantis.com>> wrote: I want to start off by thanking everyone who joined us at the first working session in Vancouver, and those folks who have already started adding content to the app catalog. I was happy to see the enthusiasm and excitement, and am looking forward to working with all of you to build this into something that has a major impact on OpenStack adoption by maki
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
Should RefStack be involved here? To integrate tightly with the App Catalog, the Cloud Provider would be required to run RefStack against their cloud, the results getting registered to an App Catalog service in that Cloud. The App Catalog UI in Horizon could then filter out from the global App Catalog any apps that would be incompatible with their cloud. I think the Android app store works kind of like that... Thanks, Kevin From: Keith Bray [keith.b...@rackspace.com] Sent: Wednesday, May 27, 2015 4:41 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps In-line responses. Thanks for chipping in Monty. -Keith On 5/27/15 6:03 PM, "Monty Taylor" wrote: >On 05/27/2015 06:35 PM, Keith Bray wrote: >> Joe, regarding apps-catalog for any app deployable on OpenStack >> (regardless of deployment technology), my two cents is that is a good >> idea. I also believe, however, that the app-catalog needs to evolve >> first with features that make it super simple to understand which >> artifacts will work on which clouds (out-of-the-box) vs. needing >> additional required dependencies or cloud operator software. My >> guess is there will be a lot of discussions related to defcore, >> and/or tagging artifacts with known public/private cloud >> distributions the artifacts are known to work on. To the extent an >> openstack operator or end user has to download/install 3rd party or >> stack forge or non defcore openstack components in order to deploy an >> artifact, the more sophisticated and complicated it becomes and we >> need a way to depict that for items shown in the catalog. >> >> For example, I'd like to see a way to tag items in the catalog as >> known-to-work on HP or Rackspace public cloud, or known to work on >> RDO. Even a basic Heat template optimized for one cloud won't >> necessarily work on another cloud without modification. > >That's an excellent point - I have two opposing thoughts to it. > >a) That we have to worry about the _vendor_ side of that is a bug and >should be fixed. Since all clouds already have a service catalog, >mapping out a "this app requires trove" should be easy enough. The other >differences are ... let's just say as a user they do not provide me value I wouldn't call it a bug. By design, Heat is pluggable with different resource implementations. And, different cloud run different plug-ins, hence a template written for one cloud won't necessarily run on another cloud unless that cloud also runs the same Heat plug-ins. > >b) The state you describe is today's reality, and as much as wringing >out hands and spitting may feel good, it doesn't get us anywhere. You >do, in _fact_ need to know those things to use even basic openstack >functions today- so we might as well deal with it. I don't buy the argument of you need to know those things to make openstack function, because: The catalog _today_ is targeted more at the end user, not the operator. The end user shouldn't need to know whether trove is or is not set up, let alone how to do it. Maybe that isn't the intention of the catalog, and probably worth sorting out. > >I'll take this as an opportunity to point people towards work in this >direction grew out of a collaboration between infra and ansible: > >http://git.openstack.org/cgit/openstack-infra/shade/ >and >http://git.openstack.org/cgit/openstack/os-client-config > >os-client-config knows about the differences between the clouds. It has, >sadly, this file: > >http://git.openstack.org/cgit/openstack/os-client-config/tree/os_client_co >nfig/vendors.py > >Which lists as much knowledge as we've figured out so far about the >differences between clouds. > >shade presents business logic to users so that they don't have to know. >For instance: I'm all +1 on different artifact types with different deployment mechanisms, including Ansible, in case that wasn't clear. As long as the app-catalog supports letting the consumer know what they are in for and expectations. I'm not clear on how the infra stuff works, but agree we don't want cloud specific logic... I especially don't want the application architect authors (e.g. The folks writing Heat templates and/or Murano packages) to have to account for Cloud specific checks in their authoring files. It'd be better to automate this on the catalog testing side at best, or use author submission + voting as a low cost human method (but not without problems in up-keep). > >import shade >cloud = shade.openstack_cloud() >cloud.create_image( >name='ubuntu-tr
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
Kevin, I like your vision. Today we have images, heat templates, Murano packages. What are your thoughts on how to manage additions? Should it be restricted to things in the OpenStack namespace under the big tent? E.g., I'd like to see Solum language packs get added to the app-catalog. Solum is currently in stack forge, but meets all the criteria I believe to enter OpenStack namespace. We plan to propose it soon. Folks from various companies did a lot of work the past few summits to clearly distinguish, Heat, Murano, Mistral, and Solum as differentiated enough to co-exist and add value to the ecosystem. Thanks, -Keith From: , Kevin M mailto:kevin@pnnl.gov>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, May 27, 2015 6:27 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps I'd say, tools that utilize OpenStack, like the knife openstack plugin, are not something that you would probably go to the catalog to find. And also, the recipes that you would use with knife would not be specific to OpenStack in any way, so you would just be duplicating the config management system's own catalog in the OpenStack catalog, which would be error prone. Duplicating all the chef recipes, and docker containers, puppet stuff, and . is a lot of work... The vision I have for the Catalog (I can be totally wrong here, lets please discuss) is a place where users (non computer scientists) can visit after logging into their Cloud, pick some app of interest, hit launch, and optionally fill out a form. They then have a running piece of software, provided by the greater OpenStack Community, that they can interact with, and their Cloud can bill them for. Think of it as the Apple App Store for OpenStack. Having a reliable set of deployment engines (Murano, Heat, whatever) involved is critical to the experience I think. Having too many of them though will mean it will be rare to have a cloud that has all of them, restricting the utility of the catalog. Too much choice here may actually be a detriment. If chef, or what ever other configuration management system became multitenant aware, and integrated into OpenStack and provided by the Cloud providers, then maybe it would fit into the app store vision? Thanks, Kevin From: Joe Gordon [joe.gord...@gmail.com<mailto:joe.gord...@gmail.com>] Sent: Wednesday, May 27, 2015 3:20 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo mailto:ca...@mirantis.com>> wrote: I want to start off by thanking everyone who joined us at the first working session in Vancouver, and those folks who have already started adding content to the app catalog. I was happy to see the enthusiasm and excitement, and am looking forward to working with all of you to build this into something that has a major impact on OpenStack adoption by making it easier for our end users to find and share the assets that run on our clouds. Great job. This is very exciting to see, I have been wanting something like this for some time now. The catalog: http://apps.openstack.org The repo: https://github.com/stackforge/apps-catalog The wiki: https://wiki.openstack.org/wiki/App-Catalog Please join us via IRC at #openstack-app-catalog on freenode. Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox, Serg Melikyan. I’ve started a doodle poll to vote on the initial IRC meeting schedule, if you’re interested in helping improve and build up this catalog please vote for the day/time that works best and get involved! http://doodle.com/vf3husyn4bdkui8w At the summit we managed to get one planning session together. We captured that on etherpad[1], but I’d like to highlight here a few of the things we talked about working on together in the near term: -More information around asset dependencies (like clarifying requirements for Heat templates or Glance images for instance), potentially just by providing better guidance in what should be in the description and attributes sections. -With respect to the assets that are listed in the catalog, there’s a need to account for tagging, rating/scoring, and a way to have comments or a forum for each asset so potential users can interact outside of the gerrit review system. -Supporting more resource types (Sahara, Trove, Tosca, others) What about expanding the scope of the application catalog to any application that can run *on* OpenStack, versus the implied scope of applications that can be deployed *by* (heat, murano, etc.) OpenStack and *on* OpenStack services (nova, cinder etc.). This w
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
config_drive=yes > >And it should mostly just work everywhere. It's not strictly true - >image uploading takes slightly more work (you need to know the needed >format per-cloud) - but there is a role for that: > >https://github.com/emonty/ansible-build-image > >point being - this SHOULD be as easy as the above, but it's not. We're >working on it out on the edges - but that work sadly has to be redone >for each language and each framework. > >So - a) we should take note of the how hard this is and the fact that we >need registries of capabilities - and b) we should fix it so that >libraries like shade do not need to exist. I look forward to the day >when I can retire it as a git repo. I fear that day will never come. +1 to registration of capabilities. That should be a core service me thinks. Is there a project already for this? > >I do strongly hope that things like the app catalog and Joe's suggest >that it be able to host things like ansible playbooks bring in to stark >relief how hard doing something so valuable really is these days. > >> Thanks, -Keith >> >> From: Joe Gordon >> mailto:joe.gord...@gmail.com>> Reply-To: >> "OpenStack Development Mailing List (not for usage questions)" >> >>mailto:openstack-dev@lists.openstack.o >>rg>> >> >> >Date: Wednesday, May 27, 2015 5:20 PM >> To: "OpenStack Development Mailing List (not for usage questions)" >> >>mailto:openstack-dev@lists.openstack.o >>rg>> >> >> >Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps >> >> >> >> On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo >> mailto:ca...@mirantis.com>> wrote: I want to >> start off by thanking everyone who joined us at the first working >> session in Vancouver, and those folks who have already started adding >> content to the app catalog. I was happy to see the enthusiasm and >> excitement, and am looking forward to working with all of you to >> build this into something that has a major impact on OpenStack >> adoption by making it easier for our end users to find and share the >> assets that run on our clouds. >> >> Great job. This is very exciting to see, I have been wanting >> something like this for some time now. >> >> >> The catalog: http://apps.openstack.org The repo: >> https://github.com/stackforge/apps-catalog The wiki: >> https://wiki.openstack.org/wiki/App-Catalog >> >> Please join us via IRC at #openstack-app-catalog on freenode. >> >> Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox, >> Serg Melikyan. >> >> I¹ve started a doodle poll to vote on the initial IRC meeting >> schedule, if you¹re interested in helping improve and build up this >> catalog please vote for the day/time that works best and get >> involved! http://doodle.com/vf3husyn4bdkui8w >> >> At the summit we managed to get one planning session together. We >> captured that on etherpad[1], but I¹d like to highlight here a few >> of the things we talked about working on together in the near term: >> >> -More information around asset dependencies (like clarifying >> requirements for Heat templates or Glance images for instance), >> potentially just by providing better guidance in what should be in >> the description and attributes sections. -With respect to the assets >> that are listed in the catalog, there¹s a need to account for >> tagging, rating/scoring, and a way to have comments or a forum for >> each asset so potential users can interact outside of the gerrit >> review system. -Supporting more resource types (Sahara, Trove, Tosca, >> others) >> >> What about expanding the scope of the application catalog to any >> application that can run *on* OpenStack, versus the implied scope of >> applications that can be deployed *by* (heat, murano, etc.) OpenStack >> and *on* OpenStack services (nova, cinder etc.). This would mean >> adding room for Ansible roles that provision openstack resources [0]. >> And more generally it would reinforce the point that there is no >> 'blessed' method of deploying applications on OpenStack, you can use >> tools developed specifically for OpenStack or tools developed >> elsewhere. >> >> >> [0] >> >>https://github.com/ansible/ansible-modules-core/blob/1f99382dfb395c1b993b >>2812122761371da1bad6/cloud/openstack/os_server.py >> >> -Discuss using glance artifact repository as the backend rather >> than flat YAML files -REST API, enable sea
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
I'd say, tools that utilize OpenStack, like the knife openstack plugin, are not something that you would probably go to the catalog to find. And also, the recipes that you would use with knife would not be specific to OpenStack in any way, so you would just be duplicating the config management system's own catalog in the OpenStack catalog, which would be error prone. Duplicating all the chef recipes, and docker containers, puppet stuff, and . is a lot of work... The vision I have for the Catalog (I can be totally wrong here, lets please discuss) is a place where users (non computer scientists) can visit after logging into their Cloud, pick some app of interest, hit launch, and optionally fill out a form. They then have a running piece of software, provided by the greater OpenStack Community, that they can interact with, and their Cloud can bill them for. Think of it as the Apple App Store for OpenStack. Having a reliable set of deployment engines (Murano, Heat, whatever) involved is critical to the experience I think. Having too many of them though will mean it will be rare to have a cloud that has all of them, restricting the utility of the catalog. Too much choice here may actually be a detriment. If chef, or what ever other configuration management system became multitenant aware, and integrated into OpenStack and provided by the Cloud providers, then maybe it would fit into the app store vision? Thanks, Kevin From: Joe Gordon [joe.gord...@gmail.com] Sent: Wednesday, May 27, 2015 3:20 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo mailto:ca...@mirantis.com>> wrote: I want to start off by thanking everyone who joined us at the first working session in Vancouver, and those folks who have already started adding content to the app catalog. I was happy to see the enthusiasm and excitement, and am looking forward to working with all of you to build this into something that has a major impact on OpenStack adoption by making it easier for our end users to find and share the assets that run on our clouds. Great job. This is very exciting to see, I have been wanting something like this for some time now. The catalog: http://apps.openstack.org The repo: https://github.com/stackforge/apps-catalog The wiki: https://wiki.openstack.org/wiki/App-Catalog Please join us via IRC at #openstack-app-catalog on freenode. Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox, Serg Melikyan. I’ve started a doodle poll to vote on the initial IRC meeting schedule, if you’re interested in helping improve and build up this catalog please vote for the day/time that works best and get involved! http://doodle.com/vf3husyn4bdkui8w At the summit we managed to get one planning session together. We captured that on etherpad[1], but I’d like to highlight here a few of the things we talked about working on together in the near term: -More information around asset dependencies (like clarifying requirements for Heat templates or Glance images for instance), potentially just by providing better guidance in what should be in the description and attributes sections. -With respect to the assets that are listed in the catalog, there’s a need to account for tagging, rating/scoring, and a way to have comments or a forum for each asset so potential users can interact outside of the gerrit review system. -Supporting more resource types (Sahara, Trove, Tosca, others) What about expanding the scope of the application catalog to any application that can run *on* OpenStack, versus the implied scope of applications that can be deployed *by* (heat, murano, etc.) OpenStack and *on* OpenStack services (nova, cinder etc.). This would mean adding room for Ansible roles that provision openstack resources [0]. And more generally it would reinforce the point that there is no 'blessed' method of deploying applications on OpenStack, you can use tools developed specifically for OpenStack or tools developed elsewhere. [0] https://github.com/ansible/ansible-modules-core/blob/1f99382dfb395c1b993b2812122761371da1bad6/cloud/openstack/os_server.py -Discuss using glance artifact repository as the backend rather than flat YAML files -REST API, enable searching/sorting, this would ease native integration with other projects -Federated catalog support (top level catalog including contents from sub-catalogs) - I’ll be working with the OpenStack infra team to get the server and CI set up in their environment (though that work will not impact the catalog as it stands today). I am pleased to see moving this to OpenStack Infra is a high priority. A quick nslookup of http://apps.openstack.org shows it us currently hosted on linode at http://nb-23-239-6-45.fremont.nodebalancer.linode.com/. And last I checked lino
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
On 05/27/2015 06:35 PM, Keith Bray wrote:
> Joe, regarding apps-catalog for any app deployable on OpenStack
> (regardless of deployment technology), my two cents is that is a good
> idea. I also believe, however, that the app-catalog needs to evolve
> first with features that make it super simple to understand which
> artifacts will work on which clouds (out-of-the-box) vs. needing
> additional required dependencies or cloud operator software. My
> guess is there will be a lot of discussions related to defcore,
> and/or tagging artifacts with known public/private cloud
> distributions the artifacts are known to work on. To the extent an
> openstack operator or end user has to download/install 3rd party or
> stack forge or non defcore openstack components in order to deploy an
> artifact, the more sophisticated and complicated it becomes and we
> need a way to depict that for items shown in the catalog.
>
> For example, I'd like to see a way to tag items in the catalog as
> known-to-work on HP or Rackspace public cloud, or known to work on
> RDO. Even a basic Heat template optimized for one cloud won't
> necessarily work on another cloud without modification.
That's an excellent point - I have two opposing thoughts to it.
a) That we have to worry about the _vendor_ side of that is a bug and
should be fixed. Since all clouds already have a service catalog,
mapping out a "this app requires trove" should be easy enough. The other
differences are ... let's just say as a user they do not provide me value
b) The state you describe is today's reality, and as much as wringing
out hands and spitting may feel good, it doesn't get us anywhere. You
do, in _fact_ need to know those things to use even basic openstack
functions today- so we might as well deal with it.
I'll take this as an opportunity to point people towards work in this
direction grew out of a collaboration between infra and ansible:
http://git.openstack.org/cgit/openstack-infra/shade/
and
http://git.openstack.org/cgit/openstack/os-client-config
os-client-config knows about the differences between the clouds. It has,
sadly, this file:
http://git.openstack.org/cgit/openstack/os-client-config/tree/os_client_config/vendors.py
Which lists as much knowledge as we've figured out so far about the
differences between clouds.
shade presents business logic to users so that they don't have to know.
For instance:
import shade
cloud = shade.openstack_cloud()
cloud.create_image(
name='ubuntu-trusty',
filename='ubuntu-trusty.qcow2',
wait=True)
Should upload an image to an openstack cloud no matter the deployer
choices that are made.
The new upstream ansible modules build on this - so if you say:
os_server: name=ubuntu-test flavor_ram=1024 image='Ubuntu 14.04 LTS'
config_drive=yes
It _should_ just work. Of course, image names and image content across
clouds vary - so you probably want:
os_image: name=ubuntu-trusty file=ubuntu-trusty.qcow2 wait=yes
register=image
os_server: name=ubuntu-test flavor_ram=1024 image={{ image.id }}
config_drive=yes
And it should mostly just work everywhere. It's not strictly true -
image uploading takes slightly more work (you need to know the needed
format per-cloud) - but there is a role for that:
https://github.com/emonty/ansible-build-image
point being - this SHOULD be as easy as the above, but it's not. We're
working on it out on the edges - but that work sadly has to be redone
for each language and each framework.
So - a) we should take note of the how hard this is and the fact that we
need registries of capabilities - and b) we should fix it so that
libraries like shade do not need to exist. I look forward to the day
when I can retire it as a git repo. I fear that day will never come.
I do strongly hope that things like the app catalog and Joe's suggest
that it be able to host things like ansible playbooks bring in to stark
relief how hard doing something so valuable really is these days.
> Thanks, -Keith
>
> From: Joe Gordon
> mailto:joe.gord...@gmail.com>> Reply-To:
> "OpenStack Development Mailing List (not for usage questions)"
> mailto:openstack-dev@lists.openstack.org>>
>
>
Date: Wednesday, May 27, 2015 5:20 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
> mailto:openstack-dev@lists.openstack.org>>
>
>
Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps
>
>
>
> On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo
> mailto:ca...@mirantis.com>> wrote: I want to
> start off by thanking everyone who joined us at the first working
> session in Vancouver, and those folks who have already started adding
> content to the app catalog. I was
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
Joe, regarding apps-catalog for any app deployable on OpenStack (regardless of deployment technology), my two cents is that is a good idea. I also believe, however, that the app-catalog needs to evolve first with features that make it super simple to understand which artifacts will work on which clouds (out-of-the-box) vs. needing additional required dependencies or cloud operator software. My guess is there will be a lot of discussions related to defcore, and/or tagging artifacts with known public/private cloud distributions the artifacts are known to work on. To the extent an openstack operator or end user has to download/install 3rd party or stack forge or non defcore openstack components in order to deploy an artifact, the more sophisticated and complicated it becomes and we need a way to depict that for items shown in the catalog. For example, I'd like to see a way to tag items in the catalog as known-to-work on HP or Rackspace public cloud, or known to work on RDO. Even a basic Heat template optimized for one cloud won't necessarily work on another cloud without modification. Thanks, -Keith From: Joe Gordon mailto:joe.gord...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Wednesday, May 27, 2015 5:20 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [new][app-catalog] App Catalog next steps On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo mailto:ca...@mirantis.com>> wrote: I want to start off by thanking everyone who joined us at the first working session in Vancouver, and those folks who have already started adding content to the app catalog. I was happy to see the enthusiasm and excitement, and am looking forward to working with all of you to build this into something that has a major impact on OpenStack adoption by making it easier for our end users to find and share the assets that run on our clouds. Great job. This is very exciting to see, I have been wanting something like this for some time now. The catalog: http://apps.openstack.org The repo: https://github.com/stackforge/apps-catalog The wiki: https://wiki.openstack.org/wiki/App-Catalog Please join us via IRC at #openstack-app-catalog on freenode. Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox, Serg Melikyan. I’ve started a doodle poll to vote on the initial IRC meeting schedule, if you’re interested in helping improve and build up this catalog please vote for the day/time that works best and get involved! http://doodle.com/vf3husyn4bdkui8w At the summit we managed to get one planning session together. We captured that on etherpad[1], but I’d like to highlight here a few of the things we talked about working on together in the near term: -More information around asset dependencies (like clarifying requirements for Heat templates or Glance images for instance), potentially just by providing better guidance in what should be in the description and attributes sections. -With respect to the assets that are listed in the catalog, there’s a need to account for tagging, rating/scoring, and a way to have comments or a forum for each asset so potential users can interact outside of the gerrit review system. -Supporting more resource types (Sahara, Trove, Tosca, others) What about expanding the scope of the application catalog to any application that can run *on* OpenStack, versus the implied scope of applications that can be deployed *by* (heat, murano, etc.) OpenStack and *on* OpenStack services (nova, cinder etc.). This would mean adding room for Ansible roles that provision openstack resources [0]. And more generally it would reinforce the point that there is no 'blessed' method of deploying applications on OpenStack, you can use tools developed specifically for OpenStack or tools developed elsewhere. [0] https://github.com/ansible/ansible-modules-core/blob/1f99382dfb395c1b993b2812122761371da1bad6/cloud/openstack/os_server.py -Discuss using glance artifact repository as the backend rather than flat YAML files -REST API, enable searching/sorting, this would ease native integration with other projects -Federated catalog support (top level catalog including contents from sub-catalogs) - I’ll be working with the OpenStack infra team to get the server and CI set up in their environment (though that work will not impact the catalog as it stands today). I am pleased to see moving this to OpenStack Infra is a high priority. A quick nslookup of http://apps.openstack.org shows it us currently hosted on linode at http://nb-23-239-6-45.fremont.nodebalancer.linode.com/. And last I checked linode isn't OpenStack powered. apps.openstack.org<http://apps.openstack.org> is a great example of the type of application that should be easy to de
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
On Fri, May 22, 2015 at 9:06 PM, Christopher Aedo wrote: > I want to start off by thanking everyone who joined us at the first > working session in Vancouver, and those folks who have already started > adding content to the app catalog. I was happy to see the enthusiasm > and excitement, and am looking forward to working with all of you to > build this into something that has a major impact on OpenStack > adoption by making it easier for our end users to find and share the > assets that run on our clouds. > Great job. This is very exciting to see, I have been wanting something like this for some time now. > > The catalog: http://apps.openstack.org > The repo: https://github.com/stackforge/apps-catalog > The wiki: https://wiki.openstack.org/wiki/App-Catalog > > Please join us via IRC at #openstack-app-catalog on freenode. > > Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox, > Serg Melikyan. > > I’ve started a doodle poll to vote on the initial IRC meeting > schedule, if you’re interested in helping improve and build up this > catalog please vote for the day/time that works best and get involved! > http://doodle.com/vf3husyn4bdkui8w > > At the summit we managed to get one planning session together. We > captured that on etherpad[1], but I’d like to highlight here a few of > the things we talked about working on together in the near term: > > -More information around asset dependencies (like clarifying > requirements for Heat templates or Glance images for instance), > potentially just by providing better guidance in what should be in the > description and attributes sections. > -With respect to the assets that are listed in the catalog, there’s a > need to account for tagging, rating/scoring, and a way to have > comments or a forum for each asset so potential users can interact > outside of the gerrit review system. > -Supporting more resource types (Sahara, Trove, Tosca, others) > What about expanding the scope of the application catalog to any application that can run *on* OpenStack, versus the implied scope of applications that can be deployed *by* (heat, murano, etc.) OpenStack and *on* OpenStack services (nova, cinder etc.). This would mean adding room for Ansible roles that provision openstack resources [0]. And more generally it would reinforce the point that there is no 'blessed' method of deploying applications on OpenStack, you can use tools developed specifically for OpenStack or tools developed elsewhere. [0] https://github.com/ansible/ansible-modules-core/blob/1f99382dfb395c1b993b2812122761371da1bad6/cloud/openstack/os_server.py > -Discuss using glance artifact repository as the backend rather than > flat YAML files > -REST API, enable searching/sorting, this would ease native > integration with other projects > -Federated catalog support (top level catalog including contents from > sub-catalogs) > - I’ll be working with the OpenStack infra team to get the server and > CI set up in their environment (though that work will not impact the > catalog as it stands today). > I am pleased to see moving this to OpenStack Infra is a high priority. A quick nslookup of http://apps.openstack.org shows it us currently hosted on linode at http://nb-23-239-6-45.fremont.nodebalancer.linode.com/. And last I checked linode isn't OpenStack powered. apps.openstack.org is a great example of the type of application that should be easy to deploy with OpenStack, since as far as I can tell it just needs a web server and that is it. So wearing my OpenStack developer hat on, why did you go with linode and not any one of the OpenStack based public clouds [1]? If OpenStack is not a good solution for workloads like this, then it would be great to know how what needs work. [1] https://www.openstack.org/marketplace/public-clouds/ > There were a ton of great ideas that came up and it was clear there > was WAY more to discuss than we could accomplish in one short session > at the summit. I’m looking forward to continuing the conversation > here on the mailing list, on IRC, and in Tokyo as well! > > [1] https://etherpad.openstack.org/p/YVR-app-catalog-plans > > -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 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] [new][app-catalog] App Catalog next steps
I want to start off by thanking everyone who joined us at the first working session in Vancouver, and those folks who have already started adding content to the app catalog. I was happy to see the enthusiasm and excitement, and am looking forward to working with all of you to build this into something that has a major impact on OpenStack adoption by making it easier for our end users to find and share the assets that run on our clouds. The catalog: http://apps.openstack.org The repo: https://github.com/stackforge/apps-catalog The wiki: https://wiki.openstack.org/wiki/App-Catalog Please join us via IRC at #openstack-app-catalog on freenode. Our initial core team is Christopher Aedo, Tom Fifield, Kevin Fox, Serg Melikyan. I’ve started a doodle poll to vote on the initial IRC meeting schedule, if you’re interested in helping improve and build up this catalog please vote for the day/time that works best and get involved! http://doodle.com/vf3husyn4bdkui8w At the summit we managed to get one planning session together. We captured that on etherpad[1], but I’d like to highlight here a few of the things we talked about working on together in the near term: -More information around asset dependencies (like clarifying requirements for Heat templates or Glance images for instance), potentially just by providing better guidance in what should be in the description and attributes sections. -With respect to the assets that are listed in the catalog, there’s a need to account for tagging, rating/scoring, and a way to have comments or a forum for each asset so potential users can interact outside of the gerrit review system. -Supporting more resource types (Sahara, Trove, Tosca, others) -Discuss using glance artifact repository as the backend rather than flat YAML files -REST API, enable searching/sorting, this would ease native integration with other projects -Federated catalog support (top level catalog including contents from sub-catalogs) - I’ll be working with the OpenStack infra team to get the server and CI set up in their environment (though that work will not impact the catalog as it stands today). There were a ton of great ideas that came up and it was clear there was WAY more to discuss than we could accomplish in one short session at the summit. I’m looking forward to continuing the conversation here on the mailing list, on IRC, and in Tokyo as well! [1] https://etherpad.openstack.org/p/YVR-app-catalog-plans -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
