[katello-devel] Future feature RFC: Package Upload

[Todd Sanders]

On 03/20/2012 12:58 PM, Bryan Kearney wrote:
> 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.

Fine, but not Satellite replacement. Having to select every single rpm 
in a directory is silly, and having to run createrepo locally just to be 
able to sync...well sillier.

This should be trivial in the CLI....cut-n-paste is pretty simple.

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

Again, this is already supported by Pulp.  Aren't we really just talking 
about client interfaces (web-ui and CLI)?  The app logic should be 
entirely in the Pulp black-box, right?

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

+1 for priority being CLI.

-Todd
>
> -- bk
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel