[katello-devel] Future feature RFC: Package Upload

Wed Mar 21 00:16:45 UTC 2012

On 03/20/2012 04:58 PM, James Labocki wrote:
> ----- Original Message -----
>> From: "Bryan Kearney"<bkearney at redhat.com>
>> To: katello-devel at redhat.com
>> Sent: Tuesday, March 20, 2012 12:58:28 PM
>> Subject: Re: [katello-devel] Future feature RFC: Package Upload
>>
>> On 03/20/2012 12:50 PM, Mike McCune wrote:
>>> On 03/20/2012 06:33 AM, Brad Buckingham wrote:
>>>>
>>>> On 03/20/2012 08:30 AM, Todd Sanders wrote:
>>>>> On 03/19/2012 03:25 PM, Brad Buckingham wrote:
>>>>>> In the future, the plan is to provide Katello users with the
>>>>>> ability
>>>>>> to upload a package. This email is to present a couple of
>>>>>> options
>>>>>> for accomplishing this in the UI and gather some initial
>>>>>> feedback.
>>>>>>
>>>>>> Assumptions:
>>>>>> - Prior to package upload, the target repository must exist.
>>>>>> - When a package is uploaded, it will be uploaded only to the
>>>>>> Library.
>>>>>>
>>>>>> The following are a couple of options for accomplishing this in
>>>>>> the UI:
>>>>>>
>>>>>> 1. Incorporate it as part of Content Management ->  Custom
>>>>>> Content
>>>>>> Providers
>>>>>>
>>>>>> For example,
>>>>>> a. select [provider] ->  Products&  Repos ->  [repository]
>>>>>> b. from the Repository Details subpanel, allow the user the
>>>>>> ability to browse
>>>>>> to a package file and click 'Upload'
>>>>>>
>>>>>> 2. Incorporate it as part of Content Management ->  Promotions
>>>>>>
>>>>>> For example,
>>>>>> a. in the content tree, navigate to Repos
>>>>>> b. select the repo. (Note: currently, users can see repos
>>>>>> listed, but not select them).
>>>>>> c. from the Repository Details pane (new), allow the user the
>>>>>> ability to browse
>>>>>> to a package file and click 'Upload'. (Notes: We could also
>>>>>> use this pane to display
>>>>>> a few details on the repository, such as name, url and other
>>>>>> useful info.).
>>>>>>
>>>>>> I lean towards option 2 for a couple of reasons:
>>>>>> - Before a user adds a package, they are likely to browse to see
>>>>>> what
>>>>>> packages exist. Currently, this would be done from the
>>>>>> Promotions
>>>>>> page; therefore, they would already be on the page.
>>>>>> - In the future, users will have the ability to download
>>>>>> packages.
>>>>>> Assuming this will be based on earlier implementations, this
>>>>>> would be
>>>>>> from the Promotions page; therefore, having both upload/download
>>>>>> on
>>>>>> Promotions keeps it 'somewhat' consistent.
>>>>>>
>>>>>> There may be other options as well.
>>>>>>
>>>>>> Any thoughts/opinions/preferences?
>>>>>>
>>>>>> Thanks,
>>>>>> Brad
>>>>>>
>>>>>> _______________________________________________
>>>>>> katello-devel mailing list
>>>>>> katello-devel at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/katello-devel
>>>>>
>>>> [brad] Folks, A lot of great feedback. Thanks! As a next step,
>>>> will
>>>> create a wiki page to outline the requirements for the feature.
>>>> For
>>>> integration in the UI, will assume that this will be part of the
>>>> overall
>>>> content browser solution, so we'll work the details of UI
>>>> look/design as
>>>> part of that bigger feature.
>>>>
>>>>> Couple of comments here:
>>>>>
>>>>> 1. Let's not reinvent the wheel here, the heavy lifting has
>>>>> already
>>>>> been done in Pulp. We should expose the same set of functionality
>>>>> that Pulp provides with regards to package uploads via it's cli.
>>>>> See:
>>>>> http://pulpproject.org/ug/UGContent.html#upload
>>>>>
>>>
>>> definite big +1
>
> +1
>
>>>
>>>> [brad] +1. I had looked over the REST APIs, but not the CLI.
>>>> Thanks
>>>> for the pointer.
>>>>> 2. Package uploads are only valid for "Custom" Providers.
>>>>>
>>>> [brad] +1. That was the intent.
>>>>> 3. We need to support both uploading single packages and/or
>>>>> *directories* of packages to the Library, and only to the
>>>>> Library.
>>>>> IMO, the best place for this functionality would be within a
>>>>> content
>>>>> browser either (a) from a screen where the user is browsing all
>>>>> packages in the Library, or (b) from a screen where the where the
>>>>> user
>>>>> is browsing all packages scoped to a repository in the Library.
>>>>> Isn't
>>>>> the content browser functionality targeted for our next release?
>>>>>
>>>> [brad] Thanks for the input regarding the needs. Based on the
>>>> clarifications on what Katello will need to support, the content
>>>> browser
>>>> is the better fit, as it doesn't really fit in to the existing
>>>> capabilities. Content browser is planned for the next release.
>>>> We'll
>>>> need to get the discussions rolling on that one, if they haven't
>>>> already, since this would be a small piece of that bigger
>>>> solution.
>>>
>>> directory uploads would be awesome, unfortunately without something
>>> like
>>> Flash or Java there is no way to upload a directory of files with a
>>> browser, you can only do a file-by-file approach with pure
>>> JavaScript
>>> and HTML. More info here:
>>>
>>> http://stackoverflow.com/questions/254251/what-is-the-best-way-to-upload-a-folder-to-a-website
>>>
>>>
>>> just something to keep in mind. For the CLI this won't be an issue
>>> but
>>> for our WebUI we won't be able to do a whole directory.
>>
>> IMHO.. simple at first. package only. If we want a fancy directory,
>> make
>> a provider which supports a local directory and polls.
>
> What about supporting upload of an archive containing multiple packages instead?
>

