On 6 September 2013 19:49, Rob Weir <robw...@apache.org> wrote: > On Fri, Sep 6, 2013 at 12:14 PM, janI <j...@apache.org> wrote: > > On 6 September 2013 15:27, Dave Fisher <dave2w...@comcast.net> wrote: > > > >> > >> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote: > >> > >> > On 9/4/13 10:17 PM, Rob Weir wrote: > >> >> On Wed, Sep 4, 2013 at 12:36 PM, janI <j...@apache.org> wrote: > >> >>> Hi. > >> >>> > >> >>> We have had some longer discussions on different ML/IRC about how a > >> >>> vm-admin should behave and which level of service we expect for our > >> servers. > >> >>> > >> >>> We need new admins, so this is also a request for anyone interested > to > >> chip > >> >>> in. > >> >>> > >> >>> We have had some unfortunate incidents on all 3 vm, of different > >> nature, > >> >>> which made me question if we as a community: > >> >> > >> >> I assume we have vms for Forums and for Wiki. But what is the 3rd > one? > >> >> > >> >>> a) want servers, that are cared for professionally or by happening. > >> >>> b) want to (are capable to) maintain the servers ourself. > >> >>> c) are prepared to support a change that make a), b) possible. > >> >>> > >> >> > >> >> I assume we want well-maintained servers that help us get our > >> >> project-related tasks done, and also help serve our users. > >> > > >> > +1 that is the main goal, a working reliable infra structure that > helps > >> > to run our project. > >> > > >> > In the > >> >> past, before you got involved, we were not very "proactive". It > >> >> seemed like we just waited for something to break, and then tried to > >> >> fix it. > >> > > >> > Exactly and doing it proactive is much better and in the end probably > >> > less work. > >> > > >> >> > >> >> I assume another goal is that we have several people helping with the > >> >> admin, to share the work, avoid burnouts, cover for vacation, etc. > >> > > >> > And that is a very important goal, we need an environment where we can > >> > at any time step in if somebody is not available. I now very well in > the > >> > same way as Jan how it is to be a bottleneck. Well it#s true for many > >> > others of us in different areas. But if the servers are not running or > >> > the services not available more people are affected faster > >> > > >> > > >> >> > >> >>> I have formulated some thoughts on how admins could work, but in > >> general I > >> >>> believe we should convince infra to take over the vm responsibility > and > >> >>> keep our well functioning forum/wiki admins. > >> >>> > >> >>> We have a vm-team in place, that was created with the purpose of not > >> having > >> >>> a single person as admin. I my opinion the team have not lived up to > >> that > >> >>> purpose but I am still thankful for the help I have received. > >> >>> > >> >>> Remarks the ideas below are my personal thought, which I have used > >> during > >> >>> the time where I maintained the servers: > >> >>> > >> >>> =========== > >> >>> The server should at all times be maintained with the following > >> priority: > >> >>> 1) security (the backside of being popular is to have the attention > of > >> >>> people who want to gain merit by breaking our servers) > >> >>> 2) stability (we have limited cpu/ram/disk so we must optimize) > >> >>> 3) add user wishes (we already have stable systems, 1,2 are far > more > >> >>> important that enhancing the systems). > >> >>> > >> >> > >> >> and maybe > >> >> > >> >> 3b) Try to evolve systems so users can implement their own wishes, in > >> >> a way compatible with 1) and 2). For example, if routine logos and > >> >> footers are synched to resources in the project's SVN tree, then any > >> >> committer can update things. > >> > >> I really like this idea. > >> > > > > I am impressed, is this real serious ? > > > > Think about all the fuzz we have had on several MLs because one committer > > successfully convinced a vm-admin to change our logo, and the suggestion > is > > to make that automatic. > > > > Any committer who wants a change, just do a "svn commit", is that really > > wanted ? > > > > It also makes it possible for any committer to fix a problem if one occurs. > > > A couple of questions to that: > > > > Committer X want extension translate, and do a "svn commit" the config is > > updated, but does not work because of other dependencies, who clears up > the > > work ? for sure THAT is not a vm-admin task. > > > > Same as when a committer checks in code that breaks the build. > > > > Committer X changes the logo, but doing a "svn commit", Committer Y dont > > like it and does a "svn commit", where are our users in this process or > our > > decision process ? > > > > Same as when a committer checks in code that someone doesn't like. > > We have a community-based process that handles these things already. > > Your proposal doesn't really avoid these issues. It handles it by > having an admin judge the will of the community. > yes like all other vms I know.
> > > 3b) is a sure way to scare any prof. SA away, thats pure anarchy. > > > > In the good sense of the word "anarchy", yes. > > Note: I wouldn't do this for config files and core system files. But > why should the logo or banner or footer of the forums or the wiki be > any harder for a committer to edit than the same content of our > website? > Maybe because the CMS are laid out for that our apps are not. If you change logo to e.g. a different size you will also need to edit - css - php (for mwiki) - update symlinks (for php2bb) and you might also need to change in the httpd caching scheme, if the new logo has a different extension. If you want to change to footer, you need to - for wiki edit a php script, that also contains securtiy relevant information. - for php2bb, it can partly already be done by forum admin, but by doing that you break the setup (all forums have identical setup, with symlinks to a central place. But never mind. As requested by infra, I tried a last time, to get consensus on having our vms maintained at the level and guidelines used for infra vms and failed. I acknowledge the fact that the community want vms that are open playgrounds (letting admins change as they please, and even allow committer access), I believe differently. I have, effective 2 hours ago, asked root@a.o to remove my sudo right/access to the vms and the alert notifications, so I can no longer be expected to react and/or do cleanup of others playground work. The vms are not at risk, imacat, jsc, andrea and arist all have access and sudo. Thanks for the trust the community have given me in the past. rgds jan I. > Regards, > > -Rob > > > > Dont misunderstand, I have no problem with the community implementing > > something like that, just dont expect to get stable well maintained > servers > > ! We have a serious problem with the current admins, expanding that to > all > > committers, that is something that will be in interesting to watch for a > > large distance. > > > > > >> >> > >> >>> Being an admin on a vm is a job that does not take soo much time, > but > >> >>> requires a lot of monitoring and communication (especially with > infra). > >> >>> > >> >>> A good setup would be, 3 types of admin: > >> >>> Each server will have an appointed "owner" (anchor-admin) > >> >>> A number of persons have full sudo on a server (admin) > >> >>> A number of persons can reboot/restart/work on po files (help-admin) > >> >>> > >> >>> === Anchor-admin responsibilities === > >> >>> Anchor-admin is the "owner" of the vm and the prime contact to > infra. > >> >>> > >> >>> Anchor-admin has the overall responsibility of the vm. > >> >>> 1) help when receiving alerts > >> >>> 2) keep informed on available patches, especial security related > >> patches > >> >>> 3) create/keep a maintenance plan > >> >>> 4) coordinate changes external to vm (like dns) with infra > >> >>> 5) participate in infra discussions relevant for the vm (e.g. > >> certificates) > >> >>> 6) monitor the vm regularly for resource usage > >> >>> 7) secure that appl changes are implemented with relevant consensus > >> >>> 8) discuss work with admin, with the goal that they should be able > to > >> take > >> >>> over one day. > >> >>> > >> >>> These activities are expected to take 3-4 hours pr week, more in the > >> >>> beginning and less later. The hour usage highly depend on the number > >> and > >> >>> level of admins. > >> >>> > >> >>> === Admin responsibilities === > >> >>> Admins help the anchor admin with ongoing maintenance and have full > >> sudo. > >> >>> > >> >>> All changes must be discussed and agreed with the anchor admin, no > >> change > >> >>> is so important that it cannot wait until discussed ! > >> >>> > >> >> > >> >> We might also want an admin-...@openoffice.apache.org list and > perhaps > >> >> a private one as well to coordinate. > >> > >> Perhaps an admin-dev, but a private one is a not a good idea - the team > >> should be on the infrastructure list and infra should know what is up. > >> > > We can make any number of MLs, current fact is that surden admins do NOT > > reply to private mails, asking them to act. > > > > I for one, do not need more MLs, I need rules admin follow or leave. > > > >>> > >>>> Admins are expected to: > >>>> 1) help when receiving alerts > >>>> 2) stay informed with the vm configuration > >>>> including but not limited to: > >>>> - where are which configuration done, and stored (svn/backup) > >>>> - how are the apps. configured > >>>> - read and update runbook, if something is unclear > >>>> 3) participate in the regular maintenance > >>>> 4) coordinate all non-scheduled work with anchor-admin > >>>> > >>>> These activities are expected to take 1-2 hours pr week, more in the > >>>> beginning and less later. > >>>> > >>>> Admin does not need to be specialists, we all learn, but it is > important > >>>> that the admin have motivation and time to learn. > >>>> > >>>> > >>>> === Help-admin responsibilities === > >>>> Help-admins are located in different timezones, so we have 24/7 > coverage > >>>> and have limited sudo (only restart/reboot/handle po files). > >>>> > >>>> When a help-admin receives an alert mail, actions should be taken > >>>> 1) is the vm reachable via ssh, then login else escalate to > admin/infra > >>>> 2) is the vm overloaded, or is apache/mysql not running > >>>> 3) restart the needed processes > >>>> 4) mail at least anchor-admin about with obervations and what was > done. > >>>> > >>>> > >>>> === > >>>> remark the above are just my thoughts, there are a lot of other > >>>> possibilities. > >> > >> It sounds very reasonable to me and worth to work in this direction. I > >> see myself more in the role of a help-admin but I willing to learn more > >> to be a better admin. > > > > I agree that the plan is reasonable and professional. > >> > > > > thanks for you kinds words, but 3b) makes that plan obsolete. With 3b) > > everyone is admin, a problem something like 1.000 times bigger than > today, > > where we cannot control 3 admins. > > > > rgds > > jan I. > > > > > >> > >> Regards, > >> Dave > >> > >> > > >> > Juergen > >> > > >> >>> > >> >>> Lets hear your opinion? > >> >>> > >> >> > >> >> It sounds like a good way to think of this. > >> >> > >> >> Regards, > >> >> > >> >> -Rob > >> >> > >> >>> rgds > >> >>> jan I. > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> >> > >> > > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
