Mailing List Archive

I should further add that I'm trying to add a Template with the following params:
Type: Element
Output Channel: File
Category: /module/spotlight (which is a new category I just created)

The Groups section in the Category edit screen is also grayed out, but it has "All Categories" in the Current Groups box.

The Groups section in the File o/c edit screen is also grayed out, but it has "All Output Channels" in the Current Groups box.

Thanks,
Mike

On Jan 15, 2010, at 7:58 AM, Fletcher, Michael wrote:

> Hello,
>
> I've done a make upgrade from 1.10.2 to 1.10.7.
> All of my Group Membership boxes (in Users & Groups maintenance pages for instance) are grayed out (disabled). The data seems to be there, but I cannot modify them. The Available Groups is empty and the listbox is narrow, as if there are no groups to choose from. The Current Groups has the old data, but it is grayed out.

Odd. What browser/OS?

> I noticed this when I tried to create a new template and got the following error:
> Can't call method "get_objects" on an undefined value at /usr/lib/perl5/site_perl/5.8.8/Bric/Biz/ElementType.pm line 1782, <GEN11> line 111.
>
> Here is the piece of Bric code that is throwing the error:
> sub get_containers {
> my ($self, $key_name) = @_;
>
> my $grp = $self->_get_element_type_grp;
> return $grp->get_objects unless defined $key_name;
>
> return first { $_->get_key_name eq $key_name } $grp->get_objects;
> }
>
> Something seems to have happened to my Groups. I've "Vacuumed" the tables, but that didn't help.

Hrm. Vacuuming won't help with this.

> I should further add that I'm trying to add a Template with the following params:
> Type: Element
> Output Channel: File
> Category: /module/spotlight (which is a new category I just created)
>
> The Groups section in the Category edit screen is also grayed out, but it has "All Categories" in the Current Groups box.

That's good.

> The Groups section in the File o/c edit screen is also grayed out, but it has "All Output Channels" in the Current Groups box.

Also good. What about the screen for the element type for which you're trying to create a template?

Best,

David

On Jan 20, 2010, 2:10 PM David wrote:

> Odd. What browser/OS?

Any browser - I use Firefox, but it also happens in IE7 (Both on Windows XP Pro)

