I am trying to port the demo script to hammer. So far, so good
I have a question about how the cli should behave for importing a
manifest. I will submit bugs once I have agreement on how it should go.
In the UI, I do the following:
A) Login
B) Go to Red Hat Subscriptions
C) Import
In the CLI, should I create a provider first, or should there be a
single "import_manifest" command equivilant to B which I assume creates
a red hat provider and then does the import?
On a related note, the new UI is starting to downplay providers. Should
the CLI keep the concept in there?
> I am trying to port the demo script to hammer. So far, so good
>
> I have a question about how the cli should behave for importing a
> manifest. I will submit bugs once I have agreement on how it should go.
>
> In the UI, I do the following:
>
> A) Login
> B) Go to Red Hat Subscriptions
> C) Import
>
> In the CLI, should I create a provider first, or should there be a single
> "import_manifest" command equivilant to B which I assume creates a red hat
> provider and then does the import?
>
A red hat provider is created for each organization automatically. Thus, I
think you should just have an import_manifest command where you specify the
organization to import into.
> On a related note, the new UI is starting to downplay providers. Should
> the CLI keep the concept in there?
No.
···
On Thu, Jan 16, 2014 at 12:49 PM, Bryan Kearney wrote:
My thinking, unfiltered by deep consideration, is this: Providers remain behind the scenes but are not exposed anywhere to the user (neither CLI nor UI). The previous "Red Hat" provider features get moved to the organization level (again, behind the scenes they are still really trickling down to the provider).
The reason I suggest keeping providers around is for the case, hopefully in the near future, where multiple subscription manifests may be imported. I'm afraid of chopping them out completely before we have a firm grasp on what the implications on subscriptions is.
···
----- Original Message -----
> From: "Eric D Helms"
> To: "foreman-dev"
> Sent: Thursday, January 16, 2014 1:55:41 PM
> Subject: Re: [foreman-dev] [Katello] How should importing a manifest work in the CLI
>
> On Thu, Jan 16, 2014 at 1:52 PM, Bryan Kearney > wrote:
>
> > On 01/16/2014 01:50 PM, Eric D Helms wrote:
> >
> >>
> >> No.
> >>
> >> What is the future plan for providers?
>
>
> Basically, remove them from the users interaction. See
> https://trello.com/c/NA9PljNV/295-remove-content-providers for details of
> current on going work.
>
>
> >
> >
> > -- 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/groups/opt_out.
> >
>
> --
> 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/groups/opt_out.
>
>
>
>> From: "Eric D Helms" <ericdhelms@gmail.com>
>> To: "foreman-dev" <foreman-dev@googlegroups.com>
>> Sent: Thursday, January 16, 2014 1:55:41 PM
>> Subject: Re: [foreman-dev] [Katello] How should importing a manifest work in the CLI
>>
>>
>>>
>>>>
>>>> No.
>>>>
>>>> What is the future plan for providers?
>>
>>
>> Basically, remove them from the users interaction. See
>> https://trello.com/c/NA9PljNV/295-remove-content-providers for details of
>> current on going work.
>>
>>
>>>
>>>
>>> – 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/groups/opt_out.
>>>
>>
>> –
>> 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/groups/opt_out.
>>
>
> My thinking, unfiltered by deep consideration, is this: Providers remain behind the scenes but are not exposed anywhere to the user (neither CLI nor UI). The previous "Red Hat" provider features get moved to the organization level (again, behind the scenes they are still really trickling down to the provider).
>
> % hammer subscriptions import --organization ACME --file manifest.zip
>
+1
> The reason I suggest keeping providers around is for the case, hopefully in the near future, where multiple subscription manifests may be imported. I'm afraid of chopping them out completely before we have a firm grasp on what the implications on subscriptions is.
without looking at the datamodel the fact that you want to import
multiple manifests should NOT require a 1:1 relationship to
Manifest:Provider, and subsequently NOT require that you create multiple
RH providers per import in an Org. Hopefully we aren't tied to this 1:1
concept.
Mike
···
On 01/16/2014 12:10 PM, Tom McKay wrote:
> ----- Original Message -----
>> On Thu, Jan 16, 2014 at 1:52 PM, Bryan Kearney >> wrote:
>>> On 01/16/2014 01:50 PM, Eric D Helms wrote:
–
Mike McCune
mmccune AT redhat.com
Red Hat Engineering | Portland, OR
Systems Management | 650-254-4248
