I upgraded from 1.6 to 1.7beta2 today. I had a fair amount of trouble. First, I was using production_slave, and the conversion to production was NOT smooth. The documentation here is really inadequate. The sysconfig files refer to the wrong ports as defaults. Eventually, I think I got pretty much everything back up and running. However, I'm still having some persistent issues. In the web UI, I only ever get "Loading packages..." and "Loading data..." when viewing a project. The logs don't say much: ==> /srv/www/obs/webui/log/production.log <== [I|#27303] Processing ApplicationController#index (for A.B.C.D at 2010-01-21 11:42:54) [GET] [F|#27303] ActionController::RoutingError (No route matches "/index.html" with {:method=>:get}): public/dispatch.fcgi:24 [E|#27303] rescue_action: caught ActionController::RoutingError: No route matches "/index.html" with {:method=>:get} [D|#27303] ERROR: 404; no such route The "Server Status" page also appears to be broken. Other than that, it seems to be chugging along. -- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, Jan 21, 2010 at 12:16 PM, Jon Nelson wrote:

On Thu, Jan 21, 2010 at 12:06 PM, Jon Nelson wrote:

...

I upgraded from 1.6 to 1.7beta2 today. I had a fair amount of trouble.

Also, the init scripts for obswebuidelayed and obsapidelayed both report "failed", although ps tells me that they do not fail.

Also, the issue where stopping obsworker does not kill the screen processes, and so you are left after a number of restarts with lots of screen processes. This is also true for 1.6.X -- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thursday 2010-01-21 19:45, Jon Nelson wrote:

On Thu, Jan 21, 2010 at 12:16 PM, Jon Nelson wrote:

...

On Thu, Jan 21, 2010 at 12:06 PM, Jon Nelson wrote:

...

I upgraded from 1.6 to 1.7beta2 today. I had a fair amount of trouble.

Also, the init scripts for obswebuidelayed and obsapidelayed both report "failed", although ps tells me that they do not fail.

Also, the issue where stopping obsworker does not kill the screen processes, and so you are left after a number of restarts with lots of screen processes. This is also true for 1.6.X

This is intended behavior. If you do not like that - and I certainly don't either - remove the "zombie on" line from /etc/init.d/obsworker. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, Jan 21, 2010 at 12:55 PM, Adrian Schröter wrote:

Am Donnerstag, 21. Januar 2010 19:06:55 schrieb Jon Nelson:

...

I upgraded from 1.6 to 1.7beta2 today. I had a fair amount of trouble.

First, I was using production_slave, and the conversion to production was NOT smooth. The documentation here is really inadequate.

actually, you should keep running with production_slave. Neither the lighttpd, nor database config  or rails .rb config should be touched.

I tried to make it go with production slave, but it appears as though a) the cron jobs have production hard-coded b) /etc/lighttpd/vhosts.d/rails.inc uses "production" as well. c) it seems as though other bits have 'production' hard-coded as well Rather than change hard-coded values, it was easier to edit the production config file and restart. The lighttpd config file is one of those things that is very much under the purview of a system admin. I didn't have it running on ports 80, 81, and 82 before - I was using vhosts (obs1, obs2, and obs3 - all on port 80) and for lots of reasons wanted to leave it that way. The database config I *also* wanted to retain, so I had to edit that as well. A new deployment is one thing, but upgrading from 1.6.x I wanted to keep some things the same.

Can you tell where this went wrong ?

Sure. I shut down all of the obs* processes, upgraded all of the packages, and reviewed the /usr/share/doc/packages/obs-api/README.UPDATERS file. The file *also* uses "production" and not "production_slave". # cd /srv/www/obs/api/ # RAILS_ENV="production" rake db:migrate Additionally, the README.UPDATERS file didn't tell me anything about changing the /etc/lighttpd/vhosts.d/obs.conf file, changing any of the database files (which, regardless of whether or not one was using production_slave as I was, will no longer work - the database.yml file was not updated nor documented).

...

The sysconfig files refer to the wrong ports as defaults.

hm, we do not have ports defined in sysconfig by default. What was the necessary change at your side ?

The /etc/sysconfig/obs-worker file (snippet): ## Path: Applications/OBS ## Description: define source server host to be used ## Type: string ## Default: "localhost:5352" ## Config: OBS # OBS_SRC_SERVER="localhost:5352" ## Path: Applications/OBS ## Description: define repository server host to be used ## Type: string ## Default: "localhost:6262" ## Config: OBS # OBS_REPO_SERVER="localhost:5252" You'll note that the "Default" string for OBS_REPO_SERVER is wrong (6262 is not 5252), and I had to manually adjust the ports. Figuring out *which* ports took a while, as *this* change was also not documented. Something like "the default ports for the repo server and src server have changed from XXX to YYY. Please review the following files to make sure the changes are made." would have been nice. Should I be changing BSConfig.pm directly? I had to.

