1:22 a.m.
Hi.
I wonder if when assigning costs to hardware profiles and hardware profile
properties, I should use the same privilege as would be used when
editing the hardware profile.
That is:
require_privilege(Privilege::MODIFY, @hardware_profile)
My thinking goes:
I don't want a separate path in the UI for assigning costs, as it would
be even more confusing then now. So in the place where you can find the
UI to edit frontend hardware profile I put the cost assignment for
backend profile.
Given it's in almost the same place and from user's point of view it
deals with the hardware profile, then it would be logical to use the
same privilege.
Thoughts?
--
Martin Povolny <mpovolny(a)redhat.com>
tel. +420777714458
4:44 a.m.
On 11/22/2012 07:22 AM, Martin Povolny wrote:
Hi.
I wonder if when assigning costs to hardware profiles and hardware profile
properties, I should use the same privilege as would be used when
editing the hardware profile.
That is:
require_privilege(Privilege::MODIFY, @hardware_profile)
My thinking goes:
I don't want a separate path in the UI for assigning costs, as it would
be even more confusing then now. So in the place where you can find the
UI to edit frontend hardware profile I put the cost assignment for
backend profile.
Given it's in almost the same place and from user's point of view it
deals with the hardware profile, then it would be logical to use the
same privilege.
Thoughts?
Sounds good to me, Martin.
There's a whole other persona associated with deciding what the costs
should be, but the person who actually assigns the costs in Conductor is
likely to be the sys admin who deals with other aspects of hardware
profile management.
Angus
5:34 a.m.
On 26/11/2012, at 8:44 PM, Angus Thomas <athomas(a)redhat.com> wrote:
On 11/22/2012 07:22 AM, Martin Povolny wrote:
> Hi.
>
> I wonder if when assigning costs to hardware profiles and hardware profile
> properties, I should use the same privilege as would be used when
> editing the hardware profile.
>
> That is:
>
> require_privilege(Privilege::MODIFY, @hardware_profile)
>
>
> My thinking goes:
>
> I don't want a separate path in the UI for assigning costs, as it would
> be even more confusing then now. So in the place where you can find the
> UI to edit frontend hardware profile I put the cost assignment for
> backend profile.
>
> Given it's in almost the same place and from user's point of view it
> deals with the hardware profile, then it would be logical to use the
> same privilege.
>
> Thoughts?
>
Sounds good to me, Martin.
There's a whole other persona associated with deciding what the costs should be, but
the person who actually assigns the costs in Conductor is likely to be the sys admin who
deals with other aspects of hardware profile management.
Angus
That is interesting.
So the sysadmin would do the cost constraints management alongside the rest of their
duties but someone else (potentially) would simply want the cost analytics to make generic
cost decisions?
Is that the right way to think about it?
The finance guy gets a dashboard and the sysadmin applies the actual cost setting rules?
5:46 a.m.
On 11/26/2012 11:34 AM, Andrew Fitzsimon wrote:
Is that the right way to think about it?
The finance guy gets a dashboard and the sysadmin applies the actual cost setting rules?
I was thinking that the finance guy decides what the chargeable costs
ought to be, and tells the Admin
In terms of reporting, the finance guy might look at a couple of graphs
in Conductor but, more likely, he gets a CSV export from Conductor, and
loads it up into some spreadsheet application.
I don't think Conductor ever needs to grow beyond fairly simple cost
reporting. There are other apps which do that far better.
5:54 a.m.
+1
CSV export keeps our expectation risk low and helps us concentrate on the admin performing
the actual duties.
On 26/11/2012, at 9:46 PM, Angus Thomas <athomas(a)redhat.com> wrote:
On 11/26/2012 11:34 AM, Andrew Fitzsimon wrote:
> Is that the right way to think about it?
> The finance guy gets a dashboard and the sysadmin applies the actual cost setting
rules?
I was thinking that the finance guy decides what the chargeable costs ought to be, and
tells the Admin
In terms of reporting, the finance guy might look at a couple of graphs in Conductor but,
more likely, he gets a CSV export from Conductor, and loads it up into some spreadsheet
application.
I don't think Conductor ever needs to grow beyond fairly simple cost reporting. There
are other apps which do that far better.
3:23 a.m.
On 26/11/2012, at 12:46 PM, Angus Thomas wrote:
On 11/26/2012 11:34 AM, Andrew Fitzsimon wrote:
> Is that the right way to think about it?
> The finance guy gets a dashboard and the sysadmin applies the actual cost setting
rules?
I was thinking that the finance guy decides what the chargeable costs ought to be, and
tells the Admin
Yeah. That matches my SysAdmin-ing experience in most places too. SysAdmin guy asks the
relevant business unit what the values are which need typing in. They email him back
with
the values, plus any updates when they come along. (ie 6 monthly price changing or
whatever)
+ Justin
--
Aeolus Cloud Evangelist
http://www.aeolusproject.org
12:26 a.m.
On 11/22/2012 02:22 AM, Martin Povolny wrote:
Hi.
I wonder if when assigning costs to hardware profiles and hardware profile
properties, I should use the same privilege as would be used when
editing the hardware profile.
That is:
require_privilege(Privilege::MODIFY, @hardware_profile)
My thinking goes:
I don't want a separate path in the UI for assigning costs, as it would
be even more confusing then now. So in the place where you can find the
UI to edit frontend hardware profile I put the cost assignment for
backend profile.
Given it's in almost the same place and from user's point of view it
deals with the hardware profile, then it would be logical to use the
same privilege.
Thoughts?
Hmm -- so you're editing provider HWPs here not conductor/front-end ones
right? If we're associating with front-end profiles, the above sounds
exactly right to me -- if you can edit the HWP, you can edit its cost.
However, my understanding of this whole model is we're associating costs
with the provider-end HWPs. Provider HWPs aren't editable at all right
now -- we pull them from deltacloud and don't change them. As such, I
think you would instead want to check permissions on the provider. i.e.
if you can edit the provider, you can edit the HWP privileges:
require_privilege(Privilege::MODIFY, @hardware_profile.provider)
As a variation on this, if we have reason to separate users here -- and
have one user that can edit costs but not basic provider stats, we can
handle that too. In that case we want to check for "modify Hardware
Profile" privileges, but on the provider (since, again we don't track
this at the provider HWP level but on the HWP itself.
i.e. you'd want this:
require_privilege(Privilege::MODIFY, HardwareProfile,
@hardware_profile.provider)
(I think I have the syntax correct above)
Then to support the use case for allowing only people that have provider
edit privileges edit these costs, we'd add the (Privilege::MODIFY,
HardwareProfile) privilege to the same roles that currently allow
provider modification.
There's one other complication here -- prior discussions with athomas
were suggesting that we actually drop HWP-oriented permissions entirely
(since we're not really using them now - -but the system is enforcing
them), so I'm not sure how this subject affects that idea.
Scott
4175
days inactive
4180
days old
aeolus-devel@lists.fedorahosted.org
6 comments
5 participants
participants (5)
-
Andrew Fitzsimon -
Angus Thomas -
Justin Clift -
Martin Povolny -
Scott Seago