Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks
Kevin, You are right. To avoid overloading the app catalog servers, Solum operators can (should?) have local copies of the languagepacks (LPs) in their Glance/Swift installations which are part of their Solum install. Solum currently does have the ability to download LPs from Glance or Swift and use them to build application containers. Solum internally maintains metadata about each LP. One of attributes in this is to identify whether an LP is an operator LP. The LPs that an operator downloads from the app catalog would be marked as operator LPs in Solum. Also, I would assume that operators would define a process to periodically refresh these LPs from the app catalog. Currently operator LPs are available for all the tenants in Solum. Such LPs are downloaded only the first time on the hosts that build application containers, when an application that depends on that LP is built for the very first time. After that the LP is cached on the host. So the Docker daemon on that host does not need to download it again. Solum also provides configurable option to delete LPs to control hosts' disk usage. We have not yet solved how to enable a tenant to make public the LPs that they create (i.e. make their LPs available to other tenants). The solution for this would be different for different backends. I believe that Glance has a way to make images public. So we could use that for Glance. - Devdatta From: Fox, Kevin M kevin@pnnl.gov Sent: Wednesday, June 17, 2015 8:28 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks That would work, but would be a per tenant thing? So if you had lots of tenants using the same image, it would redownloaded lots of times. Are there any plans for glance integration so the cloud deployer could cache it in the image catalog? I seem to remember a version of docker that could use glance directly? Thanks, Kevin From: Adrian Otto Sent: Wednesday, June 17, 2015 5:31:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin, Magnum has a plan for dealing with that. Solum will likely have a Magnum integration that will leverage it: https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master With that said, yes, you could also optimize the performance of the upstream by caching it locally in swift. You’d want an async proceed to keep it continually updated though. Adrian On Jun 17, 2015, at 4:30 PM, Fox, Kevin M kevin@pnnl.gov wrote: so, to not beat up on the public facing server, the user would have to copy the container from the public server to the cloud's swift stoage, then the docker hosts could pull from there? Thanks, Kevin From: Adrian Otto [adrian.o...@rackspace.com] Sent: Wednesday, June 17, 2015 4:21 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin, On Jun 17, 2015, at 4:03 PM, Fox, Kevin M kevin@pnnl.gov wrote: Would then each docker host try and redownload the the prebuilt container externally? If you build from source, does it build it once and then all the docker hosts use that one local copy? Maybe Solum needs a mechanism to pull in a prebuilt LP? On each docker server Solum downloads built LP’s from swift before the containers are created, so Docker has no reason to contact the public image repository for fetching the LP images because is has a local copy. Adrian Thanks, Kevin From: Murali Allada [murali.all...@rackspace.com] Sent: Wednesday, June 17, 2015 12:53 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great place to store metadata about publicly available artifacts to make them searchable and easy to discover. The catalog would point to the 'built' artifact, not the 'unbuilt' dockerfile in github. The point of languagepacks is to reduce the amount of time the solum CI pipeline spends building the users application container. We shouldn't build the languagepack from scratch each time. -Murali From: Keith Bray keith.b...@rackspace.com Sent: Wednesday, June 17, 2015 2:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog
Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks
Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great place to store metadata about publicly available artifacts to make them searchable and easy to discover. The catalog would point to the 'built' artifact, not the 'unbuilt' dockerfile in github. The point of languagepacks is to reduce the amount of time the solum CI pipeline spends building the users application container. We shouldn't build the languagepack from scratch each time. -Murali From: Keith Bray keith.b...@rackspace.com Sent: Wednesday, June 17, 2015 2:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Hi Kevin, We absolute envision languagepack artifacts being made available via apps.openstack.org (ignoring for a moment that the name may not be a perfect fit, particularly for things like vanilla glance images ... Is it an OS or an App? ... catalog.openstack.org might be more fitting). Anyway, there are two stages for language packs, unbuilt, and built. If it's in an unbuilt state, then it's really a Dockerfile + any accessory files that the Dockerfile references. If it's in a built state, then it's a Docker image (same as what is found on Dockerhub I believe). I think there will need to be more discussion to know what users prefer, built vs. unbuilt, or both options (where unbuilt is often a collection of files, best managed in a repo like github vs. built which are best provided as direct links so a single source like Dockerhub). -Keith On 6/17/15 1:58 PM, Fox, Kevin M kevin@pnnl.gov wrote: This question may be off on a tangent, or may be related. As part of the application catalog project, (http://apps.openstack.org/) we're trying to provide globally accessible resources that can be easily consumed in OpenStack Clouds. How would these global Language Packs fit in? Would the url record in the app catalog be required to point to an Internet facing public Swift system then? Or, would it point to the source git repo that Solum would use to generate the LP still? Thanks, Kevin From: Randall Burt [randall.b...@rackspace.com] Sent: Wednesday, June 17, 2015 11:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Supporting swift downloads for operatorlanguagepacks Yes. If an operator wants to make their LP publicly available outside of Solum, I was thinking they could just make GET's on the container public. That being said, I'm unsure if this is realistically do-able if you still have to have an authenticated tenant to access the objects. Scratch that; http://blog.fsquat.net/?p=40 may be helpful. On Jun 17, 2015, at 1:27 PM, Adrian Otto adrian.o...@rackspace.com wrote: To be clear, Randall is referring to a swift container (directory). Murali has a good idea of attempting to use swift client first, as it has performance optimizations that can speed up the process more than naive file transfer tools. I did mention to him that wget does have a retiree feature, and that we could see about using curl instead to allow for chunked encoding as additional optimizations. Randall, are you suggesting that we could use swift client for both private and public LP uses? That sounds like a good suggestion to me. Adrian On Jun 17, 2015, at 11:10 AM, Randall Burt randall.b...@rackspace.com wrote: Can't an operator make the target container public therefore removing the need for multiple access strategies? Original message From: Murali Allada Date:06/17/2015 11:41 AM (GMT-06:00) To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks Hello Solum Developers, When we were designing the operator languagepack feature for Solum, we wanted to make use of public urls to download operator LPs, such as those available for CDN backed swift containers we have at Rackspace, or any publicly accessible url. This would mean that when a user chooses to build applications on top of a languagepack provided by the operator, we use a url to 'wget' the LP image. Recently, we have started noticing a number of failures because of corrupted docker images downloaded using 'wget'. The docker images work fine when we download them manually with a swift client and use them. The corruption seem to be happening when we try to download a large image using 'wget' and there are dropped packets or intermittent network issues. My thinking is to start using the swift client to download operator LPs by default instead of wget. The swift client already implements retry logic, downloading large images in chunks, etc. This means we would not get
Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks
Hi Kevin, We absolute envision languagepack artifacts being made available via apps.openstack.org (ignoring for a moment that the name may not be a perfect fit, particularly for things like vanilla glance images ... Is it an OS or an App? ... catalog.openstack.org might be more fitting). Anyway, there are two stages for language packs, unbuilt, and built. If it's in an unbuilt state, then it's really a Dockerfile + any accessory files that the Dockerfile references. If it's in a built state, then it's a Docker image (same as what is found on Dockerhub I believe). I think there will need to be more discussion to know what users prefer, built vs. unbuilt, or both options (where unbuilt is often a collection of files, best managed in a repo like github vs. built which are best provided as direct links so a single source like Dockerhub). -Keith On 6/17/15 1:58 PM, Fox, Kevin M kevin@pnnl.gov wrote: This question may be off on a tangent, or may be related. As part of the application catalog project, (http://apps.openstack.org/) we're trying to provide globally accessible resources that can be easily consumed in OpenStack Clouds. How would these global Language Packs fit in? Would the url record in the app catalog be required to point to an Internet facing public Swift system then? Or, would it point to the source git repo that Solum would use to generate the LP still? Thanks, Kevin From: Randall Burt [randall.b...@rackspace.com] Sent: Wednesday, June 17, 2015 11:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Supporting swift downloads for operatorlanguagepacks Yes. If an operator wants to make their LP publicly available outside of Solum, I was thinking they could just make GET's on the container public. That being said, I'm unsure if this is realistically do-able if you still have to have an authenticated tenant to access the objects. Scratch that; http://blog.fsquat.net/?p=40 may be helpful. On Jun 17, 2015, at 1:27 PM, Adrian Otto adrian.o...@rackspace.com wrote: To be clear, Randall is referring to a swift container (directory). Murali has a good idea of attempting to use swift client first, as it has performance optimizations that can speed up the process more than naive file transfer tools. I did mention to him that wget does have a retiree feature, and that we could see about using curl instead to allow for chunked encoding as additional optimizations. Randall, are you suggesting that we could use swift client for both private and public LP uses? That sounds like a good suggestion to me. Adrian On Jun 17, 2015, at 11:10 AM, Randall Burt randall.b...@rackspace.com wrote: Can't an operator make the target container public therefore removing the need for multiple access strategies? Original message From: Murali Allada Date:06/17/2015 11:41 AM (GMT-06:00) To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks Hello Solum Developers, When we were designing the operator languagepack feature for Solum, we wanted to make use of public urls to download operator LPs, such as those available for CDN backed swift containers we have at Rackspace, or any publicly accessible url. This would mean that when a user chooses to build applications on top of a languagepack provided by the operator, we use a url to 'wget' the LP image. Recently, we have started noticing a number of failures because of corrupted docker images downloaded using 'wget'. The docker images work fine when we download them manually with a swift client and use them. The corruption seem to be happening when we try to download a large image using 'wget' and there are dropped packets or intermittent network issues. My thinking is to start using the swift client to download operator LPs by default instead of wget. The swift client already implements retry logic, downloading large images in chunks, etc. This means we would not get the niceties of using publicly accessible urls. However, the feature will be more reliable and robust. The implementation would be as follows: • We'll use the existing service tenant configuration available in the solum config file to authenticate and store operator languagepacks using the swift client. We were using a different tenant to build and host LPs, but now that we require the tenants credentials in the config file, it's best to reuse the existing service tenant creds. Note: If we don't, we'll have 3 separate tenants to maintain. • Service tenant • Operator languagepack tenant • Global admin tenant • I'll keep the option to download the operator languagepacks from a publicly available url. I'll allow operators to choose which method they want to use by changing a setting in the solum config
Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks
Would then each docker host try and redownload the the prebuilt container externally? If you build from source, does it build it once and then all the docker hosts use that one local copy? Maybe Solum needs a mechanism to pull in a prebuilt LP? Thanks, Kevin From: Murali Allada [murali.all...@rackspace.com] Sent: Wednesday, June 17, 2015 12:53 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great place to store metadata about publicly available artifacts to make them searchable and easy to discover. The catalog would point to the 'built' artifact, not the 'unbuilt' dockerfile in github. The point of languagepacks is to reduce the amount of time the solum CI pipeline spends building the users application container. We shouldn't build the languagepack from scratch each time. -Murali From: Keith Bray keith.b...@rackspace.com Sent: Wednesday, June 17, 2015 2:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Hi Kevin, We absolute envision languagepack artifacts being made available via apps.openstack.org (ignoring for a moment that the name may not be a perfect fit, particularly for things like vanilla glance images ... Is it an OS or an App? ... catalog.openstack.org might be more fitting). Anyway, there are two stages for language packs, unbuilt, and built. If it's in an unbuilt state, then it's really a Dockerfile + any accessory files that the Dockerfile references. If it's in a built state, then it's a Docker image (same as what is found on Dockerhub I believe). I think there will need to be more discussion to know what users prefer, built vs. unbuilt, or both options (where unbuilt is often a collection of files, best managed in a repo like github vs. built which are best provided as direct links so a single source like Dockerhub). -Keith On 6/17/15 1:58 PM, Fox, Kevin M kevin@pnnl.gov wrote: This question may be off on a tangent, or may be related. As part of the application catalog project, (http://apps.openstack.org/) we're trying to provide globally accessible resources that can be easily consumed in OpenStack Clouds. How would these global Language Packs fit in? Would the url record in the app catalog be required to point to an Internet facing public Swift system then? Or, would it point to the source git repo that Solum would use to generate the LP still? Thanks, Kevin From: Randall Burt [randall.b...@rackspace.com] Sent: Wednesday, June 17, 2015 11:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Supporting swift downloads for operatorlanguagepacks Yes. If an operator wants to make their LP publicly available outside of Solum, I was thinking they could just make GET's on the container public. That being said, I'm unsure if this is realistically do-able if you still have to have an authenticated tenant to access the objects. Scratch that; http://blog.fsquat.net/?p=40 may be helpful. On Jun 17, 2015, at 1:27 PM, Adrian Otto adrian.o...@rackspace.com wrote: To be clear, Randall is referring to a swift container (directory). Murali has a good idea of attempting to use swift client first, as it has performance optimizations that can speed up the process more than naive file transfer tools. I did mention to him that wget does have a retiree feature, and that we could see about using curl instead to allow for chunked encoding as additional optimizations. Randall, are you suggesting that we could use swift client for both private and public LP uses? That sounds like a good suggestion to me. Adrian On Jun 17, 2015, at 11:10 AM, Randall Burt randall.b...@rackspace.com wrote: Can't an operator make the target container public therefore removing the need for multiple access strategies? Original message From: Murali Allada Date:06/17/2015 11:41 AM (GMT-06:00) To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks Hello Solum Developers, When we were designing the operator languagepack feature for Solum, we wanted to make use of public urls to download operator LPs, such as those available for CDN backed swift containers we have at Rackspace, or any publicly accessible url. This would mean that when a user chooses to build applications on top of a languagepack provided by the operator, we use a url to 'wget' the LP image. Recently, we
Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks
Kevin, On Jun 17, 2015, at 4:03 PM, Fox, Kevin M kevin@pnnl.gov wrote: Would then each docker host try and redownload the the prebuilt container externally? If you build from source, does it build it once and then all the docker hosts use that one local copy? Maybe Solum needs a mechanism to pull in a prebuilt LP? On each docker server Solum downloads built LP’s from swift before the containers are created, so Docker has no reason to contact the public image repository for fetching the LP images because is has a local copy. Adrian Thanks, Kevin From: Murali Allada [murali.all...@rackspace.com] Sent: Wednesday, June 17, 2015 12:53 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great place to store metadata about publicly available artifacts to make them searchable and easy to discover. The catalog would point to the 'built' artifact, not the 'unbuilt' dockerfile in github. The point of languagepacks is to reduce the amount of time the solum CI pipeline spends building the users application container. We shouldn't build the languagepack from scratch each time. -Murali From: Keith Bray keith.b...@rackspace.com Sent: Wednesday, June 17, 2015 2:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Hi Kevin, We absolute envision languagepack artifacts being made available via apps.openstack.org (ignoring for a moment that the name may not be a perfect fit, particularly for things like vanilla glance images ... Is it an OS or an App? ... catalog.openstack.org might be more fitting). Anyway, there are two stages for language packs, unbuilt, and built. If it's in an unbuilt state, then it's really a Dockerfile + any accessory files that the Dockerfile references. If it's in a built state, then it's a Docker image (same as what is found on Dockerhub I believe). I think there will need to be more discussion to know what users prefer, built vs. unbuilt, or both options (where unbuilt is often a collection of files, best managed in a repo like github vs. built which are best provided as direct links so a single source like Dockerhub). -Keith On 6/17/15 1:58 PM, Fox, Kevin M kevin@pnnl.gov wrote: This question may be off on a tangent, or may be related. As part of the application catalog project, (http://apps.openstack.org/) we're trying to provide globally accessible resources that can be easily consumed in OpenStack Clouds. How would these global Language Packs fit in? Would the url record in the app catalog be required to point to an Internet facing public Swift system then? Or, would it point to the source git repo that Solum would use to generate the LP still? Thanks, Kevin From: Randall Burt [randall.b...@rackspace.com] Sent: Wednesday, June 17, 2015 11:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Supporting swift downloads for operatorlanguagepacks Yes. If an operator wants to make their LP publicly available outside of Solum, I was thinking they could just make GET's on the container public. That being said, I'm unsure if this is realistically do-able if you still have to have an authenticated tenant to access the objects. Scratch that; http://blog.fsquat.net/?p=40 may be helpful. On Jun 17, 2015, at 1:27 PM, Adrian Otto adrian.o...@rackspace.com wrote: To be clear, Randall is referring to a swift container (directory). Murali has a good idea of attempting to use swift client first, as it has performance optimizations that can speed up the process more than naive file transfer tools. I did mention to him that wget does have a retiree feature, and that we could see about using curl instead to allow for chunked encoding as additional optimizations. Randall, are you suggesting that we could use swift client for both private and public LP uses? That sounds like a good suggestion to me. Adrian On Jun 17, 2015, at 11:10 AM, Randall Burt randall.b...@rackspace.com wrote: Can't an operator make the target container public therefore removing the need for multiple access strategies? Original message From: Murali Allada Date:06/17/2015 11:41 AM (GMT-06:00) To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks Hello Solum Developers
Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks
so, to not beat up on the public facing server, the user would have to copy the container from the public server to the cloud's swift stoage, then the docker hosts could pull from there? Thanks, Kevin From: Adrian Otto [adrian.o...@rackspace.com] Sent: Wednesday, June 17, 2015 4:21 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin, On Jun 17, 2015, at 4:03 PM, Fox, Kevin M kevin@pnnl.gov wrote: Would then each docker host try and redownload the the prebuilt container externally? If you build from source, does it build it once and then all the docker hosts use that one local copy? Maybe Solum needs a mechanism to pull in a prebuilt LP? On each docker server Solum downloads built LP’s from swift before the containers are created, so Docker has no reason to contact the public image repository for fetching the LP images because is has a local copy. Adrian Thanks, Kevin From: Murali Allada [murali.all...@rackspace.com] Sent: Wednesday, June 17, 2015 12:53 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great place to store metadata about publicly available artifacts to make them searchable and easy to discover. The catalog would point to the 'built' artifact, not the 'unbuilt' dockerfile in github. The point of languagepacks is to reduce the amount of time the solum CI pipeline spends building the users application container. We shouldn't build the languagepack from scratch each time. -Murali From: Keith Bray keith.b...@rackspace.com Sent: Wednesday, June 17, 2015 2:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Hi Kevin, We absolute envision languagepack artifacts being made available via apps.openstack.org (ignoring for a moment that the name may not be a perfect fit, particularly for things like vanilla glance images ... Is it an OS or an App? ... catalog.openstack.org might be more fitting). Anyway, there are two stages for language packs, unbuilt, and built. If it's in an unbuilt state, then it's really a Dockerfile + any accessory files that the Dockerfile references. If it's in a built state, then it's a Docker image (same as what is found on Dockerhub I believe). I think there will need to be more discussion to know what users prefer, built vs. unbuilt, or both options (where unbuilt is often a collection of files, best managed in a repo like github vs. built which are best provided as direct links so a single source like Dockerhub). -Keith On 6/17/15 1:58 PM, Fox, Kevin M kevin@pnnl.gov wrote: This question may be off on a tangent, or may be related. As part of the application catalog project, (http://apps.openstack.org/) we're trying to provide globally accessible resources that can be easily consumed in OpenStack Clouds. How would these global Language Packs fit in? Would the url record in the app catalog be required to point to an Internet facing public Swift system then? Or, would it point to the source git repo that Solum would use to generate the LP still? Thanks, Kevin From: Randall Burt [randall.b...@rackspace.com] Sent: Wednesday, June 17, 2015 11:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Supporting swift downloads for operatorlanguagepacks Yes. If an operator wants to make their LP publicly available outside of Solum, I was thinking they could just make GET's on the container public. That being said, I'm unsure if this is realistically do-able if you still have to have an authenticated tenant to access the objects. Scratch that; http://blog.fsquat.net/?p=40 may be helpful. On Jun 17, 2015, at 1:27 PM, Adrian Otto adrian.o...@rackspace.com wrote: To be clear, Randall is referring to a swift container (directory). Murali has a good idea of attempting to use swift client first, as it has performance optimizations that can speed up the process more than naive file transfer tools. I did mention to him that wget does have a retiree feature, and that we could see about using curl instead to allow for chunked encoding as additional optimizations. Randall, are you suggesting that we could use swift client for both private and public LP uses? That sounds like a good suggestion to me. Adrian
Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks
Kevin, Magnum has a plan for dealing with that. Solum will likely have a Magnum integration that will leverage it: https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master With that said, yes, you could also optimize the performance of the upstream by caching it locally in swift. You’d want an async proceed to keep it continually updated though. Adrian On Jun 17, 2015, at 4:30 PM, Fox, Kevin M kevin@pnnl.gov wrote: so, to not beat up on the public facing server, the user would have to copy the container from the public server to the cloud's swift stoage, then the docker hosts could pull from there? Thanks, Kevin From: Adrian Otto [adrian.o...@rackspace.com] Sent: Wednesday, June 17, 2015 4:21 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin, On Jun 17, 2015, at 4:03 PM, Fox, Kevin M kevin@pnnl.gov wrote: Would then each docker host try and redownload the the prebuilt container externally? If you build from source, does it build it once and then all the docker hosts use that one local copy? Maybe Solum needs a mechanism to pull in a prebuilt LP? On each docker server Solum downloads built LP’s from swift before the containers are created, so Docker has no reason to contact the public image repository for fetching the LP images because is has a local copy. Adrian Thanks, Kevin From: Murali Allada [murali.all...@rackspace.com] Sent: Wednesday, June 17, 2015 12:53 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great place to store metadata about publicly available artifacts to make them searchable and easy to discover. The catalog would point to the 'built' artifact, not the 'unbuilt' dockerfile in github. The point of languagepacks is to reduce the amount of time the solum CI pipeline spends building the users application container. We shouldn't build the languagepack from scratch each time. -Murali From: Keith Bray keith.b...@rackspace.com Sent: Wednesday, June 17, 2015 2:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Hi Kevin, We absolute envision languagepack artifacts being made available via apps.openstack.org (ignoring for a moment that the name may not be a perfect fit, particularly for things like vanilla glance images ... Is it an OS or an App? ... catalog.openstack.org might be more fitting). Anyway, there are two stages for language packs, unbuilt, and built. If it's in an unbuilt state, then it's really a Dockerfile + any accessory files that the Dockerfile references. If it's in a built state, then it's a Docker image (same as what is found on Dockerhub I believe). I think there will need to be more discussion to know what users prefer, built vs. unbuilt, or both options (where unbuilt is often a collection of files, best managed in a repo like github vs. built which are best provided as direct links so a single source like Dockerhub). -Keith On 6/17/15 1:58 PM, Fox, Kevin M kevin@pnnl.gov wrote: This question may be off on a tangent, or may be related. As part of the application catalog project, (http://apps.openstack.org/) we're trying to provide globally accessible resources that can be easily consumed in OpenStack Clouds. How would these global Language Packs fit in? Would the url record in the app catalog be required to point to an Internet facing public Swift system then? Or, would it point to the source git repo that Solum would use to generate the LP still? Thanks, Kevin From: Randall Burt [randall.b...@rackspace.com] Sent: Wednesday, June 17, 2015 11:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Supporting swift downloads for operatorlanguagepacks Yes. If an operator wants to make their LP publicly available outside of Solum, I was thinking they could just make GET's on the container public. That being said, I'm unsure if this is realistically do-able if you still have to have an authenticated tenant to access the objects. Scratch that; http://blog.fsquat.net/?p=40 may be helpful. On Jun 17, 2015, at 1:27 PM, Adrian Otto adrian.o...@rackspace.com wrote: To be clear, Randall is referring to a swift container (directory
Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks
Thanks Christopher. Will do for sure. -Murali From: Christopher Aedo ca...@mirantis.com Sent: Wednesday, June 17, 2015 3:24 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks On Wed, Jun 17, 2015 at 12:53 PM, Murali Allada murali.all...@rackspace.com wrote: Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great place to store metadata about publicly available artifacts to make them searchable and easy to discover. The catalog would point to the 'built' artifact, not the 'unbuilt' dockerfile in github. The point of languagepacks is to reduce the amount of time the solum CI pipeline spends building the users application container. We shouldn't build the languagepack from scratch each time. Murali, this is great to hear. It fits perfectly with where I'd like to see the app catalog head - which is to more easily host anything that could be run on OpenStack. Hopefully you can join us in the weeks to come (IRC or mailing list) and we can start sketching out the changes we'll need to make to allow the catalog to expand in this directly. I'm looking forward to seeing Solum assets in there! -Christopher -Murali From: Keith Bray keith.b...@rackspace.com Sent: Wednesday, June 17, 2015 2:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Hi Kevin, We absolute envision languagepack artifacts being made available via apps.openstack.org (ignoring for a moment that the name may not be a perfect fit, particularly for things like vanilla glance images ... Is it an OS or an App? ... catalog.openstack.org might be more fitting). Anyway, there are two stages for language packs, unbuilt, and built. If it's in an unbuilt state, then it's really a Dockerfile + any accessory files that the Dockerfile references. If it's in a built state, then it's a Docker image (same as what is found on Dockerhub I believe). I think there will need to be more discussion to know what users prefer, built vs. unbuilt, or both options (where unbuilt is often a collection of files, best managed in a repo like github vs. built which are best provided as direct links so a single source like Dockerhub). -Keith On 6/17/15 1:58 PM, Fox, Kevin M kevin@pnnl.gov wrote: This question may be off on a tangent, or may be related. As part of the application catalog project, (http://apps.openstack.org/) we're trying to provide globally accessible resources that can be easily consumed in OpenStack Clouds. How would these global Language Packs fit in? Would the url record in the app catalog be required to point to an Internet facing public Swift system then? Or, would it point to the source git repo that Solum would use to generate the LP still? Thanks, Kevin From: Randall Burt [randall.b...@rackspace.com] Sent: Wednesday, June 17, 2015 11:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Supporting swift downloads for operatorlanguagepacks Yes. If an operator wants to make their LP publicly available outside of Solum, I was thinking they could just make GET's on the container public. That being said, I'm unsure if this is realistically do-able if you still have to have an authenticated tenant to access the objects. Scratch that; http://blog.fsquat.net/?p=40 may be helpful. On Jun 17, 2015, at 1:27 PM, Adrian Otto adrian.o...@rackspace.com wrote: To be clear, Randall is referring to a swift container (directory). Murali has a good idea of attempting to use swift client first, as it has performance optimizations that can speed up the process more than naive file transfer tools. I did mention to him that wget does have a retiree feature, and that we could see about using curl instead to allow for chunked encoding as additional optimizations. Randall, are you suggesting that we could use swift client for both private and public LP uses? That sounds like a good suggestion to me. Adrian On Jun 17, 2015, at 11:10 AM, Randall Burt randall.b...@rackspace.com wrote: Can't an operator make the target container public therefore removing the need for multiple access strategies? Original message From: Murali Allada Date:06/17/2015 11:41 AM (GMT-06:00) To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks Hello Solum Developers, When we were designing the operator languagepack feature for Solum, we wanted to make use
Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks
On Wed, Jun 17, 2015 at 12:53 PM, Murali Allada murali.all...@rackspace.com wrote: Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great place to store metadata about publicly available artifacts to make them searchable and easy to discover. The catalog would point to the 'built' artifact, not the 'unbuilt' dockerfile in github. The point of languagepacks is to reduce the amount of time the solum CI pipeline spends building the users application container. We shouldn't build the languagepack from scratch each time. Murali, this is great to hear. It fits perfectly with where I'd like to see the app catalog head - which is to more easily host anything that could be run on OpenStack. Hopefully you can join us in the weeks to come (IRC or mailing list) and we can start sketching out the changes we'll need to make to allow the catalog to expand in this directly. I'm looking forward to seeing Solum assets in there! -Christopher -Murali From: Keith Bray keith.b...@rackspace.com Sent: Wednesday, June 17, 2015 2:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Hi Kevin, We absolute envision languagepack artifacts being made available via apps.openstack.org (ignoring for a moment that the name may not be a perfect fit, particularly for things like vanilla glance images ... Is it an OS or an App? ... catalog.openstack.org might be more fitting). Anyway, there are two stages for language packs, unbuilt, and built. If it's in an unbuilt state, then it's really a Dockerfile + any accessory files that the Dockerfile references. If it's in a built state, then it's a Docker image (same as what is found on Dockerhub I believe). I think there will need to be more discussion to know what users prefer, built vs. unbuilt, or both options (where unbuilt is often a collection of files, best managed in a repo like github vs. built which are best provided as direct links so a single source like Dockerhub). -Keith On 6/17/15 1:58 PM, Fox, Kevin M kevin@pnnl.gov wrote: This question may be off on a tangent, or may be related. As part of the application catalog project, (http://apps.openstack.org/) we're trying to provide globally accessible resources that can be easily consumed in OpenStack Clouds. How would these global Language Packs fit in? Would the url record in the app catalog be required to point to an Internet facing public Swift system then? Or, would it point to the source git repo that Solum would use to generate the LP still? Thanks, Kevin From: Randall Burt [randall.b...@rackspace.com] Sent: Wednesday, June 17, 2015 11:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum] Supporting swift downloads for operatorlanguagepacks Yes. If an operator wants to make their LP publicly available outside of Solum, I was thinking they could just make GET's on the container public. That being said, I'm unsure if this is realistically do-able if you still have to have an authenticated tenant to access the objects. Scratch that; http://blog.fsquat.net/?p=40 may be helpful. On Jun 17, 2015, at 1:27 PM, Adrian Otto adrian.o...@rackspace.com wrote: To be clear, Randall is referring to a swift container (directory). Murali has a good idea of attempting to use swift client first, as it has performance optimizations that can speed up the process more than naive file transfer tools. I did mention to him that wget does have a retiree feature, and that we could see about using curl instead to allow for chunked encoding as additional optimizations. Randall, are you suggesting that we could use swift client for both private and public LP uses? That sounds like a good suggestion to me. Adrian On Jun 17, 2015, at 11:10 AM, Randall Burt randall.b...@rackspace.com wrote: Can't an operator make the target container public therefore removing the need for multiple access strategies? Original message From: Murali Allada Date:06/17/2015 11:41 AM (GMT-06:00) To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Solum] Supporting swift downloads for operator languagepacks Hello Solum Developers, When we were designing the operator languagepack feature for Solum, we wanted to make use of public urls to download operator LPs, such as those available for CDN backed swift containers we have at Rackspace, or any publicly accessible url. This would mean that when a user chooses to build applications on top of a languagepack provided by the operator, we use a url to 'wget' the LP image. Recently, we have started noticing a number
Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks
That would work, but would be a per tenant thing? So if you had lots of tenants using the same image, it would redownloaded lots of times. Are there any plans for glance integration so the cloud deployer could cache it in the image catalog? I seem to remember a version of docker that could use glance directly? Thanks, Kevin From: Adrian Otto Sent: Wednesday, June 17, 2015 5:31:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin, Magnum has a plan for dealing with that. Solum will likely have a Magnum integration that will leverage it: https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master With that said, yes, you could also optimize the performance of the upstream by caching it locally in swift. You’d want an async proceed to keep it continually updated though. Adrian On Jun 17, 2015, at 4:30 PM, Fox, Kevin M kevin@pnnl.gov wrote: so, to not beat up on the public facing server, the user would have to copy the container from the public server to the cloud's swift stoage, then the docker hosts could pull from there? Thanks, Kevin From: Adrian Otto [adrian.o...@rackspace.com] Sent: Wednesday, June 17, 2015 4:21 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin, On Jun 17, 2015, at 4:03 PM, Fox, Kevin M kevin@pnnl.gov wrote: Would then each docker host try and redownload the the prebuilt container externally? If you build from source, does it build it once and then all the docker hosts use that one local copy? Maybe Solum needs a mechanism to pull in a prebuilt LP? On each docker server Solum downloads built LP’s from swift before the containers are created, so Docker has no reason to contact the public image repository for fetching the LP images because is has a local copy. Adrian Thanks, Kevin From: Murali Allada [murali.all...@rackspace.com] Sent: Wednesday, June 17, 2015 12:53 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great place to store metadata about publicly available artifacts to make them searchable and easy to discover. The catalog would point to the 'built' artifact, not the 'unbuilt' dockerfile in github. The point of languagepacks is to reduce the amount of time the solum CI pipeline spends building the users application container. We shouldn't build the languagepack from scratch each time. -Murali From: Keith Bray keith.b...@rackspace.com Sent: Wednesday, June 17, 2015 2:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Hi Kevin, We absolute envision languagepack artifacts being made available via apps.openstack.org (ignoring for a moment that the name may not be a perfect fit, particularly for things like vanilla glance images ... Is it an OS or an App? ... catalog.openstack.org might be more fitting). Anyway, there are two stages for language packs, unbuilt, and built. If it's in an unbuilt state, then it's really a Dockerfile + any accessory files that the Dockerfile references. If it's in a built state, then it's a Docker image (same as what is found on Dockerhub I believe). I think there will need to be more discussion to know what users prefer, built vs. unbuilt, or both options (where unbuilt is often a collection of files, best managed in a repo like github vs. built which are best provided as direct links so a single source like Dockerhub). -Keith On 6/17/15 1:58 PM, Fox, Kevin M kevin@pnnl.gov wrote: This question may be off on a tangent, or may be related. As part of the application catalog project, (http://apps.openstack.org/) we're trying to provide globally accessible resources that can be easily consumed in OpenStack Clouds. How would these global Language Packs fit in? Would the url record in the app catalog be required to point to an Internet facing public Swift system then? Or, would it point to the source git repo that Solum would use to generate the LP still? Thanks, Kevin From: Randall Burt [randall.b...@rackspace.com] Sent: Wednesday, June 17, 2015 11:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev
Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks
Kevin, Yes, the solution to slow performance on public registry servers is to cache content locally. Arranging that is not difficult, but we are not to that point yet. Basically you set up the bay models to use heat templates that set Docker Distribution to use a cloud local upstream. That upstream would use the public registry as an upstream. We can make this really easy. In addition to the Magnum registry feature I referenced, we would also need a feature to in Magnum to allow a BayModel to have an override parameter to allow setting the bay node's distribution upstream server, and a configuration directive to set a default value for that setting in the main Magnum configuration file. I see no need to conflate Glance images and Docker container images when there is already a protocol implementation that will support swift cloud storage on a per tenant basis. We plan to use the prevailing open source implementation of registry v2 as a first iteration, and decide if that needs to be further refined later. Adrian Original message From: Fox, Kevin M kevin@pnnl.gov Date: 06/17/2015 6:35 PM (GMT-08:00) To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks That would work, but would be a per tenant thing? So if you had lots of tenants using the same image, it would redownloaded lots of times. Are there any plans for glance integration so the cloud deployer could cache it in the image catalog? I seem to remember a version of docker that could use glance directly? Thanks, Kevin From: Adrian Otto Sent: Wednesday, June 17, 2015 5:31:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin, Magnum has a plan for dealing with that. Solum will likely have a Magnum integration that will leverage it: https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master With that said, yes, you could also optimize the performance of the upstream by caching it locally in swift. You’d want an async proceed to keep it continually updated though. Adrian On Jun 17, 2015, at 4:30 PM, Fox, Kevin M kevin@pnnl.gov wrote: so, to not beat up on the public facing server, the user would have to copy the container from the public server to the cloud's swift stoage, then the docker hosts could pull from there? Thanks, Kevin From: Adrian Otto [adrian.o...@rackspace.com] Sent: Wednesday, June 17, 2015 4:21 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin, On Jun 17, 2015, at 4:03 PM, Fox, Kevin M kevin@pnnl.gov wrote: Would then each docker host try and redownload the the prebuilt container externally? If you build from source, does it build it once and then all the docker hosts use that one local copy? Maybe Solum needs a mechanism to pull in a prebuilt LP? On each docker server Solum downloads built LP’s from swift before the containers are created, so Docker has no reason to contact the public image repository for fetching the LP images because is has a local copy. Adrian Thanks, Kevin From: Murali Allada [murali.all...@rackspace.com] Sent: Wednesday, June 17, 2015 12:53 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Kevin\Keith, Yes, we would like to use the catalog for globally available artifacts, such as operator languagepacks. More specifically the catalog would be a great place to store metadata about publicly available artifacts to make them searchable and easy to discover. The catalog would point to the 'built' artifact, not the 'unbuilt' dockerfile in github. The point of languagepacks is to reduce the amount of time the solum CI pipeline spends building the users application container. We shouldn't build the languagepack from scratch each time. -Murali From: Keith Bray keith.b...@rackspace.com Sent: Wednesday, June 17, 2015 2:10 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Solum][app-catalog] [ Supporting swift downloads for operator languagepacks Hi Kevin, We absolute envision languagepack artifacts being made available via apps.openstack.org (ignoring for a moment that the name may not be a perfect fit, particularly for things like vanilla glance images ... Is it an OS or an App? ... catalog.openstack.org might be more fitting). Anyway
