[katello-devel] Future feature RFC: Package Upload

[Bryan Kearney]

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
>
>> [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.

>
>>> 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.

>
>>> 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 :)

-- bk