Re: [Pulp-dev] Pulp3 Ansible Installer Temporarily Removal and Unification

[Jeremy Audet]

I'd like to request that we actually do something different:

   1. For now, leave the ansible-pulp3 installer alone. If someone makes a
   good pull request, we merge it. Otherwise, we leave it alone.
   2. Work on the Ansible code in pulp/devel. Make it satisfy developer,
   QE, and eventually end-user use cases.
   3. Once the Ansible code in pulp/devel is good enough, move it into the
   ansible-pulp3 repository, and publish it as a role. Do future development
   work there.

I'm confident that this will produce some good results. Using this
approach, *I've made the pulp/devel Ansible installer support RHEL 7.* I'm
sure I could also accomplish other goals like making it easy to switch
between AMQP brokers, web servers, etc. I'd love it if y'all could start
reviewing my pull requests against pulp/devel
.
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Pulp3 Ansible Installer Temporarily Removal and Unification

[Brian Bouterse]

[update]

Delete the ansible installation section from the Pulp3 docs (
https://pulp.plan.io/issues/3437)   <--- on the sprint
Strip down the dev environment to match a vanilla install (
https://pulp.plan.io/issues/3438)   <-- deleted and replaced by "Replace
Pulp3 dev installer with the actual Pulp ansible" which is (
https://pulp.plan.io/issues/3452)
Update Jenkins Jobs to not use Ansible Installer (
https://pulp.plan.io/issues/3439) <--- still needs grooming

On Tue, Mar 6, 2018 at 4:28 PM, Brian Bouterse  wrote:

> There has been discussion on how to unify the 3-4 different Ansible
> installers. I want to recap the current thinking and planned changes that
> have come out of those discussions. The following 3 pieces of work are
> being proposed, in hopes of being groomed by another core member barring
> any -1s.
>
>
> Delete the ansible installation section from the Pulp3 docs (
> https://pulp.plan.io/issues/3437)
> Strip down the dev environment to match a vanilla install (
> https://pulp.plan.io/issues/3438)
> Update Jenkins Jobs to not use Ansible Installer (
> https://pulp.plan.io/issues/3439)
>
>
> ^ will remove Pulp's existing usages of the Ansible installer to free it
> up to be unified and then brought back sometime after core is in beta.
> @PieterLexis has contributed to this role (https://github.com/pulp/
> ansible-pulp3/pull/6) which likely will be the best role/playbook to
> adopt to do both source and pypi installs while the others would be deleted.
>
> I hope these three issues can be groomed and all added to this sprint. Any
> feedback, questions, ideas are welcome either here or on the issue.
>
> Thanks!
> Brian
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Importer Name

[Brian Bouterse]

I left some responses inline.

On Thu, Mar 8, 2018 at 11:13 AM, Austin Macdonald  wrote:

> Motivation:
> The name "importer" carries some inaccurate implications.
> 1) Importers should "import". Tasks like "sync" will do the actual
> importing. The object only holds the configuration that happens to be used
> by sync tasks.
> 2) Sync tasks on mirror mode remove content as well as add it, so "import"
> isn't quite right.
>
> Proposed name: Remote
>
> The inspiration for remote is "git remote". In git, remotes represent
> external repositories, which is almost exactly what our importers do.
>

I'm +0 thinking that either name is fine but that those unfamiliar with
git, but those familiar with git would benefit from the name change.


>
> ---
> Part 2: Trim the fields
>
> Currently, Importers have settings that can be categorized in 2 ways. I am
> proposing removing the "sync settings" from the Remote model:
>
> External Source information
> name
> feed_url
> validate
> ssl_ca_certificate
> ssl_client_certificate
> ssl_client_key
> ssl_validation
> proxy_url
> username
> password
>
> Sync settings
> download_policy
> sync_mode
>
> This had some advantages when Importers were related to Repositories. For
> example, having a repository.importer that always used the same sync mode
> made sense. However, the "how" to sync settings don't make much sense when
> importers and repositories are not linked. It seems very reasonable that a
> user might have 2 repositories that sync from the same source (ex EPEL). It
> does not make sense for them to have create an Importer for the EPEL
> repository twice or more just to change sync_mode or download policy.
> Instead of modeling these fields, I propose that they should POST body
> parameters.
>
> example
>
> POST v3/remotes/1234/sync/ repositorty=myrepo_href sync_mode=additive,
> dl_policy=immediate
> POST v3/remotes/1234/sync/ repositorty=myother_href sync_mode=mirror,
> dl_policy=deferred
>

+1 to this change. I think this makes sense to specify the sync_mode and
dl_policy with sync params with each download because the Importer having
one policy apply to any repo that uses it does not make much sense.


>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev