Re: [Spacewalk-devel] pgsql merge status

2009-07-22 Thread Milan Zazrivec
On Wednesday 22 July 2009 01:32:51 Jeff Ortel wrote:
 All,

 I spend most of the day doing side-by-side verification of oracle schema
 installed from master and pgsql.  I've resolve most of the discrepancies
 and pushed them.  I still have a few to deal with, most of them straight
 forward.  I also fixed a bug in chameleon and it will have to be rebuilt in
 koji and pushed into the build roots.

 One of the items that resurfaced is synonyms.  The original plan was to do
 away with the synonyms because postgres does not support them.  I've
 removed references to the synonyms in the schema (insert files) but the
 monitoring code seems to depend heavily on them. So, do leave the synonyms
 in the schema as oracle specific (the monitoring code will be broken for
 postgres) or do we replace references to the synonyms in the monitoring
 code for 0.6?  Can someone comment on the LOE for this?

I'll see about removing the synonyms from the monitoring code in master
branch for Spacewalk 0.6.

-Milan

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] Selinux Temporarily Disabled in Devel Repo

2009-07-22 Thread Jan Pazdziora
On Tue, Jul 21, 2009 at 05:33:51PM -0300, Devan Goodwin wrote:
 
  On Mon, Jul 20, 2009 at 03:53:14PM -0300, Devan Goodwin wrote:
   
   We've got both selinux build problems for Fedora 11, as well as
   selinux denials post install on at least el5. As such I've
   temporarily disabled
  
  What are the AVC denials on EL 5? I'm aware of the build problems
  
 
 Now filed here:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=513071
 
 Happened on CentOS 5.2.

As it turns out to be user error and not a bug in the code, could you
please revert the commit which commented out the Requires of *-selinux
packages, and just put in a check for 0%{?fedora} == 11, similar to
spacewalk-monitoring.spec?

That way we still have *-selinux packages installed and hopefully
tested on F10 and EL5. As Spacewalk 0.5 worked with SELinux in
Enforcing on those two OSes, we should try not to introduce
regressions, and keeping the modules in the transaction seems like the
best way to achieve that.

Thank you,

-- 
Jan Pazdziora
Senior Software Engineer, Satellite Engineering, Red Hat

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] Selinux Temporarily Disabled in Devel Repo

2009-07-22 Thread Devan Goodwin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 22 Jul 2009 15:00:28 +0200
Jan Pazdziora jpazdzi...@redhat.com wrote:

 On Tue, Jul 21, 2009 at 05:33:51PM -0300, Devan Goodwin wrote:
  
   On Mon, Jul 20, 2009 at 03:53:14PM -0300, Devan Goodwin wrote:

We've got both selinux build problems for Fedora 11, as well as
selinux denials post install on at least el5. As such I've
temporarily disabled
   
   What are the AVC denials on EL 5? I'm aware of the build problems
   
  
  Now filed here:
  
  https://bugzilla.redhat.com/show_bug.cgi?id=513071
  
  Happened on CentOS 5.2.
 
 As it turns out to be user error and not a bug in the code, could you
 please revert the commit which commented out the Requires of *-selinux
 packages, and just put in a check for 0%{?fedora} == 11, similar to
 spacewalk-monitoring.spec?
 
 That way we still have *-selinux packages installed and hopefully
 tested on F10 and EL5. As Spacewalk 0.5 worked with SELinux in
 Enforcing on those two OSes, we should try not to introduce
 regressions, and keeping the modules in the transaction seems like the
 best way to achieve that.
 
 Thank you,
 

Sure.

- -- 
  Devan Goodwin dgood...@redhat.com
  Software Engineer Spacewalk / RHN Satellite
  Halifax, Canada   650.567.9039x79267
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkpnEg8ACgkQAyHWaPV9my7Z2gCfVrBnEU9biKq2z6MLg0KvMuDG
PZsAn3RkxfO1mZqhb6ueN//hMrA02ABH
=EuH3
-END PGP SIGNATURE-

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] pgsql merge status

2009-07-22 Thread Jeff Ortel



Tom Lane wrote:

Jeff Ortel jor...@redhat.com writes:

One of the items that resurfaced is synonyms.  The original plan was
to do away with the synonyms because postgres does not support them.
I've removed references to the synonyms in the schema (insert files)
but the monitoring code seems to depend heavily on them.  So, do leave
the synonyms in the schema as oracle specific (the monitoring code
will be broken for postgres) or do we replace references to the
synonyms in the monitoring code for 0.6?  Can someone comment on the
LOE for this?


Perhaps we could use views as a PG substitute for synonyms?  I agree
with the idea of getting rid of them over the long term, but it would be
nice to not have that in the critical path if there is a lot of code
that would have to change.


Perhaps.  My concern about using views even as an interim solution is that the monitoring 
code has high insert/update demands (I'm assuming) and we'd have to use 'on insert/update' 
rules to make the views seem mutable, right?  Wouldn't this degrade performance?  I 
sniffed the code a little and found that there is a mixture of references to the table 
names and synonyms.  I found about 83 references to the table names and I'm not sure about 
the synonyms since they don't have an easy pattern like 'rhn_' to grep on like the 
synonyms.  But, it makes me hopeful that the number of references to synonyms is 
relatively small.  Thanks for the suggestion.  It's good to have this as an option.




regards, tom lane

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


Re: [Spacewalk-devel] pgsql merge status

2009-07-22 Thread Tom Lane
Jeff Ortel jor...@redhat.com writes:
 Tom Lane wrote:
 Perhaps we could use views as a PG substitute for synonyms?

 Perhaps.  My concern about using views even as an interim solution is
 that the monitoring code has high insert/update demands (I'm assuming)
 and we'd have to use 'on insert/update' rules to make the views seem
 mutable, right?  Wouldn't this degrade performance?

Yeah, you're right.  I had thought monitoring suggested read-mostly,
but if it's write-heavy we probably don't want that even as a stopgap
solution.  It's not so much that I care about speed at this point,
as that having to write a bunch of rules would be dead-end effort.

regards, tom lane

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


[Spacewalk-devel] pgsql (web_user_pi_timestamp) trigger

2009-07-22 Thread Jeff Ortel

In master, the 'web_user_pi_timestamp' trigger on 'web_user_personal_info' is
being defined in:

  'rhnsat/tables/web_user_personal_info.sql' (SNIP#1)

Then redefined in (and the filename is all wrong):

 'rhnsat/tables/web_user_contact_permission.sql' (SNIP#2)

The net effect is that the 'web_user_pi_timestamp' trigger is begin installed 
as:

BEFORE INSERT OR UPDATE ON web_user_personal_info
FOR EACH ROW
BEGIN
   :new.modified := sysdate;
END;

instead of:

before insert or update on web_user_personal_info
for each row
begin
  :new.email_uc := upper(:new.email);
  :new.modified := sysdate;
end;

Does anyone know what was really intended here?

I've corrected for the net effect in pgsql but wanted to be sure the intended effect was 
being achieved.


Thanks,

Jeff








SNIP #1
---

2904 -- SQL relevant contents from file rhnsat/tables/web_user_personal_info.sql
...
2943 create or replace trigger
2944 web_user_pi_timestamp
2945 before insert or update on web_user_personal_info
2946 for each row
2947 begin
2948   :new.email_uc := upper(:new.email);
2949   :new.modified := sysdate;
2950 end;
2951 /


SNIP#2
--

36408 -- SQL relevant contents from file 
rhnsat/tables/web_user_contact_permission_triggers.sql

36409 create or replace trigger
36410 web_user_pi_timestamp
36411 BEFORE INSERT OR UPDATE ON web_user_personal_info
36412 FOR EACH ROW
36413 BEGIN
36414   :new.modified := sysdate;
36415 END;
36416 /
36417 show errors


___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel


[Spacewalk-devel] Re: Branch 'pgsql' - 2 commits - schema/spacewalk

2009-07-22 Thread Milan Zazrivec
On Wednesday 22 July 2009 01:11:17 Jeff Ortel wrote:
[..]
 |2 schema/spacewalk/common/tables/rhnSet.sql   
  |2 schema/spacewalk/common/tables/rhnSystemMigrations.sql 
[...]
 commit 79a08479f36399c26aae812fec749d0e9f38179c
 Author: Jeff Ortel jor...@redhat.com
 Date:   Tue Jul 21 16:01:15 2009 -0500

    Resolve differences between databases created master and pgsql sources.
[...]
 diff --git a/schema/spacewalk/common/tables/rhnSet.sql
 b/schema/spacewalk/common/tables/rhnSet.sql index 78105d0..87e8b83 100644
 --- a/schema/spacewalk/common/tables/rhnSet.sql
 +++ b/schema/spacewalk/common/tables/rhnSet.sql
 @@ -21,7 +21,7 @@ CREATE TABLE rhnSet
 REFERENCES web_contact (id)
 ON DELETE CASCADE,
  label  VARCHAR2(32) NOT NULL,
 -elementNUMBER NOT NULL,
 +elementNUMBER,
  element_twoNUMBER,
  element_three  NUMBER,
  CONSTRAINT rhn_set_user_label_elem_unq UNIQUE (user_id, label,
 element, element_two, element_three)

Are we sure this is correct? rhnSet table in current master branch does set
not null constraint on element column.

 diff --git a/schema/spacewalk/common/tables/rhnSystemMigrations.sql
 b/schema/spacewalk/common/tables/rhnSystemMigrations.sql index
 b5c8d74..6d81a87 100644
 --- a/schema/spacewalk/common/tables/rhnSystemMigrations.sql
 +++ b/schema/spacewalk/common/tables/rhnSystemMigrations.sql
 @@ -16,11 +16,11 @@

  CREATE TABLE rhnSystemMigrations
  (
 -org_id_toNUMBER
 +org_id_toNUMBER NOT NULL
   CONSTRAINT rhn_sys_mig_oidto_fk
   REFERENCES web_customer (id)
   ON DELETE SET NULL,
 -org_id_from  NUMBER
 +org_id_from  NUMBER NOT NULL
   CONSTRAINT rhn_sys_mig_oidfrm_fk
   REFERENCES web_customer (id)
   ON DELETE SET NULL,

I'm not sure about this change either. rhnSystemMigrations in master
branch does not set not null constraint for those two columns.

-Milan

___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel