Yesterday I went through the process of setting up and managing docker content in foreman, and came up with a couple of questions.
Foreman docker at the present time provides abilities to set up multiple external registries (places where docker content is stored). Katello allows one to manage docker content via the syncing content from external registries plus importing images, etc. It exports the published content and via pulp's crane project provides a simple registry to pull content. Foreman upstream I presume will treat it as one of the supported registries that one can provision content from .
This presents the following questions:
-
Do we want to support 2 different ways to manage docker content? In other words do we support the upstream method that foreman provides of just pulling content from external registries, bypassing content set up through the normal Katello create/sync/cv publish promotion process? Should allow users for example to just pull/run a docker image from registry hub directly? I can see this feature useful for upstream foreman, but think its worth discussing here.
-
If we want to allow the registry based approach how are we going to be able to control access based on organizations/environment, since the present day docker registry api just allows one to search on any repo by name/description?
Also note at this point crane does not offer the search calls needed for the foreman registry functionality to work (last I heard a google search appliance needed to be configured for that to work.)
Partha
> Yesterday I went through the process of setting up and managing docker content in foreman, and came up with a couple of questions.
>
> Foreman docker at the present time provides abilities to set up multiple external registries (places where docker content is stored). Katello allows one to manage docker content via the syncing content from external registries plus importing images, etc. It exports the published content and via pulp's crane project provides a simple registry to pull content. Foreman upstream I presume will treat it as one of the supported registries that one can provision content from .
>
> This presents the following questions:
>
> 1) Do we want to support 2 different ways to manage docker content? In other words do we support the upstream method that foreman provides of just pulling content from external registries, bypassing content set up through the normal Katello create/sync/cv publish promotion process? Should allow users for example to just pull/run a docker image from registry hub directly? I can see this feature useful for upstream foreman, but think its worth discussing here.
>
sure, the different options IMO, is fine. The overall solution remains
flexible, users can sync and provision with the unified Katello workflow
or they can just setup manual registry entries and provision quickly
without needing a sync. There are plenty of places in Katello + Foreman
where users can skip the unified approach and use Foreman by itself,
this isn't that much different than say:
- Manually creating Install Media to some external location
- Importing puppet classes straight off your Smart Proxy/Capsule instead
of using a Content View
I don't think Katello's role should be to hide and block Foreman's
functionality and present a 'our way or the high way' methodology. We
should be an add-on, not a replacement.
> 2) If we want to allow the registry based approach how are we going to be able to control access based on organizations/environment, since the present day docker registry api just allows one to search on any repo by name/description?
>
I'd imagine it would be like any other object in Foreman, it should be
able to be scoped to an Org and Location.
> Also note at this point crane does not offer the search calls needed for the foreman registry functionality to work (last I heard a google search appliance needed to be configured for that to work.)
>
Mike
···
On 11/20/2014 01:00 PM, Partha Aji wrote:
–
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248
I think I agree although my concern would be users who want to switch from Foreman's workflow to Katello's workflow. Would they have to start over from scratch and find, reimport, etc the docker content?
David
···
----- Original Message -----
> From: "Mike McCune"
> To: foreman-dev@googlegroups.com
> Cc: "Partha Aji"
> Sent: Thursday, November 20, 2014 4:09:05 PM
> Subject: Re: [foreman-dev] Questions on managing docker
>
> On 11/20/2014 01:00 PM, Partha Aji wrote:
> > Yesterday I went through the process of setting up and managing docker
> > content in foreman, and came up with a couple of questions.
> >
> > Foreman docker at the present time provides abilities to set up multiple
> > external registries (places where docker content is stored). Katello
> > allows one to manage docker content via the syncing content from external
> > registries plus importing images, etc. It exports the published content
> > and via pulp's crane project provides a simple registry to pull content.
> > Foreman upstream I presume will treat it as one of the supported
> > registries that one can provision content from .
> >
> > This presents the following questions:
> >
> > 1) Do we want to support 2 different ways to manage docker content? In
> > other words do we support the upstream method that foreman provides of
> > just pulling content from external registries, bypassing content set up
> > through the normal Katello create/sync/cv publish promotion process?
> > Should allow users for example to just pull/run a docker image from
> > registry hub directly? I can see this feature useful for upstream foreman,
> > but think its worth discussing here.
> >
>
> sure, the different options IMO, is fine. The overall solution remains
> flexible, users can sync and provision with the unified Katello workflow
> or they can just setup manual registry entries and provision quickly
> without needing a sync. There are plenty of places in Katello + Foreman
> where users can skip the unified approach and use Foreman by itself,
> this isn't that much different than say:
>
> * Manually creating Install Media to some external location
> * Importing puppet classes straight off your Smart Proxy/Capsule instead
> of using a Content View
>
> I don't think Katello's role should be to hide and block Foreman's
> functionality and present a 'our way or the high way' methodology. We
> should be an add-on, not a replacement.
>
> > 2) If we want to allow the registry based approach how are we going to be
> > able to control access based on organizations/environment, since the
> > present day docker registry api just allows one to search on any repo by
> > name/description?
> >
>
> I'd imagine it would be like any other object in Foreman, it should be
> able to be scoped to an Org and Location.
>
> > Also note at this point crane does not offer the search calls needed for
> > the foreman registry functionality to work (last I heard a google search
> > appliance needed to be configured for that to work.)
> >
>
> Mike
>
> --
> Mike McCune
> mmccune AT redhat.com
> Red Hat Engineering | Portland, OR
> Systems Management | 650-254-4248
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>> Yesterday I went through the process of setting up and managing docker content in foreman, and came up with a couple of questions.
>>
>> Foreman docker at the present time provides abilities to set up multiple external registries (places where docker content is stored). Katello allows one to manage docker content via the syncing content from external registries plus importing images, etc. It exports the published content and via pulp's crane project provides a simple registry to pull content. Foreman upstream I presume will treat it as one of the supported registries that one can provision content from .
>>
>> This presents the following questions:
>>
>> 1) Do we want to support 2 different ways to manage docker content? In other words do we support the upstream method that foreman provides of just pulling content from external registries, bypassing content set up through the normal Katello create/sync/cv publish promotion process? Should allow users for example to just pull/run a docker image from registry hub directly? I can see this feature useful for upstream foreman, but think its worth discussing here.
>
> sure, the different options IMO, is fine. The overall solution remains flexible, users can sync and provision with the unified Katello workflow or they can just setup manual registry entries and provision quickly without needing a sync. There are plenty of places in Katello + Foreman where users can skip the unified approach and use Foreman by itself, this isn't that much different than say:
>
> * Manually creating Install Media to some external location
> * Importing puppet classes straight off your Smart Proxy/Capsule instead of using a Content View
>
> I don't think Katello's role should be to hide and block Foreman's functionality and present a 'our way or the high way' methodology. We should be an add-on, not a replacement.
>
>> 2) If we want to allow the registry based approach how are we going to be able to control access based on organizations/environment, since the present day docker registry api just allows one to search on any repo by name/description?
>
> I'd imagine it would be like any other object in Foreman, it should be able to be scoped to an Org and Location.
Agree from a over arching goal perspective but we need to specifically figure out the following cases
- Readonly registries that don't allow search. Pulp crane for example.
- Even in the cases that allow for search, the v1 docker registry api requires it to be freeform. Need to figure out how to filter things for org/env/content view/repo level. Since foreman is treating it at a generic registry level we d need to narrow it down.
···
> On Nov 20, 2014, at 4:09 PM, Mike McCune wrote:
>> On 11/20/2014 01:00 PM, Partha Aji wrote:
Also note at this point crane does not offer the search calls needed for the foreman registry functionality to work (last I heard a google search appliance needed to be configured for that to work.)
Mike
–
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248
–
You received this message because you are subscribed to the Google Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Replies inline:
Yesterday I went through the process of setting up and managing docker
> content in foreman, and came up with a couple of questions.
>
> Foreman docker at the present time provides abilities to set up multiple
> external registries (places where docker content is stored). Katello allows
> one to manage docker content via the syncing content from external
> registries plus importing images, etc. It exports the published content and
> via pulp's crane project provides a simple registry to pull content.
> Foreman upstream I presume will treat it as one of the supported registries
> that one can provision content from .
>
I think you're misguided here, a Docker compute resource represents a
Docker host, not a Docker registry. So in that sense it doesn't compete
with Katello for content, although we do plan to get content from external
registries = https://github.com/theforeman/foreman-docker/pull/44
>
> This presents the following questions:
>
> 1) Do we want to support 2 different ways to manage docker content? In
> other words do we support the upstream method that foreman provides of just
> pulling content from external registries, bypassing content set up through
> the normal Katello create/sync/cv publish promotion process? Should allow
> users for example to just pull/run a docker image from registry hub
> directly? I can see this feature useful for upstream foreman, but think its
> worth discussing here.
>
>
"Should allow users for example to just pull/run a docker image from
registry hub directly" : not having this will equate to crippling Foreman
Docker severely. In fact I'd argue for the moment most users won't manage
their own registries and I don't see any reason to forcing them to do so.
Imagine removing support for any non-katello registered repos.
> 2) If we want to allow the registry based approach how are we going to be
> able to control access based on organizations/environment, since the
> present day docker registry api just allows one to search on any repo by
> name/description?
>
> Also note at this point crane does not offer the search calls needed for
> the foreman registry functionality to work (last I heard a google search
> appliance needed to be configured for that to work.)
>
ACLs for the Docker compute resource are in place, and when you make a call
through the API to search for images/repositories, you'll search in all
registries available to the Docker host as far as I know, so it's something
the user will configure in their Docker instance. We use the remote API
for everything related with the compute resource not the registry API.
About crane search, that is a problem and it's hard to detect, maybe just
documenting it is fine…
···
>
> Partha
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
–
Daniel Lobato
@elobatoss
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
>> Replies inline:
>>
>> Yesterday I went through the process of setting up and managing
>> docker content in foreman, and came up with a couple of questions.
>>
>> Foreman docker at the present time provides abilities to set up
>> multiple external registries (places where docker content is
>> stored). Katello allows one to manage docker content via the
>> syncing content from external registries plus importing images,
>> etc. It exports the published content and via pulp's crane project
>> provides a simple registry to pull content. Foreman upstream I
>> presume will treat it as one of the supported registries that one
>> can provision content from .
>>
>>
>> I think you're misguided here, a Docker compute resource represents a
>> Docker host, not a Docker registry. So in that sense it doesn't
>> compete with Katello for content, although we do plan to get content
>> from external registries =
>> https://github.com/theforeman/foreman-docker/pull/44
>>
>>
>> This presents the following questions:
>>
>> 1) Do we want to support 2 different ways to manage docker
>> content? In other words do we support the upstream method that
>> foreman provides of just pulling content from external registries,
>> bypassing content set up through the normal Katello create/sync/cv
>> publish promotion process? Should allow users for example to just
>> pull/run a docker image from registry hub directly? I can see this
>> feature useful for upstream foreman, but think its worth
>> discussing here.
>>
>>
>> "Should allow users for example to just pull/run a docker image from
>> registry hub directly" : not having this will equate to crippling
>> Foreman Docker severely. In fact I'd argue for the moment most users
>> won't manage their own registries and I don't see any reason to
>> forcing them to do so. Imagine removing support for any non-katello
>> registered repos.
>>
>> 2) If we want to allow the registry based approach how are we
>> going to be able to control access based on
>> organizations/environment, since the present day docker registry
>> api just allows one to search on any repo by name/description?
>>
>> Also note at this point crane does not offer the search calls
>> needed for the foreman registry functionality to work (last I
>> heard a google search appliance needed to be configured for that
>> to work.)
>>
>>
>> ACLs for the Docker compute resource are in place, and when you make a
>> call through the API to search for images/repositories, you'll search
>> in all registries available to the Docker host as far as I know, so
>> it's something the user will configure in their Docker instance. We
>> use the remote API for everything related with the compute resource
>> not the registry API.
>>
>> About crane search, that is a problem and it's hard to detect, maybe
>> just documenting it is fine…
>
> I agree 100%, the functionality available in foreman should be available
> when katello is there.
>
> However I'm not sure that the functionality that is available in foreman
> is completely sufficient for Katello's docker use case. In this case I
> have synced docker repositories from docker hub and published them in a
> content view to a lifecycle environment. I would expect when i go to to
> deploy a docker container to be able select the which repo/image/tag i
> want from my desired content view and lifecycle environment, and that
> should be limited to what organization I'm in. My guess is some
> addition ui worked in katello needs to be done to deface what is in
> foreman to add addition options when selecting a docker repo/image/tag
> for deployment.
>
that is the part that seems very counter-intuitive. Why should the
Katello plugin have to deface the foreman-docker plugin when this
feature was being built by a single team of engineers trying to produce
a unified solution between the 2 plugins?
foreman-docker should in recognize that Katello is available and act
accordingly.
> Speaking of Organizations, is there a reason why a container isn't
> associated to taxonomies? This seems fairly important if a user has
> Organizations or Locations enabled.
>
that sounds off, not sure why it wouldn't be taxable just like
everything else.
Mike
···
On 11/21/2014 12:55 PM, Justin Sherrill wrote:
> On 11/21/2014 02:18 PM, Daniel Lobato wrote:
--
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248
> From: "Daniel Lobato" <elobatocs@gmail.com>
> To: foreman-dev@googlegroups.com
> Sent: Friday, November 21, 2014 2:18:38 PM
> Subject: Re: [foreman-dev] Questions on managing docker
>
> Replies inline:
>
> Yesterday I went through the process of setting up and managing docker
> > content in foreman, and came up with a couple of questions.
> >
> > Foreman docker at the present time provides abilities to set up multiple
> > external registries (places where docker content is stored). Katello allows
> > one to manage docker content via the syncing content from external
> > registries plus importing images, etc. It exports the published content and
> > via pulp's crane project provides a simple registry to pull content.
> > Foreman upstream I presume will treat it as one of the supported registries
> > that one can provision content from .
> >
>
> I think you're misguided here, a Docker compute resource represents a
> Docker host, not a Docker registry. So in that sense it doesn't compete
> with Katello for content, although we do plan to get content from external
> registries = https://github.com/theforeman/foreman-docker/pull/44
>
Sorry I meant to say when PR 44 merges. Had that checked out in my dev branch when I was testing. So assume that was the case ( indeed the 2 nd one involving registry api also assumes the same and hence the question.)
···
----- Original Message -----
This presents the following questions:
- Do we want to support 2 different ways to manage docker content? In
other words do we support the upstream method that foreman provides of just
pulling content from external registries, bypassing content set up through
the normal Katello create/sync/cv publish promotion process? Should allow
users for example to just pull/run a docker image from registry hub
directly? I can see this feature useful for upstream foreman, but think its
worth discussing here.
“Should allow users for example to just pull/run a docker image from
registry hub directly” : not having this will equate to crippling Foreman
Docker severely. In fact I’d argue for the moment most users won’t manage
their own registries and I don’t see any reason to forcing them to do so.
Imagine removing support for any non-katello registered repos.
- If we want to allow the registry based approach how are we going to be
able to control access based on organizations/environment, since the
present day docker registry api just allows one to search on any repo by
name/description?
Also note at this point crane does not offer the search calls needed for
the foreman registry functionality to work (last I heard a google search
appliance needed to be configured for that to work.)
ACLs for the Docker compute resource are in place, and when you make a call
through the API to search for images/repositories, you’ll search in all
registries available to the Docker host as far as I know, so it’s something
the user will configure in their Docker instance. We use the remote API
for everything related with the compute resource not the registry API.
About crane search, that is a problem and it’s hard to detect, maybe just
documenting it is fine…
Partha
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Daniel Lobato
@elobatoss
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> Replies inline:
>
> Yesterday I went through the process of setting up and managing
> docker content in foreman, and came up with a couple of questions.
>
> Foreman docker at the present time provides abilities to set up
> multiple external registries (places where docker content is
> stored). Katello allows one to manage docker content via the
> syncing content from external registries plus importing images,
> etc. It exports the published content and via pulp's crane project
> provides a simple registry to pull content. Foreman upstream I
> presume will treat it as one of the supported registries that one
> can provision content from .
>
>
> I think you're misguided here, a Docker compute resource represents a
> Docker host, not a Docker registry. So in that sense it doesn't
> compete with Katello for content, although we do plan to get content
> from external registries =
> https://github.com/theforeman/foreman-docker/pull/44
>
>
> This presents the following questions:
>
> 1) Do we want to support 2 different ways to manage docker
> content? In other words do we support the upstream method that
> foreman provides of just pulling content from external registries,
> bypassing content set up through the normal Katello create/sync/cv
> publish promotion process? Should allow users for example to just
> pull/run a docker image from registry hub directly? I can see this
> feature useful for upstream foreman, but think its worth
> discussing here.
>
>
> "Should allow users for example to just pull/run a docker image from
> registry hub directly" : not having this will equate to crippling
> Foreman Docker severely. In fact I'd argue for the moment most users
> won't manage their own registries and I don't see any reason to
> forcing them to do so. Imagine removing support for any non-katello
> registered repos.
>
> 2) If we want to allow the registry based approach how are we
> going to be able to control access based on
> organizations/environment, since the present day docker registry
> api just allows one to search on any repo by name/description?
>
> Also note at this point crane does not offer the search calls
> needed for the foreman registry functionality to work (last I
> heard a google search appliance needed to be configured for that
> to work.)
>
>
> ACLs for the Docker compute resource are in place, and when you make a
> call through the API to search for images/repositories, you'll search
> in all registries available to the Docker host as far as I know, so
> it's something the user will configure in their Docker instance. We
> use the remote API for everything related with the compute resource
> not the registry API.
>
> About crane search, that is a problem and it's hard to detect, maybe
> just documenting it is fine…
I agree 100%, the functionality available in foreman should be available
when katello is there.
However I'm not sure that the functionality that is available in foreman
is completely sufficient for Katello's docker use case. In this case I
have synced docker repositories from docker hub and published them in a
content view to a lifecycle environment. I would expect when i go to to
deploy a docker container to be able select the which repo/image/tag i
want from my desired content view and lifecycle environment, and that
should be limited to what organization I'm in. My guess is some
addition ui worked in katello needs to be done to deface what is in
foreman to add addition options when selecting a docker repo/image/tag
for deployment.
Speaking of Organizations, is there a reason why a container isn't
associated to taxonomies? This seems fairly important if a user has
Organizations or Locations enabled.
-Justin
···
On 11/21/2014 02:18 PM, Daniel Lobato wrote:
Partha
--
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to foreman-dev+unsubscribe@googlegroups.com
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
–
Daniel Lobato
@elobatoss
blog.daniellobato.me http://blog.daniellobato.me
daniellobato.me http://daniellobato.me/
You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com
mailto:foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
>>> Replies inline:
>>>
>>> Yesterday I went through the process of setting up and managing
>>> docker content in foreman, and came up with a couple of questions.
>>>
>>> Foreman docker at the present time provides abilities to set up
>>> multiple external registries (places where docker content is
>>> stored). Katello allows one to manage docker content via the
>>> syncing content from external registries plus importing images,
>>> etc. It exports the published content and via pulp's crane project
>>> provides a simple registry to pull content. Foreman upstream I
>>> presume will treat it as one of the supported registries that one
>>> can provision content from .
>>>
>>>
>>> I think you're misguided here, a Docker compute resource represents a
>>> Docker host, not a Docker registry. So in that sense it doesn't
>>> compete with Katello for content, although we do plan to get content
>>> from external registries =
>>> https://github.com/theforeman/foreman-docker/pull/44
>>>
>>>
>>> This presents the following questions:
>>>
>>> 1) Do we want to support 2 different ways to manage docker
>>> content? In other words do we support the upstream method that
>>> foreman provides of just pulling content from external registries,
>>> bypassing content set up through the normal Katello create/sync/cv
>>> publish promotion process? Should allow users for example to just
>>> pull/run a docker image from registry hub directly? I can see this
>>> feature useful for upstream foreman, but think its worth
>>> discussing here.
>>>
>>>
>>> "Should allow users for example to just pull/run a docker image from
>>> registry hub directly" : not having this will equate to crippling
>>> Foreman Docker severely. In fact I'd argue for the moment most users
>>> won't manage their own registries and I don't see any reason to
>>> forcing them to do so. Imagine removing support for any non-katello
>>> registered repos.
>>>
>>> 2) If we want to allow the registry based approach how are we
>>> going to be able to control access based on
>>> organizations/environment, since the present day docker registry
>>> api just allows one to search on any repo by name/description?
>>>
>>> Also note at this point crane does not offer the search calls
>>> needed for the foreman registry functionality to work (last I
>>> heard a google search appliance needed to be configured for that
>>> to work.)
>>>
>>>
>>> ACLs for the Docker compute resource are in place, and when you make a
>>> call through the API to search for images/repositories, you'll search
>>> in all registries available to the Docker host as far as I know, so
>>> it's something the user will configure in their Docker instance. We
>>> use the remote API for everything related with the compute resource
>>> not the registry API.
>>>
>>> About crane search, that is a problem and it's hard to detect, maybe
>>> just documenting it is fine…
>>
>> I agree 100%, the functionality available in foreman should be available
>> when katello is there.
>>
>> However I'm not sure that the functionality that is available in foreman
>> is completely sufficient for Katello's docker use case. In this case I
>> have synced docker repositories from docker hub and published them in a
>> content view to a lifecycle environment. I would expect when i go to to
>> deploy a docker container to be able select the which repo/image/tag i
>> want from my desired content view and lifecycle environment, and that
>> should be limited to what organization I'm in. My guess is some
>> addition ui worked in katello needs to be done to deface what is in
>> foreman to add addition options when selecting a docker repo/image/tag
>> for deployment.
>>
>
> that is the part that seems very counter-intuitive. Why should the
> Katello plugin have to deface the foreman-docker plugin when this
> feature was being built by a single team of engineers trying to produce
> a unified solution between the 2 plugins?
>
> foreman-docker should in recognize that Katello is available and act
> accordingly.
>
I tend to agree. can we make them aware of each other?
>> Speaking of Organizations, is there a reason why a container isn't
>> associated to taxonomies? This seems fairly important if a user has
>> Organizations or Locations enabled.
>>
>
> that sounds off, not sure why it wouldn't be taxable just like
> everything else.
+1
– bk
···
On 11/21/2014 04:22 PM, Mike McCune wrote:
> On 11/21/2014 12:55 PM, Justin Sherrill wrote:
>> On 11/21/2014 02:18 PM, Daniel Lobato wrote:
Agreed with that. There's no real reason why containers are not taxable at
all. Similarly I think Foreman-docker should recognize that Katello is
around as you said, and offer extra options for the images & registries it
can find there, no need to deface it 
http://projects.theforeman.org/issues/8485
http://projects.theforeman.org/issues/8486
···
On Sun, Nov 23, 2014 at 2:39 AM, Bryan Kearney wrote:
On 11/21/2014 04:22 PM, Mike McCune wrote:
On 11/21/2014 12:55 PM, Justin Sherrill wrote:
On 11/21/2014 02:18 PM, Daniel Lobato wrote:
Replies inline:
Yesterday I went through the process of setting up and managing
docker content in foreman, and came up with a couple of questions.
Foreman docker at the present time provides abilities to set up
multiple external registries (places where docker content is
stored). Katello allows one to manage docker content via the
syncing content from external registries plus importing images,
etc. It exports the published content and via pulp's crane project
provides a simple registry to pull content. Foreman upstream I
presume will treat it as one of the supported registries that one
can provision content from .
I think you’re misguided here, a Docker compute resource represents a
Docker host, not a Docker registry. So in that sense it doesn’t
compete with Katello for content, although we do plan to get content
from external registries =
https://github.com/theforeman/foreman-docker/pull/44
This presents the following questions:
1) Do we want to support 2 different ways to manage docker
content? In other words do we support the upstream method that
foreman provides of just pulling content from external registries,
bypassing content set up through the normal Katello create/sync/cv
publish promotion process? Should allow users for example to just
pull/run a docker image from registry hub directly? I can see this
feature useful for upstream foreman, but think its worth
discussing here.
“Should allow users for example to just pull/run a docker image from
registry hub directly” : not having this will equate to crippling
Foreman Docker severely. In fact I’d argue for the moment most users
won’t manage their own registries and I don’t see any reason to
forcing them to do so. Imagine removing support for any non-katello
registered repos.
2) If we want to allow the registry based approach how are we
going to be able to control access based on
organizations/environment, since the present day docker registry
api just allows one to search on any repo by name/description?
Also note at this point crane does not offer the search calls
needed for the foreman registry functionality to work (last I
heard a google search appliance needed to be configured for that
to work.)
ACLs for the Docker compute resource are in place, and when you make a
call through the API to search for images/repositories, you’ll search
in all registries available to the Docker host as far as I know, so
it’s something the user will configure in their Docker instance. We
use the remote API for everything related with the compute resource
not the registry API.
About crane search, that is a problem and it’s hard to detect, maybe
just documenting it is fine…
I agree 100%, the functionality available in foreman should be available
when katello is there.
However I’m not sure that the functionality that is available in foreman
is completely sufficient for Katello’s docker use case. In this case I
have synced docker repositories from docker hub and published them in a
content view to a lifecycle environment. I would expect when i go to to
deploy a docker container to be able select the which repo/image/tag i
want from my desired content view and lifecycle environment, and that
should be limited to what organization I’m in. My guess is some
addition ui worked in katello needs to be done to deface what is in
foreman to add addition options when selecting a docker repo/image/tag
for deployment.
that is the part that seems very counter-intuitive. Why should the
Katello plugin have to deface the foreman-docker plugin when this
feature was being built by a single team of engineers trying to produce
a unified solution between the 2 plugins?
foreman-docker should in recognize that Katello is available and act
accordingly.
I tend to agree. can we make them aware of each other?
Speaking of Organizations, is there a reason why a container isn’t
associated to taxonomies? This seems fairly important if a user has
Organizations or Locations enabled.
that sounds off, not sure why it wouldn’t be taxable just like
everything else.
+1
– bk
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Daniel Lobato
@elobatoss
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
