On 8 September 2013 00:01, janI <j...@apache.org> wrote: > > On Sep 7, 2013 10:28 PM, "Dave Fisher" <dave2w...@comcast.net> wrote: > > > > > > On Sep 7, 2013, at 2:24 AM, janI 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. > > > > What both Rob and I were looking for is an understanding of what it > might take to have a unified approach. Your reasoning is fine we were > discussing in a robust way what it would take to make this work. You are > precisely correct to tell us what a high bar this is. > > > > We have 8 different systems to maintain brand on we need to fully > understand all of the implications. > > > > > > > > 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. > > > > You are the one who says that we want an open playground to do anything. > We are only asking for a way to control the brand. Let's talk about what it > would take. You give concrete information above and then at the same time > you quit > > > > You are impossible to have a discussion with. You should be open to > finding a way. > > I am sorry you feel that way, I have tried to get attention for about 3 > months without success and only because I give up we start to discuss, > does that make me impossible, or is it those that did not want to discuss > earlier ? > > I was forced to accept a vm-team (a very good idea), that have not reacted > to a single alert or (apart from arist helping with forum) helped with a > single change/update. But I was told, that it was all good, because we had > an efficient team, does it make me impossible that I tell the truth, that > the team does not work ? > > I have been fighting to get our servers updated, including creating > several new vms, I have 1 time asked for support, when we had the incident > with logo changes, which another admin did, in a way that put our servers > at risk. Does it make me impossible that I cannot accept the way that admin > worked (remember this is not the first incident) ? > > I feel I have really tried to find ways, but none wanted to listen, > probably because I was there and took care of it. Does that make me > impossible ? > > So yes, I did quit, because I could not see any other options. > > > >> > > > > 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. > > > > Thanks for not noticing the difference between an action and a > discussion of how we can go into a "devops" mode and alleviate some of the > burden that you feel as a sysadmin. > > I do know the difference, just look at the mail archives, and you will see > how often I have raised these problems the last couple of months. Dont > forget the vm-team was such a "alleviation", which turned out just to make > the burden worse. It seems to me, that the difference is something else: > > I fight and discuss about a workable solution with the resources we have > today, while "devops" mode and other suggestions seems to focus on a future > and resources that we dont know if we will ever get. > > We need a solution for today, who and how, we already have pending > updates. If we solve today, we can start dreaming about the future. > > > > > You act like Rob and I have no experience. That is not so. I work 12 > hours days and manage both java and php developers and solaris/ubuntu > syadmins. I am a firm believer in DevOps. As much as possible sysadmins > provide a stable environment for QUALIFIED developers to configure > applications. I may be the person most qualified in this project to help > make this full rebranding happen in a way that makes it easy and not hard > to present a unified header. > > > Actually you are one of the people in here I admire, and I believe you > have experience. But please so do I, I sold my companies a year ago, we > operated worldwide and dealt with fortune 500 companies. I decided to > change lane, stop managing and do what I really like, to help opensource > projects. Enough about you and me, I think we have established that we both > know what we do. > > I acknowledge that both you and rob have experience, but both of you talk > about an unknown future with resources we dont have right now, and we do > have a problem today to solve first. > > > > > > I've worked with Roller and Confluence, etc. > > > > I am sorry you cannot tell the difference between those who want to work > with you and those who go around you and seemingly don't respect the effort > that you provide. > > I am sorry you cannot acknowledge how long I have been fighting while > having my worries ignored. > > I am aware I should have done like some of the other vm-team members, > "nothing". I get criticized because I tell that I quit after having tried > hard to get something done, is that real fair ? Would it not be equally > fair to question the vm-team, why they cannot take over, as was expected. > > I feel that I have become more of a burden, than an asset, if my feeling > is right just tell me straight. >
After a good nights sleep, I have a positive suggestion. Take a discussion either with or among the current vm-team, on how the work can be handled. Some members of the team did the work before I took over, so they should be able to continue doing it at the same level. It seems my suggestions/presence makes the discussions more emotional/personal, something that is very uncool for the project, so I will keep a distance. If we want a higher level maintenance, as I have delivered, persuade infra to take responsibility for the vms, that will ensure professional care (I have told in here and to infra, that in such a setup, I would be happy to continue). Hope this takes the heat out of the discussion. rgds jan I. > rgds > > jan I. > > > > > > Best Regards, > > Dave > > > > > > > > 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 > > >
