On 8 September 2013 14:29, Rob Weir <robw...@apache.org> wrote: > On Sat, Sep 7, 2013 at 5:24 AM, janI <j...@apache.org> wrote: > > 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. > > > > Read my original comment again. I wrote: > > "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 didn't say, "Open it up for every one to make unrestrained changes > on system files". I said "try to evolve...". This implies change, > gradual change, deliberate change, goal-oriented change, to enable > this. It was a statement of an ideal we should keep in mind and work > towards. > > > 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. > > > > Maybe you have a different view of what consensus means. When I work > on standards committees in ISO we have a useful definition of > consensus: > > "General agreement, characterized by the absence of sustained > opposition to substantial issues by any important part of the > concerned interests and by a process that involves seeking to take > into account the views of all parties concerned and to reconcile any > conflicting arguments" > > Maybe we could adopt something like this? Note the emphasis on lack > of opposition and on discussion to reconcile views. Consensus is > something you gain by discussion, and through discussion we all remain > open to other ideas and assume good will. > > > 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. > > > > Again, the statement that I made, and which others agreed with, was > "try to evolve...". It was not talking about "open playgrounds". > > > 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. > > > > Maybe re-read the thread in light of what I've written here and see if > it still looks that way? And remember, a 72-hour discussion is the > minimum, not the maximum, especially over the weekend. >
I have done as requested and re-read not only this thread but a couple of other threads as well. Thanks for your corrections, in regards of your statements, I took you statements to the maximum extent, and you precise them to about the minimum possible range. I can however see it is as if we are in two different worlds. I was fighting to get our vm-team to work (sending lots of mails to activate them), and get the other admins to follow rules or leave. In order to keep our vms at level, I believe in being restrictive, run everything by the rules, and loudly remind those that break it. You (and dave) on the other hand thought about how the future should be (nothing wrong with that) and did not consider the eminent problems. I decided to leave with good conscience, for these reasons: - The vms are all at a very much higher level of maintenance as before. - The community have the same support as before I took over (Imacat, jsc) - My ways are much more strict than your (and the community) ideas, and I will be in constant conflict with the PMC group. I stand by my earlier mail today, talk this through with the vm-team, the managed the vms before (at another level) and can simply continue doing that. Thanks again for your clarification, but I hope you this is not the kernel problem that made me leave. rgds jan I. > Regards, > > -Rob > > > 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 > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
