While working on getting Foreman core tests to run with Katello enabled,
the predominant failure for tests is the fact that Katello adds attributes
to the User object. Further, because we need a User to talk to the backends
(Pulp and Candlepin) we use Dynflow and ActiveRecord hooks to ensure that a
remote_id is generated for each user and that the user is created in the
proper backends.
Some of the attributes on the user are legacy from when Katello was
stand-alone and are not used anymore. The most important attribute is the
remote_id that we store to identify and keep our user in sync with the
backend user. In the case of Candlepin, we only use the anonymous admin to
perform communication. In the case of Pulp, we create a user in Pulp for
every user created. This was, as I understand it, originally intended so
that we could track the actions performed in Pulp by the user that
performed them. To date, and as far as I know, this is not used at all.
Given that background, approaches we could take to alleviate having to skip
so many tests:
Remove all Katello attributes from the User object, and use only the
anonymous admin user for performing actions in Pulp and Candlepin
Dynflowize User actions in Foreman and then have Katello hook into those
Perform controller action overrides to drive create/update/delete
through Katello's Dynflow user actions
> All,
>
> While working on getting Foreman core tests to run with Katello enabled,
> the predominant failure for tests is the fact that Katello adds attributes
> to the User object. Further, because we need a User to talk to the backends
> (Pulp and Candlepin) we use Dynflow and ActiveRecord hooks to ensure that a
> remote_id is generated for each user and that the user is created in the
> proper backends.
>
> Some of the attributes on the user are legacy from when Katello was
> stand-alone and are not used anymore. The most important attribute is the
> remote_id that we store to identify and keep our user in sync with the
> backend user. In the case of Candlepin, we only use the anonymous admin to
> perform communication. In the case of Pulp, we create a user in Pulp for
> every user created. This was, as I understand it, originally intended so
> that we could track the actions performed in Pulp by the user that
> performed them. To date, and as far as I know, this is not used at all.
>
> Given that background, approaches we could take to alleviate having to skip
> so many tests:
>
> 1) Remove all Katello attributes from the User object, and use only the
> anonymous admin user for performing actions in Pulp and Candlepin
Revisiting the use of remote user is worth doing IMO
···
----- Original Message -----
Dynflowize User actions in Foreman and then have Katello hook into those
Perform controller action overrides to drive create/update/delete
through Katello’s Dynflow user actions
>
>
> > All,
> >
> > While working on getting Foreman core tests to run with Katello enabled,
> > the predominant failure for tests is the fact that Katello adds
> attributes
> > to the User object. Further, because we need a User to talk to the
> backends
> > (Pulp and Candlepin) we use Dynflow and ActiveRecord hooks to ensure
> that a
> > remote_id is generated for each user and that the user is created in the
> > proper backends.
> >
> > Some of the attributes on the user are legacy from when Katello was
> > stand-alone and are not used anymore. The most important attribute is the
> > remote_id that we store to identify and keep our user in sync with the
> > backend user. In the case of Candlepin, we only use the anonymous admin
> to
> > perform communication. In the case of Pulp, we create a user in Pulp for
> > every user created. This was, as I understand it, originally intended so
> > that we could track the actions performed in Pulp by the user that
> > performed them. To date, and as far as I know, this is not used at all.
> >
> > Given that background, approaches we could take to alleviate having to
> skip
> > so many tests:
> >
> > 1) Remove all Katello attributes from the User object, and use only the
> > anonymous admin user for performing actions in Pulp and Candlepin
>
> Revisiting the use of remote user is worth doing IMO
>
As in another user, similar to anonymous admin but whose only use is
performing remote actions?
···
On Fri, Jun 5, 2015 at 4:55 AM, Ivan Necas wrote:
> ----- Original Message -----
Dynflowize User actions in Foreman and then have Katello hook into
those
Perform controller action overrides to drive create/update/delete
through Katello’s Dynflow user actions
Interesting, I can not remember why we had users unless it was to
leverage back end security. Since these systems are effectively
databases, I think it is fine to remove the unique users. I know for
candlepin some of the commands are proxied, would this still work?
– bk
···
On 06/05/2015 07:40 AM, Eric D Helms wrote:
>
> Revisiting the use of remote user is worth doing IMO
>
>
> As in another user, similar to anonymous admin but whose only use is
> performing remote actions?
>
>
>
>
>
> > All,
> >
> > While working on getting Foreman core tests to run with Katello
> enabled,
> > the predominant failure for tests is the fact that Katello adds
> attributes
> > to the User object. Further, because we need a User to talk to
> the backends
> > (Pulp and Candlepin) we use Dynflow and ActiveRecord hooks to
> ensure that a
> > remote_id is generated for each user and that the user is
> created in the
> > proper backends.
> >
> > Some of the attributes on the user are legacy from when Katello was
> > stand-alone and are not used anymore. The most important
> attribute is the
> > remote_id that we store to identify and keep our user in sync
> with the
> > backend user. In the case of Candlepin, we only use the
> anonymous admin to
> > perform communication. In the case of Pulp, we create a user in
> Pulp for
> > every user created. This was, as I understand it, originally
> intended so
> > that we could track the actions performed in Pulp by the user that
> > performed them. To date, and as far as I know, this is not used
> at all.
> >
> > Given that background, approaches we could take to alleviate
> having to skip
> > so many tests:
> >
> > 1) Remove all Katello attributes from the User object, and use
> only the
> > anonymous admin user for performing actions in Pulp and Candlepin
>
> Revisiting the use of remote user is worth doing IMO
>
>
> As in another user, similar to anonymous admin but whose only use is
> performing remote actions?
My vote would just be to use the 'admin' user defined in pulp
server.conf (and katello.yaml), except for the consumer requests as ivan
said. Although maybe we could just use the 'admin' user for that as
well? This way we would never have to create a single user in pulp
since the 'admin' user is created at installation by pulp itself.
-Justin
···
On 06/05/2015 07:40 AM, Eric D Helms wrote:
> On Fri, Jun 5, 2015 at 4:55 AM, Ivan Necas > wrote:
> ----- Original Message -----
> 2) Dynflowize User actions in Foreman and then have Katello hook
into those
> 3) Perform controller action overrides to drive create/update/delete
> through Katello's Dynflow user actions
>
>
> Opinions?
>
>
> Eric
>
> --
> 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
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.
>
--
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
<mailto:foreman-dev%2Bunsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
> Interesting, I can not remember why we had users unless it was to leverage
> back end security. Since these systems are effectively databases, I think
> it is fine to remove the unique users. I know for candlepin some of the
> commands are proxied, would this still work?
We make all Pulp users admins in Pulp anyway so that any action could be
performed assuming they have the right Foreman/Katello permissions. If I
recall correctly, we were doing the individual users as a potential form of
auditing from within Pulp itself. Proxied Candlepin commands are still
authorized at the user or client level and non-proxied calls to Candlepin
just use the hidden admin user to perform actions. We "pass" a user to
Candlepin in the headers, but it is effectively ignored.
···
On Fri, Jun 5, 2015 at 7:53 AM, Bryan Kearney wrote:
– bk
On 06/05/2015 07:40 AM, Eric D Helms wrote:
Revisiting the use of remote user is worth doing IMO
As in another user, similar to anonymous admin but whose only use is
performing remote actions?
> Interesting, I can not remember why we had users unless it was to
> leverage back end security. Since these systems are effectively
> databases, I think it is fine to remove the unique users. I know for
> candlepin some of the commands are proxied, would this still work?
IIRC this are the cases, when the user of the request is
a consumer, in other words: registered subscription manager: we should
keep this and let the canclepin to authenticate those. But consumers
don't use the Foreman user object so we are good here.
– Ivan
···
----- Original Message -----
– bk
On 06/05/2015 07:40 AM, Eric D Helms wrote:
Revisiting the use of remote user is worth doing IMO
As in another user, similar to anonymous admin but whose only use is
performing remote actions?
This change has been completed in the latest Katello master. All database
user attributes that Katello added to the Foreman user object have been
removed along with some things like the slightly defunct 'Content Notices'.
Authentication with Pulp is now no longer on a per user basis and relies on
the admin user created by default by Pulp. Thanks all for the input and
code reviews!
···
On Mon, Jun 8, 2015 at 1:30 PM, Justin Sherrill wrote:
While working on getting Foreman core tests to run with Katello enabled,
the predominant failure for tests is the fact that Katello adds
attributes
to the User object. Further, because we need a User to talk to the
backends
(Pulp and Candlepin) we use Dynflow and ActiveRecord hooks to ensure
that a
remote_id is generated for each user and that the user is created in the
proper backends.
Some of the attributes on the user are legacy from when Katello was
stand-alone and are not used anymore. The most important attribute is
the
remote_id that we store to identify and keep our user in sync with the
backend user. In the case of Candlepin, we only use the anonymous admin
to
perform communication. In the case of Pulp, we create a user in Pulp for
every user created. This was, as I understand it, originally intended so
that we could track the actions performed in Pulp by the user that
performed them. To date, and as far as I know, this is not used at all.
Given that background, approaches we could take to alleviate having to
skip
so many tests:
Remove all Katello attributes from the User object, and use only the
anonymous admin user for performing actions in Pulp and Candlepin
Revisiting the use of remote user is worth doing IMO
As in another user, similar to anonymous admin but whose only use is
performing remote actions?
My vote would just be to use the ‘admin’ user defined in pulp server.conf
(and katello.yaml), except for the consumer requests as ivan said.
Although maybe we could just use the ‘admin’ user for that as well? This
way we would never have to create a single user in pulp since the 'admin’
user is created at installation by pulp itself.
-Justin
Dynflowize User actions in Foreman and then have Katello hook into
those
Perform controller action overrides to drive create/update/delete
through Katello’s Dynflow user actions
> This change has been completed in the latest Katello master. All database
> user attributes that Katello added to the Foreman user object have been
> removed along with some things like the slightly defunct 'Content Notices'.
> Authentication with Pulp is now no longer on a per user basis and relies on
> the admin user created by default by Pulp. Thanks all for the input and
> code reviews!
>
well done! is there other user properties we should consider moving? e.g
the "user preferences" ?
thanks,
Ohad
···
On Tue, Jun 16, 2015 at 7:24 PM, Eric D Helms wrote:
On Mon, Jun 8, 2015 at 1:30 PM, Justin Sherrill jsherril@redhat.com > wrote:
While working on getting Foreman core tests to run with Katello
enabled,
the predominant failure for tests is the fact that Katello adds
attributes
to the User object. Further, because we need a User to talk to the
backends
(Pulp and Candlepin) we use Dynflow and ActiveRecord hooks to ensure
that a
remote_id is generated for each user and that the user is created in
the
proper backends.
Some of the attributes on the user are legacy from when Katello was
stand-alone and are not used anymore. The most important attribute is
the
remote_id that we store to identify and keep our user in sync with the
backend user. In the case of Candlepin, we only use the anonymous
admin to
perform communication. In the case of Pulp, we create a user in Pulp
for
every user created. This was, as I understand it, originally intended
so
that we could track the actions performed in Pulp by the user that
performed them. To date, and as far as I know, this is not used at all.
Given that background, approaches we could take to alleviate having to
skip
so many tests:
Remove all Katello attributes from the User object, and use only the
anonymous admin user for performing actions in Pulp and Candlepin
Revisiting the use of remote user is worth doing IMO
As in another user, similar to anonymous admin but whose only use is
performing remote actions?
My vote would just be to use the ‘admin’ user defined in pulp server.conf
(and katello.yaml), except for the consumer requests as ivan said.
Although maybe we could just use the ‘admin’ user for that as well? This
way we would never have to create a single user in pulp since the 'admin’
user is created at installation by pulp itself.
-Justin
Dynflowize User actions in Foreman and then have Katello hook into
those
Perform controller action overrides to drive create/update/delete
through Katello’s Dynflow user actions
If there is an existing use case for which to implement the user
preferences then it would be worth porting. In the previous Katello uses
cases, the preferences were used to store things like per user page sizes,
locale, dashboard widget arrangements, and help tips (whether a particular
one was open or closed). As for other properties we were adding, most were
legacy or hold overs already implemented at some point by the Foreman user.
···
>
--
Eric D. Helms
Red Hat Engineering
Ph.D. Student - North Carolina State University