I like this, you can just put messaging in the UI:

"You can upload a single zip or tar file containing packages as long as 
the archive contains all the files in the root of the archive.  Katello 
will expand and import these RPMs".

>>
>>>
>>>>> 4. Packages should be able to exist without repository
>>>>> associations.
>>>>> Meaning I can upload to server, then associate with one or more
>>>>> repositories. This could be done in a single operation for
>>>>> convenience, but not required.
>>>>>
>>>> [brad] Good point. It would provide more flexibility to not force
>>>> it as
>>>> a single operation.
>>>
>>> what is the real use case for 'repoless' packages? Do people really
>>> use
>>> this that often? I ask because it will require us to write
>>> UI/CLI/API to
>>> manage packages that live outside of a repository which we really
>>> don't
>>> have any notion of now. Just making sure that this is something we
>>> really need. Wondering if we can start by forcing all packages to
>>> be at
>>> least a member of one or more repos and if people really want
>>> repoless
>>> packages we can do that too.
>>
>> +1. KISS for first cut.
>
> I don't see a reason to support packages outside of a repository. Could we provide an option to create a repository named after the package is uploaded? For example, I try to upload httpd-2.0.rpm and there is an option to create a repository with the package instead of selecting an already existing repository?
>

good idea ...

>>
>>>
>>>>> 5. Packages that already exist in a Library repository should be
>>>>> able
>>>>> to be associated and un-associated from other Library
>>>>> repositories.
>>>>>
>>>> [brad] +1
>>>>> 6. We need to support chunked uploads; and the upload should be
>>>>> able
>>>>> to resume if restarted after a failure.
>>>>>
>>>> [brad] +1
>>>
>>> definitely good but will have some interesting technical challenges
>>> from
>>> a browser's perspective.
>>
>>
>> The main scenario I have heard is cli. I would be willing, honestly,
>> to
>> make most the features cli :)
>
> While I agree with that, I'm not sure it will go over well with the Windows users. IMO, if we want to go after a broader user base we need to support it in the WUI too.

agreed, I'm not in favor of gross missmatches between CLI and WebUI.  We 
should offer the feature in some way in the webui, even if it isn't as 
fully featured as the CLI.

--
Mike McCune
mmccune AT redhat.com
Red Hat Engineering       | Portland, OR
Systems Management        | 650.254.4248