Bric is running on:
Linux version 2.6.18-92.el5 (mockbuild@builder16.centos.org) (gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP Tue Jun 10 18:49:47 EDT 2008


> What about the screen for the element type for which you're trying to create a template?

We seem to be able to create Templates for "Utility" and "Category", but not an "Element". "Element" is the only one we get the error on.

Thanks,
Mike

I solved this (in case anyone needs this info)...

Somehow, our grp=1025 got changed during the upgrade. It used to be a class=24, name=File Include, but it got changed to some _CREATE USERS_ thing with a class=8. I changed it back to the original value from our old db, and now everything seems ok.

Mike

On Jan 25, 2010, at 6:59 AM, Fletcher, Michael wrote:

> We seem to be able to create Templates for "Utility" and "Category", but not an "Element". "Element" is the only one we get the error on.

Do you have groups in the grp table in the database? Are they active?

David

On Jan 26, 2010, at 8:30 AM, Fletcher, Michael wrote:

> I solved this (in case anyone needs this info)...
>
> Somehow, our grp=1025 got changed during the upgrade. It used to be a class=24, name=File Include, but it got changed to some _CREATE USERS_ thing with a class=8. I changed it back to the original value from our old db, and now everything seems ok.

This happened while upgrading from 1.10.2 to 1.10.7?

Best,

David

On Thursday, January 28, 2010 9:10 AM David E. Wheeler wrote:

> This happened while upgrading from 1.10.2 to 1.10.7?

Yes. But the upgrade wasn't exactly as recommended. We do not have enough space on the system to do the upgrade and we're moving to a new system. So I installed 1.10.2 on a new system and then copied over some of my data from the PostgreSQL database. I copied everything except Media, Stories, and Templates because we're developing a new site from scratch. I copied over all the supporting data like Output Channels, Categories, Element Types, etc. I made sure to copy the matching records from any related table like "members" during the copy.

Everything seemed to be working fine, so then I did the upgrade to 1.10.7. Everything still seemed fine until I tried to create a new Template.

I'm hoping that I don't find any other anomalies from this approach later :|

Thanks,
Mike

On Jan 28, 2010, at 9:27 AM, Fletcher, Michael wrote:

> Yes. But the upgrade wasn't exactly as recommended. We do not have enough space on the system to do the upgrade and we're moving to a new system. So I installed 1.10.2 on a new system and then copied over some of my data from the PostgreSQL database. I copied everything except Media, Stories, and Templates because we're developing a new site from scratch. I copied over all the supporting data like Output Channels, Categories, Element Types, etc. I made sure to copy the matching records from any related table like "members" during the copy.

Wow. That's just…crazy. I don't know whether to admire you or fear you. A little of both, perhaps.

> Everything seemed to be working fine, so then I did the upgrade to 1.10.7. Everything still seemed fine until I tried to create a new Template.

You're luck that's all that you've noticed so far.

> I'm hoping that I don't find any other anomalies from this approach later :|

There was no way to do a pg_dump and then restore the dump on the new box? Hook up a USB drive to it or something? That would have been a lot safer -- and a lot less work for you.

Best,

David

On Thursday, January 28, 2010 9:38 AM David E. Wheeler wrote:

> Wow. That's just...crazy. I don't know whether to admire you or fear you. A little of both, perhaps.

Hmmm, That's not very nice.

We're trying to do several things at once with little or no impact on our editorial staff.
1. Retire an old server that has no disk space and get onto a new server (vmware)
2. Update Bricolage
3. Build a new site

With no disk space and a 24/7 news operation, it a difficult undertaking and I've done everything I can to insure a smooth transition for the users. Our DB and /comp and /burn are just too big to try and move it all to a new server and do an upgrade without significant downtime to the editorial staff. Even if we had the disk space, I would have had to move all the existing Templates and postpone the new site development until after the Bric update. With the approach I've taken, I was able to move all the "supporting" data and then we'll start SOAPing the stories and media from the old server to the new server (selectively) while we're developing the new site in the new Bric.

I am aware of the risks involved in this approach, but I didn't see any other viable option under these circumstances.

Can I ask how you would have approached this?

Thanks,
Mike

On Jan 28, 2010, at 10:12 AM, Fletcher, Michael wrote:

> On Thursday, January 28, 2010 9:38 AM David E. Wheeler wrote:
>
>> Wow. That's just...crazy. I don't know whether to admire you or fear you. A little of both, perhaps.
>
> Hmmm, That's not very nice.

I meant it as a complement.

> We're trying to do several things at once with little or no impact on our editorial staff.
> 1. Retire an old server that has no disk space and get onto a new server (vmware)
> 2. Update Bricolage
> 3. Build a new site
>
> With no disk space and a 24/7 news operation, it a difficult undertaking and I've done everything I can to insure a smooth transition for the users. Our DB and /comp and /burn are just too big to try and move it all to a new server and do an upgrade without significant downtime to the editorial staff. Even if we had the disk space, I would have had to move all the existing Templates and postpone the new site development until after the Bric update. With the approach I've taken, I was able to move all the "supporting" data and then we'll start SOAPing the stories and media from the old server to the new server (selectively) while we're developing the new site in the new Bric.
>
> I am aware of the risks involved in this approach, but I didn't see any other viable option under these circumstances.
>
> Can I ask how you would have approached this?

I would have somehow got some external storage plugged into the thing, then run `make clone` from that external storage. No downtime at all for Bricolage. Then I would have unplugged the USB drive and plugged it into the new box and run `perl Makefile.PL && make && make install` from there. Complete clone of the existing installation with database fully in tact, all templates, stories, images, etc.

But that's just me. If you don't need all the existing content and versions in the new installation, then maybe that would have been overkill. Quite a few people have thrown out their existing installs, setting up brand new Bricolage servers and copied over selected stuff from the old server via SOAP. You're the first I've heard of to selectively copy stuff from the database, however (did you use PostgreSQL's COPY feature? How awesome is that??).

Best,

David

On Thursday, January 28, 2010 10:21 AM David E. Wheeler wrote:

>I would have somehow got some external storage plugged into the thing, then run `make clone` from that external storage. No downtime at all for Bricolage. Then I would have unplugged the USB drive and plugged it into the new box and run `perl Makefile.PL && make && make install` from there. Complete clone of the existing installation with database fully in tact, all templates, stories, images, etc.

The part I don't understand with this approach is the "no downtime" part. If we're copying 100GB of /comp & /burn, and 70GB of database, and then installing that on a new system, how do you keep the new system up-to-date during the copy & update while editors are still publishing on the system you're trying to retire?

I would love to do it this way, except for the part about still having all my old Templates (yuk), but I could always delete those later. I just don't understand how to do this seamlessly, no downtime and synchronized between old and new.

Thanks,
Mike

On Jan 28, 2010, at 10:43 AM, Fletcher, Michael wrote:

> The part I don't understand with this approach is the "no downtime" part. If we're copying 100GB of /comp & /burn, and 70GB of database, and then installing that on a new system, how do you keep the new system up-to-date during the copy & update while editors are still publishing on the system you're trying to retire?

It's just a database dump and a file system copy. They might experience some slowdown, but likely not much. You might want to do a bulk publish while you're doing it, though. Your server is multicore, right?

> I would love to do it this way, except for the part about still having all my old Templates (yuk), but I could always delete those later. I just don't understand how to do this seamlessly, no downtime and synchronized between old and new.

Why would you think downtime would be required?

Best,

David

On Thursday, January 28, 2010 11:20 AM David E. Wheeler wrote:

> Why would you think downtime would be required?

So make clone just creates another instance of the same Bricolage system pointing to the same DB. Any changes to the DB during the make clone will not be lost, but what about the content in /burn and /comp? How does that get added during the make clone process? Also, when I move that instance to a new server and do the upgrade to 1.10.7, that will take time. How long can a make upgrade take on an installation our size? Won't that be downtime?

Thanks,
Mike

On Jan 28, 2010, at 1:47 PM, Fletcher, Michael wrote:

> On Thursday, January 28, 2010 11:20 AM David E. Wheeler wrote:
>
>> Why would you think downtime would be required?
>
> So make clone just creates another instance of the same Bricolage system pointing to the same DB.

No, a new database with all of your data exported from the old database.

> Any changes to the DB during the make clone will not be lost, but what about the content in /burn and /comp? How does that get added during the make clone process?

It's a snapshot. You'll get whatever was in the database at the time of the pg_dump, and whatever templates and such were in place at the time of the cp -rf. Probably a good idea to clean out temp files and staging/preview files before doing it, though.

> Also, when I move that instance to a new server and do the upgrade to 1.10.7, that will take time. How long can a make upgrade take on an installation our size? Won't that be downtime?

You should schedule a downtime to do an upgrade, always. But the minor version upgrades are usually pretty fast. Hell, 2.0.0 will be pretty fast, I think, though you're going to want to do some training first, I think.

Best,

David