Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
Johannes Renner wrote: % On 06/04/2012 08:47 PM, Miroslav Suchy wrote: % >> So here is the latest version of the patches. % > % > Committed (with some white space and check style fixes). Thanks for contribution. % % Thank you very much, here is already a first follow up patch: % % Replace "default" string with the new constant RhnHelper.DEFAULT_FORWARD, % just for being consistent with recent changes here. % % Regards, % Johannes Applied. Thanks. -- Michael Mráka Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 06/04/2012 08:47 PM, Miroslav Suchy wrote:
>> So here is the latest version of the patches.
>
> Committed (with some white space and check style fixes). Thanks for
> contribution.
Thank you very much, here is already a first follow up patch:
Replace "default" string with the new constant RhnHelper.DEFAULT_FORWARD,
just for being consistent with recent changes here.
Regards,
Johannes
--
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
>From d3fe367991d13c85b83e5a821688d4c32db5f248 Mon Sep 17 00:00:00 2001
From: Johannes Renner
Date: Wed, 6 Jun 2012 15:27:35 +0200
Subject: [PATCH] Refactor "default" to RhnHelper.DEFAULT_FORWARD
---
.../images/ScheduleImageDeploymentAction.java |3 ++-
.../action/user/UserCredentialsDeleteAction.java |3 ++-
.../action/user/UserCredentialsEditAction.java |3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/java/code/src/com/redhat/rhn/frontend/action/systems/images/ScheduleImageDeploymentAction.java b/java/code/src/com/redhat/rhn/frontend/action/systems/images/ScheduleImageDeploymentAction.java
index 117f949..a3a9491 100644
--- a/java/code/src/com/redhat/rhn/frontend/action/systems/images/ScheduleImageDeploymentAction.java
+++ b/java/code/src/com/redhat/rhn/frontend/action/systems/images/ScheduleImageDeploymentAction.java
@@ -34,6 +34,7 @@ import com.redhat.rhn.domain.user.User;
import com.redhat.rhn.frontend.action.renderers.ImagesRenderer;
import com.redhat.rhn.frontend.struts.RequestContext;
import com.redhat.rhn.frontend.struts.RhnAction;
+import com.redhat.rhn.frontend.struts.RhnHelper;
import com.redhat.rhn.frontend.taglibs.list.ListTagHelper;
import com.redhat.rhn.manager.action.ActionManager;
import com.redhat.rhn.manager.system.SystemManager;
@@ -115,7 +116,7 @@ public class ScheduleImageDeploymentAction extends RhnAction {
request.getRequestURI());
}
// Find the default destination
-forward = actionMapping.findForward("default");
+forward = actionMapping.findForward(RhnHelper.DEFAULT_FORWARD);
}
return forward;
}
diff --git a/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsDeleteAction.java b/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsDeleteAction.java
index 7dcacef..431a2f1 100644
--- a/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsDeleteAction.java
+++ b/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsDeleteAction.java
@@ -28,6 +28,7 @@ import com.redhat.rhn.domain.credentials.CredentialsFactory;
import com.redhat.rhn.domain.user.User;
import com.redhat.rhn.frontend.struts.RequestContext;
import com.redhat.rhn.frontend.struts.RhnAction;
+import com.redhat.rhn.frontend.struts.RhnHelper;
/**
* Delete credentials for external systems or APIs.
@@ -61,6 +62,6 @@ public class UserCredentialsDeleteAction extends RhnAction {
getStrutsDelegate().saveMessages(request, messages);
return mapping.findForward("success");
}
-return mapping.findForward("default");
+return mapping.findForward(RhnHelper.DEFAULT_FORWARD);
}
}
diff --git a/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsEditAction.java b/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsEditAction.java
index 6473985..8048eb1 100644
--- a/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsEditAction.java
+++ b/java/code/src/com/redhat/rhn/frontend/action/user/UserCredentialsEditAction.java
@@ -29,6 +29,7 @@ import com.redhat.rhn.domain.credentials.CredentialsFactory;
import com.redhat.rhn.domain.user.User;
import com.redhat.rhn.frontend.struts.RequestContext;
import com.redhat.rhn.frontend.struts.RhnAction;
+import com.redhat.rhn.frontend.struts.RhnHelper;
/**
* Create and edit credentials for external systems or APIs.
@@ -93,6 +94,6 @@ public class UserCredentialsEditAction extends RhnAction {
request.setAttribute(ATTRIB_CREDS, newCreds);
}
}
-return mapping.findForward("default");
+return mapping.findForward(RhnHelper.DEFAULT_FORWARD);
}
}
--
1.7.7
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 29.5.2012 17:35, Johannes Renner wrote: . Not sure if I solved your quiz though, Yes, you did :) So here is the latest version of the patches. Committed (with some white space and check style fixes). Thanks for contribution. Mirek ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 05/16/2012 01:33 PM, Johannes Renner wrote:
http://downloads.sourceforge.net/simple/%{name}-%{version}.zip
Thanks, I didn't know that. Changed it in our specfile as well.
Regards,
Johannes
We don't do it that way all the time, because sometimes we use bznew and
convert upstreams tar.gz to tar.bz2, and then the url does not make sense.
Duncan
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 21.5.2012 15:29, Uwe Gansert wrote: The vmdk image (that we already support) is a complete virtual harddisk that contains the image and can be booted directly by kvm. Aha, I just find that too. It is not intuitive IMHO. But OK. Mirek ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 05/21/2012 02:17 PM, Miroslav Suchý wrote: > On 05/18/2012 05:11 PM, Miroslav Suchy wrote: >> >> I still have to test the client part. > > in spec: > Requires: python-curl > > In Fedora/RHEL the package is called python-pycurl, please fix it using %if No problem. > After image is scheduled, you land on: > /rhn/systems/details/virtualization/VirtualGuestsList.do > I would prefer to stay on: > /rhn/systems/details/virtualization/Images.do Oh sure, I agree with you, would prefer that as well. > Beside that I do not see another problem. > So please fix that and I will be happy to commit those patches. Sounds good, I will fix all the things you mentioned, and will then send a new version of the patches these days. Thank you, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 21.05.2012 14:15, Miroslav Suchý wrote: Any problem with DiskImage? Can you add it to list of valid Images? hm, it's not so easy to add and I'm not sure if you really want that. The "disk image"-type in Studio is an image type that boots, formats a harddisk and then dumps itself onto the hard disk. The hard disk is not part of the image and must be provided by the user. You can use that image type to boot on a real physical machine with a USB Stick for example. Then the hard disk of the physical machine is formatted and the image is dumped onto it. It's not really for virtual machines - even though it can be used there too. The vmdk image (that we already support) is a complete virtual harddisk that contains the image and can be booted directly by kvm. maybe you want a different format? like qcow2? Then you have to convert the vmdk file to qcow2 because Studio can not build qcow2 images :/ -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 05/18/2012 05:11 PM, Miroslav Suchy wrote: I still have to test the client part. in spec: Requires: python-curl In Fedora/RHEL the package is called python-pycurl, please fix it using %if After image is scheduled, you land on: /rhn/systems/details/virtualization/VirtualGuestsList.do I would prefer to stay on: /rhn/systems/details/virtualization/Images.do Beside that I do not see another problem. So please fix that and I will be happy to commit those patches. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 05/21/2012 01:45 PM, Uwe Gansert wrote:
On 21.05.2012 13:19, Miroslav Suchý wrote:
the reason we only support kvm and xen images
Ehm, how do you support KVM?
I anticipate that for KVM is supposed DiskImage format. But it does not
show up in Spacewalk WebUI, although it is created in SuseStudio.
with the vmware/virtualbox/kvm (vmdk) image
You should see the vmdk image in the webui
we support vmdk and xen so far
Aha I see:
+// List of all valid image types
+private static List validImageTypes = Arrays.asList("vmx",
"xen");
Any problem with DiskImage? Can you add it to list of valid Images?
--
Miroslav Suchy
Red Hat Satellite Engineering
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 21.05.2012 13:19, Miroslav Suchý wrote: the reason we only support kvm and xen images Ehm, how do you support KVM? I anticipate that for KVM is supposed DiskImage format. But it does not show up in Spacewalk WebUI, although it is created in SuseStudio. with the vmware/virtualbox/kvm (vmdk) image You should see the vmdk image in the webui we support vmdk and xen so far -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 05/21/2012 10:35 AM, Uwe Gansert wrote: the reason we only support kvm and xen images Ehm, how do you support KVM? I anticipate that for KVM is supposed DiskImage format. But it does not show up in Spacewalk WebUI, although it is created in SuseStudio. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 05/18/2012 05:11 PM, Miroslav Suchy wrote: > In WebUI patch please do s/SUSE Manager/@@PRODUCT_NAME@@/ Sure, I will do that for the next version of the patches. Sorry for that. > When I enter credentials for Suse studio they are not validated. Can you > later add some code to do > some validation? I.e. do tome test connection and warn if it do not work? Yes, I already planned to add a button for testing the credentials later on. Probably not for this first release we are doing now, though. > I still have to test the client part. Thanks for the feedback so far. We will wait until you tested the client part, since you might come up with more feedback. -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 18.05.2012 17:11, Miroslav Suchy wrote: Why default format (DiskFormat) does not show up in list of images. I can see XEN, VMX in list, but not DiskFormat (which is probably usefull for KVM). Additionally I could not see Preloaded ISO and OVF image. Is it filtered out on purposse. the reason we only support kvm and xen images at the moment is that we did test the other formats yet but we wanted to deliver the feature, to see how customers use it. So there is no technical reason for not supporting the other formats at the moment and the feature will be enhanced later. Why is there specified proxy? Could not we use default proxy specified in /etc/sysconfig/rhn/up2date ? Or simply use Spacewalk proxy if existed? you can use every http proxy of course and libcurl will use the one from the environment variables of the system. But we talked to our consultants and they recommended to add a proxy setting just for this special case because it often happens that the clients can not reach the internet at all on purpose - not even over a proxy. The admin might want to configure an exception for the SUSE Studio case. So the proxy settings in that UI are for the special case where the clients are cut off from the internet but should be able to reach susestudio.com for the images - like I said, consulting suggestion :) In the very beginning we had designed the feature in a way that the Spacewalk/SUSE Manager Server was downloading all the images and the clients then fetched them from there. But we changed our mind later and except for the proxy thing, the design is better like it is now. -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
In WebUI patch please do s/SUSE Manager/@@PRODUCT_NAME@@/ When I enter credentials for Suse studio they are not validated. Can you later add some code to do some validation? I.e. do tome test connection and warn if it do not work? Why default format (DiskFormat) does not show up in list of images. I can see XEN, VMX in list, but not DiskFormat (which is probably usefull for KVM). Additionally I could not see Preloaded ISO and OVF image. Is it filtered out on purposse. Why is there specified proxy? Could not we use default proxy specified in /etc/sysconfig/rhn/up2date ? Or simply use Spacewalk proxy if existed? I still have to test the client part. Mirek ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 18.5.2012 16:01, Johannes Renner wrote: Oh yeah, sorry, I forgot to revise the upgrade files. I can come up with another patch fixing that, or maybe rather with a new version of 0001. New version of 0001. But hold on, I will send another issues to fix, so you can fix it in one bunch. But in which way it differs from clean install in this case? I wanted to leave it to you as easy quiz. :) I will give you hint: foreign key to table suseCredentialsType. Also at what index those files should start, looks like you are currently at 0047-rhnOrgQuota.sql? Nothing should happen when there are two same number if those files does not depends/conflicts each other. We are keeping it unique just for pure sanity. You can choose whatever number you want. I would choose 60 or even 100 and you have big buffer in case the commit will take some time. BTW: I succefully built simply-xml and susestudio-java-client in spacewalk koji. So this is not blocker for this patch anymore. Mirek ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 05/18/2012 02:45 PM, Miroslav Suchy wrote: > In patch 0001 - schema db - you are missing upgrades for table > suseCredentialsType. > > And upgrades for table suseCredentials differs from clean install. Oh yeah, sorry, I forgot to revise the upgrade files. I can come up with another patch fixing that, or maybe rather with a new version of 0001. But in which way it differs from clean install in this case? Also at what index those files should start, looks like you are currently at 0047-rhnOrgQuota.sql? Regards, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
In patch 0001 - schema db - you are missing upgrades for table suseCredentialsType. And upgrades for table suseCredentials differs from clean install. Mirek ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 16.5.2012 13:33, Johannes Renner wrote:
Good, let me see how that looks like and I will change add it to our package as
well.
--- simple-xml.spec.orig2012-05-16 16:36:42.0 +0200
+++ simple-xml.spec 2012-05-16 15:20:19.0 +0200
@@ -21,8 +21,13 @@
Summary:An XML serialization framework for Java
Version:2.6.3
Release:0
+%if 0%{?suse_version}
License:Apache-2.0
Group: Development/Libraries/Java
+%else
+License:ASL 2.0
+Group: Development/Libraries
+%endif
Url:http://simple.sourceforge.net
Source0:
http://downloads.sourceforge.net/simple/%{name}-%{version}.zip
BuildRoot: %{_tmppath}/%{name}-%{version}-build
@@ -40,9 +45,14 @@
of XML configuration and communication systems.
%packagejavadoc
+%if 0%{?suse_version}
License:Apache-2.0
-Summary:Javadocs for Simple XML Serialization Framework
Group: Development/Languages/Java
+%else
+License:ASL 2.0
+Group: Documentation
+%endif
+Summary:Javadocs for Simple XML Serialization Framework
%descriptionjavadoc
Simple is a high performance XML serialization and configuration
framework for
Mirek
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 05/16/2012 12:49 PM, Miroslav Suchy wrote:
> On 16.5.2012 11:01, Johannes Renner wrote:
>> I guess we could have some "%if (0%?rhel/?suse_version) %else ..." though,
>> if you prefer that.
>
> Ok, I will put there %if and for license as well.
Good, let me see how that looks like and I will change add it to our package as
well.
>>> > simple-xml.src: W: invalid-url Source0: simple-xml-2.6.2.zip
>> Fixed that and put a URL. Not a valid one though, since download URLs are
>> dynamically generated
>> for this project that is hosted on sourceforge.
>
> http://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.net
>
> In this case valid url is:
> http://downloads.sourceforge.net/simple/simple-xml-2.6.3.zip
>
> so in spec should be:
>
> http://downloads.sourceforge.net/simple/%{name}-%{version}.zip
Thanks, I didn't know that. Changed it in our specfile as well.
Regards,
Johannes
--
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 16.5.2012 11:01, Johannes Renner wrote:
I guess we could have some "%if (0%?rhel/?suse_version) %else ..." though, if
you prefer that.
Ok, I will put there %if and for license as well.
> simple-xml.src: W: invalid-url Source0: simple-xml-2.6.2.zip
Fixed that and put a URL. Not a valid one though, since download URLs are
dynamically generated
for this project that is hosted on sourceforge.
http://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.net
In this case valid url is:
http://downloads.sourceforge.net/simple/simple-xml-2.6.3.zip
so in spec should be:
http://downloads.sourceforge.net/simple/%{name}-%{version}.zip
Mirek
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 05/15/2012 09:29 PM, Miroslav Suchy wrote: > On 15.5.2012 14:28, Johannes Renner wrote: >> On 05/15/2012 01:25 PM, Miroslav Suchy wrote: >>> +Requires: susestudio-java-client >>> >>> This will require susestudio-java-client rpm? It is not present in neither >>> in Fedora nor in >>> jpackage. >>> Can I take: >>> >>> https://build.opensuse.org/package/view_file?file=susestudio-java-client.spec&package=susestudio-java-client&project=Java%3Abase&rev=3acd29dcce3b7fe9fad7c42e11358e75 >>> >>> >>> or you have some recent spec? >> >> I just checked it again: yes, please take it from there. This is the most >> recent specfile >> and sources. In case you don't have the other required package in Fedora or >> jpackage >> (simple-xml), you can get it from here as well: >> >> https://build.opensuse.org/package/show?package=simple-xml&project=Java%3Abase >> >> Thanks, >> Johannes >> > > OK, I started with simple-xml. It sucessfully build on all supported > platforms. Thats good. > > Can you fix these warnings and errors of rpmlint: Ok, I committed some changes to the spec, please see my comments below + the changes itself: https://build.opensuse.org/package/rdiff?linkrev=base&package=simple-xml&project=Java%3Abase&rev=3 > simple-xml.src: E: description-line-too-long C Simple is a high performance > XML serialization and > configuration framework for Java. I shortened the description lines to < 79 characters. > simple-xml.src: W: non-standard-group Development/Libraries/Java Please assign whatever group is valid for Fedora/RedHat, since "Development/Libraries/Java" is just the right group to be used for SUSE. I guess we could have some "%if (0%?rhel/?suse_version) %else ..." though, if you prefer that. > simple-xml.src: E: no-changelogname-tag > this one can be ignored as first build with tito will fix it. Good, since we usually maintain those changelogs in separate .changes files. > simple-xml.src: W: invalid-license Apache-2.0 Same as above: please edit it and set the Fedora equivalent for your needs. If I change it, OBS will print a warning, since Apache-2.0 is the correct license string for SUSE. According to http://fedoraproject.org/wiki/Licensing you might have to put "ASL 2.0". > simple-xml.src:53: W: setup-not-quiet No idea about that one, OBS doesn't print that warning. I added -q to %setup, HTH. > simple-xml.src: W: invalid-url Source0: simple-xml-2.6.2.zip Fixed that and put a URL. Not a valid one though, since download URLs are dynamically generated for this project that is hosted on sourceforge. > And I see that upstream has new version: 2.6.3. Can you rebase to it? Is just > version bump > sufficient or spec needs more changes? The new version seems to build just fine, so I rebased the package. Thank you, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 15.5.2012 14:28, Johannes Renner wrote: On 05/15/2012 01:25 PM, Miroslav Suchy wrote: +Requires: susestudio-java-client This will require susestudio-java-client rpm? It is not present in neither in Fedora nor in jpackage. Can I take: https://build.opensuse.org/package/view_file?file=susestudio-java-client.spec&package=susestudio-java-client&project=Java%3Abase&rev=3acd29dcce3b7fe9fad7c42e11358e75 or you have some recent spec? I just checked it again: yes, please take it from there. This is the most recent specfile and sources. In case you don't have the other required package in Fedora or jpackage (simple-xml), you can get it from here as well: https://build.opensuse.org/package/show?package=simple-xml&project=Java%3Abase Thanks, Johannes OK, I started with simple-xml. It sucessfully build on all supported platforms. Thats good. Can you fix these warnings and errors of rpmlint: simple-xml.src: E: description-line-too-long C Simple is a high performance XML serialization and configuration framework for Java. simple-xml.src: W: non-standard-group Development/Libraries/Java simple-xml.src: E: no-changelogname-tag this one can be ignored as first build with tito will fix it. simple-xml.src: W: invalid-license Apache-2.0 simple-xml.src:53: W: setup-not-quiet simple-xml.src: W: invalid-url Source0: simple-xml-2.6.2.zip And I see that upstream has new version: 2.6.3. Can you rebase to it? Is just version bump sufficient or spec needs more changes? ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 05/15/2012 01:25 PM, Miroslav Suchy wrote: > +Requires: susestudio-java-client > > This will require susestudio-java-client rpm? It is not present in neither in > Fedora nor in jpackage. > Can I take: > > https://build.opensuse.org/package/view_file?file=susestudio-java-client.spec&package=susestudio-java-client&project=Java%3Abase&rev=3acd29dcce3b7fe9fad7c42e11358e75 > > or you have some recent spec? I just checked it again: yes, please take it from there. This is the most recent specfile and sources. In case you don't have the other required package in Fedora or jpackage (simple-xml), you can get it from here as well: https://build.opensuse.org/package/show?package=simple-xml&project=Java%3Abase Thanks, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 15.05.2012 13:25, Miroslav Suchy wrote: The Python code was revised by Uwe, see patch 0002 and 0003. print filePath ^^ This probably omitted from some debugging. you are right of course. That line slipped in accidently from a debugging session and can be removed. -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 15.5.2012 11:39, Johannes Renner wrote: Hi Miroslav, attached please find a new version of our patches. We considered most of your advices, see my comments below and the patches itself, of course. Hi, I spent just 10 minutes on preliminary review. Please give me few days for complete review. However I have few question, see inline: We normalized the credentials type, see patch 0001. The image type is not passed as a parameter to the deployment action anymore, so we currently do not need another table. Looks good to me. The Python code was revised by Uwe, see patch 0002 and 0003. print filePath ^^ This probably omitted from some debugging. +private static final long serialVersionUID = 1438261396065921002L; I do not see it used anywhere in code. Does it have some sense? Per convention/best practice, serializable classes usually define a serial version UID. I usually generate it, otherwise my IDE prints a warning. It can be discussed though if it makes sense, since these IDs actually need to be maintained over time. That means, if the code of a class changes somehow, a new UID needs to be generated. Otherwise, objects of the 'old' type will be assumed to be compatible with the 'new' class when deserializing. The problem is that most developers do not maintain their serial version UIDs, and in this case the whole mechanism makes no sense anymore. But personally, I try to maintain them ;-) Aha, did not know that. I'm not fluent in Java. Seems legit then. +Requires: susestudio-java-client This will require susestudio-java-client rpm? It is not present in neither in Fedora nor in jpackage. Can I take: https://build.opensuse.org/package/view_file?file=susestudio-java-client.spec&package=susestudio-java-client&project=Java%3Abase&rev=3acd29dcce3b7fe9fad7c42e11358e75 or you have some recent spec? Mirek ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 04/13/2012 10:24 AM, Uwe Gansert wrote:
+def _md5(path):
Could not you flip to sha1 or sha256?:
I know that md5 is not state of the are anymore but we need to use that
because Studio provides the checksum in md5.
We should change that in Studio but for now it's like that.
OK. I expected something like, that. It seems fair.
+# this is not nice but tarfile.py does not support
+# sparse file writing :(
I did not test it but:
http://docs.python.org/library/tarfile.html
say:
The GNU tar format (GNU_FORMAT). It supports long filenames and
linknames, files bigger than 8 gigabytes and sparse files. It is the de
facto standard on GNU/Linux systems. tarfile fully supports the GNU tar
extensions for long names, sparse file support is read-only.
the last three words are the problem.
read-only for sparse files :/
Aha :)
+%dir %{rhn_conf_dir}
This is not needed. This directory is already owned by rhn-client-tools,
which are required by rhn-virtualization-common
it's needed for our build service or our BS will cry about "directory
not owned by any package" after building. Unless I add a package to the
BUILDREQUIRES that owns that directoy already - but it would be bad to
change the BUILDREQUIRES just for that.
I can remove that %dir for Red Hat in the spec file but not for SUSE
Yes, please use:
%if 0%{?suse_version} ...
for that.
--
Miroslav Suchy
Red Hat Satellite Engineering
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 05.04.2012 12:18, Miroslav Suchý wrote:
+sys.path.append("/usr/share/rhn/")
I'm sure one append is enough.
hehe ;) probably yes
+def _md5(path):
Could not you flip to sha1 or sha256?:
I know that md5 is not state of the are anymore but we need to use that
because Studio provides the checksum in md5.
We should change that in Studio but for now it's like that.
+import hashlib
You should put in Requires python-hashlib then.
hm, okay but not on SUSE. It's in python-base on SLES.
On Red Hat that might be true, I'll fix that in the spec file for Red Hat.
+c = pycurl.Curl()
Why not use directly
from urlgrabber.grabber import URLGrabber
which will shield you from internals?
actually I like pycurl. I'll look at URLGrabber again but IIRC I had
problems with it. I just don't remember what it was.
I'm not sure if I'd like to change that.
+# this is not nice but tarfile.py does not support
+# sparse file writing :(
I did not test it but:
http://docs.python.org/library/tarfile.html
say:
The GNU tar format (GNU_FORMAT). It supports long filenames and
linknames, files bigger than 8 gigabytes and sparse files. It is the de
facto standard on GNU/Linux systems. tarfile fully supports the GNU tar
extensions for long names, sparse file support is read-only.
the last three words are the problem.
read-only for sparse files :/
I'd prefer to use a module too but there is no way as far as I can see
+%dir %{rhn_conf_dir}
This is not needed. This directory is already owned by rhn-client-tools,
which are required by rhn-virtualization-common
it's needed for our build service or our BS will cry about "directory
not owned by any package" after building. Unless I add a package to the
BUILDREQUIRES that owns that directoy already - but it would be bad to
change the BUILDREQUIRES just for that.
I can remove that %dir for Red Hat in the spec file but not for SUSE
All I did not mention/comment above will probably be changed to your
suggestion. Thanks for the feedback.
--
ciao, Uwe Gansert
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 04/05/2012 02:00 PM, Miroslav Suchý wrote: > On 03/30/2012 04:46 PM, Johannes Renner wrote: >> Oh yes, there is two new required jar files, while RPM packages + spec files >> can be >> found here: >> >> -https://build.opensuse.org/package/show?package=susestudio-java-client&project=Java%3Abase >> -https://build.opensuse.org/package/show?package=simple-xml&project=Java%3Abase >> >> The reason why susestudio-java-client currently requires simple-xml is that >> it is >> supposed to run on Android as well, where javax.xml.* classes are not >> available. > > I see no problem with these two. They cleanly build on my Fedora. Once you > clean up issues with your > patch I can import them to our koji. Sounds good. We will work on cleaning up those issues following your recommendations and then come back with the new set of patches. Thanks for your review, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 03/30/2012 04:46 PM, Johannes Renner wrote: Oh yes, there is two new required jar files, while RPM packages + spec files can be found here: -https://build.opensuse.org/package/show?package=susestudio-java-client&project=Java%3Abase -https://build.opensuse.org/package/show?package=simple-xml&project=Java%3Abase The reason why susestudio-java-client currently requires simple-xml is that it is supposed to run on Android as well, where javax.xml.* classes are not available. I see no problem with these two. They cleanly build on my Fedora. Once you clean up issues with your patch I can import them to our koji. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 03/30/2012 04:46 PM, Johannes Renner wrote:
On 03/27/2012 02:53 PM, Miroslav Suchý wrote:
I'm looking forward to see your patches.
Ok, here they are. They apply to spacewalk master and I tried to not forget
anything.
The last patch is about fixing checkstyle issues only, while the other ones are
about
patching the respective parts of Spacewalk, not very intrusive though.
Oh yes, there is two new required jar files, while RPM packages + spec files
can be
found here:
-
https://build.opensuse.org/package/show?package=susestudio-java-client&project=Java%3Abase
- https://build.opensuse.org/package/show?package=simple-xml&project=Java%3Abase
The reason why susestudio-java-client currently requires simple-xml is that it
is
supposed to run on Android as well, where javax.xml.* classes are not available.
+CREATE TABLE suseCredentials
...
+type VARCHAR2(32) NOT NULL,
+CREATE TABLE rhnActionImageDeploy
...
+image_typeVARCHAR2(32) NOT NULL,
Hmm, can we normalize those table. I suppose that type is something
enumarated. In such case I would put those values in separate table and
here put just reference.
+bridge_device VARCHAR2(32) DEFAULT('br0') NOT NULL,
Really not null? I'm sure I had some virtual machines without network.
+url = row['download_url']
+proxy_server = row['proxy_server']
+proxy_user= row['proxy_user']
+proxy_pass= row['proxy_pass']
+mem_kb= row['mem_kb']
+vcpus = row['vcpus']
+bridge_device = row['bridge_device']
+
+if row['image_type'] == 'vmx':
+image_type = 'vmdk'
+elif row['image_type'] == 'xen':
+image_type = 'xen'
+else:
+raise InvalidAction("image.deploy: invalid image_type")
+
+
+return (url, proxy_server, proxy_user, proxy_pass, mem_kb, vcpus,
image_type, bridge_device)
That assigment is overkill. Can you just:
return (row['download_url'] ...)
you will save 6 lines. But this is really no blocker. :)
+++ b/backend/server/action_extra_data/image.py
...
+def deploy(server_id, action_id, data={}):
+if not data:
+return
+log_error("action_error.image.deploy: Should do something "
+"useful with this data", server_id, action_id, data)
log_error? really?
That would couse traceback IIRC. if you do not know what to do with
returned data just call pass or log_debug.
+++ b/client/tools/rhn-virtualization/actions/image.py
...
+sys.path.append("/usr/share/rhn/")
+import virtualization.support as virt_support
+from virtualization.util import hyphenize_uuid
+
+sys.path.append("/usr/share/rhn/")
I'm sure one append is enough.
+IMAGE_BASE_PATH = "/var/lib/libvirt/images/"
+STUDIO_KVM_TEMPLATE = "/etc/sysconfig/rhn/studio-kvm-template.xml"
+STUDIO_XEN_TEMPLATE = "/etc/sysconfig/rhn/studio-xen-template.xml"
Can this be defined in config file? That would be awesome.
+if os.path.isfile(STUDIO_KVM_TEMPLATE):
+f = open(STUDIO_KVM_TEMPLATE, 'r')
+KVM_CREATE_TEMPLATE = f.read()
+f.close()
+
+if os.path.isfile(STUDIO_XEN_TEMPLATE):
+f = open(STUDIO_XEN_TEMPLATE, 'r')
+XEN_CREATE_TEMPLATE = f.read()
+f.close()
Duplicate code. I would prefer to create function which read content of
file.
+def deploy(downloadURL, proxyURL="", proxyUser="", proxyPass="",
memKB=524288, vCPUs=1, imageType="vmdk", virtBridge="xenbr0",
extraParams="",cache_only=None):
I would try to persuade you to not pass every single attribute as
specific attribute of this function.
We had several problems with that in past.
The problem is that if you would pass another attribute (e.g storage
location) next year, you could not do that easily.
Because if you pass this action with additional storage_location
attribute (even if it will be set to "") to client which could not
handle it, than it will traceback. So you will have to use and check
capabilities (which is PITA).
If you pass these values as dictionary, you will save yourself lots of
problems in future.
Additionally you do not use attribute cache_only at all. That is bad.
If cache_only is true you should not execute this action and you just
prepare this action. I.e. action packages.install will download packages
to /var/cache/yum so when the action is really executed, then those rpm
are already downloaded and the action is executed faster.
If you do not want to implement or it does not make sense for you, then
just put at the top of this function:
if cache_only:
return (0, "no-ops for caching", {})
Although as I can see, in your case you can take advance from this
framework and put this if before:
+# image exists in /var/lib/libvirt/images/image-name now
which means after:
_getImage(fileName,downloadURL,proxySettings)
if it needs to be called.
+def _md5(path):
Could not you flip to sha1 or sha256?:
https://www.google.cz/search?q=md5%20not%20safe&hl=cs&lr=
I know we use md5 on several places, but new things should not start
with m
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 03/27/2012 01:42 PM, Johannes Renner wrote: As I have written in my first mail: We would be willing to commit this feature upstream, but I am actually doubting that you will just take the commits and push them into master. You assume it correctly. I (and no one from Spacewalk team) is going to blindly apply patches you will send. It can be applied flawlessly if there is no problem (historicaly we done that with Audit Review feature contributed by Joshua Roys). But we can start discussing about that code. And rejection of some code is possible - we done that in past as well. But generally rejection is not so common. I could not anticipate it, when I did not seen that code of yours yet. Reasons may include: - The whole feature is very SUSE specific (integration of a SUSE product) So what? We had bunch of very Debian specific changes too. Originaly Spacewalk managed Fedoras and RHELs. Your team made very good effort for supporting SLEs and OpenSUSEs. If you make KIWI working, then good. I would be happy to see contribution of ncc-sync too, despite the fact that it is SUSE specific too. Personally I would be happy even if somebody will contribute with feature for managing Windows. The possibilities are open for everybody. - There is a new dependency on a library for talking to the API Client or Server? If it is for Server, you must be sure that the new dependency can be installed on all officially supported OS. Currently Spacewalk Server can be installed on Fedora 15, 16 and RHEL 5 and 6. BTW: If you provide environment and set up processes to build Spacewalk Server on SLE, then SLE can be officially supported as well. But you must be proactive about that. - There is a new table for storing a user's API credentials (suseXYZ namespace) I have no problem with new table(s). Of course, when you are doing changes in those tables, you must provide upgrade scripts. I can prepare and send patches if you are fine with such things. I just need to make sure that there is some interest and that these patches will not be rejected after I put in the work to make them apply to Spacewalk master. We like new features. But we care even more about sustainability of the code. If you will address issues raised by Spacewalk developers (either by fixing code or convince us that your code is in fact correct) and your code is either very small or you make promise that you will maintain that code (historically e.g. spacecmd), then we will accept it. But we are not going to beg for the code. We can live without it. The motivation for contributing to upstream is that it will make diff between upstream and your private branch smaller, which will make *your* life easier. I'm looking forward to see your patches. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 03/27/2012 11:35 AM, Miroslav Suchý wrote: > On 03/27/2012 10:27 AM, Johannes Renner wrote: >> The feature involves a new action type to be put in table rhnActionType, >> which >> we chose to give the ID 500 for now (just to make sure there will be no >> clash in >> the near future). Would you maybe want to provide us with an ID for this >> action >> that we can safely use throughout the future or what is the preferred >> procedure >> here? > > We are not going to assign ID for action which is not in our master. Thanks for the clarification. > If you ever decide to contribute your work to Spacewalk project, you can take > advantage to have it > in upstream and no one will override that id. > If you decide - for whatever reason - to keep it private, you will have to > live with the fear and > uncertainty that one day we will use that id for something else. As I have written in my first mail: We would be willing to commit this feature upstream, but I am actually doubting that you will just take the commits and push them into master. Reasons may include: - The whole feature is very SUSE specific (integration of a SUSE product) - There is a new dependency on a library for talking to the API - There is a new table for storing a user's API credentials (suseXYZ namespace) I can prepare and send patches if you are fine with such things. I just need to make sure that there is some interest and that these patches will not be rejected after I put in the work to make them apply to Spacewalk master. Thank you, Johannes -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
On 03/27/2012 10:27 AM, Johannes Renner wrote: The feature involves a new action type to be put in table rhnActionType, which we chose to give the ID 500 for now (just to make sure there will be no clash in the near future). Would you maybe want to provide us with an ID for this action that we can safely use throughout the future or what is the preferred procedure here? We are not going to assign ID for action which is not in our master. If you ever decide to contribute your work to Spacewalk project, you can take advantage to have it in upstream and no one will override that id. If you decide - for whatever reason - to keep it private, you will have to live with the fear and uncertainty that one day we will use that id for something else. -- Miroslav Suchy Red Hat Satellite Engineering ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Deployment of images built with SUSE Studio
Hi Johannes. > We recently added a feature to our branch of Spacewalk that enables users to > deploy images that were built with SUSE Studio [1] to registered virtual host > systems. Will this feature be committed to the upstream or will it only be available in the SUSE branch? Bye, Christian. -- Christian Berendt Solution Architect Mail: bere...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
[Spacewalk-devel] Deployment of images built with SUSE Studio
Hello, We recently added a feature to our branch of Spacewalk that enables users to deploy images that were built with SUSE Studio [1] to registered virtual host systems. The feature involves a new action type to be put in table rhnActionType, which we chose to give the ID 500 for now (just to make sure there will be no clash in the near future). Would you maybe want to provide us with an ID for this action that we can safely use throughout the future or what is the preferred procedure here? Some info about the feature itself: Basically there is a new subtab to the virtualization tab on a specific system for listing a user's images and scheduling image deployments based on the list of images. Further there is another simple UI for entering a user's credentials for querying the Studio API. If you are interested in this feature I will be happy to prepare patches for spacewalk master, just tell me. Thank you, Johannes [1] http://susestudio.com -- SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
