I''ve been tinkering around with managing users and am concerned with
the
overall administrative usability of the inheritance overrides.
For instance, the user games:
redhat_base:
user { games: ensure => present }
local_site inherits redhat_base:
User[games] { ensure => absent }
This is fine, but imagine a few levels of nesting later with an admin that
wants to ensure that a user is absent that isn''t defined higher up and
also
ensure that games is absent.
example inherits local_site:
# The intuitive way to do this is to do :
user {
baduser: ensure => absent
games: ensure => absent
}
# But this breaks saying that ''games'' is previously defined,
so you have to
do:
user{ baduser: ensure => absent }
User[games] { ensure => absent }
# Which, I believe is really unintuitive and breaks if someone higher up in
the maintenance chain decides to start managing baduser.
Is there some way to make the intuitive method work? Obviously, testing
should fix all of this, but it seems bad when managing something early in
the inheritance chain breaks something lower down that previously had
completely correct syntax.
Thanks,
Trevor
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
On Jan 25, 2007, at 11:02 AM, Trevor Vaughan wrote:> I''ve been tinkering around with managing users and am concerned > with the overall administrative usability of the inheritance > overrides. > > For instance, the user games: > > redhat_base: > > user { games: ensure => present } > > local_site inherits redhat_base: > > User[games] { ensure => absent } > > This is fine, but imagine a few levels of nesting later with an > admin that wants to ensure that a user is absent that isn''t defined > higher up and also ensure that games is absent. > > example inherits local_site: > > # The intuitive way to do this is to do : > > user { > baduser: ensure => absent > games: ensure => absent > } > > # But this breaks saying that ''games'' is previously defined, so you > have to do: > > user{ baduser: ensure => absent } > User[games] { ensure => absent } > > # Which, I believe is really unintuitive and breaks if someone > higher up in the maintenance chain decides to start managing baduser. > > Is there some way to make the intuitive method work? Obviously, > testing should fix all of this, but it seems bad when managing > something early in the inheritance chain breaks something lower > down that previously had completely correct syntax.While I agree with you that this can get somewhat cumbersome, it seems like you''ve got a cumbersome design, which might be having a larger impact than the syntax. Why does the example class inherit local_site? It''s redundantly overriding the games user, which (from your limited example) is the only apparent link between the two classes. It seems that the only reason is because the person writing ''example'' does not feel the need to know what is in the base classes. Puppet classes aren''t so powerful that their developers can currently afford to ignore the contents of parent classes, I think. So, while the problem you describe exists in theory, I''m not convinced it exists in real life. -- It''s not to control, but to protect the citizens of Singapore. In our society, you can state your views, but they have to be correct. -- Ernie Hai, co-ordinator of the Singapore Government Internet Project --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
It stems from a problem with lower level management of systems. For instance: 1) The Campus SA''s manage the base build 2) The Departmental level SA''s manage the department build and can''t directly modify 1 3) The student lab level SA''s (students) manage the lab level build and can''t directly modify 1 or 2 4) The lab sub-research group (more students) manage their subgroup and can''t directly modify 1 or 2 or 3 It may seem a bit silly, but that''s the territory that comes with University-style bureaucracy and, while I would love (truly) to get rid of the middle men, this was the design that the manglement wanted for control and extensibility. But, it also makes it really difficult to make sure you''re keeping track of EVERYTHING in all of the levels of inheritance. Also, the more that I thought about it, the more I saw the potential applications of this in corporate environments. Thanks, Trevor On 1/25/07, Luke Kanies <luke@madstop.com> wrote:> > On Jan 25, 2007, at 11:02 AM, Trevor Vaughan wrote: > > > I''ve been tinkering around with managing users and am concerned > > with the overall administrative usability of the inheritance > > overrides. > > > > For instance, the user games: > > > > redhat_base: > > > > user { games: ensure => present } > > > > local_site inherits redhat_base: > > > > User[games] { ensure => absent } > > > > This is fine, but imagine a few levels of nesting later with an > > admin that wants to ensure that a user is absent that isn''t defined > > higher up and also ensure that games is absent. > > > > example inherits local_site: > > > > # The intuitive way to do this is to do : > > > > user { > > baduser: ensure => absent > > games: ensure => absent > > } > > > > # But this breaks saying that ''games'' is previously defined, so you > > have to do: > > > > user{ baduser: ensure => absent } > > User[games] { ensure => absent } > > > > # Which, I believe is really unintuitive and breaks if someone > > higher up in the maintenance chain decides to start managing baduser. > > > > Is there some way to make the intuitive method work? Obviously, > > testing should fix all of this, but it seems bad when managing > > something early in the inheritance chain breaks something lower > > down that previously had completely correct syntax. > > While I agree with you that this can get somewhat cumbersome, it > seems like you''ve got a cumbersome design, which might be having a > larger impact than the syntax. > > Why does the example class inherit local_site? It''s redundantly > overriding the games user, which (from your limited example) is the > only apparent link between the two classes. It seems that the only > reason is because the person writing ''example'' does not feel the need > to know what is in the base classes. Puppet classes aren''t so > powerful that their developers can currently afford to ignore the > contents of parent classes, I think. > > So, while the problem you describe exists in theory, I''m not > convinced it exists in real life. > > -- > It''s not to control, but to protect the citizens of Singapore. In our > society, you can state your views, but they have to be correct. > -- Ernie Hai, co-ordinator of the Singapore Government > Internet Project > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >_______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jan 25, 2007, at 1:35 PM, Trevor Vaughan wrote:> It stems from a problem with lower level management of systems. > > For instance: > > 1) The Campus SA''s manage the base build > 2) The Departmental level SA''s manage the department build and > can''t directly modify 1 > 3) The student lab level SA''s (students) manage the lab level build > and can''t directly modify 1 or 2 > 4) The lab sub-research group (more students) manage their subgroup > and can''t directly modify 1 or 2 or 3 > > It may seem a bit silly, but that''s the territory that comes with > University-style bureaucracy and, while I would love (truly) to get > rid of the middle men, this was the design that the manglement > wanted for control and extensibility. But, it also makes it really > difficult to make sure you''re keeping track of EVERYTHING in all of > the levels of inheritance. Also, the more that I thought about it, > the more I saw the potential applications of this in corporate > environments.I understand that, but at some point someone needs to have authoritative control. Either you''re responsible for getting rid of unused users, or you''re not. If you don''t have clear functional lines between the groups, then there''s not a lot Puppet can do to act like those lines exist. For the record, the syntax you originally proposed (that didn''t differentiate between initial resource specification and later overrides) was previously supported and was considered essentially hideous. -- I worry that the person who thought up Muzak may be thinking up something else. --Lily Tomlin --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com