...

Eventually, I think I got pretty much everything back up and running. However, I'm still having some persistent issues.

In the web UI, I only ever get "Loading packages..." and "Loading data..." when viewing a project. The logs don't say much:

==> /srv/www/obs/webui/log/production.log <== [I|#27303]

Processing ApplicationController#index (for A.B.C.D at 2010-01-21 11:42:54) [GET] [F|#27303] ActionController::RoutingError (No route matches "/index.html" with {:method=>:get}):   public/dispatch.fcgi:24

[E|#27303] rescue_action: caught ActionController::RoutingError: No route matches "/index.html" with {:method=>:get} [D|#27303] ERROR: 404; no such route

Indeed not nice, but it isn't the problem.

can you check the source server log if you see something there ?

I suspect it's being routed incorrectly. I can provide more details (offline if you prefer) if I can be told what to look for.

...

The "Server Status" page also appears to be broken.

obsapidelayjobs and obswebdelayedjobs are running ?

Yes.

it may take some minutes after the information is there.

After a few hours I would have expected something. The graphs are clearly not working. Using firebug, it appears that the request is returning, but it's returning a *lot* of HTML. For example, I suspect that THIS is one of the URLs being fetched: http://$SOMEHOST/monitor/plothistory?range=24&set=pc_blocked&time=1264101911 What it's returning for content, however, appears to be the complete page for my home project. http://$SOMEHOST/project/show?project=home%3Ajnelson Also of note, the obsapisetup and obsstoragesetup init scripts are quite a surprise. Should they really be init scripts? They do some fairly scary stuff, like rewriting config files and setting up other bits, and since they are totally undocumented I have chosen to avoid them as yet. -- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Donnerstag, 21. Januar 2010 20:28:40 schrieb Jon Nelson:

On Thu, Jan 21, 2010 at 12:55 PM, Adrian Schröter wrote:

...

Am Donnerstag, 21. Januar 2010 19:06:55 schrieb Jon Nelson: .... it may take some minutes after the information is there.

After a few hours I would have expected something.

The graphs are clearly not working. Using firebug, it appears that the request is returning, but it's returning a *lot* of HTML. For example, I suspect that THIS is one of the URLs being fetched:

http://$SOMEHOST/monitor/plothistory?range=24&set=pc_blocked&time=1264101911

What it's returning for content, however, appears to be the complete page for my home project.

http://$SOMEHOST/project/show?project=home%3Ajnelson

Also of note, the obsapisetup and obsstoragesetup init scripts are quite a surprise.

yes, they should not be enabled by default. They are only active on the appliance, where one expects to get the system autoconfigured based on the network/dhcp informations. But this maybe explains why you suddenly got new configurations in some place ;) I will state this in the READMEs explicit. hm, or I split them into a sub package. Need to think about it. Please read this to understand their purpose: http://en.opensuse.org/Build_Service/OBS-Appliance bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, Jan 21, 2010 at 1:46 PM, Jon Nelson wrote:

On Thu, Jan 21, 2010 at 1:43 PM, Adrian Schröter wrote:

...

 http://en.opensuse.org/Build_Service/OBS-Appliance

Hey - the OBS appliance thing seems pretty cool! -- Jon -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

Am Donnerstag, 21. Januar 2010 20:46:16 schrieb Jon Nelson:

On Thu, Jan 21, 2010 at 1:43 PM, Adrian Schröter wrote:

...

Am Donnerstag, 21. Januar 2010 20:28:40 schrieb Jon Nelson:

...

On Thu, Jan 21, 2010 at 12:55 PM, Adrian Schröter wrote: ...

...

...

Also of note, the obsapisetup and obsstoragesetup init scripts are quite a surprise.

yes, they should not be enabled by default. They are only active on the appliance, where one expects to get the system autoconfigured based on the network/dhcp informations.

But this maybe explains why you suddenly got new configurations in some place ;)

Well, they *are* disabled by default, and I managed to avoid running them. It's not so much that I got new configurations in some places, it's that old configurations weren't completely migrated over.

I don't remember which, but either api or webui didn't get the "old" configuration from frontend/webclient. In both cases the database.yml file wasn't copied over, either.

...

I will state this in the READMEs explicit. hm, or I split them into a sub package. Need to think about it.

I would much prefer a sub package. Safety!

JFYI, after sleeping I decided to add an additional sysconfig setting for protection to enable these services. (People who start blindly all obs* runlevel scripts may also blindly install all obs* packages ;) bye adrian -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org