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. > 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? 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
